Passkey vs. Security Key : différences et comment choisir

Passkey vs security key : comparez les types d’identifiants FIDO2 selon le niveau d’assurance, l’attestation, la récupération et les modèles de déploiement en entreprise. Découvrez lequel convient à votre environnement.

Qu'est-ce que les passkeys et les clés de sécurité ?

En 2021, Colonial Pipeline a retracé un incident de ransomware jusqu'à un mot de passe VPN compromis, et l'entreprise a payé environ 4,4 millions de dollars de rançon, selon un communiqué du DOJ. C'est la réalité opérationnelle de l'accès initial basé sur les identifiants : les attaquants n'ont pas besoin de failles zero-day lorsqu'ils peuvent pratiquer le phishing, la réutilisation ou le credential stuffing contre une authentification basée sur les mots de passe.

Les passkeys et les clés de sécurité physiques existent toutes deux pour combler cette lacune. Elles reposent sur la même base cryptographique, mais la différence dans la manière dont elles stockent et gèrent les identifiants est importante lorsqu'il s'agit de protéger une entreprise.

Une passkey est un identifiant d'authentification FIDO qui remplace les mots de passe par des paires de clés cryptographiques. Selon la FIDO Alliance, les passkeys permettent aux utilisateurs de se connecter à des applications et des sites web en utilisant le même processus que pour déverrouiller leur appareil : biométrie, code PIN ou schéma. Les passkeys existent sous deux formes :

• Passkeys synchronisées : stockent les identifiants dans un gestionnaire d'identifiants sauvegardé dans le cloud et les synchronisent sur vos appareils.
• Passkeys liées à l'appareil : verrouillent la clé privée sur un seul appareil. Elle ne quitte jamais ce matériel.

En pratique, le modèle de stockage est ce qui détermine la plupart des compromis en entreprise.

Une clé de sécurité matérielle (également appelée authentificateur itinérant) est un dispositif matériel externe qui communique avec les navigateurs et les systèmes d'exploitation via USB, NFC ou Bluetooth en utilisant le protocole FIDO2 CTAP (Client-to-Authenticator Protocol). Pensez aux YubiKeys, cartes à puce et jetons similaires. Par définition, elles sont liées à l'appareil : la clé privée est stockée dans un module de sécurité matériel et ne peut pas être exportée ou copiée.

Les deux technologies partagent la même base cryptographique. Chaque identifiant est unique, lié à un domaine de service spécifique, et repose sur la cryptographie à clé publique standard. Les données biométriques ne quittent jamais votre appareil. Le serveur ne stocke que la clé publique. Cette conception commune rend les deux options pertinentes pour le même problème de sécurité fondamental.

Comment les passkeys et les clés de sécurité s'intègrent à la cybersécurité

Le DBIR Verizon 2025 rapporte que l'abus d'identifiants représente une part importante des accès initiaux : 22 % des violations impliquent l'abus d'identifiants comme méthode d'accès initial, selon le DBIR Verizon. Cela correspond à ce que l'on observe sur le terrain : une fois qu'un attaquant dispose d'identifiants valides, vous luttez contre vos propres chemins d'accès.

Les passkeys et les clés de sécurité sont toutes deux conçues pour résister au phishing. Comme le définit la spécification WebAuthn, chaque assertion d'authentification est limitée à un domaine de site web spécifique, de sorte qu'un site de phishing sur un autre domaine ne peut pas obtenir une assertion valide. Cela bloque le phishing d'identifiants, le credential stuffing et les attaques de type adversary-in-the-middle au niveau du protocole, ce qui explique pourquoi les agences et les secteurs réglementés s'orientent vers une MFA résistante au phishing.

C'est pourquoi l'OMB M-22-09 impose désormais aux agences fédérales d'utiliser uniquement une authentification résistante au phishing. La question pour votre organisation n'est pas de savoir s'il faut adopter l'authentification FIDO2, mais quel modèle d'implémentation correspond à votre profil de risque. Le tableau ci-dessous présente les principales différences côte à côte.

Passkey vs. clé de sécurité : comparaison rapide

Fonctionnalité	Passkey (synchronisée)	Clé de sécurité physique
Stockage des identifiants	Gestionnaire d'identifiants cloud (Apple Keychain, Google Password Manager)	Module de sécurité matériel sur le jeton physique
Exportabilité de la clé	Synchronisée entre appareils via le cloud	Non exportable ; verrouillée sur le matériel
Niveau d'assurance NIST	AAL2	AAL3
Résistance au phishing	Oui (liaison de domaine FIDO2)	Oui (liaison de domaine FIDO2)
Attestation de l'appareil	Non prise en charge (la synchronisation cloud rompt la chaîne de confiance)	Prise en charge (certificat fabricant intégré au matériel)
Modèle de récupération	Récupération du compte cloud via le fournisseur	Clé de secours physique ou réinscription via un administrateur
Expérience utilisateur	Transparente, fonctionne sur les appareils synchronisés	Nécessite le jeton physique à chaque connexion
Coût matériel	Aucun (basé sur logiciel)	Achat de jeton par utilisateur et gestion du cycle de vie
Compatibilité multiplateforme	Dépend de l'écosystème du fournisseur	Universelle (USB, NFC, BLE sur toute plateforme FIDO2)
Cas d'usage optimal	Collaborateurs, environnements BYOD	Administrateurs privilégiés, secteurs réglementés, conformité AAL3

La pile de protocoles, le modèle de stockage et la prise en charge de l'attestation pour chaque option déterminent votre niveau d'assurance. Voici comment ces composants se répartissent.

Comment fonctionne l'authentification FIDO2 en profondeur

Les passkeys et les clés de sécurité reposent sur la même pile de protocoles FIDO2, mais diffèrent dans la manière dont elles stockent, protègent et gèrent le matériel cryptographique sous-jacent. Comprendre ces composants vous aide à associer le bon type d'identifiant au bon niveau de risque.

Pile de protocoles FIDO2

FIDO2 se compose de deux éléments principaux définis par les spécifications FIDO :

1. W3C Web Authentication (WebAuthn) : L'API navigateur qui permet l'authentification FIDO sur les sites web et applications.
2. Client-to-Authenticator Protocol (CTAP) : Le protocole permettant aux authentificateurs externes de communiquer avec les navigateurs et systèmes d'exploitation compatibles FIDO2.

Ces deux couches assurent la liaison d'origine et la preuve cryptographique qui rendent possible une connexion forte et résistante au phishing.

Architecture de stockage des identifiants

Le modèle de stockage est la différence déterminante entre passkeys et clés de sécurité. Chaque approche gère la clé privée différemment :

• Clés de sécurité matérielles : stockent les clés privées dans des modules de sécurité matériels dédiés (HSM), souvent à l'aide d'une puce TPM. Selon la documentation Microsoft Entra, le matériel cryptographique n'est pas exportable. Il ne peut pas être copié, sauvegardé ou synchronisé.
• Passkeys synchronisées : utilisent un système d'exploitation ou une infrastructure tierce de synchronisation pour répliquer les clés cryptographiques sur plusieurs appareils. Le guide de déploiement entreprise de la FIDO Alliance précise que cela crée une dépendance à l'infrastructure de synchronisation du fournisseur de passkeys et à ses contrôles de sécurité.

Cette distinction de stockage conditionne toutes les décisions ultérieures concernant l'attestation, la conformité et la récupération.

Attestation

L'attestation de l'appareil est une technique intégrée aux protocoles FIDO et WebAuthn qui permet à l'authentificateur de vérifier cryptographiquement la chaîne de confiance depuis le fabricant de l'appareil. Selon le livre blanc sur l'attestation de la FIDO Alliance, cela nécessite un certificat fabricant intégré dans l'élément sécurisé de l'authentificateur.

Les passkeys synchronisées ne peuvent pas fournir la provenance de l'appareil car la synchronisation cloud rompt cette chaîne cryptographique. Si vous imposez l'attestation dans votre plateforme d'identité, seuls les identifiants liés à l'appareil sont éligibles.

Alignement sur la conformité

NIST SP 800-63B-4 trace une distinction claire. AAL2 exige une authentification résistante au phishing, et les passkeys synchronisées comme les clés de sécurité peuvent répondre à ce critère. AAL3 exige une clé d'authentification non exportable, ce qui exclut totalement les passkeys synchronisées.

Ces composants correspondent directement à ce qui se passe lors de la connexion et là où les deux types d'identifiants se comportent différemment.

Enregistrement, authentification et points de divergence

Le flux d'authentification pour les passkeys et les clés de sécurité suit le même schéma FIDO2. La différence réside dans la gestion du stockage, de la portabilité et de la récupération des identifiants en arrière-plan.

Enregistrement (les deux méthodes)

Lors de l'inscription, l'authentificateur génère une paire de clés publique/privée unique liée au domaine du service. La clé privée reste sur l'authentificateur, et le serveur ne stocke que la clé publique.

Authentification (les deux méthodes)

1. Le serveur envoie un défi cryptographique.
2. Vous effectuez une vérification locale : scan d'empreinte digitale, reconnaissance faciale, code PIN ou pression sur un bouton physique.
3. L'authentificateur signe le défi avec la clé privée.
4. Le serveur valide la signature à l'aide de la clé publique stockée.

Ce flux commun explique pourquoi les deux approches bloquent les attaques de phishing au niveau du protocole.

Portabilité

Avec une clé de sécurité physique, vous transportez un jeton qui authentifie sur un nombre illimité d'appareils. Branchez-le sur n'importe quel navigateur compatible FIDO2 ou approchez-le en NFC, et vous êtes connecté.

Avec les passkeys synchronisées, vos identifiants sont automatiquement répliqués sur les appareils de l'écosystème de votre fournisseur : Apple, Google ou un gestionnaire tiers. Vous vous authentifiez sur votre ordinateur portable, et la même passkey fonctionne sur votre téléphone sans rien transporter de plus. Cependant, la portabilité entre écosystèmes reste inégale. Un flux fonctionnant sur Chrome/Windows peut se comporter différemment sur Safari/macOS, et des écarts d'expérience utilisateur au niveau du navigateur persistent pour les déploiements en entreprise.

Frontières de sécurité

Pour les identifiants liés à l'appareil, un attaquant a besoin de vos identifiants, d'un accès physique au jeton matériel et de la capacité à contourner l'authentification locale.

Pour les identifiants synchronisés, la frontière de sécurité se déplace vers votre fournisseur cloud. Si un attaquant compromet le compte cloud via l'ingénierie sociale ou la manipulation de la réinitialisation fournisseur, il peut synchroniser les identifiants sur un appareil contrôlé par l'attaquant.

Ce déplacement de la frontière est un enjeu de planification opérationnelle. Les deux types d'identifiants comportent des compromis à anticiper avant l'application en entreprise, et ces compromis n'ont d'importance que si les plateformes, navigateurs et fournisseurs d'identité que vous utilisez prennent effectivement en charge le type d'identifiant choisi.

Où les passkeys et les clés de sécurité sont-elles prises en charge aujourd'hui ?

En 2025, l'adoption des passkeys et des clés de sécurité a atteint un point de bascule pratique dans les écosystèmes grand public et entreprise.

• Systèmes d'exploitation et navigateurs. Apple (iOS 16+, macOS Ventura+), Google (Android 9+) et Microsoft (Windows 10/11 via Windows Hello) prennent tous en charge nativement la création et l'authentification par passkey. Tous les principaux navigateurs, dont Chrome, Safari, Edge et Firefox, prennent en charge WebAuthn. Selon la FIDO Alliance, plus de 95 % des appareils iOS et Android sont désormais compatibles passkey, et plus d'un milliard d'utilisateurs ont activé au moins une passkey.
• Fournisseurs d'identité. Les IdP d'entreprise ont ajouté la prise en charge FIDO2 de manière généralisée. Microsoft Entra ID prend en charge les passkeys liées à l'appareil sur les clés de sécurité FIDO2 et dans Microsoft Authenticator, avec la prise en charge des passkeys synchronisées en préversion. Okta prend en charge à la fois les passkeys et les clés de sécurité FIDO2 comme authentificateurs résistants au phishing, avec application de l'attestation et contrôles de politique basés sur l'AAGUID. Cisco Duo, Ping Identity et d'autres grands IdP prennent également en charge l'inscription FIDO2 pour les deux types d'identifiants. Cela signifie que votre IdP ne sera probablement pas le facteur bloquant.
• Clés de sécurité matérielles : fonctionnement universel sur toutes les plateformes compatibles FIDO2 via USB, NFC ou Bluetooth. Les principaux fabricants comme Yubico proposent des clés multiprotocoles (YubiKey 5 Series) prenant en charge FIDO2, PIV/Smart Card et OTP, couvrant les besoins d'authentification modernes et hérités dans un seul jeton.
• Lacunes de portabilité multiplateforme. Les passkeys synchronisées rencontrent encore des difficultés lors du passage entre écosystèmes. Une passkey créée dans Apple Keychain ne se synchronise pas nativement avec Google Password Manager ou un appareil Windows. La FIDO Alliance travaille sur ce point avec le Credential Exchange Protocol (CXP), une spécification en cours d'élaboration par Apple, Google, Microsoft, 1Password, Bitwarden et Dashlane pour standardiser le transfert sécurisé et chiffré des passkeys entre fournisseurs. Le CXP devrait atteindre le stade de brouillon public en 2026. D'ici là, les gestionnaires de mots de passe tiers comme 1Password et Bitwarden offrent l'expérience passkey multiplateforme la plus cohérente.

Pour la planification en entreprise, la principale conclusion est que la prise en charge des plateformes n'est plus un obstacle à l'adoption. Les dernières frictions concernent la portabilité inter-écosystèmes pour les passkeys synchronisées et la préparation organisationnelle autour de l'inscription, de la récupération et de l'application des politiques. Ces défis opérationnels méritent une attention particulière.

Défis et limitations à anticiper

Aucune méthode d'authentification n'élimine tous les risques. Lors du déploiement à grande échelle des passkeys ou des clés de sécurité, vous rencontrerez un ensemble restreint de défis récurrents :

• Les workflows de récupération deviennent un contrôle de première ligne. Si des attaquants peuvent influencer votre support ou le processus de réinitialisation fournisseur, ils peuvent contourner votre flux de connexion le plus robuste.
• La perte de clé devient un problème de disponibilité. Un jeton perdu peut bloquer un utilisateur à moins d'avoir prévu des sauvegardes et des workflows administrateur.
• Les différences de plateforme créent des frictions. La fragmentation des navigateurs et des OS peut entraîner une expérience WebAuthn incohérente et une charge de support accrue.
• La gestion du cycle de vie est réelle. L'émission, le remplacement et la révocation ajoutent du travail, surtout si vous élargissez la couverture des jetons au-delà des utilisateurs privilégiés.

Ce ne sont pas des cas théoriques. En 2023, MGM Resorts a révélé un incident cyber lié à l'ingénierie sociale avec un impact négatif estimé à 100 millions de dollars, selon un dépôt MGM. Des facteurs de connexion robustes aident, mais il faut aussi renforcer les opérations d'identité, y compris le support et les processus de secours. La bonne nouvelle est que chacune de ces contraintes correspond à une pratique de déploiement spécifique à mettre en place avant l'application.

Bonnes pratiques de déploiement des passkeys et des clés de sécurité

Que vous déployiez des passkeys, des clés de sécurité ou les deux, ces pratiques vous aident à aligner le déploiement sur le risque, l'utilisabilité et la réalité opérationnelle :

1. Segmenter selon le risque et le niveau d'assurance. Délivrez une clé de sécurité matérielle aux administrateurs privilégiés, dirigeants et rôles réglementés où AAL3 ou une attestation forte sont nécessaires. Utilisez les passkeys synchronisées pour le reste du personnel lorsque AAL2 suffit.
2. Rendre l'inscription et les sauvegardes systématiques. Exigez la configuration d'une passkey lors de l'intégration d'un appareil, et enregistrez plusieurs authentificateurs par utilisateur afin de disposer d'une sauvegarde qui n'oblige pas à revenir à des facteurs facilement usurpables.
3. Renforcer la récupération de compte et les solutions de secours. Considérez la récupération de compte comme un contrôle : renforcez la vérification d'identité pour les réinitialisations via le support, limitez les méthodes de secours et surveillez les usages anormaux des solutions de secours.
4. Déployer par phases et surveiller en continu. Pilotez d'abord les groupes à risque élevé, élargissez progressivement, puis appliquez une fois que le support utilisateur et les workflows de réinitialisation sont maîtrisés. Maintenez une visibilité continue sur les déplacements inhabituels, les changements d'appareils à risque et les réinscriptions suspectes.

En appliquant ces quatre pratiques, vous réduisez les blocages et limitez les options de l'attaquant sans ralentir les utilisateurs. Vous pouvez alors établir un modèle de segmentation clair pour attribuer le bon type d'identifiant à chaque cas.

Comment choisir entre une passkey et une clé de sécurité ?

Le choix entre une passkey et une clé de sécurité ne doit pas être exclusif. La plupart des entreprises adoptent un modèle hybride car différentes populations nécessitent des niveaux d'assurance et des parcours de récupération différents.

Utilisez cette segmentation pour clarifier le choix :

• Clé de sécurité matérielle : à utiliser lorsque vous avez besoin d'AAL3, de clés non exportables et d'une forte attestation matérielle pour les accès privilégiés.
• Passkey synchronisée : à utiliser lorsque AAL2 suffit et que vous souhaitez réduire la charge IT pour l'accès du personnel général.
• Politique hybride : utilisez des clés de sécurité pour les administrateurs et rôles réglementés, et des passkeys synchronisées pour le reste des utilisateurs.
• Conception axée sur la récupération : considérez les parcours de réinitialisation et de secours comme faisant partie de votre dispositif de contrôle, car ils peuvent annuler la MFA résistante au phishing.

Une fois cette segmentation établie, l'étape suivante consiste à s'assurer que vous pouvez toujours détecter et stopper les activités liées à l'identité après la connexion.

Points clés à retenir

Les passkeys et les clés de sécurité physiques offrent toutes deux une authentification résistante au phishing grâce à la cryptographie FIDO2, mais répondent à des besoins différents en entreprise. Les passkeys synchronisées privilégient l'expérience utilisateur et l'évolutivité pour les collaborateurs à AAL2. 

Les clés de sécurité liées à l'appareil fournissent des identifiants non exportables, une attestation matérielle et une conformité AAL3 pour les utilisateurs privilégiés et les environnements réglementés. Pour la plupart des entreprises, vous déploierez les deux dans un modèle basé sur le risque, puis ajouterez une visibilité sur les menaces liées à l'identité pour détecter ce que les contrôles d'authentification seuls ne peuvent pas empêcher.

FAQ

Qu’est-ce qu’un Passkey ?

Une passkey est un identifiant d’authentification FIDO2 qui utilise la cryptographie à clé publique au lieu d’un secret partagé comme un mot de passe. Lorsque vous enregistrez une passkey, votre appareil génère une paire de clés unique : la clé privée reste sur l’appareil (ou se synchronise via un fournisseur cloud), et le serveur ne conserve que la clé publique. 

Vous vous authentifiez à l’aide d’une analyse biométrique, d’un code PIN ou du déverrouillage de l’appareil. Comme l’identifiant est lié à un domaine spécifique et n’est jamais transmis, il empêche le phishing et les attaques par bourrage d’identifiants au niveau du protocole.

Quelle est la différence entre AAL2 et AAL3 ?

AAL2 et AAL3 sont des niveaux d'assurance d'authentification NIST qui définissent le degré de confiance que vous pouvez accorder à une connexion. AAL2 exige une authentification résistante au phishing, mais peut autoriser des identifiants synchronisés qui se déplacent entre les appareils sous le contrôle d'un fournisseur. 

AAL3 élève le niveau en exigeant une clé matérielle non exportable et des exigences de vérification plus strictes. En pratique, cela fait des passkeys synchronisées une solution adaptée à AAL2, tandis que les clés de sécurité ou d'autres authentificateurs liés à l'appareil sont utilisés pour AAL3.

Qu’est-ce qu’une attaque de redaction sur Passkey ?

Les attaques de dissimulation de passkeys ciblent la couche d’interface utilisateur en masquant ou en supprimant les invites de passkey, incitant ainsi les utilisateurs à recourir à des mots de passe, des SMS ou d’autres solutions de repli moins sécurisées. Les attaquants peuvent procéder ainsi via des proxys adversary-in-the-middle, des pages de connexion manipulées ou des extensions de navigateur malveillantes qui modifient l’affichage côté utilisateur. 

Pour réduire les risques, limitez les solutions de repli, appliquez des règles d’accès conditionnel et verrouillez les politiques d’extension. Il est également recommandé de générer des alertes en cas de pics soudains d’utilisation des solutions de repli, souvent signes de tentatives de coercition active.

Comment déployer les Passkeys et Security Keys par phases ?

Un déploiement progressif commence généralement par des travaux préparatoires : confirmer la prise en charge de WebAuthn, définir les politiques AAL2 versus AAL3, et élaborer des procédures robustes de réinitialisation et de réinscription. Déployez les security keys d’abord auprès des rôles privilégiés et à haut risque, puis déployez les passkeys synchronisés par vagues auprès de l’ensemble des collaborateurs. 

Appliquez des politiques FIDO uniquement lorsque l’adoption et la préparation du support sont stables. Conservez les facteurs hérités uniquement le temps d’éviter les blocages pendant la transition, puis retirez-les.

Les Passkeys synchronisés sont-ils sécurisés dans les environnements BYOD ?

Oui, mais il faut des garde-fous. Stockez les passkeys professionnels dans des conteneurs gérés ou des profils professionnels afin que les clés restent dans votre contexte géré, et non dans un coffre-fort cloud personnel. Limitez la création de passkeys aux navigateurs et applications gérés lorsque c’est possible, et auditez les identifiants professionnels enregistrés sous des comptes personnels. 

Votre modèle de récupération de compte est également important : si les réinitialisations reposent sur des étapes facilement manipulables par ingénierie sociale, les passkeys synchronisés perdent une grande partie de leur niveau d’assurance.

Pourquoi les entreprises utilisent-elles à la fois les Passkeys et les Security Keys ?

Vous utilisez les deux car aucun authentificateur unique n’équilibre l’assurance, l’utilisabilité et les opérations pour chaque rôle. Donnez des clés de sécurité aux utilisateurs privilégiés, aux administrateurs et aux rôles réglementés qui nécessitent des clés non exportables et une forte preuve de provenance de l’authentificateur. 

Utilisez des passkeys synchronisées pour l’ensemble des collaborateurs lorsque l’AAL2 est suffisant et que la facilité d’utilisation favorise l’adoption. Appliquez ensuite des politiques cohérentes de secours et de réinscription pour les deux groupes afin que les attaquants ne puissent pas rétrograder les utilisateurs vers des facteurs plus faibles.