Conditional Access Session Controls, Sign-In Frequency, Named Locations: What Actually Revokes a Live Token

Conditional Access Session Controls Sign-In Frequency Named Locations: What Each One Controls

If you searched for conditional access session controls sign-in frequency named locations, you are almost certainly chasing one question: does tightening a session control actually eject anyone who is already signed in? The short answer is no. A session control describes what happens the next time Microsoft Entra ID evaluates the session — it does not reach into an access token that has already been issued and take it back.

Microsoft's session controls reference lists eight controls: application enforced restrictions, Conditional Access application control, sign-in frequency, persistent browser session, customize continuous access evaluation, disable resilience defaults, require token protection for sign-in sessions, and use Global Secure Access security profile. Two of them — sign-in frequency and persistent browser session — behave over time in ways documented on a separate page, adaptive session lifetime policies, which is also where Microsoft states that "Conditional Access is a Microsoft Entra ID P1 or P2 capability that requires a premium license."

If you audit those settings through Microsoft Graph rather than the portal, the picture is narrower still. The v1.0 conditionalAccessSessionControls resource exposes exactly five properties — applicationEnforcedRestrictions, cloudAppSecurity, disableResilienceDefaults, persistentBrowser, signInFrequency — so a script that enumerates v1.0 session controls will not see token protection or the CAE toggle at all.

The default is more permissive than most admins assume. Microsoft states plainly: "The Microsoft Entra ID default configuration for user sign-in frequency is a rolling window of 90 days." The rationale is explicit — "don't ask users to provide their credentials if the security posture of their sessions hasn't changed."

How It Works: When a Policy Is Actually Evaluated

This is the sentence that governs everything else. From Microsoft's network signals documentation:

Conditional Access policies are evaluated when: a user initially signs in to a web app, mobile or desktop application. A mobile or desktop application that uses modern authentication, uses a refresh token to acquire a new access token. By default, this check occurs once an hour.

And, for browsers: "for web applications, policies apply at initial sign-in and are good for the lifetime of the session at the web application." Microsoft adds the practical consequence: "By default, Microsoft Entra ID issues tokens hourly. After users move off the corporate network, within an hour the policy is enforced for applications using modern authentication."

So a location policy is a renewal-time check, not a live tripwire — unless continuous access evaluation is in play.

Sign-in frequency, including "Every time"

Sign-in frequency "specifies how long a user can access a resource before being asked to sign in again." Choosing Every time does not mean continuously. Microsoft: "When you select Every time, the policy requires full reauthentication when the session is evaluated. This requirement means that if the user closes and opens their browser during the session lifetime, they might not be prompted for reauthentication." The control also "factors in five minutes of clock skew when every time is selected, so that it doesn't prompt users more often than once every five minutes."

Enforcement is also deferred for anything non-interactive: "If the client app (under activity details) is a browser, the system defers sign-in frequency enforcement of events and policies on background services until the next user interaction. On confidential clients, the system defers sign-in frequency enforcement on non-interactive sign-ins until the next interactive sign-in."

On joined devices there is a second clock: "unlocking the device or signing in interactively refreshes the Primary Refresh Token (PRT) every four hours." Microsoft's own worked example has a one-hour SIF policy prompting the user at 05:45 — five hours and 45 minutes after the initial 00:00 sign-in — because the PRT was refreshed at 04:45.

Continuous access evaluation is the part that revokes

Continuous access evaluation (CAE) is what turns policy into near-real-time revocation, and it does so for a closed list of critical events: a user account is deleted or disabled; a password is changed or reset; MFA is enabled for the user; an administrator explicitly revokes all refresh tokens; high user risk is detected by ID Protection. Microsoft's stated latency: "the goal for critical event evaluation is for response to be near real time, but latency of up to 15 minutes might be observed because of event propagation time; however, IP locations policy enforcement is instant."

The trade is longer tokens: "Token lifetime increases to long-lived, up to 28 hours, in CAE sessions." Without CAE-capable clients, "your default access token lifetime remains 1 hour." And critically for this article: "Sign-in Frequency is honored with or without CAE."

The Gap: Where a Live Token Outlives Your Policy

1. Country-based named locations are invisible to CAE

This is the single highest-value line in the CAE documentation:

CAE only has insight into IP-based named locations. CAE doesn't have insight into other location conditions like MFA trusted IPs or country/region-based locations. When a user comes from an MFA trusted IP, trusted location that includes MFA Trusted IPs, or country/region location, CAE won't be enforced after that user moves to a different location. In those cases, Microsoft Entra issues a one-hour access token without instant IP enforcement check.

A "block access from outside these countries" policy therefore reverts the tenant to the pre-CAE hourly model. Microsoft's own guidance is unambiguous: "Don't use country/region location conditions or the trusted ips feature that is available in Microsoft Entra multifactor authentication's service settings page."

2. Too many IP ranges silently disables live location enforcement

"When the sum of all IP ranges specified in location policies exceeds 5,000, CAE can't enforce user change location flow in real time. In this case, Microsoft Entra issues a one-hour CAE token." The threshold is tenant-wide — the sum across every location policy, not a per-policy cap — so it is crossed by accumulation rather than by any single edit. Only location enforcement degrades: "CAE continues enforcing all other events and policies besides client location change events." The structural limits are also finite: no more than 195 named locations, no more than 2,000 IP ranges per named location, and only CIDR masks greater than /8.

3. Split egress paths trigger the IP-variation exception

When the IP Entra sees and the IP the resource provider sees differ — proxies, split-tunnel VPN, SD-WAN, SNAT, IPv6 — "Microsoft Entra interprets that the client continues to be in an allowed location and should be granted access. Therefore, Microsoft Entra issues a one-hour token that suspends IP address checks at the resource until token expiration." That is standard mode, on by default. Microsoft's stricter alternative, which its CAE page still labels Public Preview, is strict location enforcement: "immediately stopping access if the IP address detected by the resource provider isn't allowed by Conditional Access policy."

4. Persistent browser cookies survive the policy

Microsoft's warning on persistence is blunt: "In persistent browsers, cookies remain stored on the user's device even after the browser is closed. These cookies might access Microsoft Entra artifacts, which remain usable until token expiration, regardless of the Conditional Access policies applied to the resource environment." An adversary-in-the-middle proxy that harvests that cookie inherits exactly this property — see Entra ID AiTM token replay and impossible travel detection and device code phishing for how the theft happens in the first place.

5. The device platform condition is unverified input

"Conditional Access identifies the device platform using information provided by the device, such as user agent strings. Because user agent strings can be modified, this information isn't verified." A platform condition is a scoping mechanism, not an authentication control. Microsoft's recommendation is to use it "with Microsoft Intune device compliance policies or as part of a block statement."

6. Policy edits do not apply retroactively

"Changes made to Conditional Access policies and group membership made by administrators could take up to one day to be effective… Some optimization is done for policy updates, which reduce the delay to two hours." Tightening a policy after an incident does not evict the sessions that already exist. Two further blind spots are worth naming: "CAE doesn't support Guest user accounts", and "Teams is made up of multiple services, the calls and chat services don't adhere to IP-based Conditional Access policies."

Detection

Start with the configuration, then the telemetry.

Import-Module Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes 'Policy.Read.All'

# Policies with no session controls at all, and those relying on country locations
Get-MgIdentityConditionalAccessPolicy |
    Select-Object DisplayName, State,
        @{n='SessionControls';e={ $_.SessionControls | ConvertTo-Json -Depth 4 -Compress }},
        @{n='Locations';e={ $_.Conditions.Locations | ConvertTo-Json -Depth 3 -Compress }}

# Named locations: which are IP-based (CAE-visible) and which are trusted
Get-MgIdentityConditionalAccessNamedLocation |
    Select-Object Id, DisplayName, AdditionalProperties

Both cmdlets need only Policy.Read.All; Microsoft lists Global Reader, Security Reader, Security Administrator and Conditional Access Administrator among the least-privileged roles for these reads. The equivalent REST calls are GET /identity/conditionalAccess/policies and GET /identity/conditionalAccess/namedLocations.

In the Graph response, an IP-based location is #microsoft.graph.ipNamedLocation with isTrusted and ipRanges[].cidrAddress; a country location is #microsoft.graph.countryNamedLocation with countriesAndRegions and includeUnknownCountriesAndRegions. Only the first kind is enforced live by CAE. A persistent browser control appears as persistentBrowser with mode of always or never, and sign-in frequency as signInFrequency with frequencyInterval of timeBased or everyTime.

The Azure Monitor SigninLogs table carries all of these. A starting query for the split-path problem:

SigninLogs
| where TimeGenerated > ago(7d)
| where isnotempty(IPAddressFromResourceProvider)
| where IPAddressFromResourceProvider != IPAddress
| summarize Sessions = count(),
            Users = dcount(UserPrincipalName)
        by AppDisplayName, IPAddress, IPAddressFromResourceProvider, ConditionalAccessStatus
| order by Sessions desc

Microsoft's SigninLogs table reference describes IPAddressFromResourceProvider as "the IP address a user used to reach a resource provider, used to determine Conditional Access compliance for some policies… This value is often null" — null is the healthy case, meaning both views agree. Its portal equivalent is the IP address (seen by resource) column in the sign-in logs, and Microsoft ships a public workbook template, Continuous Access Evaluation Insights, to surface the same mismatches.

Remediation

1. Convert enforcement-critical locations to IP-based named locations. Microsoft: "If you want your location policies to be enforced in real time by continuous access evaluation, use only the IP based Conditional Access location condition and configure all IP addresses, including both IPv4 and IPv6, that can be seen by your identity provider and resources provider." Keep country locations for coarse blocking only, and remember that a location marked trusted "can't be deleted without first removing the trusted designation."

2. Enumerate every egress IP — both views. Include the addresses Entra sees at authentication and the addresses Exchange Online, SharePoint Online, Teams and Microsoft Graph see. Do not pad the list: "Don't add non dedicated or nonenumerable egress IPs into Trusted Named Location Conditional Access rules as it can weaken security." Keep the tenant-wide total under 5,000 ranges.

3. Fix the proxy blind spot properly. With a cloud proxy or VPN, "the IP address Microsoft Entra ID uses while evaluating a policy is the IP address of the proxy. The X-Forwarded-For (XFF) header… isn't used because there's no validation that it comes from a trusted source." Microsoft recommends Global Secure Access source IP restoration, or a device-based control instead of an IP list.

4. Only then consider strict location enforcement. Validate first with the CAE workbook and the IP address (seen by resource) filter. Microsoft's caveat: "If traffic to Microsoft Entra ID or a CAE supported resource is through a shared or undefinable egress IP, don't enable strict location enforcement in your Conditional Access policies." Roll out group by group.

5. Set persistent browser to never — and scope it correctly. Graph documents the constraint directly on the property: "All apps should be selected for this session control to work correctly." A persistent-browser policy scoped to a subset of apps is not doing what its name implies.

6. Do not lean on the platform condition alone. Pair Device platforms with Intune compliance or the Filter for devices condition. Note that the older Device state condition is deprecated, and "device state and filters for devices can't be used together in Conditional Access policy."

7. Clear two known conflicts before enabling sign-in frequency. Disable "Remember MFA on trusted devices" first — "using these two settings together might prompt users unexpectedly" — and do not mix session controls with the legacy configurable token lifetime feature, which "Microsoft retired… for refresh and session token lifetimes on January 30, 2021."

8. Revoke explicitly during an incident. Because policy edits take up to a day (two hours with optimisation) to reach resource providers, use the direct action:

Import-Module Microsoft.Graph.Users.Actions

# A UPN can also be used as -UserId.
Revoke-MgUserSignInSession -UserId $userId

Revoke-MgUserSignInSession "invalidates all the refresh tokens issued to applications for a user (and session cookies in a user's browser), by resetting the signInSessionsValidFromDateTime user property to the current date-time." It needs User.RevokeSessions.All at minimum. The portal equivalent is Revoke Session on the user profile page. Confirm your break-glass accounts are excluded from any location policy before you tighten it.

9. Add token protection where the client supports it. Token protection "attempts to reduce attacks using token theft by ensuring a token is usable only from the intended device", and the TokenProtectionStatusDetails column in SigninLogs reports whether a sign-in token was bound to its device.

How EtcSec Detects This

An EtcSec Azure audit reads your Conditional Access policies and named locations through Microsoft Graph and flags the configuration gaps behind every scenario above: CA_NO_SESSION_CONTROLS when no enabled policy sets a sign-in frequency or a persistent browser mode, CA_PERSISTENT_BROWSER_ENABLED when browser cookies are allowed to persist, CA_NO_NAMED_LOCATIONS and CA_NO_TRUSTED_LOCATIONS when the tenant has no location vocabulary for CAE to enforce, CA_NO_LOCATION_BLOCK when no policy blocks on location at all, and CA_NO_PLATFORM_FILTER when no policy scopes by device platform. These pair naturally with the broader review in Entra ID Conditional Access gaps, baseline policy coverage gaps, and the end-to-end Entra ID security audit guide.