You set the lease lifetime and renewal ceiling for every team's issued credentials — what do you trade off, and where do you land?

Setting lifetimes looks like picking numbers. It is really deciding how much of your reliability you are prepared to stake on every consumer's renewal code, in exchange for how small a window a stolen credential is useful in. ## The window: exposure against fragility The window is how long an issued credential is accepted before it must be extended. **Shortening it buys:** - A smaller value for any copy that escapes — a credential lifted from a host, a rendered file or a log is useful for the remainder of its window and no longer. - Faster decay of abandoned credentials, so the live population stays close to the number of running consumers. - Turnover that is observable, because a consumer which cannot renew shows up in hours rather than never. **Shortening it costs:** - Renewal traffic proportional to fleet size divided by the window, and a store that is now on the critical path more often. - Every consumer's renewal and retry path becomes load-bearing. Code that runs every 12 hours gets debugged; code that runs every 30 seconds gets debugged sooner, but it also fails sooner. - Correlated risk: with a short window, a store outage of the same order as the window is an estate-wide event rather than an inconvenience. The honest heuristic is to make the window comfortably longer than the worst renewal outage you intend to survive, and comfortably shorter than the interval at which your fleets redeploy. Those two constraints usually leave a range, not a point, and the range is where judgment goes. ## The ceiling: continuity against turnover The ceiling is how far renewal may push the window, measured from first issue. - A **high or absent** ceiling means well-behaved consumers keep one value alive indefinitely, and nobody ever learns whether the adoption path works. - A **low** ceiling means a forced re-issue on a schedule: a reconnect that nothing was wrong with, which is precisely what makes it a rehearsal rather than an incident. The number to reason from is how often you want the expensive path exercised. Something that runs on a normal working week is trustworthy; something that has never run is a plan. ## Classes, not one number One estate-wide number is wrong for someone. Two or three classes cover almost everything: | Class | Window | Ceiling | Why | |---|---|---|---| | Short job | minutes to an hour | equal to the window | finishes inside the window; no renewal machinery at all | | Long-running consumer | hours | days | renews continuously; the ceiling forces periodic re-issue | | Interactive operator | short, tied to the task | short | a person is present; no unattended renewal to build | Publish the class, the two numbers and the reason. A team that knows why the number is what it is will build to it; a team handed a number will ask for an exemption. ## The rule about exemptions The request is always the same: one long-running process cannot handle a forced re-issue, so please raise its ceiling. Granting it removes the only mechanism that would have caught the gap, and the gap does not go away — it waits for the day the credential has to change for a reason you do not control. The substantive answer is to fund the adoption path, and to make the exemption expensive to keep: time-boxed, recorded with an owner, and reviewed on a date. Where an exemption really is unavoidable, compensate with something that turns over on its own — a scheduled re-issue the platform runs, rather than a promise. ## What you are really standardising Three properties, and the numbers are only how you express them: 1. **A bounded worth for any escaped credential**, stated in hours rather than hoped for. 2. **A live population that tracks the running one**, so the downstream systems and the access records stay interpretable. 3. **An adoption path that has demonstrably run**, on every consumer, recently. Measure the third one directly. "Percentage of credential classes whose re-issue path ran in the last month" is a better number than either lifetime, because the lifetimes are inputs and that is the outcome they were chosen to produce. ## Where designs differ Stores differ in whether a ceiling can be expressed at all, whether windows are set per class or per consumer, and whether a single renewal may extend by the full window or by less. Where a store cannot enforce what you have decided, the decision does not disappear — it moves into a schedule you run and a report you read, and it is worth being explicit about which of your two numbers is enforced and which is merely intended.