- Error number
- 18470
- Severity
- 14 (user-correctable error)
- State
- 1
- Product
- Microsoft SQL Server Database Engine
- Versions
- All supported SQL Server versions (2016 to 2025), Azure SQL Managed Instance
- Category
- Logins & Permissions
- Last reviewed
- 24 October 2026
On this page
What it means
Error 18470 means the password was right but the login has been disabled on the server, so SQL Server refuses the connection until an administrator enables it again.
A login has an enabled or disabled flag (sys.server_principals.is_disabled), set with ALTER LOGIN ... DISABLE or the Status page of the login properties. When a disabled login presents the correct password, SQL Server rejects the connection with 18470 at severity 14 and, unlike most login failures, tells the client the reason. Existing sessions of the login are not affected; only new connections fail.
The reason is shown only when the password is correct. In our test, the same disabled login with a wrong password produced the generic error 18456 on the client and state 7 in the error log, so an attacker guessing passwords does not learn that the account exists and is disabled. If you see 18456 state 7, fix the password and the disabled flag.
Common causes
- An administrator disabled the login on purpose: a leaver, a retired application, or a security incident.
- The login is
sa: Microsoft documents that sa starts out disabled when an instance installed with Windows Authentication is switched to mixed mode. - A login retirement plan disabled the login before dropping it, and an application nobody knew about still uses it.
- A script or policy that disables unused logins included one that is still needed.
Diagnose it
Read-only These queries only read metadata and dynamic management views. They do not change data, permissions or configuration, so they are safe to run first.
Is the login disabled, and when was it last changed?
SELECT name, type_desc, is_disabled, create_date, modify_date
FROM sys.server_principals
WHERE name = N'app_login';is_disabled = 1 confirms the cause. modify_date is when the login was last altered, a starting point for finding out who disabled it and why.
Read the failures in the error log
Requires membership of securityadmin or sysadmin.
EXEC sp_readerrorlog 0, 1, N'The account is disabled';One line per failed attempt with the login name and the client address: which machines still try to use the disabled login.
Check the other login properties before enabling it
SELECT LOGINPROPERTY(N'app_login', 'IsLocked') AS is_locked,
LOGINPROPERTY(N'app_login', 'IsExpired') AS is_expired,
LOGINPROPERTY(N'app_login', 'IsMustChange') AS must_change;All 0 means enabling is enough. A 1 means the next attempt will fail with a different reason (locked out, expired or must change), so fix that in the same change.
How to fix it
Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.
Confirm why the login was disabled
Read-onlyBefore enabling anything, ask the team that owns security. A login disabled after a leaver or an incident should stay disabled; the application should move to its own login instead.
Enable the login
Changes permissionsIf the login is still meant to be used, enable it. Requires ALTER ANY LOGIN.
ALTER LOGIN [app_login] ENABLE;Move the application to a dedicated login instead of sa
Changes permissionsIf the disabled login is sa, leave it disabled. Create a login for the application with only the database roles it needs and change the connection string.
CREATE LOGIN [app_login] WITH PASSWORD = N'Use-a-strong-unique-password-1';
-- then, in the application database:
CREATE USER [app_login] FOR LOGIN [app_login];
ALTER ROLE db_datareader ADD MEMBER [app_login];Examples
Connecting with a disabled login and the correct password
Reproduced with a temporary SQL login. The client output and the matching error log lines follow.
ALTER LOGIN [app_login] DISABLE;
-- From a command prompt, with the correct password:
-- sqlcmd -S . -C -U app_login -Q "SELECT 1"
-- Then, as an administrator, read the error log:
EXEC sp_readerrorlog 0, 1, N'app_login';Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login failed for user 'app_login'. Reason: The account is disabled.. Error log: Error: 18470, Severity: 14, State: 1. Login failed for user 'app_login'. Reason: The account is disabled. [CLIENT: <local machine>]
How to prevent it
Keep a register of which application uses which login, and disable logins in a planned retirement: announce, disable, watch the error log for 18470 from unexpected hosts, then drop. Monitoring the error log for 18470 shows quickly who still depends on a disabled login.
Do not share logins between applications or people, and keep sa disabled. The SQL Server security lesson covers least-privilege logins.
Common questions
Why do I get 18470 for sa?
sa is usually disabled on purpose; for example it starts out disabled when an instance installed with Windows Authentication is switched to mixed mode. Use a named login with the permissions you need instead of enabling sa.
Can a disabled login still be used through impersonation?
Yes. Microsoft documents that disabled logins keep their permissions and can still be impersonated (EXECUTE AS LOGIN by someone with IMPERSONATE permission on it), so review IMPERSONATE grants too.
Is 18470 different from 18456?
Yes. 18470 is raised when the password is correct and the only problem is the disabled flag; the client sees the reason. With a wrong password the client only sees 18456, and the error log shows state 7.
Learn more on CodeWithSQL
Official documentation
- ALTER LOGIN (Transact-SQL)
- MSSQLSERVER_18456 (Microsoft Learn)
- Database engine events and errors 18000 to 18999 (Microsoft Learn)
Last technically reviewed 24 October 2026; examples and diagnostics run on SQL Server 2025 (17.0.1145.4). Message text checked against the engine's sys.messages catalogue.