Microsoft a enfin fait passer les Microsoft Entra passkeys on Windows en General Availability fin avril 2026. Concrètement, ça veut dire qu’on peut maintenant enregistrer des passkeys FIDO2 directement dans le conteneur Windows Hello et s’authentifier à Entra ID en passwordless. Cela fonctionne que le PC soit Entra-joined, registered, ou rien !
Personnel, partagé, BYOD, peu importe. Avec le rollout en cours jusqu’à mi-juin 2026, c’est le bon moment pour tester en lab avant que la migration auto vers les passkey profiles ne tombe sur votre tenant.
Dans cet article, on va voir comment configurer ça côté tenant (avec un focus sur la distinction entre l’ancienne UI Passkey (FIDO2) settings et la nouvelle expérience Passkey profiles), comment l’utilisateur enregistre sa passkey côté poste.
Au programme
- Un peu d’histoire …
- Entra passkey on Windows : c’est quoi exactement ?
- Pré-requis tenant, poste et utilisateur
- Ancienne UI : configuration via « Passkey (FIDO2) settings »
- Nouvelle UI : configuration via « Passkey profiles »
- Côté utilisateur : enregistrer sa première passkey Windows Hello
- Le piège du Enforce attestation
- Retex : les erreurs qu’on a croisées en lab
0. Un peu d’histoire …
Au début, l’authentification sur les environnements Microsoft reposait presque exclusivement sur le mot de passe. Un simple login + password suffisait pour accéder aux ressources d’entreprise, aussi bien on-premises que cloud.
Rapidement, les limites de ce modèle sont devenues évidentes :
- mots de passe faibles
- réutilisation entre services
- phishing
- fuites de credentials
- attaques par bruteforce
Pour renforcer la sécurité, le MFA est alors devenu la norme. La première vague de MFA a surtout reposé sur les SMS, les appels téléphoniques ou les codes OTP. Cela améliorait clairement la sécurité, mais avec plusieurs problèmes :
- fatigue utilisateur
- dépendance au réseau mobile
- vulnérabilités SIM swap
- expérience parfois lourde
Ensuite sont arrivées les applications d’authentification comme Microsoft Authenticator, avec les notifications push, le number matching ou les OTP locaux.
L’expérience devenait plus fluide, mais on restait encore dans un modèle “mot de passe + validation secondaire”. Puis Microsoft a commencé à pousser fortement le passwordless avec :
- Windows Hello for Business
- les clés FIDO2 comme YubiKey
Cette fois, l’objectif était clair : supprimer complètement le mot de passe. Le problème, c’est que ces solutions restaient souvent liées à un device d’entreprise, à un PC Entra joined, ou à une clé hardware dédiée.
Les environnements BYOD, postes partagés ou machines temporaires restaient donc compliqués à gérer proprement en passwordless. Puis sont arrivées les passkeys synchronisées sur mobile :
- iPhone via iCloud Keychain
- Android via Google Password Manager
- Microsoft Authenticator
Et c’est là qu’apparaît aujourd’hui “Entra passkey on Windows”. Le principe change beaucoup de choses : le PC Windows peut désormais héberger lui-même une passkey FIDO2 sans avoir à être joint au tenant.
1. Entra passkey on Windows : c’est quoi exactement ?
Pour rappel, jusqu’ici, si vous vouliez du passwordless FIDO2 sur Entra ID, il fallait soit une clé hardware type YubiKey, soit Windows Hello for Business (qui exige un device Entra-joined ou registered).
Les PC perso ou partagés étaient alors condamnés au mot de passe + MFA classique.
Avec Entra passkey on Windows, Microsoft permet désormais de créer une passkey FIDO2 directement dans le conteneur Windows Hello local, sans que le device soit joint au tenant. La passkey est device-bound (elle ne quitte jamais le poste), stockée dans le TPM, et débloquée par PIN, empreinte ou reconnaissance faciale.
Plusieurs passkeys peuvent cohabiter pour plusieurs comptes Entra sur le même PC.
Attention, le piège classique : ne confondez pas Entra passkey on Windows avec Windows Hello for Business.
Les deux utilisent Windows Hello, mais ce sont deux mécanismes distincts. Voici le tableau qui devrait vous éviter de mélanger les deux en réunion :
| Critère | Entra passkey on Windows | Windows Hello for Business |
|---|---|---|
| Standard | FIDO2 | Protocole 1P Microsoft (pas FIDO2) |
| Device join requis | Non | Oui (Entra-joined ou registered) |
| Sign-in OS Windows | Non | Oui |
| SSO Entra après login | Non | Oui |
| Provisionnement | User-initiated | Auto au device registration |
| Plusieurs comptes / device | Oui | Non (1 device = 1 compte) |
| Pilotage | Authentication Methods + passkey profiles | Intune / GPO |
En clair : sur un device managé Entra-joined, gardez Windows Hello for Business. Sur un poste non-joined, perso ou partagé, Entra passkey on Windows est ce qu’il vous faut.
2. Pré-requis tenant, poste et utilisateur
Avant de vous lancer dans la conf, vérifiez que vous cochez tout ça :
| Périmètre | Pré-requis |
|---|---|
| Tenant | Microsoft Entra ID (toute édition). Authentication Policy Admin ou Global Admin pour configurer. |
| Tenant | Méthode Passkey (FIDO2) activée dans Authentication methods. |
| Tenant | Conditional Access qui n’exige pas un device compliant ou Entra-joined sur le flux d’enregistrement. |
| Poste | Windows 11 24H2 minimum (build 26100+). Le provider passkey natif n’existe pas sur 23H2 ou Windows 10. |
| Poste | Edge ou Chrome à jour (≥ version 124). |
| Poste | TPM 2.0 opérationnel (tpm.msc doit afficher « prêt »). |
| Poste | Windows Hello configuré : PIN obligatoire, biométrie recommandée. |
| User | Une MFA réussie dans les 5 dernières minutes avant de cliquer « Add » sur la passkey. |
3. Ancienne UI : configuration via « Passkey (FIDO2) settings »
Si vous n’avez pas encore migré vers la nouvelle expérience, vous êtes encore sur la vue legacy Passkey (FIDO2) settings. Vous la reconnaissez à un bandeau bleu en haut : « Synced passkeys and passkey profiles are now available. Upgrade to the new experience » :
Tant que vous n’avez pas cliqué sur ce lien, vous restez sur l’ancien modèle, et il fonctionne très bien pour Entra passkey on Windows, à condition de bien renseigner manuellement les AAGUIDs :
| Authentificateur Windows Hello | AAGUID | Description |
|---|---|---|
| Authentificateur matériel Windows Hello | 08987058-cadc-4b81-b6e1-30de50dcbe96 | Clé privée stockée dans un module TPM basé sur le matériel. |
| Authentificateur matériel Windows Hello VBS | 9ddd1817-af5a-4672-a2b9-3e3dd95000a9 | La sécurité basée sur la virtualisation (VBS) utilise la virtualisation matérielle et l’hyperviseur Windows pour stocker des clés privées dans le module TPM de l’ordinateur hôte. |
| Authentificateur logiciel Windows Hello | 6028b017-b1d4-4c02-b4b3-afcdafc96bb2 | Clé privée stockée dans un module TPM basé sur logiciel. |
Étape 0 : Connectez-vous au Microsoft Entra admin center, allez dans Protection → Authentication methods → Policies → Passkey (FIDO2) :
Étape 1 : Onglet Enable and Target : activez la méthode et scopez les utilisateurs concernés (un groupe pilote pour démarrer, c’est plus sain).
Étape 2 : Onglet Configure, dans la section General :
- Allow self-service set up : Yes
- Enforce attestation : No (j’insiste, on en reparle plus bas)
Étape 3 : Section Key Restriction Policy :
- Enforce key restrictions : Yes
- Restrict specific keys : Allow
- Cliquez sur Add AAGUID et ajoutez les 3 AAGUIDs Windows Hello :
| AAGUID | Authenticator |
|---|---|
08987058-cadc-4b81-b6e1-30de50dcbe96 | Windows Hello Hardware Authenticator (TPM matériel) |
9ddd1817-af5a-4672-a2b9-3e3dd95000a9 | Windows Hello VBS Hardware Authenticator (VBS + TPM) |
6028b017-b1d4-4c02-b4b3-afcdafc96bb2 | Windows Hello Software Authenticator (TPM logiciel) |
Vous pouvez aussi ajouter les AAGUIDs Microsoft Authenticator si vous voulez autoriser les passkeys via l’app mobile :
90a3ccdf-635c-4729-a248-9b709135078f: Microsoft Authenticator Androidde1e552d-db1d-4423-a619-566b625cdc84: Microsoft Authenticator Apple
Étape 4 : Cliquez sur Save en bas. Et c’est tout pour l’ancienne UI.
4. Nouvelle UI : configuration via « Passkey profiles »
Microsoft a introduit en mars 2026 le modèle des passkey profiles, qui remplace progressivement l’ancienne config FIDO2. L’idée : pouvoir définir plusieurs profils (jusqu’à 3 par tenant) avec des règles différentes selon les groupes :
Par exemple un profil avec attestation enforced pour les admins (YubiKey obligatoire), et un autre sans pour les utilisateurs standards (Windows Hello autorisé).
L’auto-enablement de la nouvelle UI court d’avril à fin mai 2026 sur les tenants. Donc même si vous ne faites rien, Microsoft va finir par migrer votre tenant. Mon conseil : faites la bascule volontairement, comme ça vous maitrisez le moment et ce qui change.
Étape 0 : Toujours dans Authentication methods → Passkey (FIDO2), cliquez sur le lien « Upgrade to the new experience » dans le bandeau bleu.
Étape 1 : Microsoft migre votre conf existante dans un Default passkey profile. Vos AAGUIDs et restrictions actuels sont préservés. Le passkeyType du profil est déterminé par votre réglage d’attestation :
| Enforce attestation | Types autorisés par défaut |
|---|---|
| Enabled | Device-bound uniquement |
| Disabled | Device-bound + Synced (configurable) |
Étape 2 : Cliquez sur le Default passkey profile pour l’éditer. Le panneau latéral s’ouvre avec :
- Name : Default passkey profile (verrouillé, on ne peut pas le supprimer ni le renommer)
- Enforce attestation : décoché
- Passkey types : Device-bound, Synced (ajustez si besoin)
- Target specific AAGUIDs : à cocher si vous voulez forcer une allow-list explicite
Étape 3 : En théorie, depuis la GA de fin avril 2026, Microsoft a supprimé l’obligation d’allow-lister les AAGUIDs Windows Hello. Donc si votre tenant a bien reçu la bascule, vous n’avez rien d’autre à faire.
En pratique pendant le rollout (qui finit mi-juin 2026), le tenant peut ne pas encore avoir basculé. Si l’enregistrement échoue côté utilisateur sans raison apparente, cochez Target specific et ajoutez les 3 AAGUIDs Windows Hello. C’est le contournement que j’ai dû appliquer en lab en mai 2026 :
| Authentificateur Windows Hello | AAGUID | Description |
|---|---|---|
| Authentificateur matériel Windows Hello | 08987058-cadc-4b81-b6e1-30de50dcbe96 | Clé privée stockée dans un module TPM basé sur le matériel. |
| Authentificateur matériel Windows Hello VBS | 9ddd1817-af5a-4672-a2b9-3e3dd95000a9 | La sécurité basée sur la virtualisation (VBS) utilise la virtualisation matérielle et l’hyperviseur Windows pour stocker des clés privées dans le module TPM de l’ordinateur hôte. |
| Authentificateur logiciel Windows Hello | 6028b017-b1d4-4c02-b4b3-afcdafc96bb2 | Clé privée stockée dans un module TPM basé sur logiciel. |
Étape 4 : Save. Vous pouvez créer jusqu’à 3 profils différents et les assigner à des groupes différents via l’onglet Enable and target.
5. Côté utilisateur : enregistrer sa première passkey Windows Hello
Maintenant qu’on est bon côté tenant, voyons l’expérience utilisateur. Le poste doit être en Windows 11 24H2, avec PIN Hello configuré et Edge à jour. C’est important.
Étape 0 : L’utilisateur ouvre Edge en session normale, et fait une MFA fraîche sur My Sign-Ins | Security Info | Microsoft.com → Add sign-in method → choisissez Passkey dans la liste :
Étape 1 : Windows ouvre une fenêtre qui demande où enregistrer la passkey. Choisissez « This Windows device » (ou « Windows Hello » selon la version d’Edge).
Étape 2 : Le prompt Windows Hello apparaît. Authentifiez-vous avec visage, empreinte ou PIN Hello.
Étape 3 : Donnez un nom à la passkey (ex : « Laptop perso », « PC bureau »). Validez.
C’est bien enregistré sur votre compte :
Mais aussi sur votre poste :
Concrètement, ça donne quoi à la prochaine connexion ? L’utilisateur tape son email sur la page de login Microsoft, le navigateur propose la passkey du device, Windows Hello se déclenche (visage / PIN) et il est connecté. Plus de mot de passe, plus de SMS, plus de prompt MFA séparé. Le rêve.
6. Le piège du Enforce attestation
C’est LE piège qui m’a fait perdre du temps en lab et que vous allez forcément rencontrer si vous avez le réflexe sécu de tout durcir :
Le réglage Enforce attestation dans le profil passkey demande à l’authentificateur de fournir une preuve cryptographique signée par le constructeur, garantissant qu’il s’agit bien d’un device authentique (typiquement une YubiKey certifiée FIDO). Sur le papier, c’est une bonne pratique sécu.
Le problème : Windows Hello ne fournit pas encore d’attestation reconnue par Entra. Microsoft le dit explicitement dans la doc :
À noter : la doc MS Learn parle encore de public preview à la date de rédaction, mais la limite est confirmée post-GA :
Attestation isn’t supported for Microsoft Entra passkey on Windows during public preview. As a result, if Enforce attestation is enabled in a passkey profile that allows Windows Hello AAGUIDs, passkey registration attempts to Windows Hello will fail.
In the Authentication methods policy in the Microsoft Entra admin center, ensure that Enforce attestation is set to No for any passkey profile that includes Windows Hello AAGUIDs during public preview.
Enable Microsoft Entra passkey on Windows — Microsoft Learn
Concrètement, si vous cochez Enforce attestation = Yes sur un profil qui scope des utilisateurs sur Windows Hello, l’enregistrement échoue à la dernière étape (juste au moment où l’utilisateur nomme la passkey).
Côté serveur Entra, la requête est rejetée parce que la « preuve » attendue n’arrive pas :
La solution propre : deux profils séparés
- Profil « YubiKey / clés certifiées » : Enforce attestation = Yes, scopé aux admins / users à fort privilège. AAGUIDs des modèles YubiKey autorisés en allow-list.
- Profil « Windows Hello » : Enforce attestation = No, scopé aux utilisateurs standards. Allow-list avec les 3 AAGUIDs Windows Hello.
C’est exactement ce que la nouvelle UI passkey profiles permet de faire (jusqu’à 3 profils par tenant). Sur l’ancienne UI, vous étiez obligé de choisir un seul réglage tenant-wide, d’où l’intérêt de migrer si vous avez des cas d’usage mixtes.
Mon retour terrain : pour le moment, sur les Windows Hello passkeys, on accepte de se passer d’attestation. Le risque est limité parce que les credentials sont stockés dans le TPM et device-bound. Le jour où Microsoft livrera l’attestation Windows Hello, on rebascule. Pour les YubiKeys, l’attestation reste obligatoire.
7. Retex : les erreurs qu’on a croisées en lab
Pour finir, le vrai retour de tests, parce que la doc Microsoft ne couvre pas les cas où ça part en sucette. Voici les deux erreurs principales rencontrées en lab et comment les diagnostiquer.
Erreur 1 : « We’re sorry, we ran into a problem »
Message qui apparait juste à l’étape Name your security key, après que la clé ait été reconnue. Avec un Correlation ID dans les détails. Frustrant parce que tout semble fonctionner jusqu’à la dernière seconde.
Cause la plus fréquente : vous êtes sur le mauvais flux. Vous avez cliqué sur « Security key » au lieu de « Passkey » dans Add sign-in method. Le flux Security key n’utilise pas Windows Hello comme provider et tente de s’enregistrer comme une clé externe, d’où le crash final.
Erreur 2 : « Passkey not registered »
Message qui apparait sur le bon flux (Passkey, pas Security key), avec le texte « This might be due to a timeout, a canceled request or a private browsing window ». Le message officiel suggère timeout / cancel / private mode, mais en pratique la cause est ailleurs.
De mon côté, je n’ai eu aucun souci en navigation privée :
Cause #1 : Windows Hello pas configuré. Vérifiez Paramètres → Comptes → Options de connexion → Code PIN (Windows Hello). Sans PIN Hello, le provider n’a rien à appeler.
Cause #2 : rollout GA pas encore activé sur votre tenant. C’est la cause que j’ai rencontrée. Microsoft a annoncé que la GA enlève l’obligation d’allow-lister les AAGUIDs Windows Hello, mais cette bascule se déploie progressivement jusqu’à mi-juin 2026. Si votre tenant n’a pas encore reçu la modification, l’enregistrement échoue silencieusement.
Fix : dans le passkey profile, cochez Target specific AAGUIDs et ajoutez explicitement les 3 AAGUIDs Windows Hello. Save, retentez. Ça contourne le délai de rollout.
Cause #3 : Windows trop vieux. Sur 23H2 ou Windows 10, le picker n’affiche pas « This Windows device » dans la liste des providers. Vous voyez seulement « iPhone/Android » et « Security key ». Pas de chemin valide pour Windows Hello passkey.
Fix : passez en 24H2.
Cause #4 : Enforce attestation = Yes sur un profil scopant Windows Hello (cf. section précédente).
Fix : vérifiez que Enforce attestation est bien à No.
Conclusion
Entra passkey on Windows comble enfin un trou dans la stratégie passwordless de Microsoft : les PC non-managés peuvent désormais s’authentifier en FIDO2 sans avoir à sortir une YubiKey ni à passer par le téléphone. Pour les contractors, les postes partagés, les BYOD, c’est une vraie avancée.
Les pièges principaux à retenir :
- Windows 11 24H2 minimum côté poste, sinon vous restez bloqué sur l’ancien flux Security key
- Choisir « Passkey » et pas « Security key » dans Add sign-in method
- Ne pas cocher Enforce attestation sur le profil qui scope Windows Hello
- Pendant le rollout GA (avril → mi-juin 2026), allow-lister explicitement les 3 AAGUIDs Windows Hello si l’enregistrement échoue
- Migrer volontairement vers les passkey profiles avant l’auto-enablement de fin mai 2026
Foncez tester en lab avec un compte de test, validez le flux, puis pilotez le déploiement sur un groupe pilote avant d’ouvrir vanne large. Et surtout, anticipez la migration auto vers les passkey profiles qui tombe entre maintenant et fin mai — autant maitriser le moment plutôt que le subir.
Enfin, pour aller plus loin :
- Enable Microsoft Entra passkey on Windows — Microsoft Learn
- How to enable passkeys (FIDO2) — Microsoft Learn
- FIDO2 compatibility — Microsoft Learn
À tester d’urgence en lab !
