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:

SELECT name, is_disabled
FROM sys.server_principals
WHERE sid = 0x01; -- the 'sa' login, even if renamed

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:

-- 1) Verify you have another sysadmin:
SELECT sp.name
FROM sys.server_role_members rm
JOIN sys.server_principals sp ON sp.principal_id = rm.member_principal_id
WHERE rm.role_principal_id = SUSER_ID('sysadmin');

-- 2) Optionally end any current 'sa' sessions:
-- Find them:
SELECT session_id FROM sys.dm_exec_sessions WHERE original_login_name = 'sa';
-- KILL <session_id>  -- run for each if you need a clean cutover

-- 3) Disable 'sa':
ALTER LOGIN [sa] DISABLE;  -- blocks future logins; ownership stays intact

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:

CREATE LOGIN [BreakGlass_Admin] WITH PASSWORD = 'use-a-random-20+-char-secret!';
EXEC sp_addsrvrolemember 'BreakGlass_Admin', 'sysadmin';

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