Why does a renewing session survive a policy that demands MFA at every login?

## Where the gate actually sits "Multi-factor on every login" is a condition on the **authentication ceremony**. The ceremony runs when a client turns up without a usable session: a new device, a cleared browser, a lapsed session. The population subject to the policy is therefore *people signing in*. Someone who acquired a session that has already been issued is not in that population, and never enters it while the session keeps working. ## Three mechanics that stop the next login happening **Idle (inactivity) timeout.** Measured from last use. Every request restarts the clock, and "use" does not mean a person: scripted or scheduled activity keeps it alive just as well. A session in continuous use never becomes idle, so an idle timeout alone bounds nothing. **Renewal.** Short access-token lifetimes are routinely mistaken for short session lifetimes. When an access token expires, a refresh credential is exchanged for a new one. That exchange is machine-to-machine: no prompt, no factor, no human. It can repeat for as long as the provider is willing to honour the refresh credential. **Persistent sign-in.** The "stay signed in" or "remember this browser" choice deliberately makes the session survive browser restarts, which removes the most common accidental trigger for a fresh ceremony. None of the three re-runs the ceremony, so none of them re-presents a factor. ## The one setting that does force a ceremony An **absolute session lifetime**: a hard ceiling measured from the original authentication rather than from last use. When it is reached, the provider stops honouring renewal and a ceremony is required. It is the only one of the timers that cannot be pushed forward by using the session. Plenty of tenants leave it unset or set it in weeks, in which case there is no future moment at which the factor must be presented again. ## Reading it off the token An ID token minted by renewal is explicit about this if you read the right fields. `auth_time` still points at the original ceremony. `amr` still lists the methods used *then*, unchanged. `iat` and `exp` describe this token only. A token issued this morning can be a month of renewal away from any human. ## Why this changes what the access is worth Someone who acquires one live session and never goes further - no code running anywhere, no host owned - holds exactly one identity's worth of access, and prices it by how long it will still be honoured multiplied by what that identity reaches. Where no ceiling exists, the duration term is "until somebody ends it". That is precisely why live sessions are traded rather than passwords: no factor stands between the buyer and the tenant. It also means the acquirer's own restraint predicts nothing - the objective belongs to whoever ends up holding it. ## Where a factor can still be demanded Not by the login policy, but by an operation. OpenID Connect expresses it two ways: `prompt=login` forces the provider to authenticate the user again, and `max_age` sets the maximum acceptable age in seconds since `auth_time`, obliging re-authentication when the last ceremony is older than that. Both are demands attached to a request for an operation, which is a different control class from a rule about logins. ## The corrected claim The common senior answer is: *we mandate multi-factor on every login, so a stolen session is bounded by the next login.* The correction is that a renewing session may never present a login again. The bound is the absolute lifetime plus whatever operations demand recent authentication - and when the first is unset and the second is empty, there is no bound at all.