Device Association in Intune: a practical Autopilot guide

Windows Autopilot Device Association establishes the device-to-organisation relationship before enrolment. It is particularly useful when different devices need different preparation policies even when the same user enrols them. This article covers the device preparation feature, rather than changing the primary user of an already managed device.

What association establishes

The feature writes tenant affinity into UEFI firmware and supports device-targeted preparation policies and additional OOBE customisation. Associated devices are recognised as corporate-owned. Association establishes an early identity relationship; it does not by itself demonstrate that a device meets your compliance policy or has installed its security tooling. [1]

Check physical-device readiness

Microsoft requires a physical Windows 11 device with a healthy TPM 2.0; virtual machines are unsupported. The documented minimum is Windows 11 24H2 or 25H2 with KB5120998 or later. Validate the current requirements against the actual image before a pilot. Device preparation licensing and network prerequisites apply, with additional Autopilot and attestation endpoints over HTTPS. Use the linked endpoint list rather than a regional subset. [2]

Use least-privilege roles covering preparation-policy work and associated-device management. Test network access from OOBE, where user sign-in and the normal desktop proxy experience may not exist. Treat any proxy exception as a reviewed network design decision.

A small pilot, end to end

1. Prepare the underlying Autopilot device preparation policy, enrolment settings and intended apps.
2. At OOBE region selection, press the Windows key five times and export device information to an approved USB drive.
3. Open Devices > Enrollment > Device association > Devices, select Add and import the exported CSV. The documented portal flow accepts one device per CSV.
4. Optionally assign its preparation policy directly. Without this assignment, the enrolling user’s policy is used if one exists.
5. Connect the pre-associated device to the network in OOBE to complete association, then continue enrolment. Verify the state changes and the intended policy.

If personal enrolment is blocked, use either device association or corporate identifiers before deployment; both are not required. Existing devices can supply the DeviceLink CSV from Autopilot diagnostics. [3]

Reset, repair and transfer

Hardware-identity changes can create stale pre-association records. Association also takes precedence during OOBE if the device was already registered for classic Autopilot. The current overview states that removal from Intune is not supported: use the documented local removal procedure. [4] [1]

For a tenant migration, make device release a named workstream alongside data migration. Record the source association, intended target, authorised technician, recovery material and acceptance evidence. Do not assume deleting cloud device objects completes the transfer.

Define success beyond the association state

I would start with several hardware models and both office and remote network paths. Include procurement, service desk and asset disposal teams in the walkthrough: the association lifecycle extends beyond the person who creates the Intune policy.