What’s the issue?
SQL Server allows database roles to be nested, meaning one database role can be added as a member of another database role. When this happens, every member of the inner role automatically inherits the permissions granted to the outer role, in addition to any permissions the inner role holds directly.
Role nesting is a legitimate security modeling technique used to compose permissions, but it can also obscure the effective access of users by hiding permissions behind chains of role memberships. The flattened set of permissions a user actually has becomes harder to determine without specifically tracing role membership.
This finding identifies databases where one or more database roles is a member of another database role.
Why is this a problem?
Nested roles make it harder to answer the basic security question of who has access to what. A user appears to be in a single role, but that role may inherit permissions from another role, which may inherit from yet another role, producing a chain that must be traced before the effective permissions are clear. Reviewers and auditors often miss permissions granted through the chain, leading to incomplete reviews.
The condition also creates risk during permission changes. Granting a permission to one role can unintentionally extend that permission to users in other roles through the nesting relationship, particularly when the team performing the change is unaware of the existing nesting. The effect can be substantial when the receiving role has many members or when the nesting chain is several layers deep.
Nesting also complicates lifecycle changes. When a role is dropped or modified, every role that had it nested must be reviewed to confirm the change does not break expected access. In environments where roles have accumulated over time, the nesting graph can become tangled enough that no one fully understands the implications of any particular change.
Microsoft’s general guidance is to keep role structures flat where possible, granting permissions directly to roles that correspond to clear application or user functions rather than building hierarchies through nesting. Flat structures are easier to review, easier to change safely, and easier to document, while nested structures should be used sparingly and with clear purpose.
What should you do about this?
Review each nested relationship with the application owners and the team responsible for the database security model. Determine whether the nesting was deliberate, whether it still serves a clear purpose, and whether the same access could be modeled more simply by granting permissions directly to the appropriate roles or users.
For nesting that no longer serves a purpose, remove the role-in-role membership using ALTER ROLE [OuterRoleName] DROP MEMBER [InnerRoleName];. But before doing so, identify which permissions were inherited through the nesting and grant them directly to the inner role or its members where they are still required, so removing the nesting does not break expected access.
For nesting that is genuinely required, document the relationship, the rationale, and the resulting effective permissions. The documentation should make it possible to review the security model without having to retrace the nesting graph each time, which significantly reduces the audit burden and the risk of misunderstanding the configuration.