Un exercice de récupération des passkeys vérifie comment un collègue retrouve l'accès lorsque son authentificateur habituel est indisponible. Avant d'imposer les passkeys, testez deux situations : un moyen d'authentification de secours reste disponible, ou tous les moyens utilisables sont perdus. Vérifiez qui peut autoriser leur remplacement, quels comptes restent accessibles et ce qu'il advient des sessions déjà ouvertes.

C'est une réponse concrète au débat qui anime Hacker News cette semaine. Dans son [article du 14 octobre, « Passkeys Are Not a Trap »](https://scotthelme.co.uk/passkeys-are-not-a-trap/), Scott Helme conteste certaines affirmations sur l'attestation des passkeys. La [discussion](https://news.ycombinator.com/item?id=50088935) soulève aussi des questions d'accès ordinaires : où le moyen d'authentification a-t-il été enregistré, que se passe-t-il sur un autre appareil, qui aide lorsqu'il disparaît ? Ces commentaires sont des témoignages, pas une mesure du taux d'échec. Ils décrivent néanmoins des situations que votre déploiement doit prévoir.

Vous pouvez défendre une authentification résistante au hameçonnage et exiger une procédure de récupération utilisable. Pour une startup, le meilleur moyen de l'évaluer est de l'essayer avant qu'un collègue en ait besoin pendant un entretien ou un incident en production.

## Commencez par un ordinateur portable perdu

Utilisez un espace de travail de test et une collègue fictive, Maya. Elle a un entretien dans une demi-heure, son ordinateur habituel est indisponible et elle doit accéder au logiciel de recrutement depuis un autre navigateur. L'exercice doit établir ce qu'elle peut réellement faire, y compris les étapes qui exigent l'intervention d'une autre personne.

Notez sa situation de départ avant de modifier les paramètres. Quel moyen d'authentification utilise-t-elle habituellement ? Où est-il stocké ? Peut-elle utiliser son téléphone sans son ordinateur ? Une clé de sécurité distincte est-elle déjà enregistrée ? Peut-elle accéder à l'adresse e-mail utilisée pour la récupération ? Qui est autorisé à l'aider ?

Ces questions décrivent des dépendances différentes. Un téléphone peut contenir une passkey synchronisée, recevoir un e-mail de récupération et approuver l'accès au gestionnaire de mots de passe. Le mentionner trois fois ne crée pas trois voies d'accès indépendantes.

Commencez par garder un moyen de secours enregistré à disposition et considérez l'appareil habituel comme indisponible pour l'exercice. Ouvrez un navigateur distinct et authentifiez-vous avec ce moyen de secours. Voir un deuxième moyen dans les paramètres du compte ne suffit pas : il faut vérifier que Maya peut l'utiliser dans les conditions qui suivraient la perte.

Essayez ensuite d'enregistrer un nouveau moyen d'authentification. L'application peut exiger une nouvelle authentification avant d'autoriser les modifications, même si une page est encore ouverte. Notez à quel moment elle la demande, quelle méthode elle accepte et si le moyen de secours permet de franchir cette étape.

Consignez le temps nécessaire et les obstacles observés. Vous n'avez pas besoin d'un objectif emprunté à une autre entreprise. Il vous faut assez d'éléments pour décider si votre équipe peut accepter l'interruption et si les instructions restent compréhensibles sans la personne qui les a rédigées à côté.

## Distinguez connexion de secours et récupération du compte

Utiliser un moyen d'authentification encore enregistré diffère d'une demande faite à l'application de rétablir la confiance après la perte de tous les moyens utilisables. Donnez des noms distincts à ces situations dans les instructions : elles n'imposent pas les mêmes démarches à l'utilisateur et à l'administrateur.

Le [livre blanc de la FIDO Alliance sur le déploiement en entreprise](https://fidoalliance.org/white-paper-replacing-password-only-authentication-with-passkeys-in-the-enterprise/) distingue les passkeys synchronisées des moyens d'authentification liés à une clé matérielle. La synchronisation peut aider après un changement d'appareil. Une clé matérielle enregistrée au préalable peut offrir une autre voie d'authentification. Son utilité dépend de sa disponibilité et de sa prise en charge dans l'environnement où le collègue doit s'en servir.

Supposons que le téléphone de Maya puisse utiliser une passkey synchronisée après la panne de son ordinateur. La connexion de secours fonctionne. Supposons maintenant que les deux appareils dépendent du même compte chez le fournisseur de moyens d'authentification, et que ce compte soit lui aussi inaccessible. Le premier test réussi n'a pas résolu le deuxième problème.

Établissez un inventaire des dépendances plutôt que de compter les appareils :

| Situation | Ce qui reste digne de confiance | Ce que l'exercice doit établir |
|---|---|---|
| Ordinateur indisponible, moyen de secours enregistré fonctionnel | Un moyen d'authentification existant | Le secours permet de s'authentifier et d'enregistrer un remplacement |
| Nouvel appareil, synchronisation disponible | Le fournisseur de moyens d'authentification et sa procédure de récupération | L'utilisateur peut retrouver l'accès sans l'appareil manquant |
| Tous les moyens utilisables sont indisponibles | La procédure de récupération de l'application | Une personne ou un mécanisme défini peut autoriser le remplacement |
| Soupçon de vol ou de compromission | Moyens d'authentification et sessions dont l'état est incertain | La récupération comprend un examen distinct des accès qui subsistent |

Ce tableau est une aide à la préparation. Ajoutez vos observations réelles dans une procédure d'exploitation interne. Un résultat vide signifie que la voie n'a pas été testée, même si la documentation du fournisseur la décrit clairement.

N'utilisez pas « sans mot de passe » pour résumer tout ce qui intervient dans la récupération. Une passkey peut protéger une opération d'authentification alors qu'un compte fournisseur, une boîte e-mail ou une décision d'administrateur reste nécessaire pour retrouver l'accès.

## Simulez aussi la perte du fournisseur de moyens d'authentification

Une passkey synchronisée peut améliorer la disponibilité, mais le fournisseur de synchronisation constitue un autre système auquel votre collègue devra peut-être récupérer l'accès. Testez ce que l'application permet lorsque ce système est inaccessible, au lieu de supposer qu'un autre appareil fournira toujours le moyen d'authentification.

Pour cette partie de l'exercice de Maya, considérez toutes les passkeys utilisables comme indisponibles. Faites-le avec une identité de test ; n'effacez pas les moyens d'authentification d'un administrateur de production pour rendre le scénario réaliste. Suivez la procédure documentée de l'application depuis un navigateur vierge et notez la première condition que Maya ne peut pas remplir.

Elle peut peut-être se connecter avec une autre méthode et accéder à une page d'enregistrement restreinte. L'application autorise peut-être uniquement les passkeys et la renvoie vers une procédure distincte de récupération d'identité. Un administrateur peut peut-être accorder une autorisation de remplacement strictement limitée. Ce sont des conceptions de récupération sensiblement différentes.

Le [document FIDO sur le déploiement des passkeys synchronisées](https://fidoalliance.org/wp-content/uploads/2024/05/Synced-Passkey-Deployment_-Emerging-Practices-for-Consumer-Use-Cases_2024-May-31.pdf) traite de l'authentification alternative et de la récupération, en complément des moyens synchronisés. Pour l'exploitation, il faut examiner à la fois la procédure du fournisseur et celle de l'application. Une voie fonctionnelle ne prouve pas que l'autre fonctionne, et le terme « passkey » ne garantit pas l'export entre les fournisseurs choisis.

Demandez à Maya de suivre les instructions sans ses notes ni ses favoris habituels. Si la procédure se trouve derrière le même accès qu'elle tente de rétablir, rendez les instructions nécessaires disponibles par un autre canal approprié.

Testez également l'adresse de réception. Un message de récupération envoyé à une ancienne boîte e-mail peut faire échouer une procédure pourtant solide. Même une adresse appartenant à la personne qui demande de l'aide ne prouve pas la légitimité de la demande si la compromission de sa boîte fait partie du scénario.

## Décidez qui peut autoriser le remplacement

La récupération avec l'aide d'un administrateur fait reposer la confiance sur la personne qui approuve la demande et sur les preuves qu'elle accepte. Attribuez cette responsabilité avant d'imposer les passkeys, y compris en cas d'absence de l'administrateur habituel.

Le message de Maya arrive : « J'ai perdu mon téléphone et mon ordinateur. Pouvez-vous réinitialiser ma passkey ? » L'approbation doit suivre une procédure que l'administrateur peut expliquer et répéter. Un nom d'affichage convaincant et une réponse urgente par e-mail constituent des bases fragiles pour accorder un nouvel accès à un espace contenant des informations sur les candidats.

Utilisez un canal indépendant adapté à l'équipe et au risque. Par exemple, un administrateur peut appeler Maya aux coordonnées déjà obtenues par une procédure de confiance. Un nouveau numéro fourni dans la demande de récupération elle-même ne constitue pas une confirmation indépendante. Consignez la vérification sans recueillir de données personnelles inutiles dans un ticket d'assistance.

Les [recommandations du NIST sur l'authentification et la gestion des authentificateurs](https://pages.nist.gov/800-63-4/sp800-63b.html) traitent la récupération séparément de l'authentification avec les authentificateurs restants. Elles décrivent des méthodes de récupération dans un cadre de niveaux d'assurance, demandent des notifications de récupération et abordent l'analyse de risque des méthodes propres à une application. Vous pouvez vous en servir pour examiner votre conception sans affirmer que votre startup ou fournisseur atteint un niveau d'assurance particulier.

Pendant l'exercice, demandez à l'administrateur d'expliquer exactement ce qu'autorise son action. Permet-elle un seul enregistrement de remplacement, ouvre-t-elle l'application entière, réinitialise-t-elle un autre facteur ou désactive-t-elle une politique pour tous ? Privilégiez une action dont le périmètre et la durée correspondent à la tâche approuvée.

Rendez ensuite cet administrateur indisponible dans le scénario. Qui peut effectuer la même action autorisée ? Cette personne peut-elle trouver la procédure et vérifier l'identité de Maya ? Si personne ne le peut, consignez cette limite de disponibilité et décidez si elle est acceptable avant d'imposer ce moyen d'authentification.

Ne désactivez pas discrètement une politique de l'espace de travail pour réussir l'exercice. Si l'assouplissement de l'obligation constitue une option d'urgence explicite, documentez qui peut l'autoriser, quels accès il ouvre et comment rétablir la politique. Cette décision mérite sa propre trace écrite.

## Vérifiez quelles sessions restent ouvertes

Remplacer un moyen d'authentification et mettre fin aux accès existants sont deux opérations distinctes. L'exercice doit établir ce qu'il advient des anciennes sessions de navigateur et des jetons connectés, surtout lorsqu'un appareil a pu être volé.

Le [modèle des moyens d'authentification et des assertions de WebAuthn](https://www.w3.org/TR/webauthn-3/) rattache les moyens à clé publique au service auprès duquel l’utilisateur s’authentifie (la relying party) et définit leur validation lors de l'authentification. Ces propriétés fondent la résistance au hameçonnage lorsqu'elles sont correctement mises en œuvre. Elles ne signifient pas que chaque requête ultérieure répète l'opération, ni que supprimer un moyen annule automatiquement une session déjà créée.

Après le remplacement, revenez au navigateur d'origine de Maya. Pour un exercice maîtrisé, utilisez un autre navigateur de test afin de représenter l'appareil indisponible. Peut-il encore lire des données ? Modifier des paramètres ? Le retrait de l'ancien moyen change-t-il l'un de ces résultats ? Observez le comportement plutôt que de supposer que le mot « réinitialisation » implique un nettoyage complet du compte.

Examinez ensuite les outils connectés au compte. Un jeton API peut continuer de fonctionner parce qu'il constitue un moyen d'authentification indépendant. Une connexion à un assistant peut disposer de ses propres règles d'autorisation et de révocation. Décidez quels accès doivent subsister lors d'un remplacement ordinaire et lesquels révoquer en cas de soupçon de compromission.

Notre [liste de contrôle des fournisseurs pour le départ d'un utilisateur SSO](/blog/sso-offboarding-vendor-acceptance-checklist) couvre des questions voisines sur les sessions et les accès connectés. La même distinction compte ici : modifier la manière dont une personne s'authentifie ne suffit pas à établir quelles autorisations ou quels moyens antérieurs ont pris fin.

Consignez le résultat concrètement : l'accès de l'ancien navigateur a été révoqué, le moyen manquant a été retiré et un jeton désigné a été renouvelé, si ces actions ont réellement eu lieu. « Compte récupéré » est trop vague pour indiquer au prochain administrateur si un attaquant pourrait encore détenir une session utilisable.

## Décidez du déploiement à partir de l'exercice

Imposez les passkeys lorsque vous comprenez les voies d'authentification prises en charge et avez accepté les limites de récupération restantes. Un exercice réussi doit produire une procédure utilisable, un administrateur responsable et une trace des accès qui subsistent après le remplacement.

Gardez des preuves concises. Pour chaque scénario, notez la situation initiale, la voie tentée, le résultat observé et la modification nécessaire. Signalez les dépendances à une personne, une boîte e-mail, un fournisseur ou un appareil précis. Corrigez les étapes qui ont échoué et rejouez-les avant d'étendre l'obligation.

Séparez le résultat technique de la décision. « La clé de secours a permis l'authentification depuis l'ordinateur de remplacement » est une observation. « Chaque collègue doit enregistrer un moyen de secours disponible séparément avant le déploiement » est un choix de politique. « Nous acceptons un délai jusqu'au retour d'un administrateur autorisé » est un autre choix possible, à condition que l'équipe concernée le comprenne.

Vous pouvez mesurer le temps nécessaire, les demandes d'assistance et les tentatives d'enregistrement abandonnées pendant le déploiement. Ce sont des mesures de votre propre procédure. Elles n'exigent ni référence sectorielle inventée ni promesse d'une baisse du travail d'assistance d'un pourcentage précis grâce aux passkeys.

Enfin, expliquez les démarches à effectuer avant le début de l'obligation et la manière de demander de l'aide ensuite. Indiquez où les moyens d'authentification sont gérés, quelles voies de secours l'équipe prend en charge et ce qu'un administrateur demandera avant d'autoriser le remplacement. Un message court lié à une procédure testée est plus utile qu'une assurance générale selon laquelle personne ne perdra l'accès.

## Comment fonctionne la récupération des passkeys dans Kit

L'application doit décrire assez clairement ses limites d'accès et de récupération pour permettre un exercice. Dans Kit, une passkey appartient à la personne, tandis qu'un compte peut exiger une vérification par passkey avant qu'un navigateur ouvre cet espace de travail. Il s'agit de l'accès de l'équipe au produit ; [l'accès au portail candidat](/blog/why-we-killed-passwords-for-candidates) suit une procédure distincte.

L'administrateur qui active l'obligation doit déjà posséder une passkey. Le paramètre utilise l'autorisation **gérer la sécurité**, disponible pour les rôles Admin et Security Analyst. Il n'existe aucune exemption générale pour le propriétaire. Examinez d'abord le tableau de conformité des membres : l'obligation prend effet immédiatement, sans délai de grâce ni déploiement progressif intégré.

Une vérification par passkey doit être consignée pour la session du navigateur. L'enregistrement d'un moyen par un collègue ne prouve pas que chacun de ses navigateurs existants l'a utilisé. Une fois vérifiée, cette session peut rester conforme pendant toute sa durée de vie ; la politique ne demande pas une nouvelle assertion à chaque page. Une session authentifiée au moyen de SAML imposé peut aussi satisfaire l'obligation. La robustesse de cette authentification dépend de la politique du fournisseur d'identité.

Si un collègue connecté perd toutes ses passkeys, un administrateur de sécurité autorisé peut émettre une autorisation de réenregistrement. Kit l'envoie directement au membre par e-mail. Le lien ouvre une page de confirmation ; la confirmation consomme l'autorisation et ouvre une **fenêtre d'enregistrement de 15 minutes pour ce compte**. L'autorisation est utilisable une seule fois dans les **24 heures**, et une nouvelle émission remplace la précédente. La [documentation sur l'obligation des passkeys](/docs/requiring-passkeys) explique la procédure.

Cette voie exige toujours que le membre soit connecté sous l'identité correspondante. Elle ne promet pas de récupérer une identité Kit devenue entièrement inaccessible. L'administrateur doit vérifier la demande de manière indépendante, et l'acheminement de l'e-mail reste un élément de confiance. Le réenregistrement ne révoque pas non plus automatiquement les anciennes sessions de navigateur.

Les jetons API et les connexions MCP ont une autre limite : ils vérifient que leur utilisateur a enregistré une passkey au lieu d'effectuer une assertion WebAuthn. Pour évaluer les outils connectés, considérez cette garantie comme plus faible que la preuve fournie dans le navigateur.

Rejouez l'exercice avec ces limites avant d'activer le paramètre. Commencez par le [guide de configuration des passkeys](/docs/passkeys), puis testez le remplacement et examinez la [sécurité de connexion](/docs/sign-in-security) avec un autre administrateur autorisé. Le résultat utile est un collègue capable de suivre la procédure de récupération et un administrateur qui sait exactement quel accès il a rétabli.