Autopilot Device Association : Que cache cette nouvelle fonctionnalité ?

Microsoft a annoncé le 27 août 2026 une nouvelle fonctionnalité pour Autopilot Device Preparation : Device Association.

Son objectif est assez simple à résumer : permettre à une organisation d’identifier et d’associer de manière fiable un PC Windows 11 physique à son tenant avant même que l’enrôlement MDM commence.

Derrière cette phrase se cache cependant un changement technique intéressant. Device Association introduit une chaîne de confiance reposant notamment sur le TPM 2.0, une identité matérielle attestée et un marqueur d’affinité avec le tenant enregistré dans l’UEFI.

La fonctionnalité fait partie de Windows Autopilot Device Preparation et ne doit donc pas être confondue avec l’enregistrement historique d’un appareil dans Windows Autopilot

Mais commençons par la base.

Qu’est-ce que Windows Autopilot Device Preparation ?

Windows Autopilot Device Preparation est la nouvelle génération de l’expérience Autopilot introduite par Microsoft pour simplifier le déploiement des appareils Windows 11 dans Microsoft Intune.

Son objectif reste le même que celui de Windows Autopilot : permettre à un utilisateur de recevoir un PC neuf ou réinitialisé et de le configurer avec un minimum d’intervention IT.

Mais Device Preparation repose sur une architecture différente du modèle Autopilot historique : Au lieu de s’appuyer principalement sur un appareil préenregistré dans le service Windows Autopilot à l’aide de son Hardware Hash, Device Preparation s’intègre plus directement à Microsoft Intune et Microsoft Entra ID.

Le processus repose sur des Device Preparation Policies qui définissent notamment :

• Les groupes auxquels l’appareil doit être ajouté
• Les applications qui doivent être installées pendant la préparation
• Les scripts et configurations nécessaires
• Les paramètres de sécurité à appliquer
• Le comportement attendu pendant l’OOBE.

Lorsqu’un utilisateur démarre un appareil compatible et s’authentifie avec son compte professionnel, Windows identifie la Device Preparation Policy applicable puis prépare automatiquement la machine avant de remettre la session à l’utilisateur.

Microsoft a notamment conçu cette approche pour simplifier l’administration d’Autopilot et réduire certaines dépendances historiques liées à l’enregistrement préalable des appareils.

Device Preparation introduit également une logique plus dynamique autour des groupes d’appareils et de la préparation du poste.

Cependant, dans son fonctionnement initial, il restait une difficulté importante : comment identifier avec certitude un appareil physique précis avant que son enrollment ne commence ?

C’est précisément le problème auquel répond Windows Autopilot Device Association.

Device Association vient donc compléter Device Preparation en ajoutant une relation explicite entre :

Autrement dit, Device Preparation définit comment un appareil doit être préparé.

Device Association permet désormais de définir quel appareil précis doit suivre cette préparation, avant même son enrollment dans Intune.

Comment fonctionne Device Association ?

Le mécanisme repose sur trois opérations principales :

Pre-associate → Associate → Remove association

1. Pre-associate

La première étape consiste à déclarer dans Intune que l’on souhaite associer une machine donnée au tenant. L’administrateur récupère pour cela les informations du périphérique, puis les importe dans :

Intune → Appareils → Enrollment → Device association → Appareils

Le device apparaît alors avec l’état : Pre-associated

À ce stade, Microsoft enregistre l’intention d’établir une association entre le hardware et le tenant, mais le marqueur d’association n’a pas encore été inscrit sur la machine. Une Device Preparation Policy peut également être affectée directement au device à ce moment-là. 

2. Associate

L’étape suivante intervient côté machine.

Lorsque le PC pré-associé accède au réseau pendant l’OOBE, Windows contacte les services Autopilot. Le système vérifie alors que la machine présente bien l’identité TPM attendue.

Microsoft indique explicitement que Device Association utilise :

• Une identité protégée par le TPM
• Une attestation TPM
• Une validation cryptographique de cette identité.

Si cette validation réussit, un marqueur contenant l’affinité avec le tenant est écrit dans le firmware UEFI de la machine.

Le statut du device devient alors : Associated

Ce marqueur est ensuite utilisé pour attester l’affinité de la machine avec l’organisation lors de l’enrollment. 

Le workflow peut être représenté ainsi :

L’association est persistante

Un des aspects les plus intéressants de Device Association est que l’association ne dépend pas de l’installation Windows actuellement présente sur le disque.

Le marqueur d’affinité avec le tenant étant stocké dans le firmware UEFI, Microsoft indique qu’il survit notamment à un reset ou une réinstallation Windows ou à la suppression de l’enrollment MDM. Autrement dit, réinstaller Windows ne suffit pas à supprimer Device Association. 

Pour retirer complètement l’association, il faut supprimer l’information d’affinité présente sur le device. Microsoft précise également que cette opération nécessite un accès physique à la machine. Du point de vue du mécanisme Device Association, la personne disposant de cet accès physique est considérée comme propriétaire du matériel pour l’opération de retrait de l’association.

Autre conséquence directe de Device Association : une machine pré-associée ou associée est automatiquement reconnue comme Corporate-Owned : Il n’est donc pas nécessaire d’ajouter parallèlement le numéro de série ou une autre information dans les Windows Corporate Identifiers.

Microsoft considère les Corporate Identifiers et Device Association comme deux moyens alternatifs de déterminer si un appareil peut être considéré comme conforme / corporate pendant sa préparation. 

Le rôle de l’export DeviceLink

Pour effectuer la pré-association, Intune doit disposer des informations permettant d’identifier le device. Microsoft utilise pour cela un fichier appelé DeviceLink.csv.

Lors de l’OOBE, il peut être récupéré en ouvrant le menu Autopilot (Appui cinq fois sur la touche Windows puis Export device information). Le CSV devra ensuite être importé dans Intune afin de créer l’enregistrement Pre-associated.

À l’heure actuelle, Intune impose une contrainte assez importante : un seul appareil par fichier CSV. Il faut donc importer séparément chaque DeviceLink lorsqu’on utilise directement cette méthode dans l’interface Intune.

Il est également possible de récupérer un DeviceLink sur un PC déjà en fonction, car le DeviceLink n’est pas réservé à une machine encore présente dans l’OOBE. Sur une machine ayant déjà terminé son installation, Microsoft indique que le fichier peut être récupéré depuis les diagnostics Autopilot.

Deux méthodes existent.

Depuis Windows :
Paramètres → Comptes → Accès professionnel ou scolaire → Exporter les journaux de gestion

En ligne de commande :

mdmdiagnosticstool.exe -area "DeviceEnrollment;DeviceProvisioning;Autopilot" -zip "C:\Users\Public\Documents\AutopilotDiagnostics.zip"

Cette commande collecte les informations liées à : DeviceEnrollment, DeviceProvisioning et Autopilot

Elle génère ensuite l’archive C:\Users\Public\Documents\AutopilotDiagnostics.zip. Il suffit alors d’extraire cette archive et de rechercher le fichier DeviceLink_<ComputerName>.csv ou DeviceLink.csv

DeviceLink et Hardware Hash : quelle différence ?

C’est probablement l’un des points pouvant générer le plus de confusion.

DeviceLink et Hardware Hash servent tous les deux à identifier un appareil physique, mais ils appartiennent à deux workflows Autopilot différents et n’ont pas exactement le même objectif.

Le Hardware Hash

Dans Windows Autopilot historique, l’enregistrement d’un appareil repose sur son identité matérielle, communément appelée : Hardware Hash. Avant qu’un appareil puisse être déployé via Windows Autopilot, son identité matérielle doit être enregistrée auprès du service Autopilot.

Microsoft décrit l’enregistrement traditionnel comme deux opérations :

1. Récupérer le Hardware Hash
2. Associer cette identité matérielle à un tenant.

Le service Windows Autopilot maintient ensuite une base permettant d’associer ces identités matérielles aux organisations clientes.

Lors d’un import manuel dans Intune, on retrouve typiquement un CSV de ce type :

Device Serial Number,Windows Product ID,Hardware Hash,Group Tag,Assigned User

Le Hardware Hash est donc utilisé pour enregistrer la machine auprès du service Windows Autopilot. 

Le DeviceLink

DeviceLink quant à lui, est utilisé dans le cadre du Windows Autopilot Device Preparation + Device Association

Il sert à créer la pre-association permettant ensuite au service de vérifier l’identité TPM de la machine pendant l’OOBE.

Il ne faut donc pas considérer DeviceLink comme un simple nouveau format de Hardware Hash : Le DeviceLink fait partie d’un workflow où l’identité de la machine est ensuite attestée matériellement avant que l’affinité avec le tenant ne soit écrite dans l’UEFI. 

Si l’on devait comparer les deux fonctionnalité, cela donnerait le tableau suivant :

	Hardware Hash	DeviceLink
Technologie	Windows Autopilot	Autopilot Device Preparation
Workflow	Device registration	Device Association
Objectif	Enregistrer et reconnaître l’appareil auprès du service Autopilot	Pré-associer l’appareil avec un tenant
Import	Windows Autopilot Devices	Device Association
Validation TPM	Facultatif	TPM attestation obligatoire
Marqueur UEFI d’affinité tenant	Non	Oui
Politique directement ciblée sur le device	Profil Autopilot selon le modèle Autopilot	Device Preparation Policy
Plusieurs appareils par CSV	Jusqu’à 500 pour un import Intune manuel	Actuellement un seul device par CSV
Utilisation possible par OEM / partenaires	Oui	Pas encore pour l’import Device Association

Le point à retenir peut être résumé ainsi :

Hardware Hash :

DeviceLink :

Il ne faut cependant pas interpréter Device Association comme le remplacement immédiat du mécanisme Hardware Hash.

Les deux technologies coexistent : Microsoft précise même qu’un appareil déjà enregistré dans Windows Autopilot peut également être pré-associé avec Device Association.

Dans ce cas, lors du passage dans l’OOBE, Device Association prend la priorité, et le device suit le parcours défini par sa Device Preparation Policy

Une identité matérielle qui peut évoluer

Autre subtilité intéressante : la valeur du DeviceLink peut varier entre deux exports sans que l’identité matérielle du device ait changé : Microsoft explique que le DeviceLink embarque notamment des métadonnées temporelles.

Deux exports successifs peuvent donc produire des fichiers différents. Cela ne signifie pas pour autant que la pre-association existante est devenue invalide. 

En revanche, certaines opérations peuvent effectivement modifier l’identité matérielle utilisée par Device Association. Microsoft cite notamment : Un reset des paramètres BIOS / UEFI, certaines opérations de nettoyage de l’UEFI, une modification de la configuration Secure Boot, la suppression explicite de Device Association.

Dans ce cas, le service peut ne plus être capable de faire correspondre la nouvelle identité avec l’ancienne pre-association.

Les Device-targeted policies

Device Association ne sert pas uniquement à améliorer l’identification de la machine : Il permet également de cibler directement une Device Preparation Policy sur un appareil donné.

C’est un changement intéressant dans la logique de Windows Autopilot Device Preparation : Lors de la pre-association, l’administrateur peut sélectionner explicitement la Device Preparation Policy à utiliser.

Cela signifie qu’un même utilisateur peut préparer plusieurs machines et que chacune d’entre elles peut suivre une politique différente.

Si aucune policy n’est directement assignée au device, Device Preparation peut continuer à rechercher une politique affectée à l’utilisateur qui réalise l’enrollment.

Si aucun des deux ne possède de policy correspondante, aucune Device Preparation Policy n’est appliquée. 

Personnalisation de l’OOBE

Le fait de reconnaître l’appareil avant l’enrollment permet également au Device Preparation d’agir plus tôt dans le processus OOBE.

Microsoft permet notamment de configurer :

• La région
• Le clavier
• Le masquage des conditions de licence Microsoft
• Le masquage des paramètres de confidentialité
• Certaines options liées au changement de compte
• Le nom du device.

Pour le naming, Microsoft permet entre autres l’utilisation de variables telles que :

%SERIAL%

Ou :

%RAND:x%

Pour injecter une chaîne numérique aléatoire d’une longueur définie.

Les prérequis techniques

Device Association possède des prérequis nettement plus stricts que certains scénarios Autopilot traditionnels.

Au lancement, Microsoft exige :

• Windows 11 24H2 à minima + KB5120998 ou ultérieur
• Un appareil physique
• Un TPM 2.0 actif et fonctionnel
• Un TPM qui ne soit pas en Reduced Functionality Mode.

Les machines virtuelles ne sont pas supportées, la raison est directement liée au modèle de sécurité de Device Association : Microsoft doit pouvoir garantir que l’identité présentée pendant l’association est effectivement protégée et attestée par le hardware.

En plus des prérequis réseau habituels de Windows Autopilot Device Preparation, Microsoft demande notamment un accès HTTPS sur le port TCP 443 vers plusieurs services supplémentaires.

Par exemple :

https://ztd.dds.microsoft.com

ainsi que plusieurs endpoints Azure Attestation :

https://peapdamaa1.eus2.attest.azure.net
https://peapdamaa2.wus2.attest.azure.net
https://peapdamaa3.cus.attest.azure.net
https://peapdamaa5.cus.attest.azure.net

Ces flux sont cohérents avec le mécanisme d’attestation matérielle utilisé pendant Device Association. Ils devront donc être pris en compte dans les environnements disposant de filtrage Internet strict pendant l’OOBE.

Pour conclure

Device Association ajoute une nouvelle couche à Windows Autopilot Device Preparation.

Au lieu d’attendre l’enrollment pour établir complètement la relation entre le PC et l’organisation, il devient possible de créer cette relation avant l’enrôlement MDM.

Le workflow peut finalement être résumé ainsi :

Ce mécanisme apporte principalement quatre choses : Une identité matérielle vérifiée avant l’enrollment, une affinité persistante entre le device et le tenant, le ciblage direct des Device Preparation Policies et davantage de contrôle sur l’OOBE avant que le device ne soit réellement enrôlé.

DeviceLink et Hardware Hash ont donc des finalités différentes : Le Hardware Hash reste au cœur du mécanisme historique d’enregistrement Windows Autopilot.

DeviceLink est la variable utilisée pour initier le nouveau mécanisme de Device Association, lequel s’appuie ensuite sur le TPM et l’attestation matérielle pour créer une relation persistante entre l’appareil et l’organisation.

Device Association ne remplace donc pas aujourd’hui Windows Autopilot classique.

Mais techniquement, il introduit une approche différente : ne plus uniquement reconnaître un PC dans une base Autopilot, mais vérifier cryptographiquement son identité matérielle avant l’enrollment et conserver son affinité avec le tenant directement au niveau du firmware.

Sources

Microsoft Tech Community — Introducing device association for Windows Autopilot device preparation
Microsoft Learn — Overview of Windows Autopilot device association
Microsoft Learn — Requirements for Windows Autopilot device association
Microsoft Learn — Device association lifecycle management
Microsoft Learn — Associate devices
Microsoft Learn — Windows Autopilot Device Preparation workflow
Microsoft Learn — Windows Autopilot registration overview
Microsoft Learn — Manually register devices with Windows Autopilot