The 5-Minute Skew Behind "Every Time" Sign-in Frequency in Microsoft Entra ID

Conditional Access sign-in frequency set to Every time includes five minutes of clock-skew tolerance, so users are not prompted more often than once every five minutes. That is the core documented behaviour. Microsoft's configuration guide adds a useful example: if a user completed MFA in the previous five minutes and encounters another policy requiring reauthentication, Entra ID does not prompt again.

Around that rule, a more elaborate story has grown: an “MFA grace period” that joins prompts across Outlook, Teams, and OneDrive, requires a matching method, and is cancelled by a password change. Some parts are plausible, but they should not be repeated as documented product rules. More importantly, Microsoft advises using a time-based frequency for Microsoft 365 apps.

This article separates the documented rule from inference and shows where Every time fits in a policy set.

What “Every time” actually does

Every time requires full reauthentication when the session is evaluated. It does not, by itself, trigger on every app launch, tab open, or browser restart. Microsoft notes that someone who closes and reopens a browser during the session lifetime might not be prompted at all. The setting works best when the resource knows when a client needs a new token and redirects to Entra ID when its own session expires. Microsoft Learn: Require reauthentication every time (https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-session-lifetime#require-reauthentication-every-time)

Two practical consequences follow:

• Prompt count depends on the resource. A web app with a long session may redirect rarely. A desktop client that asks for tokens frequently can encounter policy evaluation more often. Microsoft says web apps usually provide a less disruptive experience than desktop apps under this setting.
• Every time without MFA can loop. Microsoft explicitly warns that requiring reauthentication every time without multifactor authentication might cause sign-in loops.
How the five-minute skew works

Microsoft calls this clock skew, not a configurable grace period. With Every time selected, Entra ID accounts for five minutes of skew so users are not prompted more often than once every five minutes. The configuration guide's prompt-tolerance section (https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-session-lifetime#prompt-tolerance) specifically says that recent MFA completion can avoid a second prompt when another Conditional Access policy requires reauthentication.

Read the diagram as a policy evaluation, not a timer that starts on app launch. The next prompt opportunity occurs only when the resource causes another evaluation. Other controls can still affect access.

The documentation does not establish a universal timestamp rule for every client and authentication path. It does not describe method matching, cross-app cookie independence, or a tenant setting to change the five minutes. Treat those as questions to test in your own environment, especially when authentication strengths or authentication context are involved.

For an audit narrative, compare initial interactive sign-ins and later policy evaluations in the sign-in logs (https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-ins). Record the app, client type, authentication details, Conditional Access result, and prompt time. The log evidence should carry the claim, rather than an assumed timeline.

Common claims, checked against the docs

Claim | Status | What Microsoft documents |
It is an “MFA grace period.” | Imprecise | The guidance calls it five minutes of clock skew or prompt tolerance. It does mention recent MFA completion as an example. |
It makes Every time suitable for Outlook, Teams, and OneDrive. | Contradicted | Use time-based sign-in frequency for Microsoft 365 apps and limit how many apps require Every time. |
Every path measures exactly five minutes from MFA completion. | Not established | The configuration guide gives a recent-MFA example, but no universal anchor rule for all paths. |
A second prompt is suppressed only when the same MFA method or strength is used. | Not documented | No method-matching rule is described in the two session-lifetime guides. |
A password change or revocation “overrides” this special window. | Not skew-specific | Session revocation after a password change or explicit revocation is described as general session behaviour. |
The rule spans desktop apps independently of browser cookies. | Not documented | Enforcement occurs at session evaluation; client and resource token behaviour determine when that happens. |

These unverified claims are not necessarily false. They need tenant-specific evidence before they belong in a design document or audit response. The morning-boot story of Outlook, Teams, and OneDrive requesting tokens together may describe a real experience, but it is a poor reason to deploy an Every time policy across Microsoft 365.

Where Every time belongs

Microsoft lists (https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-session-lifetime#require-reauthentication-every-time) sensitive applications, VPN or Network-as-a-Service resources, PIM role elevation, Azure Virtual Desktop sign-in, risky users or sign-ins, and sensitive actions such as Intune enrollment as examples where fresh authentication can be justified. These are discrete, high-value events where a prompt has clear context.

For the Azure portal and Entra admin center, Microsoft suggests a time-based frequency or reauthentication on PIM activation through authentication context. The latter scopes the request to the elevation event. PIM role-setting guidance (https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-change-default-settings) also describes a separate ten-minute reauthentication window across role activations, so do not confuse that PIM behaviour with the five-minute sign-in-frequency tolerance.

Design guidance

Requirement | Use | Why |
Shorter Microsoft 365 sessions | Time-based sign-in frequency in hours or days | Microsoft's stated recommendation; avoids repeated prompts from desktop clients. |
Fresh auth for privileged elevation | Every time, scoped through authentication context on PIM activation | The prompt is tied to role activation. |
Risk remediation | Every time with the appropriate risk-based grant control | A documented scenario; test the complete policy in report-only mode first. |
Intune enrollment or AVD sign-in | Every time, scoped to the action or resource | These are discrete sign-in events. |
Microsoft Entra Private Access | Time-based frequency | Private Access does not support Every time. (https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-session-lifetime#known-issues) |

Before deploying Every time:

• Disable Remember MFA on trusted devices. Microsoft warns that combining it with sign-in frequency can create unexpected prompts.
• Pair it with MFA or a suitable authentication strength to avoid sign-in loops.
• Keep the application scope small. Frequent prompts increase friction and can contribute to MFA fatigue.
• Account for mobile reauthentication delays. Microsoft reports an average of about 30 seconds after each frequency interval.
• Test in a test tenant, then validate policy results and actual prompts in sign-in logs before rollout.
Takeaway

The five-minute tolerance is a real safety valve. It is not a reason to build a Microsoft 365-wide Every time policy. Use this control for specific, high-risk events; use time-based frequency for Microsoft 365 productivity apps. Document anything beyond Microsoft's stated behaviour as a tested observation in your tenant.

Sources

• Conditional Access adaptive session lifetime policies (https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-session-lifetime), Microsoft Learn.
• Configure adaptive session lifetime policies (https://learn.microsoft.com/en-us/entra/identity/conditional-access/howto-conditional-access-session-lifetime), Microsoft Learn.
• Configure Microsoft Entra role settings in PIM (https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-change-default-settings), Microsoft Learn.