Can Admin Rename SA Account in SQL Server? – Interview Question of the Week #256

Question: Can an administrator rename the sa login? Yes. ALTER LOGIN sa WITH NAME = [SQLAuthority] changes its name; it doesn’t remove the built-in login’s identity or privileges.

When I ask this in interviews, a common answer is that sa can only be enabled or disabled, because it’s the system administrator account. The surprising part is that it can be renamed too.

-- Read-only identity check, including after a rename:
SELECT name, principal_id, sid, is_disabled
FROM sys.sql_logins
WHERE sid = 0x01;

-- Deliberate administration examples only, not executed here:
-- ALTER LOGIN sa WITH NAME = [SQLAuthority];
-- ALTER LOGIN [SQLAuthority] DISABLE;
-- ALTER LOGIN [SQLAuthority] ENABLE;

The SID 0x01 identifies the built-in SQL login even after a rename, so the read-only query is a reliable way to find its current name. The administration commands are commented deliberately: this interview example is not an instruction to change your server’s access today.

After renaming it, use the new name for DISABLE or ENABLE; sa no longer identifies that login. If you haven’t renamed it, ALTER LOGIN sa DISABLE and ENABLE work on its existing name.

Have another tested administrative login before disabling access, and review applications or jobs that depend on the old name. Renaming doesn’t replace individual authentication, least-privilege permissions or an appropriate authentication policy. Renaming is also not disabling: a renamed sa still works for anyone who knows the new name and the password.

I dislike seeing a shared sa login embedded in application connection strings or handed to every developer. Named accounts make accountability possible, and applications usually need much less than sysadmin access. Changing the name alone doesn’t solve that problem.

Renaming sa is not disabling it, it is a new label on the same key, so find it by SID 0x01.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.