Share via

Mitigating the "Session Gap": Entra ID Policy Enforcement vs. Application-Level Session Cookies

passione 60 Reputation points
2026-04-24T06:18:05.85+00:00

Hi community,

I am evaluating the security posture of our SSO environment, specifically focusing on the disconnect between Entra ID token issuance and application session management. My assessment is based on two distinct scenarios:

Managed Devices (PRT-based): These devices use a Primary Refresh Token (PRT) to provide "Silent SSO." While this satisfies MFA requirements automatically, I am concerned about the "MFA Claim" persistence. If an app-specific Conditional Access policy requires a Sign-In Frequency (SIF) check, how does Entra ID effectively "signal" the application to invalidate its internal session cookie and force a fresh interactive MFA, especially if the PRT is still valid and "healthy"?

Unmanaged/Personal Devices (Cookie-based): These devices rely entirely on browser cookies for SSO. Since Entra ID only evaluates CA/MFA during the initial token exchange, the application's internal session cookie could potentially outlive the Entra ID session. How can we ensure that a session on an unmanaged device is terminated immediately across all apps when the browser is closed or the user's risk level changes, given that there is no PRT to manage the lifecycle?

  1. App-Specific Enforcement: Why do certain apps successfully force re-authentication via SIF while others continue to allow access via their own local cookies without checking back with Entra ID? Is there a specific OIDC/SAML attribute or "Session Management" standard we should look for in SaaS apps to ensure they don't "hide" from Entra ID policies?
Microsoft Security | Microsoft Entra | Microsoft Entra ID
0 comments

Answer accepted by question author

  1. Rukmini 40,235 Reputation points Microsoft External Staff Moderator
    2026-04-24T06:53:46.6166667+00:00

    Hey passione—what you’re running into is the classic “identity-side session” vs. “app-side session” gap. Entra ID (formerly Azure AD) issues tokens under CA policies (like MFA, Sign-in Frequency, CAE) but most apps then mint their own cookies or sessions and rarely check back with the IdP. Here’s how to tighten that up:

    1. Managed/PRT-based devices (Silent SSO + PRT)
      • Use a Sign-in Frequency (SIF) CA policy. When you scope SIF to an app (or all apps), Entra ID stamps a max_age claim into the tokens. Once that window expires (counted from the last PRT refresh), any AcquireToken call (MSAL AcquireTokenSilent or interactive) will force MFA again.
      • Caveat: Your app must be built to honor that. If it never reacquires tokens (e.g. keeps users on a decade-long cookie), it won’t see max_age expiry. You need to adopt an OAuth2/OIDC flow that periodically checks token lifetimes or triggers silent/token refreshes.
      • To handle CA policy changes (e.g. you tighten MFA requirements), enable Continuous Access Evaluation (CAE). CAE-aware apps (Exchange Online, SharePoint Online, MS Graph) will get near-real-time revocation notifications on events like force-sign-out, password reset, user risk flagged, etc.
    2. Unmanaged/browser-cookie-only devices
      • In your Conditional Access session controls, disable “Persistent browser session.” That makes ESTSAUTH (the browser session cookie) transient—once the user closes the browser, the cookie is gone.
      • For on-the-fly risk changes (e.g. Identity Protection flags high risk), again rely on CAE. CAE-capable apps will either drop the session immediately or kick back to Entra ID for reauthentication when they see a claims challenge.
      • Make sure your apps implement OIDC front-channel or back-channel logout. When a user signs out in one app or via https://login.microsoftonline.com/common/oauth2/v2.0/logout, Entra ID can ping each app’s end_session_endpoint so they clear their cookies.
    3. Why some apps reauth and some don’t
      • Only apps that follow OAuth2/OIDC standards for session management (max_age, check_session_iframe, end_session_endpoint) or that support CAE will honor SIF and real-time revocation.
      • If an app simply issues its own session cookie and never talks to the IdP again, it “hides” from your CA policies. To avoid that, look for SaaS vendors that advertise: • OIDC Session Management support (per the OpenID spec: max_age, session state checks, front/back-channel logout) • Continuous Access Evaluation support • SAML SingleLogout bindings

    In short, you need a blend of:

    • Conditional Access session controls (Sign-in Frequency + Persistent Browser Session)

    • Continuous Access Evaluation for real-time revocation

    • App-side implementation of OIDC session management (max_age, end_session_endpoint) or SAML SLO

    Hope that helps tighten up the “session gap”!

    — Reference Links —

    1. Conditional Access session controls (Sign-in Frequency, Persistent Browser Session) https://docs.microsoft.com/azure/active-directory/conditional-access/concept-conditional-access-session https://docs.microsoft.com/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime#user-sign-in-frequency
    2. Continuous Access Evaluation (CAE) https://docs.microsoft.com/azure/active-directory/conditional-access/concept-continuous-access-evaluation
    3. OIDC Session Management spec (max_age, check_session_iframe, end_session_endpoint) https://openid.net/specs/openid-connect-session-1_0.html
    4. Browser session cookies in Entra ID https://learn.microsoft.com/entra/identity/authentication/concept-authentication-web-browser-cookies
    5. Microsoft Entra Identity Protection & CAE real-time revocation https://docs.microsoft.com/azure/active-directory/conditional-access/concept-continuous-access-evaluation#customize-continuous-access-evaluation

    Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making. If the resolution was helpful, kindly take a moment to click on 210246-screenshot-2021-12-10-121802.pngand click on Yes for was this answer helpful. And, if you have any further query do let us know.

    Was this answer helpful?

    1 person found this answer helpful.

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.