Sign-in frequency and persistent sessions: getting Conditional Access session controls right
In our audits we see two opposite extremes: tenants where nobody ever re-authenticates, and tenants where users complete MFA several times a day with no real security gain. Conditional Access session controls let you find a sensible middle ground, provided you understand what they actually do.
Entra ID default behaviour
With no specific policy, Microsoft Entra ID favours continuity: refresh tokens are renewed as long as they are used, and a session can remain valid for a very long time on a device that is used regularly. This is not an unreasonable choice. The session is revoked when the password changes, when an administrator revokes sessions, or when continuous access evaluation detects a critical event. But for a browser on a personal computer, or for an administrative account, that lifetime is often too long.
These controls should also be kept separate from the idle session timeout for Microsoft 365 web apps, which is configured elsewhere, in the Microsoft 365 admin center. Sign-in frequency is not an inactivity timeout: it sets the interval after which the user must authenticate again, whether or not they were active.
Sign-in frequency
This session control forces a new interactive authentication after a period expressed in hours or days. It applies to the scope of the policy: users, applications, conditions. A few points to keep in mind:
- re-authentication covers the factors required by the policy: password, MFA, or both depending on the context;
- on a Windows device joined to Entra ID, the check relies on the age of the Primary Refresh Token (PRT): a recent Windows sign-in may be enough to satisfy the condition;
- overlapping policies with different values result in the most restrictive one being applied, which often catches teams by surprise.
The "Every time" option
Sign-in frequency also offers an "Every time" value. It forces re-authentication each time the policy is evaluated, with a small tolerance to avoid loops. It is not meant for general use. Its use cases are specific:
- policies based on sign-in risk or user risk, so that risk remediation genuinely goes through a fresh authentication;
- Intune device enrolment or security information registration;
- access to a sensitive action protected by an authentication context, such as activating a privileged role.
Not every application handles this mode in the same way; check the current Microsoft documentation for supported scenarios before extending it.
Persistent browser session
This second control determines whether the browser session survives the browser being closed. It has two values, "Always persistent" and "Never persistent", and overrides the choice users would otherwise make at the "Stay signed in?" prompt. It is only available when the policy targets all resources. "Never persistent" is the most useful value: on an unmanaged or shared device, it guarantees that closing the browser ends the session.
Too much MFA hurts MFA. Overly frequent re-authentication prompts train users to approve without thinking. That reflex is exactly what MFA fatigue attacks and phishing exploit. A few prompts, in the right places, work better.
Finding the balance
The right approach is to differentiate by context rather than apply a single value to everyone. The table below is a reasonable starting point, to be adjusted to your organisation:
| Context | Sign-in frequency | Persistent session |
|---|---|---|
| Managed, compliant device | Default behaviour | Default behaviour |
| Browser on an unmanaged device | A few hours | Never persistent |
| Admin roles and admin portals | Short, in the order of a few hours | Never persistent |
| Risky sign-in or risky user | Every time | Not applicable |
On managed devices, protection relies more on device compliance, phishing-resistant methods and continuous access evaluation than on repeated re-authentication.
What an audit checks
- Specific session controls for unmanaged devices and privileged accounts.
- Overlapping policies that unintentionally enforce an overly short frequency.
- Use of the "Every time" option in risk-based policies.
- Consistency between the persistent session setting and the "Stay signed in?" prompt.
- A clear distinction between sign-in frequency and the Microsoft 365 idle session timeout.