The $2,000 Blind Spot: Why "Account Closed" Isn't Real Security
Most IT teams have a version of the same mental checklist for an employee exit.
Disable the SSO. Revoke Active Directory access. Remove them from Slack. Deactivate the email. Archive the account. Check, check, check, check, check. Done. Offboarded.
Except the laptop is still sitting in a closet in Portland…
This is the $2,000 blind spot → the gap between "account closed" and "device controlled" → and it is one of the most consistently underestimated risks in remote IT operations.
Closing accounts feels like finishing the job. It is not. It is half the job. The other half involves a physical endpoint that may be sitting on your network, holding data you thought you wiped, waiting to become someone else's problem.
This post explains exactly where that risk lives, how to define it precisely, and what a provable recovery process actually looks like.
Here's an outline if you want to jump to a specific section:
Why "Account Closed" Is a False Finish Line
The reason IT teams default to treating digital deprovisioning as the finish line is entirely logical. Identity is the control plane of the modern enterprise. SSO, SAML, RBAC → the entire architecture of access security runs through credentials and accounts. So when those are gone, the instinct is that the risk is gone with them.
But research consistently shows that the clean account closure most teams assume is happening is frequently not happening.
Grip Security's research found that 31% of former employees still have access to a previous employer's software accounts. That is not a fringe edge case, it is nearly one in three departures leaving a residual access thread somewhere in your stack. And if that is the state of digital deprovisioning, which is far easier to automate and verify than physical hardware recovery, the physical side of the equation is in worse shape.
Dark Reading, summarizing OneLogin's "Curse of the Ex-Employees" report, notes that 20% of businesses have experienced data breaches involving a former employee, with deprovisioning delays being a contributing factor.
The accounts are the more visible risk. But the device is the persistent one. A laptop that has not been returned and wiped is not just a missing asset on your inventory, it is an endpoint that potentially still has…
credentials cached,
files saved locally,
browser sessions stored,
and corporate data on disk.
Closing the account does not delete the disk. "Account closed" is not a security control. It is an administrative record. The control is possession.
The Physical vs. Digital Gap: Possession Is 9/10ths of Compliance
There is a reason the phrase "possession is 9/10ths of the law" has lasted. Physical control is provable in a way that digital state often is not.
In the context of device recovery, that principle translates directly into operational risk. When a device leaves an employee's hands and enters yours, with a documented, time-stamped chain of custody, you control the endpoint. Until that moment, you do not, regardless of what your MDM says.
A laptop in a former employee's closet in Austin is not a dormant asset. It is an active risk factor:
It may still be connecting to networks.
If the device was not remotely wiped before the employee's departure, or if the wipe was initiated but never confirmed, it may reconnect to Wi-Fi and resume activity on your corporate Wi-Fi profile or VPN certificate without any account credentials needed.It carries local data.
Browser caches, locally synced files, saved credentials in password managers, email archives, and downloaded documents do not disappear when an account is deprovisioned. They sit on the disk until the disk is wiped.It represents a physical entry point.
Anyone with access to that machine, whether the former employee or someone else, has access to whatever is stored on it. The account being disabled means they cannot authenticate against your cloud apps in a monitored way. It does not mean the device is clean.It is an inventory liability.
A device you cannot account for cannot be redeployed, cannot be written off cleanly, and cannot be confirmed as compliant in an audit. For organizations that are maturing their asset management posture, unverified endpoints are a governance gap.
The phrase we use in our 2026 Offboarding Risk Brief captures it simply: possession is 9/10ths of compliance.
The job is not finished when the account is closed.
It is finished when the device is in your hands, verified, and wiped.
Defining the 2026 Risk Window
The "risk window" is the operational concept that should anchor how IT teams think about physical offboarding. It is simply this:
The risk window is the time between an employee's last day and the moment a device is verified as received and wiped.
It sounds obvious once stated. But in practice, most teams do not have a clear, defined measure of how long that window is… or how to compress it. The window just stays open, sometimes for days, sometimes for weeks, sometimes indefinitely if the return falls through the cracks.
What makes the 2026 version of this risk window more dangerous than it was in 2021 or 2022 is the same dynamic we covered in the offboarding spreadsheet piece: offboarding is no longer a quarterly event.
It is a continuous stream → RTO mandates triggering remote exits, ongoing role consolidation, contractor churn cycling at 4-6x the rate of full-time employment. More exits means more open risk windows, running simultaneously, with no special-project response to close them.
The practical implication is that every day a device sits unreturned, the window stays open and the probability of recovery drops. After 30 days, the probability of recovering a device from a former employee drops by nearly 60%. The first week after departure is not just the most convenient time to initiate retrieval, it is the only time where recovery is genuinely high-probability.
This is why the target for time-to-initiation → resignation to retrieval start → is under 24 hours. Not because it is a nice number, but because the window starts closing the moment the employee walks out the door.
Why MDM Alone Doesn't Close the Loop
A common source of false confidence in mid-market IT teams is MDM coverage. If the device is enrolled in Jamf or Intune or Mosyle, the thinking goes, it can be remotely wiped at any time. So the physical risk is covered.
This reasoning has several gaps worth naming directly.
Remote wipe requires the device to be online and reachable.
A device that is powered off, in airplane mode, or on a network your MDM cannot reach through will not receive the wipe command. The command queues. It may execute eventually. Or it may not.MDM tells you what the device is supposed to be doing, not what it is actually doing.
An unenrollment event, a firmware reinstall, or a factory reset before the wipe command is received can all break the chain. MDM gives you visibility into enrolled, compliant devices. A device that has been manipulated before return may not be what your MDM thinks it is.MDM does not physically retrieve the device.
Even a device that has been successfully wiped remotely still needs to come back to your hands for redeployment, disposal, or inventory closure. A wiped device sitting in a closet is still an open item on your asset register. The loop is not closed until you have verified receipt and confirmed the serial number matches.MDM is not chain-of-custody evidence.
If you are ever in a situation where you need to demonstrate that a device was properly controlled through an employee exit (for a compliance review, an insurance claim, an investigation, or a regulatory inquiry) an MDM log showing a wipe command was sent is not the same as a documented recovery with timestamped carrier scan, photo verification, and serial match confirmation.
MDM is a critical tool. It is not a substitute for a physical recovery process with documented evidence.
What Provable Chain of Custody Actually Means
"Chain of custody" is a term that sounds like it belongs in a courtroom or an evidence locker. For IT offboarding in 2026, it is simply the operational discipline of being able to prove, at any point, exactly where a device has been, who had it, and what state it was in.
The reason this matters for mid-market IT teams, not just enterprises with compliance teams, is that the situations requiring proof are not just formal regulatory audits. They include:
A disgruntled former employee claiming harassment around the return process
An insurance claim for an unreturned device
A security incident where a former employee's device appears in a breach investigation
A leadership request to audit device recovery rates after a round of exits
An M&A due diligence process requiring inventory verification
In all of these scenarios, "we sent them an email and they said they shipped it" is not a useful answer. Documented evidence is.
Chain of custody in device recovery means building a paper trail → or more accurately, a timestamped digital trail → that documents every handoff from the moment retrieval is initiated to the moment the device is verified as received and wiped.
The goal is not bureaucracy.
The goal is being able to answer, quickly and without ambiguity, the questions that matter: Did we start the retrieval within 24 hours? When did the device enter transit? When was it received? Does the serial number match? Was it verified?
A process that cannot answer those questions is not a chain of custody. It is a series of hopes.
What "Good" Looks Like: The Three Must-Have Evidence Points
A functional chain of custody for physical device recovery does not require enterprise ITAM software or a dedicated asset management team. It requires three things to be documented, in order, for every exit. These are the minimum viable evidence points that separate "we tracked intent" from "we documented control."
1) Timestamped Initiation
The first evidence point is the record of when the retrieval process was started and by whom. This means a system-generated timestamp, not a manual spreadsheet entry with today's date typed in. The difference matters because a manual entry can be backdated, forgotten, or filled in retroactively. A system-generated timestamp is provable.
The initiation record should capture: the employee's departure date, the device serial number, who initiated the retrieval, and when. This is the anchor point of your risk window measurement. Without it, you cannot calculate time-to-initiation, and you cannot demonstrate that you acted promptly after an exit.
For organizations serious about this, the 24-hour target is not arbitrary → it is the operational threshold that separates proactive control from reactive chasing. A timestamped initiation record within 24 hours of departure is the first line of evidence that your process is running as designed.
2) Carrier Scan Evidence
The second evidence point is proof that the device entered carrier custody → a real carrier scan, not a shipping label being printed. This is a meaningful distinction.
Printing a label and handing it to the former employee is not the same as that employee dropping the package at a UPS store and getting a scan. The label being printed is an intent to ship. The carrier scan is a shipment. Until a carrier scan exists, the device has not actually moved. It is still in the employee's possession, regardless of what your tracking portal says.
Carrier scan evidence creates a verifiable time record for time-to-in-transit → the KPI that measures from label issuance to first carrier scan. The target is under 48 hours. When that number slips to five days, or seven days, or "we're not sure," the risk window is staying open long past the point where recovery probability starts to decline.
The carrier scan is also the first point where the chain-of-custody documentation gains external verification. A carrier record is a third-party timestamp. It is harder to dispute than an internal system entry.
3) Receipt Verification → Photo and Serial Match
The third evidence point is the one most teams skip, and it is the one that determines whether the loop is actually closed.
Receipt verification means confirming, upon physical arrival at your facility or receiving partner, that the device received is the device that was supposed to be returned. That confirmation has two required components: a photo of the device as received, capturing its condition, and a confirmed serial number match against the record in your asset inventory.
Why the photo? Because condition on arrival matters for insurance purposes, asset valuation, and any dispute about damage. Without a photo, you have no baseline for post-return condition claims.
Why the serial match? Because without it, you have not verified that the right device came back. A box can arrive. An old personal laptop can arrive. A different model can arrive. Until the serial number is confirmed against your asset record, you have not closed the loop, you have received a package.
The verification time KPI → receipt to serial match confirmation and inventory close → should be under 48 hours. That is the window where the recovery is confirmed and the risk window is officially closed.
Quick audit: Does Your Process Prove Control, or Just Track Intent?
Answer yes or no to each of the following:
When retrieval is initiated, does your system generate a timestamped record automatically, without manual entry?
Can you report your average time-to-initiation across the last 30 days of exits?
Do you have carrier scan confirmation (not just label issuance) for every device that was supposed to ship?
Is your time-to-in-transit tracked as a distinct metric, separate from whether a label was printed?
When a device is received, is a photo taken and a serial number match confirmed against your asset inventory?
Is verification time (receipt to confirmed serial match) under 48 hours?
Could you pull a complete chain-of-custody record for any exit from the last six months in under five minutes?
If a security incident involved a former employee's device, could you prove the device was recovered and wiped, with timestamps?
If you answered "no" to three or more of these, you have a chain-of-custody gap - not in theory, an actual operational gap. The evidence does not exist. And in the scenarios where that evidence matters, "we think we got it back" is not going to be sufficient.
Closing: the mindset shift from logistics to governance
The shift that matters in 2026 is not "how do we ship boxes back faster."
It is this: device recovery is a governance function, not a logistics task.
Governance means documentation.
It means provable control. It means being able to demonstrate, at any time, that the process ran correctly → not because you are expecting an audit, but because the discipline of documented control is what separates a recoverable situation from an unrecoverable one.
The account closure checklist is not enough anymore, if it ever was.
The MDM console showing a wipe command was sent is not enough. An email thread that ends with "they said they shipped it" is definitely not enough.
The standard in 2026 is a closed risk window: timestamped initiation, carrier scan evidence, and receipt verification with a confirmed serial match. That is the chain of custody. That is what "device controlled" actually means.
If you want the full IT risk checklist, the KPI framework, and scenario playbooks for high-frequency exit types → including RTO resignations, contractor exits, and M&A integrations → they are in our 2026 Offboarding Risk Brief here:
No form to fill, completely complimentary to download.
FAQ
-
The risk window is the time between an employee's last day and the moment a device is physically received, verified, and wiped. It is the period during which the device is uncontrolled and the data on it is potentially accessible. The goal of a functional recovery process is to compress that window to under 10 days, with initiation starting within 24 hours of departure.
-
Remote wipe requires the device to be online and reachable. It also does not return the device to your inventory, does not confirm the serial number, and does not generate the chain-of-custody documentation you need for audits, insurance claims, or incident response. MDM handles digital deprovisioning. It does not close the physical loop.
-
Tracking a return typically means knowing whether a shipping label was created and whether you received a box. Chain of custody means documenting every handoff with timestamped evidence, when retrieval was initiated, when the device entered carrier transit, when it was received, and what its condition and serial number were at receipt. Chain of custody is provable control. Tracking is intent.
-
Because after 30 days, the probability of recovering a device from a former employee drops by nearly 60%. The first days after departure are the highest-probability window for recovery. Waiting until HR follows up, or until an IT ticket gets assigned, or until someone notices the spreadsheet entry is stale, all of those delays shrink the window. Twenty-four hours is not an aggressive target. It is the threshold that separates a process that works from one that relies on goodwill.
-
At minimum: a photo of the device as received, a confirmed serial number match against your asset inventory record, and a timestamp for when that verification was completed. That is the evidence that closes the risk window and confirms the chain of custody is intact.
