Answers and comments at a recent popular question Does changing "sa" password require a SQL restart (in mixed mode)? indicate that renaming and disabling sa at build time is a best practice.

Any time you have a well-known account, like administrator on a Windows system or sa for SQL Server, you should take certain steps to secure it. Let's look at specifically what you should do with sa:

Set a hard to guess password.

Rename sa.

Disable sa.

Ensure that no other accounts exist named sa.


But what if it has been years since the instance was built? the original DBA is long gone, I don't know what strange things they might have done. It's a production server, I can't just change make changes to the sa login and fix things as they come to light.

If I rename and disable the sa account years later, what issues might I have?

Can all the possible issues be identified and addressed, before making changes to the sa account?

  • testing on development is a good start.. – kevinsky Feb 21 '19 at 17:20
  • 4
    Can all the possible issues be identified and addressed, before making changes to the sa account? No, some legacy app, somewhere, that only connects once a year, could still be out there. There will always be some cleanup, afterwards. – Sean Gallardy - Retired User Feb 21 '19 at 17:28
  • 1
    I don't know that I really buy that renaming sa is valuable. If your password policy is good, and you don't blindly give it to everyone who asks for it, it shouldn't matter; if you give a crappy password to whatever account you use in sa's place, or share that one in the same way, it's not like finding sysadmin role members is tough for anyone with connect rights. This seems like security theater, like changing the port SQL Server is running on simply because it will take a port scanner half a second longer to find it. – Aaron Bertrand Feb 21 '19 at 18:21
  • @AaronBertrand I think it really comes down to what the non-disabled sa account gets assigned to run/own. If it is disabled it really does not matter. But if it's not disabled there can be issues. I recall something about the sa account being DB_Owner and that providing a back door, I believe there are several examples. – James Jenkins Feb 21 '19 at 18:27
  • Right. My point is giving it a different name (or creating a new SQL auth account with sysadmin) doesn't solve any problem, if all the material things that make it a problem don't also change. It is those material things that need to change, and changing them will fix the issues whether you rename sa or not. If you can't change the sa password right now because some app or process or person relies on it, that's the problem you need to fix, that they're connecting as sysadmin, not explicitly as sa. If they connect to a different sysadmin account, the problem remains. – Aaron Bertrand Feb 21 '19 at 18:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.