Les passkeys devaient être la solution définitive au phishing. Standard FIDO2, cryptographie asymétrique, liaison au domaine : toute la panoplie technique pour rendre l'hameçonnage de credentials techniquement impossible. Sauf que depuis quelques semaines, des équipes offensives documentent des méthodes qui contournent ces protections — et les comptes Microsoft Cloud sont en ligne de mire. Voici ce qui se passe vraiment, et ce que ça change pour votre stratégie d'authentification.

Pourquoi les passkeys étaient censées être la solution ultime

Pour comprendre les nouvelles attaques, il faut d'abord comprendre pourquoi les passkeys ont été présentées comme une rupture technologique. Le problème fondamental du phishing classique est simple : l'utilisateur tape son mot de passe sur un faux site, et l'attaquant récupère ce secret réutilisable. Même les codes OTP — SMS, TOTP — peuvent être phishés en temps réel avec des outils comme Evilginx, qui interceptent et rejouent les cookies de session avant qu'ils n'expirent.

Les passkeys, basées sur le standard FIDO2/WebAuthn, résolvent ce problème à la racine via trois mécanismes complémentaires. Premièrement, le lien au domaine (origin binding) : la clé privée de l'utilisateur ne répond qu'aux challenges cryptographiques provenant du domaine exact pour lequel elle a été créée. Un faux site ne peut pas déclencher une authentification valide auprès d'une passkey créée pour login.microsoftonline.com. Deuxièmement, l'absence de secret transmissible : contrairement à un mot de passe, la passkey n'est jamais envoyée au serveur — seule une signature cryptographique du challenge est transmise, inutilisable en dehors de ce contexte précis. Troisièmement, la résistance aux attaques man-in-the-middle : même si un attaquant intercepte la communication, il ne peut pas réutiliser la signature capturée car elle est liée au challenge unique du serveur légitime.

Ces trois propriétés font que les passkeys résistent en théorie à toutes les formes connues de phishing de credentials. C'est pour cette raison que Microsoft a annoncé en août 2026 que les passkeys deviendraient la méthode d'authentification par défaut sur Entra ID, avec un objectif de suppression de l'authentification SMS pour 2027.

Ce que les attaquants font vraiment : le vol de session post-authentification

La nouvelle génération d'attaques documentée en septembre 2026 ne cherche pas à phisher la passkey elle-même — c'est techniquement infaisable. Elle cible ce qui vient après l'authentification : le token de session. Et là, le modèle de sécurité change complètement.

Concrètement, voici le mode opératoire observé dans les campagnes ciblant les comptes Microsoft Cloud. L'attaquant commence par envoyer un email de phishing avec un lien vers un site qui mime l'interface Microsoft 365. L'utilisateur visite le site, qui lui demande de s'authentifier. Si l'utilisateur utilise une passkey, l'authentification échoue sur le faux site — la passkey ne répond pas à un domaine non légitime. Là s'arrête la protection FIDO2.

Mais les attaquants ont intégré une étape supplémentaire. Au lieu de tenter de capturer la passkey, ils configurent le site malveillant comme un proxy transparent vers le vrai service Microsoft. L'utilisateur, voyant que son passkey "ne fonctionne pas" sur le faux site, est invité à utiliser une méthode alternative — lien magique par email, code SMS de secours, ou authentification sur un autre appareil. Si l'utilisateur bascule sur une de ces méthodes, l'attaquant capture le token de session résultant via son proxy.

C'est la première faille : la dégradation forcée de l'authentification. Les passkeys sont robustes, mais elles coexistent souvent avec des méthodes de fallback moins sécurisées. Et l'expérience utilisateur — "ma passkey ne marche pas, j'utilise le SMS" — est précisément le vecteur exploité.

La seconde technique, plus sophistiquée, cible directement les tokens Microsoft Entra. Lorsqu'un utilisateur s'authentifie via passkey sur un appareil légitime, Microsoft génère des Primary Refresh Tokens (PRT) et des Access Tokens d'une durée de vie d'une heure. Ces tokens, stockés dans le Key Management Service de Windows ou dans les navigateurs, peuvent être exfiltrés par un malware local. Le malware n'a pas besoin de la passkey — il vole le token après que l'authentification forte a réussi. C'est une attaque post-authentification, pas un bypass de FIDO2 à proprement parler, mais le résultat final est identique : l'attaquant accède au compte.

L'attaque Device Code Flow : la vulnérabilité structurelle d'OAuth

La troisième technique est probablement la plus impactante car elle cible une fonctionnalité légitime de Microsoft Entra. Le Device Code Flow est un mécanisme OAuth 2.0 conçu pour les appareils sans navigateur (TV connectées, imprimantes, CLI). Un attaquant peut initier ce flux depuis une machine qu'il contrôle, générer un code d'activation, et l'envoyer à la victime en lui demandant de saisir ce code sur une page de connexion Microsoft légitime.

Si la victime complète l'authentification — y compris avec sa passkey — sur le vrai site Microsoft, le token OAuth résultant est remis à l'application initiateur, c'est-à-dire à l'attaquant. L'utilisateur a utilisé son authentification forte, sur le vrai domaine Microsoft, mais le résultat bénéficie à l'attaquant. Les passkeys ne protègent pas contre ce scénario parce que l'authentification s'est bien passée sur le bon domaine — le problème est dans l'attribution du token qui en résulte.

Cette technique, connue depuis plusieurs années mais sous-exploitée, connaît un regain d'intérêt depuis que Microsoft pousse vers les passkeys. Paradoxalement, les utilisateurs qui ont adopté les passkeys sont parfois moins vigilants sur ce type d'attaque parce qu'ils se croient "immunisés" contre le phishing — une fausse confiance que les attaquants exploitent délibérément.

Ce que les chiffres disent : adoption réelle et exposition résiduelle

Les données publiées par Microsoft en septembre 2026 montrent que 43 % des utilisateurs de Microsoft 365 Entreprise ont configuré au moins une passkey sur leur compte. C'est un progrès considérable par rapport aux 8 % de fin 2024. Cependant, 89 % de ces mêmes utilisateurs ont toujours au moins une méthode d'authentification de fallback activée — code SMS, application d'authentification TOTP, ou email de récupération. Cette coexistence est le talon d'Achille de l'écosystème passkey actuel.

D'autre part, les incidents documentés en 2026 montrent que les vols de tokens post-authentification ont augmenté de 340 % par rapport à 2025, selon le Microsoft Digital Defense Report 2026 publié début septembre. Cette corrélation n'est pas fortuite : à mesure que les méthodes d'authentification initiale deviennent plus robustes, les attaquants se concentrent sur le vol de l'artefact de session plutôt que sur le bypass de l'authentification elle-même. Le périmètre de défense se déplace du moment de l'authentification vers la durée de vie des tokens et leur protection en mémoire.

Les durées de vie des tokens Entra constituent un autre facteur de risque. Les Access Tokens Microsoft ont une durée de vie d'une heure, mais les Refresh Tokens peuvent durer jusqu'à 90 jours, et les Primary Refresh Tokens associés aux appareils enregistrés peuvent durer 14 heures renouvelables. Un attaquant ayant exfiltré un Refresh Token valide peut maintenir un accès persistant bien au-delà de l'authentification initiale.

Mon avis d'expert

Les passkeys sont bien meilleures que les mots de passe — ce constat reste vrai. Mais présenter FIDO2 comme la solution définitive au phishing est une erreur de cadrage dangereuse qui crée de la complaisance. Le vrai problème n'est pas l'authentification : c'est la gestion du cycle de vie des tokens qui en résulte. Vous pouvez avoir l'authentification la plus robuste du monde — si les tokens persistent 90 jours et peuvent être exfiltrés par un malware, vous n'avez pas résolu le problème fondamental. La priorité pour les RSSI en 2026 n'est pas "déployer les passkeys" — c'est "réduire la durée de vie des tokens et détecter leur utilisation anormale". Ces deux problèmes sont orthogonaux. Confondre l'un avec l'autre est exactement ce que font les attaquants pour exploiter votre angle mort.

Ce que les RSSI doivent adapter dans leur stratégie IAM

Face à ces nouvelles réalités, plusieurs ajustements concrets s'imposent dans les stratégies Identity and Access Management des organisations utilisant Microsoft 365 et Entra ID.

Premier axe : éliminer les méthodes de fallback pour les comptes privilégiés. Si un administrateur a une passkey mais conserve le SMS comme méthode de secours, la passkey n'apporte qu'une protection marginale. Les comptes administrateurs doivent être configurés avec une authentification phishing-resistant exclusive — passkey ou certificat matériel (YubiKey, Windows Hello Entreprise) — sans aucun fallback SMS ou TOTP. Cette mesure radicale est souvent résistée pour des raisons de praticité, mais c'est précisément la compromise classique qui a permis la plupart des incidents documentés.

Deuxième axe : réduire les durées de vie des tokens Entra. Par défaut, Microsoft configure des durées de vie qui maximisent la fluidité de l'expérience utilisateur. Pour les environnements sensibles, les équipes sécurité doivent utiliser les Conditional Access Policies et les Token Lifetime Policies pour réduire la durée de vie des Access Tokens (idéalement 15-30 minutes) et des Refresh Tokens (24-48 heures maximum pour les accès sensibles). Cette mesure augmente la friction mais réduit considérablement la fenêtre d'exploitation en cas de vol de token.

Troisième axe : bloquer le Device Code Flow pour les utilisateurs standards. Le Device Code Flow est rarement légitime pour les utilisateurs non-techniques. Entra ID permet de bloquer ce flux via Conditional Access. Cette mesure supprime le vecteur d'attaque décrit plus haut sans impact fonctionnel pour la grande majorité des utilisateurs.

Quatrième axe : détecter l'utilisation anormale des tokens. Microsoft Sentinel et Defender for Identity permettent de configurer des règles de détection sur les anomalies de tokens — utilisations depuis des géolocalisations inhabituelles, changements d'user-agent entre l'acquisition et l'utilisation du token, ou usage depuis des plages IP non associées à l'appareil enregistré. Ces signaux sont présents dans les cas de vol de token et permettent une détection et une révocation rapides.

Cinquième axe : former les utilisateurs aux nouvelles techniques de social engineering. L'attaque Device Code Flow n'est pas détectable par une passkey — elle requiert une vigilance humaine. Les utilisateurs doivent savoir qu'ils ne doivent jamais saisir un code d'activation suite à une sollicitation non initiée par eux-mêmes. Cette formation spécifique, ciblée sur les nouvelles techniques plutôt que sur le phishing classique de credentials, est souvent absente des programmes de sensibilisation qui n'ont pas été mis à jour depuis 2023.

Conclusion

Les passkeys représentent une avancée réelle et significative dans la lutte contre le phishing de credentials. Elles doivent être déployées massivement — ce n'est pas en question. Mais 2026 nous rappelle une vérité ancienne de la sécurité : chaque amélioration d'un contrôle déplace l'attaquant vers le contrôle adjacent. Les passkeys neutralisent le phishing de credentials ; les attaquants se concentrent donc sur le vol de tokens post-authentification, la dégradation forcée vers des fallback moins sécurisés, et les flux OAuth mal configurés. La réponse n'est pas d'abandonner les passkeys — c'est de fermer aussi les angles morts qui les entourent. Et pour ça, l'analyse technique doit prendre le dessus sur le marketing de la "fin du mot de passe".

Besoin d'un regard expert sur votre stratégie IAM ?

Ayi NEDJIMI accompagne les organisations dans l'audit et la sécurisation de leurs infrastructures d'authentification Microsoft Entra et FIDO2.

Prendre contact