What’s the issue?
SQL Server allows user-defined server roles, created with CREATE SERVER ROLE, so that instance-level permissions can be bundled and assigned to groups of logins. They provide a flexible alternative to the fixed server roles, letting a team define exactly the set of permissions a given responsibility requires.
Because the permissions in a user-defined role are chosen freely, a role can be built that grants far more authority than intended. Any login added to that role inherits the full set of permissions without the grant appearing in the login’s own permission list.
This check identifies user-defined server roles holding one or more of the following permissions: CONTROL SERVER, ALTER ANY LOGIN, IMPERSONATE ANY LOGIN, ALTER ANY SERVER ROLE, ALTER ANY CREDENTIAL, ALTER ANY LINKED SERVER, and ALTER SETTINGS.
Why is this a problem?
Each of these permissions provides a path to elevated privilege. CONTROL SERVER and IMPERSONATE ANY LOGIN are directly equivalent to sysadmin in practice. ALTER ANY LOGIN allows a member to reset the password of any SQL login, including one in sysadmin, and then connect as it. ALTER ANY SERVER ROLE allows a member to add themselves or others to any server role, including sysadmin.
The remaining permissions provide indirect but reliable paths. ALTER ANY CREDENTIAL allows a member to change the account behind a credential, which redirects any SQL Agent proxy using it. ALTER ANY LINKED SERVER allows a member to define a linked server with a privileged remote credential. ALTER SETTINGS allows a member to change instance configuration, including options that expand surface area.
Membership in these roles is also easier to overlook than direct grants. Reviews that examine permissions granted to individual logins will not surface authority inherited through a user-defined role, so a login can hold sysadmin-equivalent access while appearing to hold almost nothing.
What should you do about this?
Find user-defined server roles and their permissions by querying sys.server_principals for principals of type R where is_fixed_role = 0, joined to sys.server_permissions. Capture the members of each affected role from sys.server_role_members so you know who currently holds the inherited authority.
Review each role with the team that created it to confirm the permission set matches the actual responsibility it was meant to support. In most cases the elevated permissions can be narrowed considerably, or replaced with grants scoped to specific logins, databases, or objects rather than instance-wide equivalents.
Revoke the unnecessary permissions from the role rather than removing members, since the role definition is the underlying issue. Document the approved permission set and membership for each remaining role.