Microsoft has added another important capability to Windows Autopilot device preparation, and this one addresses one of the bigger differences between the newer device preparation model and traditional Windows Autopilot. It is called device association.
Device association allows an organization to establish a relationship with a physical Windows 11 device before the device actually enrolls into Microsoft Intune. That sounds like a relatively small change, but it changes quite a bit about how Windows Autopilot device preparation can be used.
Until now, device preparation has generally focused more on the user enrolling the device. Device association is moving the process toward a device-first model, where Intune can recognize the hardware, determine it belongs to the organization, and decide how that device should be configured before the user completes enrollment.
Microsoft announced the capability on August 27, 2026.
The Problem Device Association Is Trying to Solve
Windows Autopilot device preparation was introduced as a simpler approach to Windows provisioning. Instead of maintaining some of the registration and configuration mechanisms associated with traditional Windows Autopilot, administrators could create a device preparation policy that includes the applications, scripts, configurations, and deployment settings required for a new device.
The user signs into the device during the Windows Out-of-Box Experience, or OOBE, and the appropriate configuration is then applied. That works well, but there has always been an obvious question:
How do we know that the Windows device connecting to the tenant is actually one of our devices before enrollment occurs?
There is also another problem. What happens when the configuration needs to follow the device rather than the user? A user could have several computers, each with a different purpose. For example:
- An administrator could have a standard corporate laptop.
- The same administrator could also have a privileged access workstation.
- A developer could have a standard laptop and a separate development workstation.
- A shared or specialized system might need a completely different application and security configuration.
Assigning everything based primarily on the person signing in to the computer does not always provide sufficient control. Device association is Microsoft’s answer to that problem.
Associate the Device Before Enrollment
With device association, an administrator can create a relationship between a Windows 11 device and the Microsoft 365 tenant before the normal Intune enrollment process begins. The device is essentially known to the organization in advance.
When the device eventually starts OOBE and connects to the Internet, Windows can identify that association and determine which Windows Autopilot device preparation configuration should apply. More importantly, Microsoft isn’t simply matching something like a serial number stored in Intune. The association uses hardware-based attestation and TPM-backed cryptographic validation to verify the device’s identity.
That makes this considerably more interesting from a security perspective.
The Association Is Stored in UEFI
One of the more interesting parts of the implementation is where the association ultimately lives. Once the association is complete, tenant affinity information is stored in the device’s UEFI firmware. That means the relationship isn’t simply dependent on the current Windows installation.
The association can survive:
- A Windows reset
- Reinstallation of Windows
- Removal of the Intune enrollment
- Redeployment of the device inside the organization
The result is a much more persistent relationship between the physical hardware and the organization. If somebody wipes Windows and starts OOBE again, the device can still determine that it belongs to the organization. This moves an important part of device trust below the operating system itself.
Device-Based Policy Targeting
Device association also introduces something that I think will be particularly useful in larger environments: device-targeted Windows Autopilot device preparation policies. Previously, device preparation configuration was largely associated with the user’s enrollment. Administrators can now associate a specific device with a device preparation policy before enrollment. That means configuration can follow the hardware.
If both a device-based policy and a user-based policy could apply during enrollment, Microsoft states that the device-based assignment takes precedence. That is an important behavior to understand. Consider a user named Tom who receives two Windows devices. His primary laptop might receive:
- Microsoft 365 Apps
- Microsoft Defender configuration
- VPN software
- Standard corporate applications
His second machine could be a development workstation that requires:
- Visual Studio
- Development tools
- Different security policies
- Additional configuration scripts
Tom is still the same user. The device is what determines the required configuration. With device association, those two devices can receive different preparation policies, even if the same person signs in to both.
Better Control of Windows OOBE
The capability also gives administrators more control over what users see during Windows setup. Associated devices can have additional OOBE settings configured ahead of time, including:
- Language and region
- Keyboard configuration
- Microsoft Software License Terms
- Windows privacy settings
- Device naming
- Account-change options on company sign-in and domain error pages
The goal here is fairly straightforward. The fewer decisions an employee has to make during provisioning, the more predictable deployment becomes. Instead of handing someone a new laptop and providing instructions on which region to choose, which keyboard to select, and which buttons to click, IT can make many of those decisions before the computer ever reaches the employee.
There is one limitation worth noting.
Microsoft states that when the device uses Wi-Fi during OOBE, the language and keyboard selection screens aren’t hidden.
Device Naming Before Enrollment
Another useful addition is device naming. Administrators can configure a device name template that uses either:
- The device serial number
- A randomized value
Device naming has historically been one of those seemingly simple requirements that becomes surprisingly important once you start operating Intune at scale. Having predictable device names helps with inventory, troubleshooting, reporting, automation, and support. Being able to establish that naming during the device preparation process makes the deployment considerably cleaner.
Corporate Ownership Becomes Automatic
There is another important Intune behavior tied to device association. Associated devices are automatically classified as corporate-owned. This matters if you use Intune enrollment restrictions to prevent personally owned Windows computers from enrolling. Traditionally, one approach would be to maintain corporate device identifiers so Intune could determine that a device belonged to the organization. Device association can now directly establish that corporate relationship.
Microsoft specifically notes that an associated device does not also require a separate corporate identifier. Organizations can continue using corporate identifiers where appropriate, but the two aren’t required together. For organizations that aggressively block unmanaged or personally owned Windows devices, this creates a much cleaner onboarding path.
How Device Association Works
The process begins by creating or updating a Windows Autopilot device preparation policy. That policy contains the configuration required during deployment, including applications, scripts, deployment settings, and OOBE options. The physical device then needs to be identified.
During OOBE, a technician can open the Windows Autopilot menu and export a DeviceLink CSV containing the information required to pre-associate the device. For an existing computer, Microsoft says the same information can also be obtained from the Autopilot diagnostic logs. The CSV is then uploaded through:
Microsoft Intune admin center > Devices > Enrollment > Device association > Devices
At that point, the administrator can optionally assign a specific device preparation policy to the hardware. The device is now considered pre-associated. When the computer subsequently connects to the network during OOBE, Windows discovers the pre-association and completes the hardware-backed association. The device can then:
- Be recognized as belonging to the organization
- Receive its device-targeted preparation policy
- Be marked corporate-owned
- Receive the configured OOBE experience
- Continue through Intune enrollment
From the user’s perspective, much of this happens before they ever reach the Windows desktop.
Understanding the Association States
Administrators can monitor devices from the new Device association area in Intune. Microsoft currently describes three major states.
Pre-associated: The administrator has created the association in Intune, but the physical device hasn’t completed the association during OOBE.
Associated: The device has successfully completed association and written the tenant affinity information into UEFI.
Pending removal: The association is being removed.
Administrators can filter the device association view by properties such as policy, manufacturer, model, and association state, which should make the process considerably easier to manage at scale.
What Happens When the Device Leaves the Organization?
The persistence of device association is both one of its biggest advantages and an operational consideration for administrators. Because the association survives Windows resets and operating system reinstallation, simply wiping the computer isn’t necessarily enough when the device permanently leaves the organization.
If the computer is being:
- Sold
- Recycled
- Donated
- Returned to a leasing company
- Transferred to another organization
the device association should also be removed.
Microsoft provides a local script that can clear the tenant affinity information from UEFI. Interestingly, that removal doesn’t necessarily require access to the tenant service. An administrator or partner with physical control of the computer can perform the removal locally.
That means device association needs to be incorporated into the organization’s device decommissioning process. This is something I would add to any existing Windows lifecycle procedure rather than treating it purely as an Intune configuration task.
What About Traditional Windows Autopilot?
Device association doesn’t mean traditional Windows Autopilot suddenly disappears. Microsoft specifically designed the two approaches so they can coexist within the same tenant. The interesting part is what happens when a computer exists in both models. If a device is traditionally registered with Windows Autopilot but isn’t associated, the traditional Windows Autopilot deployment takes precedence. If that same computer is associated, Windows Autopilot device preparation takes precedence instead.
That provides organizations with a migration path rather than forcing an immediate replacement of existing Autopilot deployments. You could continue supporting thousands of existing Autopilot devices while gradually moving new hardware or specific device populations toward Windows Autopilot device preparation.
Hardware Requirements
There are some important requirements. Device association currently requires a supported physical Windows 11 device with:
- TPM 2.0
- TPM enabled
- TPM in a healthy state
- Hardware capable of performing the required attestation
Virtual machines aren’t supported. That makes sense when you consider the security model. The entire purpose of the capability is to establish a hardware-backed identity for a physical device. A virtual TPM wouldn’t provide the same relationship Microsoft is trying to establish between the tenant and the underlying hardware.
Why This Matters for Zero Trust
The part I find particularly interesting is how this fits into the broader Zero Trust model Microsoft has been building around Windows. Zero Trust discussions usually focus heavily on what happens after a device is enrolled. We verify:
- The user’s identity
- MFA
- Device compliance
- Endpoint security posture
- Conditional Access requirements
- Application access
But there is another question that needs answering before any of that happens:
Should this device have been allowed into the organization’s management environment in the first place?
Device association begins establishing that trust earlier. The organization isn’t simply waiting for somebody to authenticate and enroll a computer. The physical device has already established an authenticated relationship with the tenant using hardware-backed identity information. That is a subtle but important shift. Instead of:
User signs in → device enrolls → organization determines whether it trusts the device
We are moving closer to:
Organization identifies device → hardware proves identity → correct configuration is selected → user enrolls → access controls evaluate the resulting managed device
That is a much stronger provisioning model.
Device Preparation Is Starting to Look Much More Complete
When Windows Autopilot device preparation first appeared, I viewed it primarily as Microsoft’s attempt to simplify the increasingly complicated traditional Autopilot deployment model. The concept made sense, but there were still capabilities in traditional Autopilot that organizations depended on. Device association closes several of those gaps. It introduces persistent device identity, device-based targeting, corporate ownership identification, expanded OOBE customization, and device naming while keeping the newer device preparation architecture.
That makes the newer model considerably more interesting.
I wouldn’t immediately replace every existing Windows Autopilot deployment simply because device association now exists. Organizations with stable Autopilot environments don’t need to redesign them overnight. However, for new deployments, hardware refresh projects, and organizations moving toward cloud-native Windows management, Windows Autopilot device preparation with device association should now be part of the architecture discussion.
Microsoft is clearly continuing to build around this model. With device identity now established before enrollment, Windows Autopilot device preparation is becoming much more than just a simplified enrollment experience. It is becoming a mechanism for establishing trust in the Windows device before the user ever signs in.
More details are available from Microsoft
Overview of Windows Autopilot device association
https://learn.microsoft.com/en-us/autopilot/device-preparation/device-association/overview
Requirements for Windows Autopilot device association
Set up Windows Autopilot device preparation with device association