Disable SA account on a live SQL Server2005 instance, any drawbacks?

Last week I have been delegated to finalize the security standards within a set of SQL 2005 instances that are used by a customer, though it is usual chores for me to apply industry best practices.

On these SQL 2005 instances in particular I was more keen on applying "disabling SA account"!

I was confronted by a Database developer that  if there are any drawbacks to disabling the SA account in SQL Server 2005 and does it add true security value?

So to benefit my stance I have given the following explanation:

Followed the Best Practices (as extracted from SQL 2005 whitepaper)

• Always use Windows Authentication mode if possible.
• Use Mixed Mode Authentication only for legacy applications and non-Windows users.
• Use the standard login DDL statements instead of the compatibility system procedures.
• Change the sa account password to a known value if you might ever need to use it. Always use a strong password for the sa account and change the sa account password periodically.
• Disable xp_cmdshell unless it is absolutely needed.
• Disable COM components once all COM components have been converted to SQLCLR.
• Disable both mail procedures (Database Mail and SQL Mail) unless you need to send mail from SQL Server. Prefer Database Mail as soon as you can convert to it.
• Use SQL Server Surface Area Configuration to enforce a standard policy for extended procedure usage.
• Document each exception to the standard policy.

Not sure you are aware that if you are using 'Windows only' authentication mode then SA login account is disabled by default and random password is allocated for it, so if you need to use 'mixed mode' authentication then you have to re-enable the SA login that will obviously fail because of earlier random password assigned to it. So the best practice is to assign a 'complex' password to SA when that SQL instance has been installed for the future use of SA account by any case. Also you can rename the specified SA account to a better naming login, so to wrap up the discussion the "security" advantage it offers is disabling or securing the SA login with complex password is an added security to avoid usage of SA account with usual password guessing practices.

Say if you are not using the SA login for any of the application processes or jobs, you can simply disable it and perform those ADMIN chores using appropriate user group. This will avoid the issues of hacker or virus trying to force the attack against the locked account, so you have to test your applications thoroughly when following to disable the SA login. If you are using third party tools then ensure to discuss with corresponding vendor to ensure they haven't tresspassed this usual practice of using SA login. So the better practice is by finding and then fixing or eliminating these applications should be considered as a priority anyway. As mentioned, the account cannot be used to connect to the database until it is reenabled. Further, due to the nature of authentication failure if you have such alerting system in place will give you instant warning of such attacks within your environment.

Obviously with the above explanation there was no further discussion from that Developer group and I have implemented my choice of security practices.