01 / THE PROBLEMAnti-theft can't tell your ITAD vendor from a thief
Every control in the modern endpoint stack — MDM enrollment, activation locks, firmware passwords, persistence agents — is built on one premise: a device separated from the organization should be useless to whoever holds it. That's exactly right during the device's life, and exactly wrong at the end of it. When a still-enrolled laptop reaches a refurbisher, the protections fire as designed. The machine phones home to a tenant that no longer wants it, demands credentials nobody will ever enter, or refuses activation outright.
The consequences land in two places. Value: a locked device can't be resold as a working unit; at best it's parts, at worst it's shred weight — the depreciation math in our value recovery material assumes a sellable machine. Operations: stranded devices generate back-and-forth between your ITAD vendor and your IT team weeks after the project “ended,” and every returned pallet reopens a closed custody file. The fix is a release pass before pickup — cheap, mechanical, and almost always skipped.
02 / THE MDM LAYERMDM enrollment and enrollment programs: wiping is not releasing
The critical distinction is between what lives on the device and what lives in the vendor's cloud. Wiping the device clears the first. It does nothing to the second.
- Windows / Microsoft Intune & Autopilot. A device's Autopilot registration ties its hardware identity to your tenant. Wipe it, reinstall it — on first boot it can still present your organization's enrollment screen. Before disposition: retire or delete the device object in your MDM and remove its Autopilot device registration so the hardware hash no longer belongs to your tenant.
- Apple / Automated Device Enrollment (ABM or ASM). Macs, iPhones, and iPads assigned to your organization in Apple Business Manager re-enroll on activation no matter how many times they're erased. Release the devices from your ABM/ASM instance (or reassign ownership) before they leave. Activation Lock is a separate, additional layer — see below.
- Android / zero-touch enrollment. Corporate Android devices registered for zero-touch will re-provision into your management on setup; deregister them from the zero-touch portal at disposition.
- ChromeOS. Managed Chromebooks commonly enforce forced re-enrollment: even after a factory wipe they return to the enrolling domain. Deprovision them in the Google Admin console before disposal — this also has licensing implications, which is its own reason finance wants the step done.
The operational trap is timing. Devices are usually wiped at the ITAD facility as part of sanitization — but tenant-side release requires your admin console, which the vendor can never touch. That's why release belongs on your pre-pickup checklist, not in the vendor's statement of work.
03 / ACTIVATION LOCKSActivation Lock and account-tied locks: designed to survive erasure
Account-anchored locks are a level stubborner than MDM, because surviving a wipe is their whole job.
- Apple Activation Lock (Find My) pairs the device to an Apple Account (or, on org-owned devices, to the organization). An erased, activation-locked device still demands the original credentials on setup. For fleet devices, disable or clear Activation Lock through your MDM's supported mechanism, or ensure Find My was never user-enabled on supervised hardware. For BYOD-adjacent devices, the departing user must sign out — which is why the lock check belongs in the offboarding workflow, not just the disposal one.
- Google account locks (Android Factory Reset Protection) behave analogously: a reset device can demand the previously synced account. Remove accounts before reset, or reset from within settings rather than recovery where policy allows.
A locked device that reaches a reputable ITAD provider has one honest disposition path: it's treated as unsaleable and processed for parts or destruction, because bypassing activation locks is neither legitimate nor something a certified processor will do. The value difference between a released iPad and a locked one is effectively the entire resale price.
04 / FIRMWARE & SERVERSThe firmware layer: BIOS passwords, persistence agents, and BMCs
- BIOS / UEFI supervisor passwords. A forgotten supervisor password can block firmware settings, secure-boot changes, and sometimes boot-order changes needed for sanitization. On some enterprise laptop lines a lost supervisor password has no supported removal short of board-level service — which converts a resale-grade unit into parts. Clear firmware passwords (or record them for the processor under your agreement) before shipment.
- Persistent anti-theft / tracking agents. Firmware-embedded persistence (e.g., BIOS-anchored endpoint agents) reinstalls its client after reimaging by design. Deactivate or remove the license for retiring devices in the management console so the next owner's machine isn't calling your tenant.
- Server BMCs — iLO, iDRAC, and kin. Baseboard management controllers carry their own credentials, network configs, and logs, entirely separate from the OS drives. Reset BMCs to factory defaults during logical decommissioning — it's both a data-hygiene step and a resale-readiness step, and it's on the decommissioning checklist for that reason.
- Self-encrypting drive (SED) locks. A locked SED without its credentials can't be verifiably sanitized through normal commands — though a supported cryptographic erase or PSID revert (which destroys the data) can return the drive to usable state. Decide the SED handling path with your processor in advance.
05 / THE CHECKLISTThe pre-disposition release checklist
Run per batch, before pickup, with the results recorded against serials:
- 1. Export the batch's serials from your ITAM/MDM — this list drives every step below and reconciles the vendor's receiving report.
- 2. Retire/delete device objects in MDM (Intune, Jamf, Workspace ONE, etc.).
- 3. Remove enrollment-program registrations: Autopilot device hashes, ABM/ASM assignments, zero-touch entries; deprovision ChromeOS devices.
- 4. Verify Activation Lock / FRP status; clear via MDM or user sign-out. Quarantine any device that stays locked — it ships as no-value scrap, and the settlement report should say why.
- 5. Clear firmware passwords; deactivate persistence agents; reset BMCs on servers.
- 6. Confirm SIM/eSIM removal and cellular-line release on connected devices.
- 7. Hand the vendor the serial list with lock status noted — released devices route to remarketing, flagged ones route straight to destruction, and nobody discovers the difference three weeks later.
One process note: for remote and offboarded employees, the release steps are the same but the sequencing runs through your mail-back workflow — release the device in the console once it's confirmed received, not while it's still the user's daily driver.
Locked-device FAQ
Can our ITAD vendor just remove the locks?
No — and be wary of any vendor that offers to. Tenant-side controls can only be released from your admin consoles, which a vendor should never hold credentials for, and activation-lock bypassing is not a legitimate service. A certified processor's job is to report locked devices accurately and route them to parts or destruction; releasing them beforehand is yours.
Doesn't a factory reset take care of Intune / Autopilot?
No. A reset clears the OS and local data; Autopilot registration lives in your tenant, keyed to hardware identity. Until that registration is deleted, the device can present your enrollment screen on first boot forever. Same logic for Apple ADE and Google zero-touch — release happens in the console, not on the device.
What does a lock actually cost in resale value?
Functionally all of it, for account and enrollment locks: a released working device sells as a refurbishable unit; the same device locked is parts harvest or shred weight — a swing from real resale value to a processing cost. Firmware passwords vary; an unremovable supervisor password can also relegate a unit to parts.
Do locks interfere with data destruction itself?
Sometimes. Physical destruction works regardless of lock state — the security floor is always available. But locks can block verified logical sanitization: firmware passwords can prevent booting sanitization tooling, and a locked SED won't take standard sanitize commands without credentials (a PSID revert crypto-erases it, which at disposition is the point). Practical rule: what can't be verifiably sanitized gets destroyed, and the certificate says so.