Entra ID- user Governance- User browser session

Question

Hi Team,

Just wanted to check with you, as part of governance we used to monitor the user account status in entra id and for the risky users then we suggest user to reset the password and helpdesk do the MFA reset as well, but incase if the user has connected to any session in the browser, their sessions will be still there until its time out or they close the browser. In entra ID is there any way to configure like when the user password and MFA is reset revoke/clean the browser sessions or tokens and user has to re login to the apps? Basically what we expects, when the password reset and mfa reset is done for any user, their active sessions should become invalid so the session tokens wont be mishandled or used to exploit.

Answer 1

Hello SAGA

Thank you for reaching out to Microsoft Q&A.

Yes. In Microsoft Entra ID, you can force all active browser sessions and sign‑in tokens to be invalidated so that the user must re‑authenticate to all apps, even if the browser session is still open.

However:

Password reset or MFA reset alone is NOT sufficient

You must explicitly revoke the user’s sign‑in sessions

Why Password Reset / MFA Reset Alone Is Not Enough

Microsoft Entra ID uses tokens, not live authentication, to maintain sessions:

Access tokens → valid ~1 hour

Refresh tokens → long‑lived (used to silently re‑sign in)

Browser session cookies → controlled by the app

If you only:

Reset password

Reset MFA

➡ Existing browser sessions can remain valid until:

Token expiry

App revalidation

Browser close

For your reference: https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access

Below is the resolution:-

Use “Revoke Sessions” in Microsoft Entra ID

This action:

Invalidates all refresh tokens

Forces re‑authentication across all apps and browsers

Clears MFA claims (per‑user and Conditional Access)

Signs the user out of all active sessions

Microsoft introduced this as the correct “kill switch” for compromised or risky users

Microsoft Entra admin center

Entra ID → Users → Select user → Authentication methods → Revoke sessions

After this action, the user is required to sign in again everywhere.

This behavior is logged as:

Update StsRefreshTokenValidFrom Timestamp

Audit‑visible and security‑compliant

When Revoke sessions is triggered:

Refresh tokens are invalidated immediately

New access tokens cannot be issued

Existing access tokens:

Expire naturally (≈ 1 hour), OR

Are invalidated near‑real‑time for CAE‑enabled apps

Browser sessions are forced back to Entra ID on next request

For risky or compromised users :-

1. Reset password
2. Require MFA re‑registration
3. Revoke sessions ← CRITICAL STEP
4. (Optional) Temporarily block sign‑in
5. Re‑enable access after verification

For Browser Sessions

Entra ID cannot directly delete app‑owned cookies

Session invalidation occurs when:

App revalidates token

CAE (Continuous Access Evaluation) is supported

Modern Microsoft workloads (Exchange, SharePoint, Teams) support near‑real‑time enforcement via CAE

Reference: https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access

So, Resetting a user’s password and MFA methods does not automatically invalidate existing browser sessions in Microsoft Entra ID. To ensure all active sessions and tokens are invalidated and force re‑authentication across all applications, administrators must explicitly use the Revoke sessions action in Microsoft Entra ID. This revokes refresh tokens, clears MFA claims, and enforces sign‑in again

Answer 2

Yes. When resetting a user’s password or MFA, browser and app sessions can be explicitly revoked so that the user must reauthenticate.

Use the following controls:

1. Revoke sessions when doing account remediation
   In the Microsoft Entra admin center:
   1. Go to Entra ID → Users → <user> → Authentication methods.
   2. Use:
      • Reset password – assigns a temporary password and forces change at next sign-in.
      • Require re-register MFA – clears existing MFA methods so the user must set them up again.
      • Revoke sessions – invalidates the user’s refresh tokens, forcing reauthentication across active sessions and applications.
   This combination both changes credentials/MFA and ensures existing tokens can no longer be used, so active browser/app sessions will fail on the next token refresh and require sign-in.
2. Use Conditional Access sign-in frequency and session controls
   To tighten how long sessions can remain valid and how often users must reauthenticate (for both first and second factor), configure Conditional Access authentication session management:
   • Sign-in frequency – defines how often users must sign in again. This applies to both client and browser sessions.
   • Persistent browser session – controls whether sessions persist after closing the browser.
   These policies help ensure that, after password/MFA reset and session revocation, users are prompted again within the configured frequency and cannot maintain long-lived sessions.
3. Understand default session behavior
   • Without session lifetime policies, browser sessions rely on cookies and token lifetimes; users may stay signed in until tokens expire or the browser is closed.
   • Refresh tokens can be valid for up to 90 days with continuous use, unless explicitly revoked or blocked by Conditional Access.

For governance workflows, incorporate the following standard steps for risky users:

1. Reset password.
2. Require re-register MFA.
3. Revoke sessions.
4. Optionally enforce stricter sign-in frequency and persistent browser session settings via Conditional Access for high‑risk users or critical apps.

---

References:

• Manage user authentication methods for Microsoft Entra multifactor authentication
• Reauthentication prompts and session lifetime for Microsoft Entra multifactor authentication
• Conditional Access adaptive session lifetime policies
• Session timeouts for Microsoft 365
• Microsoft Entra ID Protection scenario: User identity risk self-remediation for enterprise-managed resources
• Microsoft Entra ID Protection risky user report