Wiped is not released 

Every hardware refresh ends with a cupboard of devices that look finished with. They have been wiped, they boot to a setup screen, and somebody has ticked a box on a spreadsheet. Then the next owner, a refurbisher or a colleague in another office, powers one on and it stops at a prompt asking for the credentials of an administrator who may have left the company two years ago.

 

The data is gone. The organisation’s claim on the hardware is not, and that gap is a security problem before it is a finance one.

 

What is actually still on the device

Nothing on the disk. What survives a factory reset is a record held somewhere else: an enrolment in a mobile device management service, a hardware identity registered with a deployment programme, or an anti-theft lock tied to a user account. The device checks in after the reset, recognises that record and refuses to go further without the original owner.

 

In a typical UK estate three mechanisms account for nearly all of it: Apple’s Activation Lock paired with Apple Business Manager, Microsoft Intune with Windows Autopilot, and factory reset protection on Android Enterprise. They live in three different consoles, and a single “wipe everything” instruction to the service desk clears none of them.

 

Why this belongs to the security team

Three reasons. First, a locked device is not evidence of a wiped device. A surprising share of the units in a leaver drawer were never reset at all, because whoever collected them could not get past the login screen either; the lock hid the data rather than removing it. Second, an orphaned device still carries the organisation’s identity in its enrolment record, which is exactly what you do not want circulating once the hardware is out of your control. Third, the mechanism that clears the lock depends on artefacts held in a live console. If the MDM tenant was decommissioned before the hardware was, the codes needed to release the device may simply no longer exist anywhere.

 

Apple: turn the lock off before you release the device

Apple’s deployment guide separates organisation-linked Activation Lock, which your device management service controls, from user-linked Activation Lock, which depends on an employee’s personal Apple Account. For the organisation-linked version Apple is explicit that the bypass codes held by the management service are “crucial to your ability to clear Activation Lock”.

 

The sequencing trap is releasing devices from Apple Business Manager too early: Apple’s guidance on releasing devices states that release is permanent, that a released device cannot be added back through automated enrolment, and that Activation Lock can no longer be managed through Apple Business Manager once a device has been released. Clear the lock first. Release second. The other order leaves the device stranded with nobody able to help.

 

Microsoft: two deletions, in order

Microsoft’s Windows Autopilot registration guidance says that “whenever a device permanently leaves an organization, the device should always be deregistered from Windows Autopilot”, and it names end of life as one of those moments. The device comes out of Intune first and out of Autopilot second, and the same page warns that “skipping steps or removing records out of order can result in orphaned records or unrecoverable devices”.

 

Deregistering through a partner portal on its own does not unenrol the device from Intune or disjoin it from Microsoft Entra ID. One practical detail: note the serial number while the device is still visible in Intune, because that is how you will find it in the Autopilot list afterwards.

 

Android: the decision has to be made before the reset

Google’s documentation for company-owned devices is direct: disabling factory reset protection, or enabling the enterprise version of it, must be done prior to the device being factory reset.

 

Once a protected handset has been wiped, the window has closed. Enterprise factory reset protection is the right setting for devices still in service, because it names the accounts allowed to reactivate a wiped handset. At disposal it has to be switched off deliberately, and it is worth knowing which of your Android estate is enrolled as company-owned before anyone books a collection.

 

The process fix

None of this is difficult, but it has to happen while the console is still switched on, which is rarely the same week the hardware is finally cleared out. The practical change is to move the unlock from the disposal process into the leaver process: when a person leaves, their devices are released in the console before they go anywhere near a cupboard.

 

For the backlog that already exists, sort it three ways. Devices you can still unlock in a live console are reusable stock. Devices whose tenant no longer exists, and devices nobody can identify, are a destruction job and should be handled as data-bearing until someone has verifiably erased or destroyed them. Tell whoever is collecting the kit which pile is which before the day, and be wary of any disposal partner who claims they can unlock devices for you.

 

The unlock is an action inside your own tenant, performed by your own administrators. Nobody else can do it, and nobody should be able to.

 

---

 

Jack Cartwright is managing director of Innovent Recycling 

 

Main image courtesy of iStockPhoto.com and Ejla