The laptop that never came back

Ask an organization how offboarding is going and the answer is usually a number: devices issued against devices returned, with a small tail of stragglers somebody is chasing. It is a real number, it is easy to produce, and it is measuring the cheapest thing in the process. A laptop is worth a few hundred dollars at resale. What was on it, and what it can still reach, is not on that scale at all.

The gap is structural rather than careless. Asset recovery has an obvious owner and an obvious artifact. Access removal is distributed across a directory, a mail tenant, half a dozen applications bought by departments, and occasionally a device that is holding a session none of those systems will tell you about.

What is still live on a returned device?¶

A returned device can still hold valid access, because modern sign-in does not work the way the word password suggests. An authenticated session is typically a refresh token cached on the device, and changing the account password does not by itself invalidate it. The account looks disabled in the directory. The mail client on a laptop in a drawer keeps synchronizing.

Revoking those sessions is a distinct administrative action with a distinct name on every major platform, and it is the step most commonly missing from a checklist written by somebody thinking in terms of passwords. It is worth finding the exact control in whichever tenant you run and putting its name in the checklist, rather than a line that says disable the account.

Three other things routinely survive. Application access bought outside IT, because the leaver's account in a departmental tool has no connection to the directory and nobody outside that department knows it exists. Data synchronized to personal storage, which is a policy question rather than a technical one and is usually discovered rather than prevented. And credentials in a browser profile, which walk out with a device that was never returned.

Does disk encryption settle the question?¶

Disk encryption settles one question well and is silent on the one that usually matters. It protects data on a device that is powered off and in somebody else's hands, which is the laptop-left-in-a-taxi case, and for that it is close to decisive. It does nothing about a device that never came back while somebody knew the passphrase, and nothing about a session already established.

The record that carries weight afterwards is not the encryption setting. It is the escrowed recovery key and the enrollment evidence: proof that this specific serial number was encrypted, from this date, with the key held centrally. Without that, an organization asserting that a lost device was encrypted is making a claim it cannot evidence, which is the position nobody wants to be in when the question is asked by a regulator rather than a colleague.

Remote wipe belongs in the same category. It is worth having and it is conditional on the device coming online, which means it is a good control and never a guarantee. Treat a wipe command as issued rather than completed until the platform confirms it, and record which of the two you have.

What changed about disposal in September 2025?¶

The guidance nearly every disposal checklist cites was withdrawn on 26 September 2025. NIST SP 800-88 Rev. 1 had been the reference for media sanitization for a decade, and Rev. 2 superseded it (opens in a new tab) on the same day. Anything still naming Rev. 1, including a great many vendor policies and internal standards, is citing a withdrawn document.

The substance is worth more than the version number. The revision describes a media sanitization program with techniques and controls chosen, in its own words, "based on the sensitivity of their information", which puts the decision on what the data was rather than on what the device is. It also gives more attention to validating that sanitization actually worked, which is the step almost always skipped, because a wipe that reports success and a wipe that succeeded look identical in a ticket.

For most organizations this changes one practical thing. A single disposal standard applied to every device is either too expensive for the laptops that held nothing or too weak for the two that held everything. The fix is to classify at issue rather than at disposal, while somebody still knows what the machine was for.

Is a disposal vendor enough?¶

A disposal vendor is enough when what they return is evidence rather than assurance, and the difference is specific. A certificate of destruction listing serial numbers, dated, naming the method, is a record that survives somebody else's audit. An assurance that all devices are securely wiped is a sentence, and it transfers no obligation, because the organization that held the data is still the one answerable for it.

This is the same argument this firm makes about subcontracting generally, and it has a floor worth stating. For a small organization disposing of a handful of machines a year, a reputable vendor with serialized certificates beats building any capability in-house, and pretending otherwise would be selling. The requirement is the paperwork, not the insourcing.

Resale deserves one extra thought. The economics are attractive and the chain lengthens: a device sold on has a next owner, and the sanitization evidence has to exist before it leaves rather than being reconstructed later. Where a machine held regulated data, the honest calculation often finds that the resale value is smaller than the cost of being able to prove what happened to it.

The four records worth keeping¶

Each of these is a line in a system you already have, and together they are what an answer looks like when somebody asks about a device eighteen months from now.

1. 1.Which serial number was issued to which person, and the date, so that a device can be traced to a data population rather than to a cost center.
2. 2.The encryption enrollment and escrowed recovery key per device, which is the evidence that the encryption checkbox was true of this machine.
3. 3.The date sessions were revoked, distinct from the date the account was disabled, because those are different events and only one of them stops a cached client.
4. 4.The disposal outcome per serial number, naming the method and the vendor, with the certificate attached rather than referenced.