SQL Server fixed server-level roles are predefined security roles built into every SQL Server instance that grant specific administrative permissions at the server level. There are 9 fixed server-level roles in SQL Server, each designed for a distinct set of administrative tasks. Understanding what each role does, and more importantly what it should NOT be used for, is one of the most practical steps you can take to tighten security across your SQL Server environment.

Why Fixed Server-Level Roles Matter for Security

Misuse of fixed server-level roles is one of the most common security problems we see in SQL Server environments. The pattern is almost always the same: an application needs database access, someone grants it sysadmin or dbcreator because it's quick and easy, and that shortcut stays in place for years. Sometimes it outlasts the application itself.

These roles were designed for delegated administration, not application access. Using them for application-level permissions violates the principle of least privilege and creates real risk. A compromised application account with sysadmin membership doesn't just expose one database - it exposes the entire SQL Server instance, every database on it, every linked server, and potentially the underlying operating system.

Getting this right matters. It's not a theoretical concern.

What Are the 9 SQL Server Fixed Server-Level Roles?

Every SQL Server instance includes the following fixed server-level roles. These cannot be deleted or modified, and their permissions are set by Microsoft.

sysadmin Members can perform any activity on the SQL Server instance. This is the highest level of privilege available. Reserve it strictly for DBAs who need full administrative control. Service accounts and application logins should never be members of this role.

serveradmin Members can configure server-wide settings and shut down the server. This includes changing sp_configure options and executing SHUTDOWN. Useful for operations staff who need to manage server configuration without full sysadmin access.

securityadmin Members can manage logins and their properties, including resetting passwords and granting, denying, or revoking server-level permissions. Be careful here. Microsoft's own documentation notes that securityadmin should be treated as equivalent to sysadmin in practice, because members can grant CONNECT SQL and manage login access in ways that effectively escalate privilege.

processadmin Members can end processes running in SQL Server using KILL. This is useful for operations staff who need to terminate blocking sessions or runaway queries without broader administrative access.

setupadmin Members can add and remove linked servers and execute certain system stored procedures. This role is rarely needed in most environments but exists for scenarios where managing linked server configuration is delegated to a specific team.

bulkadmin Members can execute the BULK INSERT statement. This is one of the more legitimately useful roles for specific application scenarios, particularly ETL processes that load large volumes of data. Even so, consider whether a database-level permission is more appropriate.

diskadmin Members can manage disk files, including adding and removing backup devices. This role is largely a legacy holdover from older SQL Server versions. In modern environments, backup device management is typically handled through sysadmin-level processes or automation tooling.

dbcreator Members can create, alter, restore, and drop any database on the instance. This is commonly misused as a "safe" alternative to sysadmin for applications that need to create databases. It is not safe. A login with dbcreator membership can create databases, restore over existing ones, and drop databases entirely.

public Every login is automatically a member of public. It represents the minimum baseline permissions for any authenticated login. You can grant permissions to public, but doing so grants them to all logins on the instance. Treat public with extreme caution.

How Do You Query Fixed Server-Level Roles in SQL Server?

You can retrieve the full list of server-level permissions using the built-in sys.fn_builtin_permissions function:

SELECT *
FROM sys.fn_builtin_permissions('SERVER')
ORDER BY permission_name;

This returns every permission that can be granted at the server scope. It's a useful reference when you're designing a least-privilege security model or auditing what permissions exist on a server.

To see which logins are members of each fixed server-level role, query the system catalog views directly:

SELECT
    r.name AS RoleName,
    m.name AS MemberName,
    m.type_desc AS MemberType,
    m.is_disabled AS LoginDisabled
FROM sys.server_role_members rm
INNER JOIN sys.server_principals r ON r.principal_id = rm.role_principal_id
INNER JOIN sys.server_principals m ON m.principal_id = rm.member_principal_id
WHERE r.is_fixed_role = 1
ORDER BY r.name, m.name;

Run this query on any SQL Server instance and you'll often find surprises. Service accounts in sysadmin. Old application logins that were never cleaned up. Developer accounts with far more access than they need. This query is a standard part of our security review process at DBA Services.

What Should Fixed Server-Level Roles NOT Be Used For?

This is worth being direct about. Fixed server-level roles should not be used for:

  • Application database access. Applications should use database-level roles (db_datareader, db_datawriter, or custom roles) with permissions scoped to specific objects.
  • Developer access to production. Developers generally don't need any fixed server-level role membership in production environments.
  • Service accounts running application workloads. A service account connecting to a specific database needs database-level permissions, not server-level role membership.
  • Granting broad access because it's convenient. Convenience-based security decisions are where most breaches start.

If an application genuinely requires server-level permissions, document exactly why and review that decision regularly. Most of the time, a properly designed database-level security model eliminates the need entirely.

How Should You Manage Server-Level Role Membership?

A practical approach to managing fixed server-level roles in production:

  1. Audit current membership using the query above. Do this before making any changes.
  2. Identify any logins that shouldn't have the access they currently have. Pay particular attention to sysadmin membership.
  3. Remove unnecessary memberships using ALTER SERVER ROLE. For example: ALTER SERVER ROLE sysadmin DROP MEMBER [domain\username];
  4. Document who has membership in each role and why. If you can't explain why a login needs a particular role, it probably doesn't need it.
  5. Review role membership on a scheduled basis, at minimum quarterly. Staff changes, project completions, and application decommissions all create stale access that accumulates over time.
  6. Use Windows Authentication and Active Directory groups where possible. Managing group membership in AD is generally easier to audit and control than managing individual SQL Server login memberships.

Key Takeaways

  • SQL Server has 9 fixed server-level roles that grant specific administrative permissions at the instance level. They cannot be modified or deleted.
  • These roles are designed for delegated administration, not application access. Using them for application logins is a significant security risk.
  • The securityadmin role should be treated with the same caution as sysadmin because of its ability to effectively escalate privileges.
  • Regular auditing of server-level role membership is essential. Use the sys.server_role_members catalog view to identify who has what access.
  • Least privilege is the correct model. If you can't justify why a login needs a fixed server-level role, remove the membership.

If you're not sure what your current server-level role memberships look like, or whether your SQL Server security model is fit for purpose, DBA Services offers SQL Server health checks that include a thorough security review. We work with organisations across Australia to identify and remediate exactly these kinds of issues before they become incidents. Get in touch to find out more.