DBCC FLUSHAUTHCACHE: Force Azure SQL to Re-authenticate

DBCC FLUSHAUTHCACHE clears the authentication cache of an Azure SQL database, so open connections must sign in again. You need it when a password change or a security incident calls for fresh credentials on every connection at once. First, it helps to know what a password change does by itself.

A Password Change Does Not End Open Sessions

It is easy to assume that a new password disconnects everyone. It does not, even on a regular SQL Server instance. A test on SQL Server 2025 shows it. The instance needs SQL Server authentication turned on. One window signs in as a throwaway login and runs a 30 second wait. A second window changes the password of that login during the wait. The first session keeps running and returns its result.

The new password applies to new connections only. After the change, a new sign-in with the old password fails with Login failed. A sign-in with the new password works. The next blocks are for a test server, because they create a login. Replace both placeholder passwords with your own, and drop the login when you finish.

-- Window 2: create the throwaway login
CREATE LOGIN AuthFlushTestLogin WITH PASSWORD = N'ReplaceWithYourOwnPassword1!', CHECK_POLICY = OFF;

-- Window 1: connect as AuthFlushTestLogin, then run
SET NOCOUNT ON;
WAITFOR DELAY '00:00:30';
SELECT 'finished' AS Outcome, SUSER_SNAME() AS LoginName;

While window 1 waits, change the password in window 2. Then read the session list. The session is still there, with the status running.

-- Window 2: change the password during the wait
ALTER LOGIN AuthFlushTestLogin WITH PASSWORD = N'ReplaceWithAnotherPassword2!';

SELECT session_id, login_name, status
FROM sys.dm_exec_sessions
WHERE login_name = N'AuthFlushTestLogin';

Why Azure SQL Needs DBCC FLUSHAUTHCACHE

Azure SQL Database caches the authentication details of a connected user in the memory of the user database. A session that stays connected is checked again in the background about every 10 hours. It happens silently, and the user sees nothing. So a changed password can take hours to reach a long-lived connection.

For most changes, that delay is harmless. After a security incident, it is not. The command below empties the cache of the database and forces the connections to authenticate again with the server.

DBCC FLUSHAUTHCACHE;

This is a statement for Azure SQL Database, which is where the cache lives. A SQL Server 2025 test instance accepts it and prints the usual completion message. The effect on a regular instance is not documented here, so run it where you mean to use it. Per the documented behavior, a connection that is forced to authenticate again needs credentials that are still valid.

List the Sessions Before You Act

Before you flush the cache, see who is connected. The next query lists the sessions of one login and builds a KILL statement for each. It only builds the text. You decide which statement to run, and the query skips your own session.

DECLARE @login sysname = N'AuthFlushTestLogin';
SELECT s.session_id,
       s.login_name,
       s.login_time,
       s.host_name,
       s.program_name,
       N'KILL ' + CONVERT(nvarchar(10), s.session_id) + N';' AS KillStatement
FROM sys.dm_exec_sessions AS s
WHERE s.is_user_process = 1
  AND s.login_name = @login
  AND s.session_id <> @@SPID
ORDER BY s.login_time;

A login without sessions returns no rows. Be careful with KILL. It ends the session at once and rolls back the open transaction of that session. Use it for one known session, not for a whole list.

You could argue that ending sessions is simpler, because KILL works the moment you run it. That is true for a handful of sessions. DBCC FLUSHAUTHCACHE covers every connection to the database in one statement.

Compare the Sessions Before and After

Run this query before the flush, and again after it. It lists the user sessions with their session id and login time.

SELECT session_id, login_name, login_time
FROM sys.dm_exec_sessions
WHERE is_user_process = 1
ORDER BY login_name, session_id;

A session with the same id and login time in both lists was not reconnected. A session that is gone in the second list was ended. A session that signed in again appears with a new id and a new login time. The login time marks when a session started, so it does not show a silent check inside a session.

Cautions

Warn the application owners first. Connections that cannot authenticate again break the application until it signs in with the new credentials. Update the connection strings and the secrets store before you run DBCC FLUSHAUTHCACHE. Plan a short window for it.

Change the password first, then flush the cache. The order matters, because a flush before the change lets the old credentials back in. Keep a note of the time, and check the sessions again afterward.

What to Remember

A password change affects new connections only. On Azure SQL Database, the open ones keep their cached credentials for hours, and DBCC FLUSHAUTHCACHE removes that gap. List the sessions first, change the password first and flush second.

Tell the application owners before you flush. Flush only for a reason, such as a password change after an incident. When you finish the test on a server of your own, drop the throwaway login.

DROP LOGIN AuthFlushTestLogin;

A new password is not a lock change, it is a key that open doors never check.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.