How long may a renewing session go without a fresh authentication ceremony when the business refuses prompts?

## What is actually being negotiated Not whether multi-factor is on: that argument is over, and it settles the ceremony. What remains are two numbers, and both are paid for in friction by people who do not report to you. 1. How long a session may keep renewing before authentication must happen again. 2. Which operations refuse to run unless it happened recently. The engineering here is trivial - they are tenant settings. The difficulty is that the cost lands on conversion rates, support volume and executive patience, while the benefit is an exposure that nobody has felt yet. ## Dial one: the absolute lifetime must be finite The argument to make in the room is about pricing. Access acquired as a live session is worth *reach multiplied by duration*. Reach is set by the account's job and you rarely get to shrink it. Duration is the dial you own, and if the absolute lifetime is unset, duration is open-ended: the session keeps renewing for as long as it is used, and no factor is ever demanded again. That is the difference between an exposure you can put a number on and one you cannot. So the non-negotiable is a finite ceiling, measured from the original authentication rather than from last use, with a different value per population. The idle timeout is not a substitute: it restarts on every request, including automated ones. ## Dial two: spend prompts where they buy durability Prompt budgets are real and they deplete. Every additional prompt makes the next one more likely to be dismissed without reading, which means over-prompting actively damages the one demand that mattered. So place them by the durability test: gate the operations whose effect outlives the session - password change, enrolling or removing a factor, editing recovery contact, granting delegated administration - and leave reads alone. A prompt on a read costs the same and buys nothing, because the session already had that reach. ## Dial three: differentiate, and refuse the loudest exemption One lifetime for the whole tenant is a political convenience, not a design. Delegated administrators, finance approvers and anyone who reaches the customer database should have short lifetimes and more gated operations; broad staff populations can carry longer ones. The request that arrives is almost always the opposite: the most senior person, with the most reach, asking to be exempted because prompts are irritating. That is the exemption with the highest price, because value scales with reach. If it cannot be refused outright, invert it - the exemption becomes a shorter lifetime and a smaller set of gated operations rather than none of either - and be explicit that you traded down rather than surrendered. ## When you lose the argument Write the decision down with the owner's name against it, keep the privileged-population settings you did win, and revisit it on a date rather than on a hope. "Security asked and was told no" is a different organisational fact from "nobody considered it", and only the first survives contact with the person who eventually asks why the number was infinite. ## What you can honestly promise a customer or a regulator Express the promise as configuration, not intent: *these operations refuse to run unless authentication happened within N minutes; administrator sessions have an absolute lifetime of H hours; the same applies on the API path as on the interactive one.* If any of those three is unset, the promise is not one you can make, and saying so before signing is cheaper than saying it afterwards. ## The trap this question is really testing Conflating factor strength with exposure duration. Buying hardware keys for the whole company improves the ceremony and changes nothing about how many days an already-issued session stays honoured. Both are needed; usually only the first is funded, because it is the one with a purchase order attached.