Windows Autopilot device association: TPM-backed tenant affinity before enrollment

Windows Autopilot device preparation originally learned which tenant a device belonged to only when the user signed in, which is too late to change OOBE pages or name the device. Device association, added to device preparation in August 2026, fixes that by binding a physical Windows 11 device to your tenant before enrollment, with the proof stored in UEFI and verified through the TPM. In this post I'll cover what it does, the requirements, how to associate a device, how the association behaves through resets and decommissioning, and how it fits alongside classic Autopilot registration.

How it works#

Association has three operations:

• Pre-associate: an admin uploads the device's exported information to Intune, which records the intent to bind that specific TPM-backed hardware identity to the tenant and optionally assigns a device preparation policy to it.
• Associate: during OOBE, as soon as the device gets a network connection (or when a technician triggers it), the device proves its identity through hardware attestation and the service writes a tenant affinity marker into the device's UEFI firmware. That marker is what the device presents at enrollment.
• Remove association: a script run on the device clears the UEFI marker when the device leaves the organisation for good.

Once associated, the device is recognised as yours before anyone signs in, which unlocks four things: it's automatically marked corporate-owned (so enrollment restrictions that block personal devices don't stop it and you don't need corporate identifiers), the device preparation policy can be targeted to the device rather than to the signing-in user, a device name template can be applied, and OOBE can be trimmed. The OOBE settings this enables in the user-driven policy are Language (Region), automatically configure keyboard, hide the Microsoft Software License Terms, hide privacy settings (location services are then off by default) and hide change account options, which needs company branding in Microsoft Entra ID. Name templates can be up to 63 characters of letters, numbers and hyphens (not digits only) and support %SERIAL% and %RAND:x%.

Prerequisites#

• Hardware: a physical device with TPM 2.0 in a healthy state. Virtual machines aren't supported, even for testing. Microsoft's requirements page specifically covers TPMs in reduced functionality mode, so check TPM health (for example with Get-Tpm) before you stage a device.
• Software: Windows 11 24H2 or 25H2 with KB5120998 or later, on Pro, Pro Education, Pro for Workstations, Enterprise, Education or Enterprise LTSC.
• Networking and licensing: the normal Windows Autopilot device preparation network requirements plus the association and attestation endpoints listed on the requirements page; licensing follows device preparation, meaning an Intune subscription together with Microsoft Entra ID P1 or P2 (included in plans such as Microsoft 365 Business Premium and E3/E5).
• RBAC: the requirements page lists the Intune permissions needed to manage device preparation policies and associated devices. Give the people who stage hardware a custom role with just those permissions rather than a tenant-wide admin role.
• Not applicable: Windows 365 Cloud PCs, which are already treated as trusted corporate devices.

Step-by-step#

1. Create the device preparation policy#

Build your user-driven device preparation policy as usual (the device group, apps and scripts, and now the OOBE and naming settings). Associated devices that have this policy assigned will use it regardless of who signs in.

2. Export the device information#

Boot the new device into OOBE and stop at the region page. Press the Windows key five times quickly to open the Autopilot menu, select Export device information, insert a USB drive (NTFS recommended) and export. The menu also offers Scan QR code, which is meant for custom apps that pre-associate through Microsoft Graph; Intune's portal upload accepts only the exported CSV today. For a device that's already past OOBE, collect Autopilot diagnostics instead and pull the DeviceLink CSV from them: Settings › Accounts › Access work or school › Export your management logs, or from an elevated prompt:

MdmDiagnosticsTool.exe -area Autopilot -cab C:\Diagnostics\Autopilot.cab

You can also use Collect diagnostics on the device in the Intune admin center and download the package.

3. Pre-associate in Intune#

Go to Devices › Enrollment › Device association › Devices › Add, browse to the CSV (one device per file for now), optionally pick the device preparation policy on the Assign device preparation policy page, review and Add. The device appears with the state Pre-associated. If you skip the policy, the device falls back to whatever device preparation policy the signing-in user has; if that user has none, no policy applies.

4. Complete the association#

Association completes automatically when the pre-associated device connects to a network in OOBE. A technician who's still at the device can also go back to the Autopilot menu and select Next; the device looks up its pre-association record and OOBE shows Association complete. From there the user signs in, the device joins Microsoft Entra ID and enrolls, and device preparation runs with the device-targeted policy.

Verify#

• In Devices › Enrollment › Device association › Devices, search by serial number or name and filter by state, policy, manufacturer or model. States are Pre-associated, Associated and Pending removal.
• During OOBE, a correctly associated device skips the pages you hid and, on Pro editions, doesn't ask whether it's a personal or work device.
• After enrollment, check the device record in Intune: ownership should read Corporate without any corporate identifier upload, and the name should match your template.
• On the device itself, the association lives in the Device Link UEFI namespace {B3DE75DA-819C-4FD5-9F01-C3D49E8CBBD7} as the variables DeviceLinkId, DeviceLinkJwtCompressed, DeviceLinkJwtLastWrite and DeviceLinkCreationTimeUtc. Microsoft's removal guidance has used the UEFI module from the PowerShell Gallery to read and clear them, so you can confirm the marker is present like this:

Install-Module UEFI -Force
$ns = '{B3DE75DA-819C-4FD5-9F01-C3D49E8CBBD7}'
'DeviceLinkId','DeviceLinkJwtCompressed','DeviceLinkJwtLastWrite','DeviceLinkCreationTimeUtc' |
    ForEach-Object { Get-UEFIVariable -Namespace $ns -VariableName $_ -ErrorAction SilentlyContinue }

Lifecycle: resets, re-uploads and removal#

• Resets don't remove it. The marker is in firmware, so it survives a Windows reset, a reinstall and removal of the enrollment; a wiped device still knows it's yours. Only clearing the UEFI variables on the device removes the affinity, which needs physical access; whoever has physical access is treated as the owner from a security standpoint.
• Clearing while still enrolled is pointless. An enrolled device is re-associated at its next check-in. If it's no longer enrolled, Intune doesn't know the marker is gone and the record simply goes stale.
• Re-uploading a CSV for the same device updates the existing record (for example to change the assigned policy) as long as the hardware identity is unchanged. Clearing the UEFI variables, resetting BIOS/UEFI settings or toggling Secure Boot changes the identity, so a new record is created and the old one becomes stale. Exported CSVs differ between exports because the DeviceLink carries timestamps; that alone doesn't invalidate anything.
• Stale pre-association records are deleted automatically after 360 days; no cleanup job needed.
• Decommissioning: for a Pre-associated device just delete it from the list. For an Associated device, unenroll it first, clear the four Device Link variables from an elevated PowerShell session on the device (clearing doesn't reset the TPM, unenroll the device or delete its Microsoft Entra or Intune objects), then delete it from the Device association list; it shows Pending removal until the request completes. Removing an association from the portal alone isn't supported.

Classic Autopilot and precedence#

Device association is a device preparation feature, not a replacement for classic Autopilot registration with a hardware hash and deployment profile. The two can coexist: a device already registered for classic Autopilot can still be pre-associated, and when it goes through OOBE the association takes precedence, so the device is deployed with the device preparation policy rather than the Autopilot profile. Within device preparation, a policy assigned directly to the associated device takes precedence over one assigned to the user's group. If you're testing both models on the same hardware, clear the association and delete the record before expecting classic Autopilot behaviour again.

Tips & gotchas#

• Corporate identifiers and association are alternatives. If every device will be associated, you can stop maintaining the corporate identifier list.
• Only one device per CSV, and OEM, reseller or partner pre-association isn't available yet; Microsoft says it's planned. Factor the per-device export into your staging workflow.
• Write the removal step into your disposal runbook. A device that leaves with the marker intact is still bound to your tenant from the firmware's point of view.

References#

• Overview of Windows Autopilot device association
• Device association lifecycle management
• Remove association from a device