Conformité Intune sous Windows 11 : l’attestation passera à Microsoft Azure Attestation

Le 17 septembre 2026, Microsoft a annoncé dans le Windows message center un changement qui touche la conformité des appareils Windows 11 gérés par Intune. L’évaluation Windows Health Attestation, celle qui contrôle BitLocker, Secure Boot et l’intégrité du code, passera automatiquement du service Device Health Attestation (DHA) à Microsoft Azure Attestation (MAA). Microsoft situe ce changement au premier semestre 2027 et ne donne pas de date de bascule.

Le travail de l’administrateur porte sur le réseau. Les appareils Windows 11 s’adresseront à des instances de Microsoft Azure Attestation choisies selon l’emplacement du tenant Intune, et non plus au point de terminaison has.spserv.microsoft.com du service Device Health Attestation. Un pare-feu, un proxy ou une inspection SSL qui les empêche de joindre ces instances fait tomber les appareils concernés en non-conformité. Là où une stratégie d’accès conditionnel exige un appareil conforme, ces appareils peuvent alors perdre l’accès aux ressources de l’organisation.

Relevé le 29 septembre 2026 sur la documentation Microsoft.

Windows 11 passera à Microsoft Azure Attestation, Windows 10 reste sur Device Health Attestation

Intune s’appuie sur les services d’attestation de Microsoft pour vérifier qu’un appareil a démarré dans un état de confiance. La page des points de terminaison réseau d’Intune décrit le nouveau comportement : si un paramètre Device Health de la stratégie de conformité Windows est activé, les appareils Windows 11 utilisent un service Microsoft Azure Attestation qui dépend de l’emplacement du tenant Intune. Cette page décrit le fonctionnement cible sans le dater ; c’est l’annonce du 17 septembre 2026 qui en donne le calendrier.

Windows 10 et les environnements GCC High et DoD continuent d’utiliser le point de terminaison has.spserv.microsoft.com du service Device Health Attestation, et Microsoft les déclare non touchés par ce changement. Windows 10 a atteint sa fin de support le 14 octobre 2025, mais il reste une version autorisée dans Intune : ses appareils peuvent encore s’inscrire et utiliser les fonctions éligibles, sans garantie de fonctionnement. Un parc mixte garde donc deux flux d’attestation, l’ancien pour Windows 10 et le nouveau pour Windows 11.

Côté Windows, le HealthAttestation CSP explique ce qui se passe sur l’appareil. Windows 11 y ajoute des nœuds qui permettent au fournisseur MDM de s’appuyer sur Microsoft Azure Attestation. Sur demande du MDM, l’appareil rassemble ses preuves d’attestation (journaux de démarrage, traces d’audit du TPM et certificat du TPM), les transmet à l’instance Microsoft Azure Attestation que le fournisseur MDM a configurée, puis reçoit un rapport signé qu’il garde en cache local. La demande d’attestation du fournisseur MDM porte l’adresse complète de l’instance à utiliser : c’est ainsi qu’Intune peut désigner l’instance propre à l’emplacement du tenant.

Les trois paramètres Device Health de la stratégie de conformité Windows

Dans une stratégie de conformité Windows, la section Device health regroupe, sous Windows Health Attestation Service evaluation rules, trois paramètres : Require BitLocker, Require Secure Boot to be enabled on the device et Require code integrity. Chacun vaut par défaut Not configured, et il n’est alors pas évalué. La page des points de terminaison fait dépendre le passage à Microsoft Azure Attestation de l’activation d’au moins un de ces paramètres.

Un paramètre voisin prête à confusion. Encryption of data storage on a device, dans la section System security, vérifie de manière générique la présence du chiffrement sur le lecteur du système. La documentation le distingue explicitement de Require BitLocker, qui s’appuie sur Device Health Attestation pour valider l’état de BitLocker au niveau du TPM.

Deux causes de non-conformité existent déjà sur ces paramètres, indépendamment du réseau, et il vaut la peine de les écarter avant de chercher du côté du pare-feu. L’état de BitLocker n’est mesuré qu’au démarrage : un appareil dont le chiffrement vient de se terminer doit redémarrer pour devenir conforme. Et Microsoft indique que Require Secure Boot to be enabled on the device apparaît Not Compliant sur les appareils qui ne prennent pas en charge TPM 2.0 ou une version ultérieure.

Un point de terminaison d’attestation bloqué rend l’appareil Windows 11 non conforme

La page des points de terminaison est explicite : si des règles de pare-feu empêchent d’atteindre le nouveau service Microsoft Azure Attestation d’Intune, les appareils Windows 11 qui ont une stratégie de conformité avec l’un des paramètres Device Health (BitLocker, Secure Boot, Code Integrity) deviennent non conformes, faute de pouvoir joindre les points de terminaison de leur emplacement.

Ce statut de non-conformité remonte dans Microsoft Entra ID. Une stratégie d’accès conditionnel dont le contrôle d’accès est Require device to be marked as compliant s’en sert pour accorder ou bloquer l’accès à la messagerie et aux autres ressources de l’organisation. Le principe de l’accès conditionnel, qui s’appuie sur l’état de conformité que signale Intune, est décrit dans notre article sur le rôle de l’accès conditionnel.

Le délai entre l’échec et le blocage dépend des actions en cas de non-conformité. Chaque stratégie de conformité porte l’action Mark device noncompliant, programmée par défaut à zéro jour : l’appareil est marqué non conforme dès que la règle échoue. Modifier ce délai crée une période de grâce pendant laquelle l’appareil n’est pas encore marqué non conforme.

Trouver l’emplacement du tenant Intune

L’emplacement se lit dans le Microsoft Intune admin center, sous Tenant administration > Tenant status, onglet Tenant details, à la ligne Tenant location. La valeur prend une forme comme « North America 0501 », et c’est la région, la première partie de la valeur, qui désigne la liste à ouvrir. La page des points de terminaison publie trois listes : North America, Europe et Asia Pacific.

L’accès à Tenant administration, dont fait partie Tenant status, demande les permissions Intune Organization.Read, ManagedDevice.Read et ManagedApp.Read, que porte le rôle intégré Intune Read Only Operator.

Les six points de terminaison Microsoft Azure Attestation d’un tenant situé en Europe

Pour un tenant dont l’emplacement est en Europe, la page publie six adresses :

https://intunemaape7.neu.attest.azure.net https://intunemaape8.neu.attest.azure.net https://intunemaape9.neu.attest.azure.net https://intunemaape10.weu.attest.azure.net https://intunemaape11.weu.attest.azure.net https://intunemaape12.weu.attest.azure.net

Les mêmes six noms d’hôte figurent, sans le préfixe https://, dans la liste consolidée des FQDN en fin de page. Microsoft demande qu’aucune règle de pare-feu ne bloque le trafic HTTPS sortant sur le port 443 vers ces points de terminaison, et qu’aucune inspection SSL ne s’y applique.

Si le parc compte encore des appareils Windows 10 avec des paramètres Device Health, has.spserv.microsoft.com doit rester joignable pour eux.

L’inspection SSL n’est pas prise en charge sur ces points de terminaison

La page des points de terminaison d’Intune indique que l’inspection du trafic SSL n’est pas prise en charge pour .manage.microsoft.com, pour .dm.microsoft.com ni pour les points de terminaison d’attestation de la section conformité, qui renvoie à la liste Microsoft Azure Attestation. La section consacrée à la migration le répète pour les adresses propres à l’emplacement du tenant.

Une exclusion de l’inspection SSL déjà posée pour has.spserv.microsoft.com ne couvre pas les nouveaux noms d’hôte : elle doit être étendue aux adresses de la liste qui correspond à l’emplacement du tenant, les six adresses ci-dessus pour un tenant situé en Europe.

Tester depuis l’appareil, sous le compte SYSTEM

Dans le HealthAttestation CSP, les nœuds ajoutés pour Windows 11, comme TriggerAttestation et AttestStatus, sont déclarés pour l’étendue Device, et non User. Pour son propre outil de diagnostic, Test-IntuneAFDConnectivity.ps1, Microsoft distingue d’ailleurs l’exécution sous l’utilisateur connecté et l’exécution sous le compte Local System, qu’elle appelle Device context, et elle indique ce second contexte pour tester la connectivité de l’appareil lui-même. Nous testons donc sous SYSTEM. Microsoft obtient ce contexte avec PsExec de Sysinternals, depuis une invite PowerShell ouverte en administrateur :

.\psexec.exe -accepteula -i -s powershell.exe

Ce script de Microsoft vérifie la résolution DNS des points de terminaison du service Intune, les connexions TCP sur les ports 80 et 443 vers les adresses IP d’Azure Front Door et la validation HTTPS vers le service Intune. Pour les adresses d’attestation de l’emplacement du tenant, un contrôle direct se lance dans la même fenêtre SYSTEM. Le script suivant, que nous avons écrit pour Windows PowerShell 5.1 et que Microsoft ne fournit pas, porte les six adresses d’un tenant situé en Europe ; pour un autre emplacement, la liste $hotes se remplace par celle de l’onglet correspondant de la page des points de terminaison. Il ouvre une connexion HTTPS vers chaque adresse avec les réglages de proxy du contexte courant, puis affiche le code de réponse et l’émetteur du certificat reçu :

# Tenant situé en Europe : les six adresses de l'onglet Europe. # Autre emplacement : remplacer par la liste de l'onglet correspondant. $hotes = 'intunemaape7.neu.attest.azure.net','intunemaape8.neu.attest.azure.net', 'intunemaape9.neu.attest.azure.net','intunemaape10.weu.attest.azure.net', 'intunemaape11.weu.attest.azure.net','intunemaape12.weu.attest.azure.net' [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 foreach ($h in $hotes) { $req = [Net.WebRequest]::Create("https://$h/") $req.Timeout = 10000 try { $req.GetResponse().Close(); $etat = 'HTTP 200' } catch { $e = $_.Exception.InnerException; if (-not $e) { $e = $_.Exception } if ($e.Response) { $etat = "HTTP $([int]$e.Response.StatusCode)" } else { $etat = "$($e.Status) $($e.Message)" } } if ($req.ServicePoint.Certificate) { $emetteur = $req.ServicePoint.Certificate.Issuer } else { $emetteur = '(aucun certificat)' } '{0} | {1} | {2}' -f $h, $etat, $emetteur }

Un code HTTP accompagné d’un émetteur de certificat montre qu’une connexion TLS a abouti jusqu’à un serveur ; comme le script interroge la racine de chaque adresse, qui n’est pas l’API d’attestation, un 404 n’y signale pas de problème. Derrière un proxy explicite, un 407, ou un 403, vient en revanche du proxy qui refuse le tunnel : le script l’affiche alors comme un code HTTP ordinaire, et l’émetteur éventuellement affiché sur cette ligne ne vaut pas preuve d’une connexion au point de terminaison. Une erreur sans code HTTP (résolution de nom, délai, connexion refusée ou relation de confiance impossible) montre que la connexion n’aboutit pas. Reste l’émetteur, sur une ligne qui a abouti : si c’est l’autorité de certification de votre proxy ou de votre pare-feu, le trafic est inspecté, même si la connexion réussit.

AttestStatus, AttestErrorMessage et GetServiceCorrelationIDs : la trace de la dernière attestation

Trois nœuds du HealthAttestation CSP renseignent sur la dernière session. AttestStatus conserve le code de réussite ou d’échec de la dernière session d’attestation, effacé avant chaque appel au service : 0 en cas de succès, sinon un code HRESULT, dont Microsoft donne comme exemple 0x80072efd, WININET_E_CANNOT_CONNECT. AttestErrorMessage conserve le message d’erreur de la dernière session, quand le service d’attestation en renvoie un ; il existe à partir de Windows 11 version 22H2 avec KB5046732 et version 24H2 avec KB5046617. GetServiceCorrelationIDs, enfin, renvoie les identifiants de corrélation du service : une attestation réussie fait deux appels entre le client et Microsoft Azure Attestation, et leurs deux GUID sont séparés par un point-virgule.

Un code de connexion comme celui de l’exemple oriente vers le réseau. Il distingue un problème de réseau d’un BitLocker ou d’un Secure Boot non conforme, les deux familles de causes décrites plus haut.

Notre lecture

Nous traiterions ce changement comme une ouverture de flux réseau à préparer, plutôt que comme un chantier sur les stratégies de conformité : l’annonce décrit une migration automatique, et ce qu’elle demande de revoir, ce sont les configurations de réseau, de pare-feu, de proxy et d’accès aux points de terminaison. Le risque tient à une configuration réseau réglée pour has.spserv.microsoft.com et qui ne connaît pas encore les nouveaux noms d’hôte, en particulier une exclusion d’inspection SSL posée nom par nom.

Nous ferions l’ouverture et le test bien avant 2027. La migration est automatique et annoncée sur une période, sans que l’administrateur la déclenche : nous préférerions que les adresses de l’emplacement du tenant soient joignables, sans inspection, avant que le premier appareil passe à Microsoft Azure Attestation, plutôt que de découvrir le problème par une vague d’appareils non conformes.

Nous testerions enfin depuis des appareils réels, sous SYSTEM, sur chaque profil réseau du parc : réseau interne, VPN, et poste nomade si un proxy ou un agent de filtrage s’y applique. Quand l’accès conditionnel exige un appareil conforme, c’est l’accès des utilisateurs qui dépend de ce test.

Ce qu’il faut vérifier

• L’emplacement du tenant, dans Tenant administration > Tenant status > Tenant details, à la ligne Tenant location.
• Les stratégies de conformité Windows qui activent Require BitLocker, Require Secure Boot to be enabled on the device ou Require code integrity, et les groupes d’appareils Windows 11 auxquels elles sont assignées.
• L’ouverture du trafic HTTPS sortant sur le port 443 vers les adresses de la liste qui correspond à l’emplacement du tenant, soit les six adresses de l’onglet Europe pour un tenant situé en Europe, sur le pare-feu comme sur le proxy.
• L’absence d’inspection SSL sur ces mêmes adresses, en plus de .manage.microsoft.com, .dm.microsoft.com et has.spserv.microsoft.com.
• has.spserv.microsoft.com, qui doit rester joignable tant que des appareils Windows 10 sont évalués sur ces paramètres.
• Le test de connexion depuis un appareil Windows 11, dans une fenêtre PowerShell ouverte sous SYSTEM, avec le code de réponse et l’émetteur du certificat pour chaque adresse.
• Les stratégies d’accès conditionnel qui exigent Require device to be marked as compliant, et le délai de l’action Mark device noncompliant dans les stratégies de conformité concernées.

Les sources Microsoft

• Windows message center, entrée du 17 septembre 2026 : Intune: Windows Health Attestation Migration to Microsoft Azure Attestation
• Network endpoints for Microsoft Intune
• Device compliance settings for Windows in Intune
• HealthAttestation CSP
• Tenant status in Microsoft Intune
• Device compliance policies in Microsoft Intune
• Configure actions for noncompliant devices in Intune