Autopilot device association: export the DeviceLink CSV, stamp UEFI, then enroll

Most Intune shops still treat Autopilot pre-staging as “collect a hardware hash, upload a CSV, assign a profile.” That version still works for classic Autopilot—but Autopilot device association is a different trust model sitting on Autopilot device preparation, and treating the new blade like another hash upload is how you waste a week debugging VMs and missing OOBE naming.

Across tenants we assess that already run Entra join and Device Preparation, the association loop fails in three places—and those are the same places the Reddit “is this just classic Autopilot?” objection actually matters.

Device association stamps tenant affinity into UEFI before enrollment

Autopilot device association binds a physical Windows 11 device to the tenant before the user signs in by writing tenant affinity into UEFI after TPM attestation. That is how Device Preparation gets OOBE naming and page skips again without waiting for interactive sign-in. It is a feature of Autopilot device preparation—not a third Autopilot product—and Microsoft’s docs limit it to Entra join on physical Windows 11 with TPM 2.0. VMs and Windows 365 are not supported for association.

You still export an identity and upload a CSV. The identity is a DeviceLink, not the classic hardware hash. Corporate-owned marking is automatic once association succeeds. Treat it as “same CSV, same trust” and you will chase enrollment failures that are really attestation or firmware problems.

What breaks it:

• Confirm Device Preparation, not classic Autopilot alone — association rides the preparation policy path; a classic profile without preparation will not give you the UEFI stamp you are expecting.
• Physical Windows 11 + healthy TPM 2.0 only — stop the pilot on Hyper-V or Windows 365 before you open a ticket.
• Secure Boot / firmware changes after associate — identity is hardware-backed; a firmware swap can invalidate what you stamped.

The admin loop: policy, DeviceLink CSV, upload, associate, enroll

Create an Autopilot device preparation policy first. Export the DeviceLink CSV from the device—OOBE Autopilot menu, diagnostics, or MdmDiagnosticsTool—then upload under Intune Devices > Enrollment > Device association > Devices. Associate (network in OOBE or a technician trigger), then enroll. Optional but useful: assign the preparation policy to the device at upload time so the device-targeted preparation path is wired before the user touches the keyboard.

If you want Autopilot Device Preparation plus device association wired the same way across the fleet—not a one-off DeviceLink upload—start with our fixed-price Device Management Jumpstart. Teams that need ongoing enrollment care can look at Managed Windows Autopilot; teams fixing a broken path or designing in-house ops can start with Autopilot Consulting.

What breaks it:

• Export DeviceLink, not a hardware-hash CSV — wrong export shape fails association even when the upload UI accepts the file.
• Associate before you expect OOBE naming — upload alone is not affinity; UEFI has to be stamped.
• Skip device-targeted preparation assignment — user-targeted-only shops rediscover why naming and page skips still wait on sign-in.

The door that stays open: TPM health, removal, and the “same CSV” objection

The r/Intune objection is fair on the surface: collect ID, upload CSV, assign policy. The trust model is not the same. Classic Autopilot leans on a hardware hash. Association leans on a TPM-backed DeviceLink identity and UEFI tenant affinity, with corporate-owned marking automatic and VMs explicitly out of scope. Pretending they are interchangeable is how pilots “prove” the feature does not work on a lab VM.

Removal is the standing gap to document for your helpdesk: clearing association is done on the device in the current release—Intune remove of association is not supported the way classic Autopilot deregistration is. Pair that with the failure modes you will actually hit: TPM 2.0 unhealthy, Secure Boot or firmware changes after associate, and technicians who still try association on a VM.

What breaks it:

• Inventory TPM health and Secure Boot before the first DeviceLink export.
• Document on-device clear as the removal path — do not promise a portal “remove association” button that does not exist yet.
• Keep VMs on classic Autopilot or a non-association prep path; do not burn the pilot on unsupported hardware.

What "good" looks like: the five-move baseline

If you do nothing else this quarter, these five moves dismantle the confusion above in order of impact:

1. Stand up Autopilot device preparation — one policy that matches how you already do Entra join OOBE, before you touch association.
2. Pilot on physical Windows 11 with TPM 2.0 — three devices, not a VM lab.
3. Export DeviceLink → upload under Device association → associate → enroll — verify OOBE naming and page skips without waiting on user sign-in.
4. Assign the preparation policy to the device at upload when you need device-targeted preparation, not only user targeting.
5. Write the failure card — TPM unhealthy, firmware change after associate, on-device clear for removal, VMs unsupported.

No new Autopilot product SKU required—just a clean preparation policy and a DeviceLink workflow your techs can repeat.

The uncomfortable question

The question worth asking is not “does Autopilot device association replace classic Autopilot hashes?”—it is “would our Device Preparation policy plus DeviceLink upload have stamped this device before the user signed in, on hardware that can actually attest?”

If you do not know, check the Device association devices blade and the device’s TPM/Secure Boot state on the next Entra-join Windows 11 unit on your bench—not the Hyper-V lab.