A laptop holding a checked-out service credential is lost — what decides whether that forces a replacement?

## The decision is about evidence, not likelihood Every argument for *not* replacing after a device loss is an argument about probability: it was probably left in a taxi, the finder probably cannot get past the lock screen, it was probably wiped. None of those is checkable, and the cost of being wrong is an attacker holding a working credential for as long as the value lives. The question a replacement trigger asks is narrower and answerable: **can you establish that the copies on the device were unreadable to whoever has it?** If the answer is no, the trigger has fired. This is what separates a trigger list from case-by-case judgement. The list does not ask you to estimate the finder's skill. ## What the usual controls actually buy | Control | What it protects | What it leaves open | |---|---|---| | Whole-disk encryption | A device powered off, with a passphrase nobody has | A device lost unlocked, suspended with keys in memory, or with the passphrase written alongside it | | A screen lock | A casual finder poking at the desktop | Anything read off the disk from another machine, if the disk is not encrypted | | Remote wipe | A device that checks in before being taken offline | A device never brought back online — and silence is not evidence of a wipe | | Short-lived credentials | Everything after the expiry passes | Everything before it — but the window is now hours, not indefinite | Notice that the first three are all conditional on a state you did not observe, and the fourth is the only one that closes by itself. That asymmetry is the reason lifetime is the strongest lever here. ## Scoping: what was actually on the machine A credential does not sit in one place on a working device. Before deciding what to replace, enumerate honestly: - A **rendered configuration file** written when the process started. - A **shell history** containing the command that passed the value as an argument. - An **open terminal buffer** or editor session holding a value that was checked out for a manual task. - A **local cache** the workload kept so it could start without reaching the store. - A **backup of the home directory** taken to another machine or another disk. - Any **stored session** with the store itself, which may still be inside its validity window and able to fetch more values. That last item matters and is often missed: the device may not only hold values, it may hold the means to fetch fresh ones. Ending that session is the first move, and it is separate from replacing the values. ## The order of work 1. **End the device's own access to the store** — the session, the enrolment, whatever identity it authenticated with — so the loss cannot become a stream of new reads. 2. **List the values reachable from it**, using read records for that identity where the store keeps them, plus whatever the machine was configured to fetch. 3. **Replace each value** so consumers have somewhere to move, move the holders across, then **refuse the old value** at the system that accepts it. Replacement alone leaves the lost copy live. 4. **Record what was declared, when, and what was covered**, because the next question anyone asks is how far the loss reached. ## The structural answer The reason a lost device is a crisis is that it was holding a long-lived value at all. Where credentials are minted on request with an expiry measured in hours, the same event shrinks from "replace a shared value across an estate" to "wait out the window and check whether it was used". Where they are minted per consumer, revocation is local. Both of those decisions are made long before the device goes missing, which is why this event is worth arguing about *in advance* rather than in the hour the ticket arrives. A final caution on direction: replacing the values does nothing about what the device's holder may already have done with them. Replacement bounds future use; it does not undo past use, and establishing what was reached is a separate piece of work.