What’s the issue?
The securityadmin fixed server role in SQL Server grants its members the ability to manage logins and their properties at the instance level. Members can create, alter, and drop logins, reset passwords for SQL logins, and grant, deny, or revoke server level permissions to other principals. The role exists to allow security administration to be delegated without granting the full power of the sysadmin role.This finding identifies the logins currently included in the securityadmin role on a SQL Server instance. The intent of the review is to confirm that only approved accounts have this level of access and to remove any that do not require it.
Why is this a problem?
Despite being framed as a delegated security administration role, securityadmin is effectively equivalent to sysadmin in terms of the access it can grant to itself or others. A member of securityadmin can create a new login and grant that login the CONTROL SERVER permission, which is functionally equivalent to sysadmin and bypasses essentially all SQL Server permission checks.A securityadmin member can also reset the password of any SQL login, including logins that already have sysadmin or other elevated privileges, then connect as that login and inherit its full permissions. This means anyone in securityadmin can promote themselves to full instance control through a path that does not require any cooperation or approval from existing sysadmins.
The implications are the same as if the account were a member of sysadmin directly: they can read, modify, or drop any object in any database, take and restore backups (a path to data exfiltration), change audit configuration, enable features such as xp_cmdshell, and use linked servers to reach other instances. The only difference is that the path to that level of control is one extra step, which provides essentially no real security benefit.
What should you do about this?
Evaluate the current members of the securityadmin role by querying sys.server_principals joined to sys.server_role_members, filtering for the securityadmin role. Capture the membership and review each entry with the security team and the SQL Server owners.Confirm that every member belongs in the role based on a current, documented job role and a clear understanding that the membership is effectively equivalent to sysadmin. Remove accounts that do not require this level of access and grant them more granular permissions instead.
Specific tasks that are sometimes assumed to require securityadmin can often be accomplished with narrower permissions: password resets for individual application logins can be handled through stored procedures with EXECUTE AS and signed permissions, and routine login creation can be delegated through similar wrapper procedures.