Autopilot device association: what removal requires

Windows Autopilot device association is now generally available. It solves a real problem — proving a device belongs to your organisation before it enrols, which removes a pile of hash-upload and corporate-identifier friction from provisioning.

It does that by writing to the firmware. And the part worth understanding before you deploy it at scale is not what it does at the start of a device's life, but what it takes to undo at the end.

What it writes, and where

Microsoft's description does not hedge:

“Device association … establishes a verifiable link between a physical device and your tenant by writing a tenant affinity marker into the device's UEFI firmware, making the device recognizable and authenticatable by the MDM provider before enrollment begins.”

The marker is stored in Device Link UEFI variables and the association is verified through TPM-backed cryptographic validation. Associated devices are also “automatically marked as corporate-owned”, which is exactly the convenience most teams want — it sidesteps personal-device enrollment restrictions without a separate corporate identifier upload.

All of that is genuinely useful. It is also, by design, a persistent hardware-level claim on the device.

Why it will get adopted anyway, and should

It is worth being straight about the upside, because the trade-off only makes sense if both halves are on the table. Microsoft lists real benefits and they solve real friction: a streamlined out-of-box experience with language, keyboard, licence and privacy pages preconfigured or skipped; device naming applied from a template before enrollment, so a machine carries the right name from its first boot; and device-targeted policy assignment, so the correct policy applies “regardless of which user signs in”.

That last one matters more than it sounds. Policy targeting has historically leaned on user groups, which breaks for shared devices, shift-worked hardware and anything provisioned before its owner is known. Device association fixes that properly.

So this is not a feature to avoid. It is a feature whose end-of-life step is heavier than its start-of-life step, which is an unusual shape and the reason it is worth a decision rather than a default.

The line that changes your decommissioning process

In Microsoft's Limitations section:

“Removing association from Intune isn't supported. To remove an association, clear the association information on the device instead.”

And stated more precisely on the removal page, in a note that deserves to be read twice:

“Removing a device from the Device association list in Intune doesn't clear the tenant affinity that's stored on an already associated device. To fully remove the association from an associated device, clear the association information on the device itself, and then delete the device from the Device association list.”

Deleting the record deletes the record. The firmware marker is untouched, and the console will show you a clean list while the hardware still carries your tenant affinity. That is a gap between what your management plane reports and what is physically true — which is precisely the class of problem this blog keeps coming back to.

What removal actually involves

It depends on state, and the two states are very different jobs:

• Pre-associated — the device has not completed association in OOBE. Delete it from the list in Intune. Microsoft: "The device is removed from the list immediately." Easy.
• Associated — the marker is written. This requires elevated PowerShell, run on the device, using the UEFI module from the PowerShell Gallery, to clear three Device Link variables. Microsoft publishes the sample commands and the namespace. Querying the variables does not require elevation; clearing them does.

Read that second one as an operations manager rather than an engineer. Offboarding a device now requires the device. Not a console action, not a remote command through the MDM you are in the middle of unenrolling it from — a person, an elevated prompt, and a module installed from a public gallery.

The ordering trap, which is the expensive one

Microsoft states the prerequisite plainly, and it is easy to get backwards:

“Before clearing the association, make sure the device is no longer enrolled with its mobile device management (MDM) provider as part of your decommissioning process. If the device remains enrolled, the MDM provider attempts to re-associate it on its next check-in.”

So the correct sequence is: unenroll, then clear the UEFI variables, then delete the Intune record. Any other order produces a device that appears to have been cleaned and quietly re-stamps itself. If your disposal runbook is written by someone working from the Intune console outward — which is the natural way to write it — it will get this wrong.

And a scoping note that stops the panic: “Clearing the Device Link UEFI variables only removes the association. It doesn't reset the TPM, unenroll the device, or delete the device's Microsoft Entra ID or Intune records.” This is one step among several, not a decommissioning button.

Where this actually bites

Provisioning is not the risk. The risk sits in the three moments a device leaves, and none of them is usually owned by the person who enabled the feature:

• Asset disposal and resale. A device sold or donated with your tenant affinity still in firmware is carrying an identifier you did not intend to ship. Nothing in the Intune console will tell you it is still there.
• Warranty replacement and RMA. Hardware going back to a vendor is not usually routed through a PowerShell step.
• Divestment or a tenant move. Devices transferring to another organisation need the marker cleared, on each device, by someone with administrative access to it — at exactly the point in a transaction when access is being taken away.

This is our read rather than Microsoft's: the feature is well-designed for onboarding and its offboarding path assumes a device you still physically control. That assumption holds for most of a fleet and fails precisely at the end of the lifecycle, which is where fleets leak.

What we would do this week

• Decide before you enable it, not after. If device association is not yet in use, the decommissioning question belongs in the decision rather than after the first hundred devices.
• If it is in use, write the removal step into the disposal runbook now — in the right order: unenroll, clear on device, delete the record.
• Tell whoever handles RMA and disposal that a console deletion is not removal. That single sentence is most of the value here.
• Check the Device association blade against your asset register. Under Devices > Enrollment > Device association > Devices, filter by state. Anything associated that you no longer physically hold is worth knowing about now.
• Note the exclusion: Microsoft states device association does not apply to Windows 365 devices, because they are already treated as trusted corporate devices.

Sources

Both Microsoft Learn pages were read in full on September 5, 2026: Overview of Windows Autopilot device association (ms.date 2026-08-25) and Remove a Windows Autopilot device association (ms.date 2026-08-07). Microsoft's own limitation wording is quoted rather than paraphrased throughout, because the distinction between deleting a record and clearing firmware is the entire point and it is easy to soften by accident.

If you would rather have the disposal runbook updated and the Device association blade reconciled against your asset register as a bounded piece of work, scope it with us.