What revocation-lag number do you sign for on a 40,000-sensor fleet, and which part of it can this service actually shorten?

"Revoked" sounds like an instant. On forty thousand sensors it is a distribution with a tail, and a business that has signed a cold-chain commitment will eventually ask what the tail is. The useful exercise is to write the number down, decompose it, and say which term anyone can actually move. ## What "revoked" actually promises Two different promises hide in the word, and only one of them is instant: - **No new authority.** Once the refresh rows are in a terminal state, that subject cannot mint anything again. This is a committed write, so it holds from the moment the transaction lands. - **No existing authority.** A short-lived token already in a device's memory keeps being presented and keeps being accepted, because verification is a signature check over a self-contained token. Stopping it early takes a suppression entry that the verifier actually reads. Any statement of the form "we revoked it" that does not say which of the two it means is not a budget. ## The three terms | term | typical size | who owns the lever | what shortening it costs | |---|---|---|---| | stop minting | milliseconds | this service | nothing; it is a committed write | | a minted token's remaining validity | up to its full lifetime | the issuing side | shorter lifetimes mean more radio wakeups per sensor per day | | suppression reaching every verifier | freshness of the consulted store | this service | verification gains a dependency on that store | The honest headline is that the second term dominates, and it is not this leaf's lever. A fleet that wakes to trade credentials is spending its battery on radio-on time; cutting the token lifetime multiplies those wakes, and on a poor link each one costs several attempts. That trade is made where tokens are minted, and the right move here is to take the lifetime as given and state the budget against it. ## The lever this service does own What is genuinely yours is the shape of the third term: 1. **Do verifiers consult a suppression entry at all?** If not, the budget is simply the token lifetime, and you should say so out loud rather than implying a revoke button does more than it does. 2. **How fresh is the consultation?** A synchronous read gives you replication lag; a cached answer gives you the cache's freshness window, which is the real number even though nobody wrote it down. 3. **What happens when that store is unreachable?** Failing closed protects the budget and can strand forty thousand sensors on a bad afternoon; failing open keeps the fleet reporting and silently suspends the budget. Pick one deliberately and write which one you picked next to the number. The refresh credential's own lifetime is also yours, and it trades differently: a long one means a sensor asleep in a container hold for six weeks can still come back and refresh, while a short one forces re-enrolment — a provisioning round-trip or, worse, a field visit — for anything that misses its window. It does not extend an attacker's window, because the row is dead server-side either way. ## Measuring that the number holds A budget nobody measures decays silently, usually the first time somebody changes a cache setting: - Run a **canary**: periodically revoke a throwaway identity that holds a live token, then measure at a verifier how long until the first rejection. Alarm on the p99 of that measurement against the signed number. - Track the fraction of verifications that reached the suppression store versus answered from a cached value, because that ratio *is* the freshness term. - Re-run the canary after any change to token lifetime, cache freshness or store topology; those are the three inputs, and all three are edited by people who are not thinking about revocation. ## What you cannot fix, and what you do instead You cannot reach a token that is already in an attacker's hands, and you cannot tell a sensor asleep in a freezer anything at all. What you can do is bound the window, publish the bound, and make the bound observable. One more failure mode belongs in the same conversation: restoring the credential table from a backup taken before a revocation silently returns those rows to active, so any restore has to be followed by replaying the revocations made since the snapshot. That is the kind of detail a signed number forces you to discover before an auditor does.