Which tenant operations must demand fresh proof of authentication, and what does that gate still not deny?

## What class of control this is This is a **preventive precondition**, usually called re-authentication or step-up. It is not about *who* the identity is - that question was settled at issuance - but about *how recently* the human behind it proved anything. It is the only control class that puts a factor back in front of someone who already holds a working session, because everything else about that session is honoured on possession. ## Choosing the operations: the durability test Apply one question to each operation: **if this succeeds, does its effect keep working after the session that performed it is gone?** - **Changing the password.** The effect is that the owner can no longer sign in and the holder decides who can. It converts a borrowed, expiring position into control of the account of record. - **Enrolling (or removing) an authentication factor.** The strongest of the four, and the one most often left ungated. Registering their own authenticator means they now pass the front door themselves; the session becomes disposable. - **Editing a recovery address or phone.** The quiet one, because nothing visibly changes today. Account recovery is a second front door, and this operation re-points it. - **Granting delegated administration.** Creates access attached to a different principal entirely, so it survives everything done to this identity. Contrast a large export or a bulk read. Damaging, certainly - but it produces no new access, so gating it spends friction without shortening anybody's foothold by a minute. ## How freshness has to be measured Freshness is a comparison against now, so the check must ask *when did authentication last happen* rather than *what does the session say about itself*. OpenID Connect gives the vocabulary: `max_age` sets the maximum seconds since `auth_time` before the provider must authenticate the user again, and `prompt=login` forces a ceremony outright. A window of a few minutes is normal for this class of operation. The defect to name explicitly is trusting `amr`. That claim lists the methods used at the original ceremony and travels unchanged through renewal, so a token minted a month later still says a second factor was involved. Reading it as "this request is multi-factor protected" turns a historical statement into a permission. ## Where the check belongs On the server, at the operation, on **every** route that reaches it. The classic failures are an API that performs the change without the interactive flow's precondition, and a delegated-administration surface that edits another account's factors while only the self-service path is gated. Disabling a control in the interface is not a gate; it is a suggestion. ## What form the proof should take For the position we are discussing - someone holding exactly one live session, no code running anywhere, no host owned - even re-typing the current password is a real barrier, because they do not have it. But it is weaker against other positions and it is not a fresh ceremony, so the stronger demand is the enrolled second factor. That matters most on factor enrolment, where the password may already be known to whoever is asking. ## What the gate still does not deny Everything the identity can reach right now. The mailbox and the files it can open. Messages sent in the user's name and believed because of it. Approvals that user is entitled to click. Directory information visible to any employee. Fresh proof bounds **how durable** the access becomes; it does nothing to **how far** it reaches while the session is honoured. A candidate who says step-up "protects the data" has the direction of the claim wrong, and it is the most common wrong answer on this subject after the multi-factor one. ## Failure modes worth naming - One path gated, another not. - The recency window measured in hours, which for an active holder is no window at all. - The gate in the interface rather than the service. - `amr` accepted as proof of recency. - Prompts sprinkled over reads, so users learn to click through the one that mattered.