What’s the issue?
IMPERSONATE ANY LOGIN is a server-level permission introduced in SQL Server 2014 that allows a login to execute in the security context of any other login on the instance. It is granted with GRANT IMPERSONATE ANY LOGIN TO [LoginName]; and is exercised through EXECUTE AS LOGIN = '<TargetLogin>'.
The permission was added to support middle-tier application scenarios, where a process needs to impersonate the accounts of the clients connecting through it, without requiring individual IMPERSONATE grants for each target login.
This finding identifies logins that hold IMPERSONATE ANY LOGIN, detected by querying sys.server_permissions joined to sys.server_principals for the permission in a granted state.
Why is this a problem?
At least one login has the IMPERSONATE ANY LOGIN permission, which lets it execute as any other login including members of the sysadmin role. The escalation path is immediate: the holder impersonates a sysadmin login and operates with full instance authority for the duration of the impersonated session.
This makes the permission functionally equivalent to sysadmin for practical purposes, in the same way that securityadmin membership and CONTROL SERVER are. Any review that examines only the sysadmin role while ignoring this permission leaves a significant gap in coverage.
The permission is also harder to spot than role membership. It appears in the server permissions catalog rather than in the familiar role member views, so it can persist unnoticed and provides an attractive way for an attacker or malicious insider to retain elevated access without appearing in the standard list of sysadmins.
What should you do about this?
Review any logins and groups with IMPERSONATE ANY LOGIN to verify they require it. Query sys.server_permissions for the permission and evaluate each holder against a current, documented job role, treating the grant with the same scrutiny you apply to sysadmin membership.
Revoke the permission where it is not required using REVOKE IMPERSONATE ANY LOGIN FROM [LoginName];, and replace it with narrower grants where impersonation is genuinely needed. Individual IMPERSONATE ON LOGIN::[SpecificLogin] grants limit the scope to only the logins actually involved in the use case.
Consider DENY IMPERSONATE ANY LOGIN on high-privilege logins that do not need it, since a DENY takes precedence over any grant inherited through group membership and prevents the permission from being acquired indirectly.