What’s the issue?
ALTER SETTINGS is a server-level permission that allows a principal to run sp_configure and RECONFIGURE, changing instance-level configuration options. It is granted with GRANT ALTER SETTINGS TO [LoginName]; and is included implicitly in the serveradmin fixed server role.
The permission exists so that configuration management can be delegated without granting full instance control, which may be a reasonable goal for teams that need to tune memory, parallelism, or similar settings as part of their responsibilities.
Why is this a problem?
One or more logins can change server configuration options without being a sysadmin, and several of those options govern the security surface of the instance. A holder can enable xp_cmdshell, Ole Automation Procedures, Ad Hoc Distributed Queries, clr enabled, or external scripts enabled, each of which opens a path to activity well beyond normal database operations.
The permission also allows changes that affect stability rather than security. Memory limits, worker thread counts, parallelism settings, and priority boost can all be modified, and a careless or malicious change to any of them can degrade performance across the instance or make it unstable.
Configuration changes are also easy to miss. They do not appear in role membership reviews, they generate no alert by default, and the effect of a change may not surface until the next service restart if the option requires one.
What should you do about this?
Identify the affected logins by querying sys.server_permissions for ALTER SETTINGS in a granted state, and review each holder against a current, documented responsibility. Include serveradmin members in the same review, since they hold the permission implicitly.
Revoke the permission where it is not required using REVOKE ALTER SETTINGS FROM [LoginName];. Where configuration changes are a legitimate part of someone’s role, consider handling them through a change management process with sysadmin execution rather than a standing grant.