- Error number
- 18486
- Severity
- 14 (user-correctable error)
- State
- Not documented by Microsoft (not reproduced here); SQL Server 2025 logged the lockout as 18456 state 78 (see the state table below)
- Product
- Microsoft SQL Server Database Engine
- Versions
- All supported SQL Server versions (2016 to 2025) and Azure SQL Managed Instance, for SQL logins with CHECK_POLICY = ON
- Category
- Logins & Permissions
- Last reviewed
- 24 October 2026
On this page
What it means
Error 18486 means the SQL login has been locked out after too many failed password attempts under the Windows account lockout policy; an administrator must unlock it.
SQL logins with CHECK_POLICY = ON follow the Windows account lockout threshold of the server (local or domain policy). After that many wrong passwords within the observation window, SQL Server locks the login: LOGINPROPERTY(name, 'IsLocked') becomes 1, and every new attempt fails, even with the correct password, until the lockout duration passes or an administrator unlocks it. The message text with number 18486 is in the engine catalogue at severity 14.
What you see depends on where you look. In our test on SQL Server 2025 the client only received the generic error 18456 text, and the error log recorded 18456 state 78 with the reason "The account is currently locked out. The system administrator can unlock it." The number 18486 itself did not appear on this build. So search the error log for the reason text, not only for the number, and treat state 78 as "locked out".
| State | Meaning |
|---|---|
| 18456 state 78 | Reproduced on SQL Server 2025: login attempt (correct or wrong password) while the login is locked out. |
| 18456 state 8 | Reproduced: each wrong password before the lockout. These count towards the lockout threshold. |
Common causes
- An application or service still uses an old password after a password change, and its retries hit the lockout threshold within minutes.
- Someone (or something) is guessing passwords for the login.
- A person mistyped the password repeatedly, or a saved password in a tool is out of date.
- Several servers or jobs use the same login, and one of them has the wrong password.
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 locked, and how many bad passwords were counted?
SELECT name, is_policy_checked,
LOGINPROPERTY(name, 'IsLocked') AS is_locked,
LOGINPROPERTY(name, 'BadPasswordCount') AS bad_password_count,
LOGINPROPERTY(name, 'BadPasswordTime') AS last_bad_password,
LOGINPROPERTY(name, 'LockoutTime') AS lockout_time
FROM sys.sql_logins
WHERE name = N'app_login';is_locked = 1 confirms the lockout. In our test bad_password_count equalled the Windows lockout threshold (10) and lockout_time was the time of the last wrong password.
Find who sent the wrong passwords
Requires membership of securityadmin or sysadmin. The client address on each line is the machine to fix.
-- Wrong passwords before the lockout (18456 state 8)
EXEC sp_readerrorlog 0, 1, N'Password did not match';
-- Attempts while locked out
EXEC sp_readerrorlog 0, 1, N'locked out';One address repeating every few seconds is usually a service with a stale password. Many addresses, or names you do not recognise, point to password guessing.
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.
Fix the source of the wrong passwords first
Client or network sideUpdate the password in the application, service or saved connection that the error log points to, or block the client if the attempts are hostile. Unlocking before this only lets the same client lock the login again.
Unlock the login (administrator)
Changes permissionsSQL Server unlocks a SQL login together with a password change. In our test this cleared IsLocked and the login connected with the new password. Requires ALTER ANY LOGIN.
ALTER LOGIN [app_login] WITH PASSWORD = N'Use-a-strong-unique-password-1' UNLOCK;Wait for the lockout duration to pass
Read-onlyMicrosoft lists the Windows lockout duration among the policy settings that apply to SQL logins with CHECK_POLICY = ON, so the lock should end by itself after that time (we did not wait for it in our test). net accounts on the server shows the threshold, duration and observation window. The client must stop sending wrong passwords first.
Examples
Ten wrong passwords, then the correct one
Reproduced with a temporary SQL login (CHECK_POLICY = ON) on a machine whose existing Windows policy has a lockout threshold of 10; no policy was changed. On SQL Server 2025 the lockout appears as 18456 state 78; the number 18486 was not raised.
-- 10 connections with a wrong password (each logs 18456 state 8), then:
SELECT LOGINPROPERTY(N'app_login', 'IsLocked') AS is_locked, -- 1
LOGINPROPERTY(N'app_login', 'BadPasswordCount') AS bad_password_count; -- 10
-- Now connect with the CORRECT password:
-- sqlcmd -S . -C -U app_login -Q "SELECT 1"Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login failed for user 'app_login'.. Error log: Error: 18456, Severity: 14, State: 78. Login failed for user 'app_login'.Reason: The account is currently locked out. The system administrator can unlock it. [CLIENT: <local machine>]
How to prevent it
Change service passwords with a plan that updates every consumer at the same moment, and alert on bursts of 18456 state 8 for one login: they are the warning before a lockout. Give each application its own login so one stale configuration cannot lock out the others.
Keep CHECK_POLICY = ON: lockout is what stops password guessing against SQL logins. Where possible, use Windows or Microsoft Entra authentication for services. The SQL Server security lesson covers login design.
Common questions
Why does the login stay locked even with the right password?
A locked login rejects every attempt until it is unlocked or the lockout duration ends. In our test the correct password produced the same failure (18456 state 78) as a wrong one.
Where does the lockout threshold come from?
From the Windows account lockout policy that applies to the server, local or domain. SQL Server has no separate threshold setting. Run net accounts on the server to see it.
Can I unlock without changing the password?
ALTER LOGIN ... UNLOCK must be combined with a password. Microsoft also documents switching CHECK_POLICY off and on, but that clears the password history and weakens the login for a moment; setting a new password is the cleaner route.
Learn more on CodeWithSQL
Official documentation
- Password policy (Microsoft Learn)
- ALTER LOGIN (Transact-SQL)
- LOGINPROPERTY (Transact-SQL)
- 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.