Passkeys dans Entra ID : une révolution annoncée, des questions en suspens
L’annonce par Microsoft de l’activation automatique des profils de passkeys et de la synchronisation des passkeys dans Entra ID (anciennement Azure Active Directory) à partir de mars 2026 est, à première vue, une initiative louable. Elle vise à simplifier l’adoption de cette technologie sans mot de passe, souvent perçue comme le Graal de l’authentification sécurisée. Nous vous en parlions lors du dernier Briefing avec un sujet dédié pour cela. Cependant, cette automatisation soulève un certain nombre de questions techniques et stratégiques qui méritent une analyse plus fine, au-delà de la rhétorique du « sans mot de passe pour tous ».
L’idée de pousser les passkeys par défaut est séduisante. Elle promet de réduire la surface d’attaque des identités en éliminant les vulnérabilités inhérentes aux mots de passe (phishing, réutilisation, faiblesse). La synchronisation des passkeys, notamment via le profil d’authentification Microsoft, vise à améliorer l’expérience utilisateur en rendant ces identifiants disponibles sur différents appareils, un point crucial pour l’adoption massive. Jusqu’à présent, la gestion des passkeys restait souvent un exercice manuel, nécessitant une intervention de l’utilisateur ou une configuration spécifique. L’automatisation proposée par Microsoft, en créant ces profils pour les utilisateurs n’ayant pas encore configuré de passkey, est une tentative évidente de forcer la main à l’adoption.
Mais cette simplification a son revers. D’un point de vue technique, l’intégration des passkeys dans l’écosystème Entra ID, et plus particulièrement la synchronisation, repose sur des mécanismes cryptographiques complexes. Les passkeys sont basés sur les standards FIDO2/WebAuthn, utilisant la cryptographie asymétrique pour générer une paire de clés : une clé publique stockée sur le service (Entra ID dans ce cas) et une clé privée conservée sur l’appareil de l’utilisateur. La synchronisation de cette clé privée, même si elle est chiffrée de bout en bout, introduit un point de confiance potentiellement unique. Le modèle de sécurité des passkeys, initialement conçu pour lier une clé privée à un appareil physique (et non à un compte cloud), voit ici ses fondements légèrement altérés par la commodité.
La question de la résilience et de la récupération est également centrale. Que se passe-t-il si un utilisateur perd tous les appareils sur lesquels ses passkeys synchronisés sont stockés ? Bien que Microsoft mentionne des mécanismes de récupération (potentiellement via des méthodes d’authentification alternatives ou des clés de récupération), la gestion de ces scénarios dans un environnement à grande échelle peut devenir un véritable casse-tête opérationnel. La promesse du « sans mot de passe » ne doit pas occulter la nécessité de planifier des scénarios de secours robustes, qui ne réintroduisent pas, par une autre porte, des vulnérabilités similaires à celles que l’on cherche à éliminer.
En outre, l’activation automatique soulève des questions de gouvernance et de contrôle. Si Entra ID active par défaut ces profils, les administrateurs IT devront s’assurer qu’ils comprennent parfaitement les implications de cette configuration pour leurs politiques de sécurité existantes. Il est essentiel que cette transition ne se fasse pas dans l’ignorance des risques potentiels liés à une adoption mal maîtrisée. L’enthousiasme pour la sécurité accrue ne doit pas nous faire oublier l’importance de la gestion du cycle de vie des identités et des accès, qui doit rester sous le contrôle strict de l’organisation.