Edit

Conditional Access adaptive session lifetime policies

Overview

Conditional Access adaptive session lifetime policies let organizations restrict authentication sessions in complex deployments. Scenarios include:

  • Resource access from an unmanaged or shared device
  • Access to sensitive information from an external network
  • High impact users
  • Critical business applications

Conditional Access provides adaptive session lifetime policy controls, so you can create policies that target specific use cases within your organization without affecting all users.

Before exploring how to configure the policy, examine the default configuration.

User sign-in frequency

Sign-in frequency specifies how long a user can access a resource before being asked to sign in again.

The Microsoft Entra ID default configuration for user sign-in frequency is a rolling window of 90 days. It might seem sensible to ask users for credentials often, but this approach can backfire. Users who habitually enter credentials without thinking might unintentionally provide them to malicious prompts.

Not asking a user to sign back in might seem alarming, but any IT policy violation revokes the session. Examples include a password change, a noncompliant device, or an account being disabled. You can also explicitly revoke users’ sessions using Microsoft Graph PowerShell. The Microsoft Entra ID default configuration is: don’t ask users to provide their credentials if the security posture of their sessions hasn’t changed.

The sign-in frequency setting works with apps that implement OAuth2 or OIDC protocols according to the standards. Most Microsoft native apps, like those for Windows, Mac, and Mobile including the following web applications comply with the setting.

  • Word, Excel, PowerPoint Online
  • OneNote Online
  • Office.com
  • Microsoft 365 Admin portal
  • Exchange Online
  • SharePoint and OneDrive
  • Teams web client
  • Dynamics CRM Online
  • Azure portal

Sign-in frequency (SIF) works with non-Microsoft SAML applications and apps that use OAuth2 or OIDC protocols, as long as they don’t drop their own cookies and regularly redirect back to Microsoft Entra ID for authentication.

User sign-in frequency and multifactor authentication

Previously, sign-in frequency applied only to first-factor authentication on Microsoft Entra joined, hybrid joined, and registered devices. You couldn't easily reinforce multifactor authentication on those devices. Based on customer feedback, sign-in frequency now applies to multifactor authentication (MFA) as well.

A diagram showing how Sign in frequency and MFA work together.

User sign-in frequency and device identities

On Microsoft Entra joined and hybrid joined devices, unlocking the device or signing in interactively refreshes the Primary Refresh Token (PRT) every four hours. The last refresh timestamp recorded for the PRT compared with the current timestamp must be within the time allotted in SIF policy for the PRT to satisfy SIF and grant access to a PRT that has an existing MFA claim. On Microsoft Entra registered devices, unlocking or signing in doesn't satisfy the SIF policy because the user isn't accessing a Microsoft Entra registered device through a Microsoft Entra account. However, the Microsoft Entra WAM plugin can refresh a PRT during native application authentication by using WAM.

Note

The timestamp captured from user sign-in isn't necessarily the same as the last recorded timestamp of PRT refresh because of the four-hour refresh cycle. The case when it's the same is when the PRT expires and a user sign-in refreshes it for four hours. In the following examples, assume SIF policy is set to one hour and the PRT is refreshed at 00:00.

Example 1: When you continue to work on the same doc in SPO for an hour

  • At 00:00, a user signs in to their Windows 11 Microsoft Entra joined device and starts work on a document stored on SharePoint Online.
  • The user continues working on the same document on their device for an hour.
  • At 01:00, the user is prompted to sign in again. This prompt is based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator.

Example 2: When you pause work with a background task running in the browser, then interact again after the SIF policy time elapsed

  • At 00:00, a user signs in to their Windows 11 Microsoft Entra joined device and starts to upload a document to SharePoint Online.
  • At 00:10, the user locks their device. The background upload continues to SharePoint Online.
  • At 02:45, the user unlocks the device. The background upload shows completion.
  • At 02:45, the user is prompted to sign in when they interact again. This prompt is based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator since the last sign-in happened at 00:00.

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.

Example 3: With four hour refresh cycle of primary refresh token from unlock

Scenario 1 - User returns within cycle

  • At 00:00, a user signs into their Windows 11 Microsoft Entra joined device and starts work on a document stored on SharePoint Online.
  • At 00:30, the user locks their device.
  • At 00:45, the user unlocks the device.
  • At 01:00, the user is prompted to sign in again. This prompt is based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator, one hour after the initial sign-in.

Scenario 2 - User returns outside cycle

  • At 00:00, a user signs into their Windows 11 Microsoft Entra joined device and starts work on a document stored on SharePoint Online.
  • At 00:30, the user locks their device.
  • At 04:45, the user unlocks the device.
  • At 05:45, the user is prompted to sign in again. This prompt is based on the sign-in frequency requirement in the Conditional Access policy configured by their administrator. It's now one hour after the PRT was refreshed at 04:45, and over four hours since the initial sign-in at 00:00.

Require reauthentication every time

In some scenarios, you might want to require fresh authentication every time a user performs specific actions, such as:

  • Accessing sensitive applications.
  • Securing resources behind VPN or Network as a Service (NaaS) providers.
  • Securing privileged role elevation in PIM.
  • Protecting user sign-ins to Azure Virtual Desktop machines.
  • Protecting risky users and risky sign-ins identified by Microsoft Entra ID Protection.
  • Securing sensitive user actions like Microsoft Intune enrollment.

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. Setting sign-in frequency to every time works best when the resource has the logic to identify when a client should get a new token. These resources redirect the user back to Microsoft Entra only once the session expires.

Limit the number of applications that enforce a policy requiring users to reauthenticate every time. Triggering reauthentication too frequently can increase security friction to a point that it causes users to experience MFA fatigue and open the door to phishing. Web applications usually provide a less disruptive experience than their desktop counterparts when require reauthentication every time is enabled. The policy 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.

Warning

Using sign-in frequency to require reauthentication every time, without multifactor authentication might result in sign-in looping for your users.

Every time strict (preview)

Every time strict (preview) is a sign-in frequency control with a shorter validity window (10 seconds) for authentication freshness. It's intended for specific applications that need fresh authentication when they request a new token. These applications must be configured to work with the control. Examples include pharmaceutical e-prescribing applications and financial or banking applications that require reauthentication for sensitive actions.

To require fresh authentication for a sensitive action, an application needs compatible session management. That logic must request a new token for the action. Applying the control alone isn't sufficient if the application continues to use its existing session without requesting a new token.

The application decides when fresh authentication is needed through its own session management logic and intervals. Its reauthentication interval can be longer than 10 seconds. When the application requests a new token, Every time strict (preview) checks the time since the user's last authentication. If at least 10 seconds have elapsed, the control requires the user to reauthenticate.

  • Target only specific applications. Don't apply it broadly to all resources.
  • Work with the application owner to confirm that the application's token requests and session management meet its reauthentication requirements.
  • Test the sign-in experience with the selected applications before rollout. Frequent prompts can disrupt users and contribute to MFA fatigue.

Warning

Do not apply Every time strict (preview) settings to Office 365 applications.

Global Secure Access sign-in every time (preview)

Global Secure Access uses Every time strict (preview) in Conditional Access to require fresh reauthentication when users access sensitive private applications. Global Secure Access application session management uses a five-minute reauthentication window.

For more information, see Sign-in every time for Microsoft Entra Private Access (preview).

Persistence of browsing sessions

A persistent browser session lets users stay signed in after closing and reopening their browser window.

Microsoft Entra ID's default for browser session persistence lets users on personal devices decide whether to persist the session by showing a Stay signed in? prompt after successful authentication. If you set up browser persistence in AD FS by following the guidance in AD FS single sign-on settings, the policy is followed, and the Microsoft Entra session is persisted as well. You configure whether users in your tenant see the Stay signed in? prompt by changing the appropriate setting in the company branding pane.

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. So, token caching can be in direct violation of desired security policies for authentication. Storing tokens beyond the current session might seem convenient, but it can create a security vulnerability by allowing unauthorized access to Microsoft Entra artifacts.

Configuring authentication session controls

Conditional Access is a Microsoft Entra ID P1 or P2 capability that requires a premium license. For more information about Conditional Access, see What is Conditional Access in Microsoft Entra ID?.

Warning

If you use the configurable token lifetime feature, don't create two different policies for the same user or app combination: one with this feature and another with the configurable token lifetime feature. Microsoft retired the configurable token lifetime feature for refresh and session token lifetimes on January 30, 2021, and replaced it with the Conditional Access authentication session management feature.

Before enabling sign-in frequency, ensure other reauthentication settings are disabled in your tenant. If "Remember MFA on trusted devices" is enabled, disable it before using sign-in frequency, as using these two settings together might prompt users unexpectedly. For more information about reauthentication prompts and session lifetime, see Optimize reauthentication prompts and understand session lifetime for Microsoft Entra multifactor authentication.

Next steps

  • Last updated on