Fix SQL Server 18456: Login Failed for sa

Quick Answer

Run these two commands in SQL Server Management Studio (SSMS) as an admin, then restart the service: ALTER LOGIN sa WITH PASSWORD = 'YourStrongPassword'; ALTER LOGIN sa ENABLE; If that doesn't work, you're likely in Windows-only auth mode—here's the full fix below.

Error 18456 is the login failed error. It shows up when you try to connect with the sa account or any SQL login and SQL Server says no. The reasons stack up fast: the account is disabled (it is by default), the server is in Windows-only authentication, the password is wrong, or the login just doesn't exist. Most of the time, it's the first two.

I've seen this exact error on fresh SQL Server 2019 installs and on legacy 2008 R2 boxes that someone accidentally reset. The frustrating part is the error message doesn't tell you which part failed—you have to dig into the SQL Server error log to see the state number, which points you to the real cause. But let's skip the log reading for now and get you connected.

Fix Steps

Open SSMS and connect using Windows Authentication. Use an account that has sysadmin rights on the SQL Server instance. If you're not sure, try your domain admin or the local administrator. If you can't connect at all, you'll need to start SQL Server in single-user mode—skip to the alternative fixes below.
Check the server's authentication mode. Right-click the server name in Object Explorer, select Properties, go to the Security page, and look under Server authentication. If Windows Authentication mode is selected, switch it to SQL Server and Windows Authentication mode. Click OK.
Enable the sa login and set a strong password. In Object Explorer, expand Security → Logins, right-click sa, and choose Properties. On the General page, type a new password in both password fields. On the Status page, under Login, select Enabled. Click OK.
If sa isn't listed, create it. Right-click Logins → New Login. Set the login name to sa, choose SQL Server authentication, type a strong password, and uncheck Enforce password policy if you're in a lab. On the Status page, set it to Enabled, and add it to the sysadmin server role on the Server Roles page.
Restart the SQL Server service. Open Services (Win+R, type services.msc), find the service named SQL Server (MSSQLSERVER) or your named instance, right-click and select Restart. After the restart, the new authentication mode takes effect.
Test the connection. Open SSMS, set the Server type to Database Engine, and the Authentication to SQL Server Authentication. Enter sa and your new password. Click Connect. You should see the Object Explorer populate.

At this point, you're usually in. If you still get 18456, the state number in the error log will tell you why. Check it by running this in a query window on the connected server:

EXEC xp_readerrorlog 0, 1, N'Login failed';

Look for the state number at the end of the line. State 1 means the login doesn't exist, state 2 means the password is wrong, state 8 means the account is disabled, and state 9 means the login is valid but you're not allowed into the database. That last one happens when the sa account doesn't have a default database that exists—fix it by setting the default database to master in the login properties.

Alternative Fixes

If you can't connect even with Windows Authentication, or you don't know the sa password and the account is disabled, you'll need to get into the server in single-user mode. Here's how:

Single-User Mode

Open SQL Server Configuration Manager from the Start menu.
Under SQL Server Services, right-click your instance and select Properties.
On the Startup Parameters tab, add -m in the box and click Add. Click OK.
Restart the service. Now only a sysadmin can connect—and only if they connect as the computer's local administrator.
Open SSMS as admin (right-click and choose Run as administrator). Connect with Windows Authentication. You'll get in.
Once in, run the ALTER LOGIN commands from the Quick Answer to reset and enable sa.
Remove the -m startup parameter the same way you added it, then restart the service again.

That trick works on SQL Server 2008 through 2022. I've used it dozens of times on forgotten servers.

Prevention Tips

Set the sa password to something long and random, then never use it for daily work. Create a separate SQL login for applications with only the permissions they need. And document the sa password in your password manager—not on a sticky note.

Also, keep the server in mixed mode if you ever need SQL logins, but that's a tradeoff. If you only use Windows Authentication, leave it on Windows-only. But if you think you'll need SQL logins later, flip it now before you're locked out.

Finally, test the sa login after every major SQL Server update. Updates sometimes reset things, and you don't want to discover it at 2 AM during a deployment.