A compromised sensor identity must lose every credential it holds — what does that kill write, and how big does the suppression list get?

A sensor comes back from a depot with its flash visibly read. The decision to kill everything for that identity is made elsewhere — by an operator on a device inventory, by a credential-recovery flow, by an automated risk rule. What this leaf owns is what the token side has to write when that event fires. ## Two stores, two writes The credentials for one subject live in two different places and only one of them is a table you can update: 1. **The refresh rows.** A ranged update: every row with that `subject`, across every family and every device it ever enrolled, set to a terminal state. This needs an index on `subject`; the digest index cannot serve it, because you do not have the digests. 2. **The short-lived tokens already minted.** These are not in any table you own — they are in flight, in device memory and in verifier caches. Nothing you write to the refresh table touches them. Suppressing them takes a second write, to whatever store verification consults. ## Order the writes, or you leave a hole Revoke the rows first, then write the cut. If the cut goes first at instant T, a refresh that was already in flight can commit at T plus a few milliseconds and mint a token whose `iat` is later than T — a token the cut will never suppress and whose row is now dead, so nothing else will catch it either. With the rows dead first, no further mint is possible, and a cut placed at *now* covers everything that did get minted. Use an inclusive comparison on the boundary second, because `iat` has one-second granularity and you would rather over-suppress the second you were already killing. ## Keyed by token identifier, or by subject and a cut | keying | entries per subject-wide kill | covers tokens you never recorded | cost | |---|---|---|---| | one entry per `jti` | one per live token | no | a burst on every bulk kill | | subject plus cut instant | one | yes | verification must know the subject before checking | Per-`jti` suppression is the right shape when you are killing one specific token you have in your hand. A subject-wide kill is the other case, and there the cut entry is the one that works, because the set you are trying to suppress includes tokens your service never wrote down. ## Sizing the list This is what makes the structure cheap enough to keep in a shared store that every verifier reads: - Each entry's lifetime is pinned to the tokens it suppresses — it can be discarded once no token issued before the cut can still be within its own validity. - So the peak size is **kills per token lifetime**, not requests per second. With short-lived tokens measured in minutes, even a stolen pallet of nine hundred sensors killed in one pass leaves nine hundred small entries for those few minutes. - Keyed per `jti` instead, the same pallet would write one entry per live token in one burst, and the structure would be bounded by traffic rather than by incidents. ## Idempotent and restartable A bulk kill will be interrupted — a deploy, a timeout, an operator who runs it twice. 1. Every write is **set-to-terminal-state**, never a toggle, so re-running it changes nothing that already landed. 2. The suppression entry is **keyed**, so writing it twice is writing it once; if a second kill arrives later, keep the *later* cut. 3. Drive the pass with a cursor over the `subject` index and record progress, so a restart resumes rather than starting over. Do not let the pass hold one long transaction across nine hundred sensors. ## What you have not revoked Be honest about the tail. Between the cut being written and the last verifier observing it, a stolen short-lived token is still accepted — the delay is replication or cache freshness if verifiers consult the store, and the token's whole remaining `exp` if they do not consult it at all. And if that store fails over empty, suppression stops silently: no verifier errors, the revoked tokens simply become acceptable again until they expire. The refresh rows stay dead throughout, so nothing new can be minted; the tail is bounded by the token lifetime, which is why that lifetime is the real guarantee and the list is only an accelerator.