Windows Hello for Business Facteur MFA Autonome Entra Octobre 2026 : la deuxième exigence de clé d'accès disparaît

Windows Hello for Business Facteur MFA Autonome Entra Octobre 2026 : ce que Microsoft a annoncé

Windows Hello for Business facteur MFA autonome Entra octobre 2026 est le changement que les équipes identité devraient déjà anticiper. Dans le billet Message Center MC1450134, « Microsoft Entra : Windows Hello for Business et macOS Platform SSO comme facteurs MFA autonomes » (publié le 7 août 2026, mis à jour le 18 août 2026), Microsoft indique qu'Entra va « reconnaître Windows Hello for Business (WHfB) et macOS Platform Single Sign-On (PSSO) comme facteurs d'authentification multifacteur (MFA) autonomes dans les scénarios d'authentification pris en charge ».

La fenêtre de déploiement est précise. La disponibilité générale (General Availability) pour les tenants Worldwide et GCC démarre « début octobre 2026 et devrait se terminer fin novembre 2026 ». Microsoft étiquette le billet planForChange avec une sévérité normale et précise clairement qu'« aucune modification de configuration n'est requise ».

Cette dernière phrase mérite qu'on s'y attarde. Aucune action admin n'est requise, mais la posture d'authentification de chaque tenant où les utilisateurs se connectent avec Windows Hello ou un Mac change d'elle-même — y compris le nombre de comptes qu'Entra signale comme MFA-capable, et les appareils depuis lesquels un utilisateur peut encore s'authentifier quand quelque chose tourne mal.

Ce qui change réellement, et ce qui fonctionnait déjà

Windows Hello for Business n'est pas ajouté aux niveaux de robustesse d'authentification (authentication strengths) — il y figurait déjà. La référence Microsoft sur les niveaux de robustesse d'authentification liste « Windows Hello for Business ou identifiant de plateforme » comme satisfaisant les trois niveaux intégrés : MFA strength, Passwordless MFA strength et Phishing-resistant MFA strength.

Ce qui ne fonctionnait pas de façon fiable, c'est le parcours de ré-authentification. La même page documente la limitation actuelle avec les mots de Microsoft :

C'est l'écart que MC1450134 comble. Selon le billet Message Center, voici les comportements après déploiement :

Deux de ces lignes méritent d'être soulignées. La ligne MFA-capable signifie que votre chiffre de conformité bouge sans qu'un seul utilisateur n'enregistre quoi que ce soit de nouveau — si vous rapportez un « pourcentage d'utilisateurs MFA-capable » à un auditeur ou à un conseil d'administration, re-baselinez-le avant et après le déploiement pour pouvoir expliquer le saut. La ligne incitation à l'enregistrement signifie que le filet de sécurité qui rattrapait auparavant les utilisateurs à méthode unique disparaît silencieusement.

Microsoft documente aussi un problème connu sur cette même page des niveaux de robustesse d'authentification, qu'il vaut la peine de relire sous cet angle : quand une ressource exige à la fois un niveau de robustesse d'authentification et une fréquence de connexion, les utilisateurs « peuvent satisfaire les deux exigences à deux moments différents », et l'exemple donné par Microsoft est celui d'un utilisateur déverrouillant son appareil Windows avec Windows Hello for Business pour satisfaire une fréquence de connexion d'une heure, pendant qu'une connexion par clé d'accès vieille de 24 heures satisfait le niveau de robustesse.

Le piège : les identifiants liés à l'appareil ne voyagent pas

Microsoft signale lui-même le risque, dans la section « Action requise et recommandations » de MC1450134 : « Comme les identifiants WHfB et macOS PSSO sont liés à l'appareil (device-bound), les utilisateurs peuvent ne pas être en mesure de compléter les défis MFA depuis des appareils où ces identifiants ne sont pas disponibles. »

Ce n'est pas une précaution de langage. C'est la propriété qui définit les deux identifiants :

• Windows Hello for Business est décrit par Microsoft comme « principalement une méthode de connexion liée à l'appareil, rattachée à la confiance de l'appareil (device trust) », l'identifiant étant « lié uniquement au compte professionnel ou scolaire utilisé pour enregistrer l'appareil ». Son type de clé d'accès est listé comme lié à l'appareil (device-bound), et non synchronisé (clé d'accès Microsoft Entra sous Windows).
• Platform Credential pour macOS « provisionne une clé cryptographique liée au matériel, sauvegardée par l'enclave sécurisée », construite sur la technologie Windows Hello for Business (Platform Credential pour macOS).

La documentation de Microsoft sur la campagne d'enregistrement montre déjà à quel point ce lien est étroit en pratique. L'incitation à enregistrer une clé d'accès est évaluée par combinaison appareil-et-navigateur, et le tableau des plateformes publié montre qu'un identifiant Windows Hello for Business supprime l'incitation uniquement sous Windows, tandis qu'un identifiant Mac Platform SSO la supprime uniquement sous macOS. L'exemple donné par Microsoft lui-même : « si un utilisateur a un identifiant Windows Hello for Business et se connecte sous Windows avec Chrome, l'incitation est supprimée. Mais si le même utilisateur se connecte sur un Mac avec Chrome, il est incité car cet identifiant ne s'applique pas à cette plateforme. » La même page précise que les utilisateurs Linux ne sont jamais incités, car les clés d'accès FIDO2 ne sont pas disponibles sous Linux.

En assemblant les pièces, l'exposition devient concrète. Après octobre, un utilisateur dont le seul identifiant MFA enregistré est un identifiant Windows Hello for Business compte comme MFA-capable, cesse d'être incité à ajouter quoi que ce soit de portable, et reste incapable de compléter un défi MFA depuis un téléphone personnel, un ordinateur portable de prêt, un Mac ou un poste Linux. Portable cassé, appareil réimagé, jour de déplacement, réponse à incident depuis la machine de quelqu'un d'autre — tout cela devient un appel au support plutôt qu'une invite de second facteur. Ce risque frappe le plus durement les comptes que vous pouvez le moins vous permettre de bloquer, c'est pourquoi les comptes d'accès d'urgence ne devraient jamais dépendre d'un identifiant lié à une seule machine.

Cela s'ajoute au retrait du MFA SMS et voix et au changement d'enregistrement MFA sans mot de passe : les solutions de repli portables sur lesquelles beaucoup de tenants s'appuient encore sont retirées au même moment où le système cesse de demander aux utilisateurs d'en enregistrer une de remplacement.

Détection : identifiez vos utilisateurs uniquement liés à l'appareil avant octobre

Tous les utilisateurs enregistrés pour une méthode sans mot de passe — FIDO2, Windows Hello for Business, ou connexion sans mot de passe par téléphone. C'est le cercle extérieur, pas la réponse :

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=isPasswordlessCapable eq true

Tous les utilisateurs détenant une clé d'accès FIDO2 liée à l'appareil. Notez ce que cette requête ne retourne pas : passKeyDeviceBound est la méthode de clé d'accès liée à l'appareil, pas Windows Hello for Business ou macOS PSSO, donc à elle seule elle ne trouvera pas les utilisateurs uniquement WHfB visés par cette section :

GET https://graph.microsoft.com/v1.0/reports/authenticationMethods/userRegistrationDetails?$filter=methodsRegistered/any(x:x eq 'passKeyDeviceBound')

Microsoft documente methodsRegistered comme filtrable avec any/eq mais ne publie pas l'ensemble complet des valeurs qu'il peut contenir, donc ne devinez pas une chaîne de méthode dans $filter. Récupérez methodsRegistered pour chaque utilisateur et filtrez localement — ce que fait l'export ci-dessous — ou lisez la colonne Methods registered dans le portail, où Windows Hello for Business est listé nommément.

Import-Module Microsoft.Graph.Reports

# Établir la référence des méthodes enregistrées de chaque utilisateur avant le déploiement.
# Nécessite AuditLog.Read.All (Reports Reader, Security Reader, Security Administrator ou Global Reader).
Get-MgReportAuthenticationMethodUserRegistrationDetail |
  Select-Object UserPrincipalName, IsAdmin, IsMfaCapable, IsPasswordlessCapable,
    @{Name = "Methods"; Expression = { $_.MethodsRegistered -join ";" }} |
  Export-Csv .\entra-mfa-baseline-pre-october-2026.csv -NoTypeInformation

Remédiation (Remediation) : que faire avant le début du déploiement

1. Rendez obligatoire une méthode portable dès l'onboarding. C'est la propre première recommandation de Microsoft dans MC1450134 : « Mettre à jour les consignes d'onboarding pour garantir que les utilisateurs enregistrent au moins une méthode MFA portable. » Un identifiant lié à l'appareil et rien d'autre est un point de défaillance unique par utilisateur.
2. Choisissez délibérément la méthode portable. Microsoft suggère « une clé d'accès synchronisée ou une clé d'accès Microsoft Authenticator en plus de WHfB ou macOS PSSO ». Notez l'arbitrage documenté par Microsoft : « Les clés d'accès synchronisées ne prennent pas en charge l'attestation », donc un profil avec Enforce attestation réglé sur Yes les exclut à l'enregistrement — l'exemple documenté par Microsoft lui-même pour les comptes à privilèges élevés associe l'attestation obligatoire à un mode uniquement lié à l'appareil (activer les clés d'accès (FIDO2)). Décidez laquelle de ces deux propriétés vous est réellement nécessaire avant de publier vos consignes.
3. Auditez les niveaux de robustesse d'authentification personnalisés. MC1450134 vous demande de « revoir les politiques Authentication Strength personnalisées pour confirmer que WHfB et macOS PSSO sont autorisés là où c'est pertinent ». Les trois niveaux intégrés incluent déjà « Windows Hello for Business ou identifiant de plateforme » ; ce sont les niveaux personnalisés que vous avez écrits vous-même qui peuvent désormais se comporter différemment de ce que vous pensiez.
4. Vérifiez les listes d'autorisation AAGUID de votre profil de clé d'accès avant de demander aux utilisateurs de s'enregistrer. Si vous utilisez des restrictions de clé, Microsoft documente que l'AAGUID du Platform Credential macOS 7FD635B3-2EF9-4542-8D9D-164F2C771EFC doit figurer dans la liste autorisée pour les défis WebAuthn. Pour les clés d'accès Windows Hello, les AAGUID documentés sont 08987058-cadc-4b81-b6e1-30de50dcbe96 (TPM matériel), 9ddd1817-af5a-4672-a2b9-3e3dd95000a9 (VBS matériel) et 6028b017-b1d4-4c02-b4b3-afcdafc96bb2 (TPM logiciel) — et Microsoft précise qu'un profil les ciblant ne peut pas imposer l'attestation.
5. Corrigez d'abord les comptes break-glass. Les comptes d'accès d'urgence doivent être joignables depuis un appareil qui n'est pas celui qui est tombé en panne. Confirmez qu'ils détiennent un identifiant portable et restent exclus des politiques qui les bloqueraient sinon.
6. Re-baselinez la métrique MFA-capable et prévenez qui l'exploite. Le chiffre va bouger parce que la définition a bougé, pas parce que la couverture s'est améliorée. Comparez votre CSV pré-déploiement à celui post-déploiement plutôt que de rapporter le nouveau chiffre comme un progrès.
7. Testez en mode rapport seul (report-only). Les changements de politique Conditional Access que vous faites en réponse à ceci doivent être validés contre du trafic réel avant application, la même discipline qui détecte les lacunes de couverture des politiques de base que la plupart des tenants traînent.
8. Mettez à jour la documentation du support. La dernière recommandation de MC1450134 est explicite : les utilisateurs n'ayant que WHfB ou macOS PSSO « ne seront plus automatiquement guidés pour enregistrer une méthode MFA supplémentaire », donc la consigne doit venir de vous. Une revue plus large de la place de ce sujet dans l'hygiène du tenant est couverte dans notre guide d'audit Microsoft Entra ID.

Comment EtcSec détecte cela

Les contrôles Conditional Access et accès à privilèges d'EtcSec ciblent les conditions qui transforment ce déploiement d'un non-événement en blocage d'accès. CA_NO_MFA_REQUIREMENT signale les tenants sans politique exigeant réellement le MFA, là où un chiffre MFA-capable mouvant crée une fausse confiance. CA_NO_BREAK_GLASS_EXCLUSION détecte les comptes d'accès d'urgence sans motif d'exclusion documenté — les comptes les plus susceptibles d'être bloqués par un identifiant uniquement lié à l'appareil. PA_GLOBAL_ADMIN_NOT_MFA fait remonter les comptes à privilèges dont l'application du MFA ne tient pas la route. CA_NO_SESSION_CONTROLS trouve les tenants qui s'appuient sur une fréquence de connexion que WHfB et macOS PSSO vont désormais satisfaire pendant le 2FA, et CA_POLICY_REPORT_ONLY détecte les politiques que vous avez testées pour ce changement mais jamais réellement appliquées.