Disable the sa login in SQL Server (and sleep better)

If you run SQL Server in 2025 and your sa login is still usable, you’re giving attackers a giant, blinking target. The sa account is the most famous login in SQL Server, it has unrestricted power, and—because it’s famous—it’s a magnet for brute-force attempts.

Microsoft’s own guidance is blunt: don’t enable or use sa unless an application truly requires it. Prefer Windows (or Entra ID) authentication and named admin accounts instead.

Below I’ll show why disabling sa is the sane default, what disabling actually does (and doesn’t do), and exact steps to audit usage and turn it off safely—backed by current docs and baselines.

Why disabling sa is a best practice

• It’s an all-powerful, well-known account. The sa login is created by default, is a member of sysadmin, and can’t be limited. You can’t drop it, but you can disable it.

• It’s heavily targeted. Because every SQL Server has (or had) an sa, attackers constantly guess its password. Microsoft explicitly warns not to enable sa unless required and recommends Windows authentication whenever possible.

• It’s a CIS hardening item. The CIS Microsoft SQL Server Benchmarks include controls to disable (and often rename) sa. If you follow CIS, you’ll be expected to do both.

Note: On Azure SQL Database (the PaaS single-database service) there is no server-level sa. On SQL Server (Windows/Linux), Azure SQL Managed Instance, and SQL Server on Azure VMs, sa exists and these recommendations apply. Microsoft’s Azure VM guidance also recommends not enabling sa.

What “disabling sa” actually does

• Blocks new logins by sa.
  ALTER LOGIN [sa] DISABLE stops future connections using sa.

• Does not affect existing sessions (you can KILL them if needed).

• Does not break ownership: disabled logins retain permissions and can still be impersonated internally. That means databases, schemas, or SQL Agent jobs owned by sa keep working.

Before you flip the switch: a quick, safe checklist

1. Make sure you already have a sysadmin you control.
   Use a Windows/Entra group or a named break-glass SQL login with a long, stored-securely password. Any login can be a sysadmin; it doesn’t have to be sa.

2. Find out if anything is still using sa.

   • Turn on login auditing (temporarily capture both successes and failures to the error log).

   • Or use SQL Server Audit to capture SUCCESSFUL_LOGIN_GROUP/FAILED_LOGIN_GROUP and filter on the sa principal.

3. Check common places sa hides in config:

   • Agent jobs owned by sa:

     SELECT name

     FROM msdb.dbo.sysjobs

     WHERE owner_sid = 0x01; -- sa

     (Jobs will still run with sa disabled, but it’s good to know what exists.)

   • Linked servers mapped to sa:

     SELECT s.name AS linked_server, sp.name AS local_login

     FROM sys.linked_logins AS l

     JOIN sys.servers AS s ON s.server_id = l.server_id

     LEFT JOIN sys.server_principals AS sp ON sp.principal_id = l.local_principal_id

     WHERE sp.principal_id = 1; -- sa principal_id

     (sa is always principal_id = 1 / SID = 0x01.)

How to see whether sa is enabled (or has been renamed)

Even if someone renamed sa, its SID is constant: 0x01. Run:

This detects the current name and whether it’s disabled. (CIS notes sa has principal_id = 1 and sid = 0x01.)

How to disable sa (T-SQL and SSMS)

T-SQL:

SSMS: Security → Logins → right-click sa → Properties → Status → Login: Disabled → OK. (Either method is equivalent.)

Should you rename sa too?

• Pros: Some baselines (CIS) explicitly require renaming sa. Renaming raises the bar slightly for opportunistic attacks that only try the literal name sa.

• Cons: Renaming is obfuscation, not real defense, and can confuse future operators if it’s undocumented. If you do rename, document it clearly (in password vault notes, runbooks, and monitoring). Community reports note operational gotchas (e.g., Agent service restarts when jobs reference the owner name). Disabling remains the meaningful control.

Don’t try to drop or de-privilege sa

You can’t drop sa, and it inherently has full permissions. The secure pattern is: leave it in sysadmin, but disable it.

A sensible “break-glass” plan

If policy requires a SQL login for emergencies, create a named sysadmin login with a 20+ char random password, store it in your vault, and leave sa disabled:

Microsoft recommends Windows/Entra authentication whenever possible; only use SQL logins when necessary.