Why Changing a User's Password Does Not Log Them Out of Outlook Web Access

The Common Assumption That Creates a Security Gap

When an Exchange or Microsoft 365 account gets compromised, the standard response is fast: change the password, done. The logic is simple -- if the attacker does not know the new password, they cannot get back in. Case closed.

Except that is not always true. An active Outlook Web Access session is not bound to the password you used to log in. It is bound to a server-side session token. Changing the password does not automatically invalidate that token. The attacker, who already has a valid session open, can keep reading emails, calendar entries, and contacts until the session expires or someone explicitly ends it.

This is not a bug. It is how token-based authentication works. But it is a gap that catches a lot of incident responders off guard.

How OWA Session Authentication Actually Works

When you log into Outlook Web Access, your browser authenticates against Exchange or Azure Active Directory using your username and password. The server verifies your credentials and issues a session token -- a small piece of data that your browser sends with every request to prove you are still authenticated. This token is independent of your password. It has its own lifetime, controlled by server configuration. When you change your password, the server updates your account credentials but does not automatically remove the session token from the server's active session store. The token stays valid until it expires or is explicitly revoked.

Here is what this means in practice:

• Exchange Server on-premises: session lifetime is controlled by the IIS authentication settings on the Client Access server. Defaults vary but 8 hours is a common starting point.
• Exchange Online: the Azure AD refresh token governs session validity. Without Conditional Access policies that enforce immediate token revocation, a password change does not kill existing web sessions. Refresh tokens can remain valid for days or weeks depending on tenant settings.
• Mobile clients and desktop apps: these use OAuth tokens tied to the Azure AD app registration. A password change does not revoke those tokens -- the user needs to re-authenticate the app specifically.

The result is the same everywhere: an attacker with an established session can often continue operating long after the password has been changed.

What Actually Revokes an OWA Session

A password reset is not a session revocation. Here is what actually ends an active session:

Exchange Online:

• Remove-AzureADUserAllRefreshToken -UserPrincipalName -- this cmdlet revokes all Azure AD refresh tokens for the account, forcing all apps and sessions to re-authenticate on the next request.


• In the Azure portal: go to the user, select "Sign out everywhere" under Session management. This has the same effect as the PowerShell cmdlet.


• Conditional Access policies can be configured to enforce token revocation on risk events, but this is not the default.

Exchange Server on-premises:

• IISReset on the Client Access server -- terminates all IIS worker processes and clears all session state.


• Recycle the MSExchangeOWAAppPool application pool -- more targeted than IISReset, clears OWA sessions without affecting other IIS sites on the same server.


• Disable then re-enable the mailbox -- this immediately invalidates all active sessions.

Both:

• Disabling the account prevents further authentication but does not kill an already-active session.


• The most reliable approach: change the password AND revoke sessions AND disable the account if the threat is severe.

A Real Attack Scenario

Here is how this gap becomes a real problem:

1. An attacker phishes a user's credentials through a convincing Microsoft 365 login page.
2. The attacker logs into OWA, starts reading emails, sets up inbox rules to forward interesting messages to an external address.
3. The defender detects the compromise -- a user report, a SIEM alert, or a DMARC report anomaly picked up through DMARCFlow showing an unusual spike in authentication failures from your domain.
4. The defender changes the compromised password.
5. The attacker, who still has an open OWA session, continues reading emails, accessing contacts, and using the mailbox. The inbox rule keeps forwarding.
6. The defender sees the mailbox in the audit log but assumes the password change solved the problem.

The attacker is using a legitimate, authenticated session. They are not failing authentication or triggering lockouts. They look exactly like the real user.

The DMARC report anomaly in step 3 is a realistic detection point. If the attacker uses the compromised account to send email from your domain -- not just read it -- that activity will appear in your DMARC aggregate reports as authentication anomalies: SPF failures from IP addresses you do not recognize, alignment mismatches, unusual sending volume. DMARCFlow catches those patterns across multiple receivers and flags them automatically. Without that monitoring, you may not see the sending activity until your domain starts landing in spam folders.

The Complete Incident Response Checklist

When you detect a compromised account, do not stop at the password reset. Run through the full list:

1. Change the password immediately.
2. Revoke all active sessions -- PowerShell for Exchange Online, IISReset or app pool recycle for Exchange Server on-premises.
3. Check inbox rules -- look for rules the attacker may have created to forward, copy, or delete messages.
4. Check mailbox delegate permissions -- attackers often add their own account as a delegate to maintain quiet access.
5. Review Mailbox audit logs for the window between initial compromise and your response -- look for items accessed, items deleted, rules created, and forwarding configured.
6. Enable or enforce MFA on the account if it is not already active.
7. Check the sign-in logs -- look for IP addresses, locations, and devices that do not match the user's normal pattern.
8. Review DMARC aggregate reports for the affected domain -- unusual sending patterns or spikes in authentication failures can indicate the attacker is using the account to send email, which creates a deliverability problem on top of the security incident.
9. Notify affected users if any data exposure is confirmed.
10. Document the timeline for the incident report.

Step 8 is where DMARCFlow fits naturally into the response workflow. It is not just a monitoring tool -- it is an intelligence source after a compromise. If the attacker starts sending from your domain, DMARC reports will show the authentication signature of that activity before it damages your domain's reputation at major receivers.

FAQ

Does changing an Exchange Online password log out all devices?

No. Changing the password invalidates the credentials but Exchange Online uses OAuth tokens that remain valid until explicitly revoked. Users will need to re-authenticate apps and mobile clients, but existing web sessions may persist until the token lifetime expires. Use "Sign out everywhere" in the Azure portal or the Remove-AzureADUserAllRefreshToken cmdlet to force immediate session termination across all devices and sessions.

How do I revoke all OWA sessions for a user?

For Exchange Online, run Remove-AzureADUserAllRefreshToken -UserPrincipalName in the Azure AD PowerShell module, or use the Azure portal session management feature. For Exchange Server on-premises, run IISReset on the Client Access server or recycle the MSExchangeOWAAppPool application pool using IIS Manager. Both approaches end all active OWA sessions for the target user immediately.

How long does an OWA session stay active after a password change?

It depends on your configuration. Exchange Server on-premises session lifetimes are set in IIS and vary by deployment -- 8 hours is a common default. Exchange Online refresh tokens can remain valid for days or weeks without specific Conditional Access enforcement. Running the session revocation cmdlets ends sessions immediately regardless of configured lifetime.

Can DMARC reports show me if an attacker is still accessing a mailbox after a password reset?

No. DMARC reports cover mail authentication at receiving servers, not mailbox access. But if the attacker uses the compromised account to send email from your domain, DMARC reports will show authentication anomalies -- SPF failures from unknown IP addresses, alignment mismatches, unexpected sending volume. Those patterns are worth investigating. Use mailbox audit logs and Azure AD sign-in logs for direct mailbox access monitoring.

What is the fastest way to end all active sessions for a compromised on-premises Exchange account?

Disable the mailbox in Exchange Admin Center or via Disable-Mailbox in the Exchange Management Shell. This immediately invalidates all active sessions. Then change the password and investigate before re-enabling the account properly.

---