What’s the issue?
SQL Server supports granular server-level permissions that can be granted directly to a login, independent of any fixed or user-defined server role. This allows a team to give a principal exactly the authority it needs without the broader reach that role membership would provide.
Because these grants sit outside the role structure, they are recorded only in the server permissions catalog and do not appear in the role membership views that most reviews rely on. A login can hold significant authority while looking unremarkable in a standard access review.
This check identifies logins granted one or more of the following permissions directly: ALTER ANY LOGIN, IMPERSONATE ANY LOGIN, ALTER ANY SERVER ROLE, ALTER ANY CREDENTIAL, and ALTER ANY LINKED SERVER.
Why is this a problem?
ALTER ANY LOGIN allows the holder to reset the password of any SQL login on the instance, including one that belongs to sysadmin, and then connect as that login with its full authority. IMPERSONATE ANY LOGIN reaches the same outcome more directly, letting the holder execute as any login without changing anything.
ALTER ANY SERVER ROLE allows the holder to add principals to any server role, including sysadmin, which is a single-statement path to full instance control. ALTER ANY CREDENTIAL allows the holder to change the Windows account behind a credential, redirecting any SQL Agent proxy that uses it to run job steps under a different account.
ALTER ANY LINKED SERVER allows the holder to create or modify linked servers, including defining one whose remote credential is a privileged account on another instance. This grants elevated access to a separate system without any approval from the administrators of that system.
What should you do about this?
Identify the affected logins by querying sys.server_permissions joined to sys.server_principals, filtering for these permission names in a granted state. Review each holder against a current, documented job role and treat the grant with the same scrutiny you apply to sysadmin membership.
Revoke permissions that are not required using REVOKE <permission> FROM [LoginName];, and replace them with narrower grants where the underlying need is legitimate. Individual object-level or login-level grants usually cover the actual requirement without the instance-wide reach.
Document the approved holders of each permission, the business justification, and the date of the most recent review.