FIDO2 et passkeys en production : ce que personne ne vous dit avant de déployer

FIDO2 est la promesse d’un monde sans mot de passe : une authentification forte, résistante au phishing, basée sur de la cryptographie asymétrique et un geste biométrique. Sur le papier, c’est une évidence. En production, c’est une opération de chirurgie fine sur l’expérience utilisateur et l’infrastructure d’authentification.

Voici ce qu’on a appris sur plusieurs déploiements, dans des contextes où l’erreur n’est pas une option.

Ce que FIDO2 résout, et ce qu’il ne résout pas

Ce que FIDO2 résout bien :

• Phishing : les credentials sont liés à l’origine (domain), un faux site ne peut pas les capturer
• Rejeu : chaque authentification produit une signature unique, non réutilisable
• Friction : un geste biométrique ou un PIN local, sans frappe de mot de passe

Ce que FIDO2 ne résout pas seul :

• La compromission de l’appareil lui-même (si l’appareil est compromis, l’authenticator l’est aussi)
• L’enrôlement initial : il faut bien bootstrapper la confiance une première fois
• La gestion de la perte ou du changement d’appareil, c’est le vrai point dur

L’enrôlement : la phase critique

L’enrôlement est le moment où l’utilisateur enregistre son authenticator (clé de sécurité physique, biométrie de l’appareil, ou passkey syncronisée). C’est là que tout se joue.

Stratégie progressive ou big bang ?

Le déploiement big bang, bascule de tous les utilisateurs en une nuit, fonctionne pour des populations technophiles et maîtrisées. Pour des populations hétérogènes (partenaires externes, utilisateurs peu technophiles, appareils d’entreprise gérés), c’est une recette pour un taux d’échec élevé et un pic de tickets support.

La stratégie progressive que nous recommandons :

1. Pilote sur 5-10% des utilisateurs, choisis parmi les early adopters volontaires
2. Extension aux équipes IT et sécurité, ils seront vos premiers support N1
3. Déploiement par cohortes, par département, avec communication et formation préalable
4. Fermeture des autres méthodes, seulement quand la couverture est > 95%

Le flow d’enrôlement doit être irréprochable

L’utilisateur qui rate l’enrôlement est perdu. Le taux d’abandon sur les flows d’enrôlement FIDO2 mal conçus peut dépasser 30%. Les points de friction les plus fréquents :

• Explication insuffisante : l’utilisateur ne comprend pas ce qu’il est en train de faire
• Timeout trop court : WebAuthn a des timeouts par défaut qui peuvent être trop courts pour des utilisateurs moins agiles
• Gestion des erreurs opaque : un NotAllowedError ne dit rien à un utilisateur non technique
• Absence de fallback clair : que fait l’utilisateur si ça ne marche pas ?

La coexistence avec l’existant

Sauf cas exceptionnel, vous ne pouvez pas éteindre votre MFA existant du jour au lendemain. FIDO2 va coexister avec TOTP, SMS OTP, et parfois des clés matérielles de première génération (U2F).

Gérer plusieurs méthodes par utilisateur

La recommandation technique est de traiter les méthodes d’authentification comme une liste ordonnée par préférence, avec un mécanisme de fallback explicite. L’utilisateur doit pouvoir :

• Choisir sa méthode préférée
• Basculer sur une méthode de secours si l’authenticator n’est pas disponible
• Voir et gérer ses méthodes enregistrées depuis son profil

Côté implémentation, le stockage des credentials FIDO2 (credentialId, clé publique, signCount, aaguid) doit être dissocié du stockage des autres facteurs. Cela facilite la migration future.

Le risque de la régression de sécurité

Le piège classique : FIDO2 est déployé, mais le mot de passe + SMS reste disponible comme fallback. Un attaquant qui veut contourner FIDO2 n’a qu’à cibler le fallback. La posture cible est que les méthodes de fallback aient elles aussi un niveau d’assurance acceptable : pas de SMS seul, pas de questions secrètes.

La gestion des appareils perdus ou volés

C’est le scénario que les équipes underestiment le plus. Un utilisateur perd son téléphone un vendredi soir. Il doit accéder à son environnement de travail lundi matin. Que se passe-t-il ?

Sans procédure de récupération robuste, la réponse est : rien, il est bloqué. Avec une procédure mal conçue, la réponse est : un vecteur d’attaque via social engineering.

Les options de récupération

Codes de récupération à usage unique : générés à l’enrôlement, stockés offline par l’utilisateur. Simple mais suppose que l’utilisateur les a bien conservés.

Authenticator de secours : l’utilisateur enregistre deux authenticators (ex : son téléphone + une clé physique). La recommandation pour les accès critiques.

Procédure d’identité en présentiel : pour les accès les plus sensibles, la récupération passe par une vérification d’identité physique. Lourde, mais c’est parfois la seule option acceptable.

Re-vérification d’identité en ligne : via un parcours e-KYC, l’utilisateur re-prouve son identité avant de pouvoir enregistrer un nouvel authenticator. C’est la convergence naturelle avec les services de confiance numérique.

La révocation doit être immédiate

Quand un appareil est signalé perdu ou volé, la révocation du credential FIDO2 associé doit être instantanée. Cela implique :

• Un mécanisme de révocation côté serveur sur le credentialId
• Une interface utilisateur accessible même sans authenticator (via la procédure de récupération)
• Des logs d’audit de toutes les révocations

Couverture des terminaux : la réalité

FIDO2 via WebAuthn requiert :

• Un navigateur compatible (Chrome 67+, Firefox 60+, Safari 14+, Edge 18+), couverture > 95% aujourd’hui
• Un authenticator : Touch ID, Windows Hello, Android Biometrics, ou clé physique

Le cas problématique : les appareils d’entreprise gérés, anciens ou avec des politiques de sécurité restrictives. Sur des parcs avec des postes Windows 7 (encore présents dans certains secteurs), des navigateurs verrouillés sur des versions anciennes, ou des configurations qui désactivent les API WebAuthn, la couverture réelle peut être significativement inférieure à 95%.

Protocole de vérification de couverture avant déploiement :

1. Inventaire des OS et navigateurs via le MDM ou les logs serveur
2. Test d’une page de détection WebAuthn sur l’ensemble du parc
3. Identification des cas hors couverture → décision : mise à jour, clé physique, ou exemption

Passkeys synchronisées : avantage ou risque ?

Les passkeys synchronisées (via iCloud Keychain, Google Password Manager) permettent de retrouver ses credentials sur un nouvel appareil du même écosystème. C’est un gain de récupération majeur. C’est aussi un transfert de confiance vers Apple ou Google.

Pour des contextes grand public ou B2B standard, c’est un excellent compromis. Pour des contextes à haute sensibilité (accès à des données de santé, financières, secret des affaires), la politique peut imposer des authenticators locaux non synchronisés (clés physiques FIDO2 certifiées).

Conclusion

FIDO2 tient ses promesses, mais le déploiement réussi n’est pas une affaire de configuration technique. C’est une opération qui touche l’UX, la gestion des identités, les procédures de support et la politique de sécurité. Les projets qui échouent ne ratent pas sur la cryptographie. Ils ratent sur l’enrôlement, la récupération et la coexistence.

Un déploiement bien préparé, avec une stratégie progressive et des procédures de récupération testées, produit un résultat durable. Un déploiement précipité produit du shadow IT : les utilisateurs bloqués trouvent des contournements.

Vous concevez ou revoyez votre architecture d’authentification ? Échangeons sur votre contexte.