What's the issue?
CONTROL SERVER is the highest level permission in the SQL Server permission hierarchy, granting its holder full control over the entire instance. The permission was introduced as part of the granular permissions model in SQL Server 2005 and is functionally equivalent to membership in the sysadmin fixed server role, with only minor edge case differences in how certain internal operations are evaluated.
This finding identifies logins that have been granted CONTROL SERVER permission directly, separate from the explicit list of sysadmin role members. 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?
A login with CONTROL SERVER permission has the same effective access as a sysadmin and can perform any action on the instance. They can read, modify, or drop any object in any database, take and restore backups (a path to data exfiltration), change the permissions of every other principal, alter audit configuration, enable features such as xp_cmdshell to execute operating system commands, create or modify SQL Server Agent jobs, and use linked servers to reach other instances.
Despite this equivalence, CONTROL SERVER grants are sometimes treated as a less risky alternative to sysadmin membership, which is a misconception. The two paths produce essentially the same outcome and deserve the same level of scrutiny in audits and reviews.
CONTROL SERVER grants can also be more difficult to spot than sysadmin role members. Sysadmin membership is visible in a single well-known query, while CONTROL SERVER permissions are recorded in the broader server permissions catalog and are easy to miss during a casual security review. This makes them an attractive path for attackers or malicious insiders who want to maintain elevated access without appearing in the standard list of sysadmins, and they can persist undetected longer than direct sysadmin membership.
What should you do about this?
Evaluate the current logins with CONTROL SERVER by querying sys.server_permissions joined to sys.server_principals, filtering for permissions where permission_name = 'CONTROL SERVER' and state = 'G' (granted) or state = 'W' (granted with grant option). Capture the list and review each entry with the security team and the SQL Server owners.
Confirm that every login with this permission belongs there based on a current, documented job role and a clear understanding that the access is equivalent to sysadmin. Remove accounts that do not require this level of access using REVOKE CONTROL SERVER FROM [LoginName]; and grant them more granular permissions instead, scoped to the specific databases, objects, or fixed server roles they actually need.
For accounts that genuinely require full instance control, consider consolidating them into the sysadmin role rather than maintaining a separate set of direct CONTROL SERVER grants. This makes the privileged account list easier to review and audit, since both paths produce equivalent access but a single location for tracking is operationally simpler. Document the rationale either way so future reviews understand the chosen approach.
Vulnerability
Category
What do the Vulnerability Levels mean?
0 - Information only. This is stuff you should know about your instances like version and service account used, but if you don't know it…well, now you do.
1 - High vulnerability requiring action. These are the issues that could most likely lead to your company being front page news for all the wrong reasons. If your instances have any results at this level then we recommend cancelling that 3-martini lunch and instead huddling with your team to figure out when to address these issues.
2 - High vulnerability to review. These include settings and assigned permissions you should review soon, if not immediately. These findings may not necessarily indicate a clear vulnerability, but we've found unexpected vulnerabilities in these categories at many, many clients.
3 - Potential vulnerability to review. These are configurations or assigned permissions you may be using that could lead to problems for users. Or maybe they're just required for your applications. Either way, we recommend reviewing these to make sure these are correct.
4 – Low vulnerability with recommended action. These are typically security inconsistencies that should be addressed. They aren't likely to cause problems, but you should clean up the mess.