Passkeys à l'échelle de l'entreprise : leçons pratiques de déploiements réels

En 2023, le rapport Data Breach Investigations de Verizon révélait que 74 % des violations impliquaient un facteur humain — phishing, vol d'identifiants ou mauvais usage — pour un coût médian de 4,45 millions de dollars par incident. Les mots de passe sont la cause racine. Malgré des décennies d’obligation d’MFA, les codes SMS sont détournés par SIM-swap, les notifications push sont saturées par fatigue, et les seeds TOTP sont récoltées via des proxies adversary-in-the-middle comme Evilginx2. Les passkeys — basés sur la norme FIDO2 — sont le premier type d'identifiant architecturalement résistant au phishing. Mais les équipes IT d’entreprise qui passent trop vite sur les slides marketing des fournisseurs découvrent rapidement que le déploiement en production est une tout autre affaire.

Pourquoi les mots de passe — et la plupart des MFA — échouent toujours

Le problème n’est pas le comportement des utilisateurs, c’est le protocole. Les secrets partagés (mots de passe, OTP) doivent être transmis et vérifiés côté serveur, créant des surfaces d’interception à chaque étape. Les catégories MFA résistantes au phishing selon NIST SP 800-63B exigent des authentificateurs basés sur la possession, où la clé privée ne quitte jamais l’appareil et le domaine du relying party est cryptographiquement lié au défi. Seules les clés de sécurité matérielles (FIDO2/CTAP2) et les passkeys satisfont ce niveau. Pourtant, les clés matérielles ont stagné à l’échelle grand public à cause du coût et des frictions UX. Les passkeys résolvent le problème de distribution en se synchronisant via les trousseaux des plateformes.

Ce que sont réellement les passkeys (techniquement)

Un passkey est un identifiant FIDO2 stocké sous forme de paire de clés asymétriques. La clé privée réside dans un enclave sécurisé ou un authentificateur de plateforme — Apple Secure Enclave, Android Strongbox, Windows Hello TPM — et n’est jamais exportée. L’enregistrement génère un credential ID, une clé publique envoyée au serveur relying party, et éventuellement une chaîne de certificat d’attestation. L’authentification produit une assertion signée sur un défi serveur concaténé avec l’origin (scheme + host + port), rendant la signature invalide sur tout autre domaine. C’est la garantie anti-phishing.

La spécification WebAuthn Level 3 ajoute trois types de credentials pertinents pour l’entreprise :

Passkeys de plateforme (synchronisés) : stockés dans iCloud Keychain, Google Password Manager ou Windows Hello — synchronisés entre appareils via des coffres E2EE. Pratiques, mais le matériel de clé privée quitte les limites de l’appareil (chiffré).
Passkeys de plateforme (liés à l’appareil) : attachés à un TPM ou Secure Enclave unique d’un seul appareil. Haute assurance, mais résistent mal à une réinitialisation — le credential est simplement perdu.
Authentificateurs itinérants (CTAP2) : clés physiques comme YubiKey série 5 ou FEITIAN BioPass. Assurance maximale, pas de synchronisation, et goulot d’étranglement pour la distribution à grande échelle en entreprise.

CTAP2.1 a ajouté PIN/UV Auth Protocol 2, la gestion des credentials (lister/supprimer sur l’appareil) et le stockage de gros blobs. Les déploiements d’entreprise visant AAL3 (NIST) ou Authenticator Assurance Level 3 imposent généralement des authentificateurs liés à l’appareil ou itinérants.

Réalités des déploiements en entreprise

Gestion des appareils et vérification d’attestation

Les démos grand public de passkeys ignorent l’attestation ; les déploiements d’entreprise ne le peuvent pas. L’attestation permet au relying party de vérifier le modèle et le fabricant de l’authentificateur avant d’accepter un enregistrement. Microsoft Entra ID prend en charge l’application de politiques d’attestation — vous pouvez restreindre les enregistrements de passkeys aux YubiKey série 5 ou à certains appareils Android avec des clés matérielles. Okta FastPass lie de même l’attestation d’appareil à l’état de conformité MDM via sa fonctionnalité Device Trust ; un Mac non inscrit dans Jamf Pro échouera à l’enregistrement. Les points de terminaison de confiance de Duo imposent des barrières similaires via leur agent.

Le défi : les certificats d’attestation doivent être récupérés depuis le FIDO Metadata Service (MDS3), mis en cache et revalidés. Les entrées MDS3 ont une révocation — un modèle d’authentificateur compromis peut être mis sur liste noire, et votre code doit gérer cela élégamment sans bloquer les utilisateurs existants sur des credentials déjà enregistrés.

Synchronisation inter-plateformes et problème de fragmentation de l’écosystème

Apple, Google et Microsoft gèrent chacun des coffres de passkeys distincts. Un employé qui enregistre un passkey sur son iPhone (iCloud Keychain) ne peut pas l’utiliser sur son PC Windows 11 d’entreprise sans passer par un flux d’authentification inter-appareil — un scan de QR code via le transport hybride CTAP2, qui repose sur la proximité Bluetooth LE. Ceci est pris en charge dans Chrome 109+ et Safari 16+ sur toutes les plateformes, mais nécessite que le Bluetooth soit activé — ce que de nombreuses politiques de durcissement des endpoints d’entreprise désactivent.

Windows Hello for Business avec Entra ID en mode hybride fonctionne bien dans l’écosystème Microsoft. Mais un environnement mixte BYOD + entreprise avec macOS, iOS, Android et Windows crée jusqu’à quatre coffres de credentials distincts qui doivent être gérés, surveillés et pris en compte lors du départ d’un employé. Aucun d’eux ne se fédère nativement avec les autres. L’offre business de passkeys de 1Password — disponible depuis 1Password 8 — agit comme un gestionnaire de passkeys tiers qui fait le pont entre écosystèmes, mais introduit une nouvelle frontière de confiance et nécessite l’extension navigateur 1Password pour gérer les appels WebAuthn via l’API publicKeyCredential.isConditionalMediationAvailable().

Intégration et départ des employés

L’intégration est la partie la plus facile. La plupart des IdP prennent désormais en charge l’inscription amorcée de passkeys : Okta et Entra ID peuvent envoyer un lien d’inscription limité dans le temps qui permet à un nouvel employé d’enregistrer un passkey immédiatement après avoir vérifié son identité via un canal séparé (OTP par email ou vérification d’identité par le manager). La partie difficile, c’est le départ. Révoquer un passkey nécessite de révoquer le credential chez le relying party — une opération côté serveur immédiate — mais le credential peut encore exister dans iCloud Keychain ou Google Password Manager, et il pourra tenter une authentification qui sera désormais rejetée. Les employés qui partent en mauvais termes ne peuvent pas « emporter leurs passkeys » pour s’authentifier avec succès, mais les équipes IT doivent avoir des runbooks clairs pour ne pas confondre révocation du credential (faite) et suppression du credential du coffre de l’appareil personnel de l’utilisateur (hors de votre juridiction).

Replis conditionnels de l’interface utilisateur

Tous les navigateurs, appareils ou versions d’OS ne supportent pas les passkeys. Safari a ajouté le support des passkeys dans iOS 16 / macOS Ventura 13. Chrome a introduit une UI stable des passkeys dans la version 108. Firefox a ajouté le support des passkeys dans la version 122 — notablement tard. Les passkeys Windows Hello nécessitent au minimum Windows 10 22H2 ou Windows 11 21H2. Votre flux d’authentification doit implémenter la Conditional Mediation — en appelant navigator.credentials.get() avec mediation: "conditional" — pour afficher les passkeys en mode remplissage automatique sans bloquer les utilisateurs sur des navigateurs non supportés qui doivent alors retomber sur les mots de passe ou TOTP. Supprimer le repli trop tôt bloquera les utilisateurs d’appareils anciens et générera immédiatement des tickets au helpdesk.

Le paysage des fournisseurs

Microsoft Entra ID est aujourd’hui l’offre la plus complète pour les passkeys en entreprise. Le support des clés de sécurité FIDO2 (liées à l’appareil) est en disponibilité générale depuis 2021 ; les passkeys synchronisés pour Windows Hello ont été ajoutés en 2024. Le filtrage d’attestation, le number matching pour les push MFA et les politiques d’accès conditionnel peuvent restreindre l’enregistrement des passkeys aux seuls appareils conformes. Le point faible : les scénarios hybrides Azure AD Join sur des environnements Windows Server AD anciens présentent des aspérités, surtout avec des applications on-prem passant par AD FS plutôt que Entra.

Okta prend en charge FIDO2 WebAuthn comme facteur d’authentification dans Okta Verify FastPass. Ses intégrations Device Trust (Jamf, Microsoft Intune, VMware Workspace ONE) permettent d’attester que l’appareil est inscrit en MDM avant d’autoriser l’inscription. Le support des passkeys comme facteur principal sans mot de passe (remplaçant totalement les mots de passe, pas seulement comme MFA de renforcement) a atteint la GA fin 2024.

Duo Security (Cisco) a ajouté le support WebAuthn comme facteur Duo, mais son offre de passkeys pour des flux entièrement sans mot de passe est moins mature que celle d’Entra ou Okta. Duo excelle dans les environnements hétérogènes où toutes les applications ne supportent pas SAML/OIDC — ses plugins PAM Unix et Windows Credential Provider permettent une assurance équivalente aux passkeys pour les flux SSH et RDP.

1Password Business permet de stocker et d’utiliser des passkeys dans le coffre 1Password, avec des politiques de partage au niveau équipe et des journaux d’audit. Utile pour les comptes de service partagés, mais introduit un risque de dépendance vis-à-vis du fournisseur et nécessite d’évaluer si vos exigences AAL permettent un gestionnaire de passkeys logiciel.

Modes de défaillance courants en production

La politique d’attestation bloque le déploiement : Activer une attestation stricte avant d’auditer les modèles d’authentificateur de votre parc bloquera les employés utilisant des appareils Android anciens ou du matériel non certifié FIDO2. Commencez avec attestation: "indirect" et durcissez plus tard.
Bluetooth désactivé par politique tue l’authentification inter-appareils : Identifiez les flux d’authentification inter-appareils basés sur QR code qui reposent sur BLE et créez des exceptions ou orientez les utilisateurs vers des clés matérielles itinérantes.
iCloud Keychain se synchronise sur les appareils personnels : Les Mac inscrits en entreprise partagent iCloud Keychain avec les iPhones personnels des employés si le même identifiant Apple est utilisé. Les profils MDM ne peuvent pas isoler cela sans un Apple ID géré — planifiez votre inscription Apple Business Manager en conséquence.
L’incohérence du RP ID casse les applications tierces : Les applications enregistrées avec un relying party ID de app.company.com rejetteront les passkeys enregistrés sur company.com et vice versa. Auditez toutes vos configurations SP/RP ID avant le déploiement.
Absence de chemin de récupération de compte : Un appareil perdu avec un passkey lié à l’appareil et sans authentificateur de secours signifie une re-vérification d’identité assistée par le helpdesk depuis zéro. Définissez le SLA de récupération avant la mise en service.

Cadre de déploiement étape par étape

Le cadre suivant suppose Entra ID ou Okta comme IdP, un parc mixte Windows/macOS/iOS/Android, et un objectif d’élimination des mots de passe comme facteur principal en 18 mois.

Mois 1-2 — Audit : Inventoriez les modèles d’authentificateur de votre parc via MDM. Vérifiez les versions de navigateur. Cartographiez la méthode d’authentification de chaque application (SAML, OIDC, NTLM legacy). Identifiez les exigences AAL par niveau d’application.
Mois 2-3 — Conception des politiques : Définissez quels segments d’utilisateurs reçoivent des passkeys synchronisés vs. liés à l’appareil. Rédigez la politique d’attestation (commencez indirect). Définissez les runbooks de récupération de compte. Confirmez que les politiques d’accès conditionnel / MFA adaptative ne bloqueront pas l’inscription.
Mois 3-5 — Pilote : Déployez auprès du personnel IT et des premiers utilisateurs. Activez les passkeys comme facteur supplémentaire optionnel en plus des mots de passe. Instrumentez les taux de succès d’inscription, les tentatives d’authentification inter-appareils et les taux de repli dans les logs de votre IdP.
Mois 5-10 — Inscription large : Lancez des campagnes d’inscription avec des liens d’auto-inscription. Visez 80 % du personnel inscrit. Gardez les mots de passe actifs comme repli. Surveillez le volume de tickets helpdesk — la récupération de compte et les tickets de passkey perdu sont vos signaux.
Mois 10-18 — Élimination des mots de passe : Pour les utilisateurs inscrits, appliquez des politiques d’accès conditionnel exigeant le passkey (FIDO2) comme méthode d’authentification. Désactivez l’authentification par mot de passe pour les niveaux d’applications couverts. Maintenez un processus de secours (break-glass) avec des jetons matériels pour les comptes administrateur.

Ce qui manque encore dans l’écosystème

Les passkeys ne sont pas terminés. Plusieurs lacunes subsistent à mi-2025 :

Absence de norme native pour l’itinérance des passkeys en entreprise : Il n’existe pas de standard FIDO Alliance pour migrer les passkeys entre plateformes (par exemple, iCloud Keychain vers Google Password Manager). La dépendance vis-à-vis du fournisseur est réelle.
Support limité pour SSH/RDP/VPN : WebAuthn est une API de navigateur. Les agents SSH supportant les clés matérielles FIDO2 (via ssh-keygen -t ecdsa-sk) existent, mais les passkeys synchronisés ne peuvent pas être utilisés dans les flux SSH natifs sans une couche de pont.
Gestion immature de la révocation d’attestation : La plupart des implémentations IdP ne gèrent pas élégamment les événements de révocation MDS3 pour les credentials existants. Vous avez besoin d’une logique personnalisée ou d’un engagement du fournisseur.
Retard de Firefox : Le support des passkeys dans Firefox (v122+) présente encore des aspérités UX pour la conditional mediation et les flux inter-appareils, et sa part de marché dans les environnements d’entreprise — en particulier gouvernementaux et financiers — n’est pas négligeable.

L’adoption des passkeys en entreprise a dépassé le stade des early adopters — Microsoft, Google et Okta livrent tous des fonctionnalités en disponibilité générale. Les équipes qui réussissent sont celles qui traitent cela comme une migration d’infrastructure, pas une mise à jour d’application : auditer d’abord, pilote intensif, et garder les replis actifs plus longtemps que ce qui semble confortable. La résistance au phishing qui vous attend à la fin vaut le coût opérationnel.