Sign-on policy settings: what's enforced now, and the one flag that still isn't
Session length and re-authentication interval on a sign-on policy used to be recorded and ignored. That's fixed — they're enforced now. What's left unenforced is narrower than this article used to say.
Which settings actually change behaviour, today
| Setting | Enforced? | Effect |
|---|---|---|
require_mfa | Yes | Asks for a second factor. Anyone covered who has not enrolled one is asked to add it on their next sign-in and is shown recovery codes once they have. |
deny | Yes | Refuses the sign-in outright. Beats every other policy regardless of rule order. Saving a deny that would leave nobody able to sign in is refused, checked against your organisation's current administrators inside and outside the office. |
require_email_verification | Yes | Decides whether an account with an unverified address may sign in at all. |
Session length (session_lifetime, session_lifetime_minutes/seconds) and re-authentication interval (reauth_seconds, require_reauth_seconds, reauth_minutes) | Yes, now. | A session issued under a policy carrying one of these genuinely ends at that lifetime, and re-authentication is genuinely demanded at that interval — propagated through login, refresh, WebAuthn step-up and SAML-issued sessions alike. |
A bare require_reauth: true, with no interval attached | No — this is the one setting still unenforced. | With no duration attached there is nothing to hold anyone to. Give it an actual interval and it takes effect; leave it as a bare flag and it stays exactly the kind of inert setting this whole article used to describe for everything in this table. |
Where session length is set
Session length and re-authentication interval are set on the global session policy — the same ordered-rule surface Sign-on policies and the decision trace documents, with its own risk, device and group conditions. The default policy a new organisation starts with already carries a session lifetime of eight hours. See Session policy and sign-out behaviour for the full set of numbers and what ends a session.
One limit worth knowing: these settings apply organisation-wide through whichever policy rule matches, not per group. If you need a shorter session specifically for one group of people rather than everyone a matching rule covers, that finer targeting is not available today.
What to do next
- If you previously removed a session-length setting from a policy because this article told you it did nothing, you can safely add it back — it will actually apply now.
- If you're setting re-authentication, always give it an actual interval rather than leaving a bare
require_reauth: true— that specific shape is still the one thing not enforced. - Read Session policy and sign-out behaviour for the full numbers, and Sign-on policies and the decision trace for how these settings interact with rule order and the per-sign-in trace.