Clés d'accès : déployer sans mot de passe

Un lundi matin, une directrice financière sort de sa boîte un téléphone neuf. Sa clé d'accès a suivi, ou pas : tout dépend de l'endroit où elle a été créée. Si elle n'a pas suivi, elle appelle le soutien technique, et c'est cet appel, pas la cryptographie, qui décide de la sécurité du compte.

Ce que disent les sources

La FIDO Alliance définit la clé d'accès (passkey) comme un justificatif d'authentification fondé sur les normes FIDO, conservé sur un téléphone, un ordinateur ou une clé de sécurité matérielle, avec lequel on ouvre une session par le geste qui déverrouille l'appareil : biométrie, NIP ou schéma. Techniquement, c'est une paire de clés cryptographiques liée au compte de l'utilisateur sur un site ou une application.

Deux types existent : les clés d'accès synchronisées sont copiées entre les appareils de l'utilisateur par un service infonuagique ; les clés d'accès liées à l'appareil ne quittent jamais un appareil unique, par exemple une clé de sécurité FIDO. Dans son livre blanc destiné aux entreprises, la FIDO Alliance en tire un tableau. Pour un besoin d'assurance faible, les deux conviennent. Pour une assurance modérée, la clé liée à l'appareil suffit et la clé synchronisée « peut suffire ». Pour une assurance élevée, la clé synchronisée est insuffisante et la clé liée à l'appareil peut suffire, selon l'authentifiant et les exigences réglementaires (FIPS 140, par exemple).

Le NIST arrive au même partage dans la révision 4 de la SP 800-63B, sans employer le mot passkey : il parle d'« authentifiants synchronisables ». Son annexe B, normative, les admet au niveau AAL2 à des conditions précises : les clés copiées vers le service de synchronisation n'y sont stockées que chiffrées, et l'accès de l'utilisateur à ces clés est protégé par une MFA équivalente au niveau AAL2. Au niveau AAL3, ils sont exclus, puisque synchroniser une clé suppose qu'elle soit exportable. Pour l'usage en entreprise fédérale, l'annexe ajoute une gestion des appareils qui empêche la copie des clés vers des appareils ou des services non autorisés, et des comptes gérés par l'organisation pour l'accès au service de synchronisation.

Le Centre canadien pour la cybersécurité, dans sa fiche ITSAP.30.033 d'avril 2026, qualifie les clés d'accès de mécanisme d'authentification robuste et résistant à l'hameçonnage, puis nomme deux limites. Le service ne peut pas facilement distinguer une clé liée à l'appareil d'une clé stockée dans un compte infonuagique personnel, et si ce compte est mal protégé, la clé s'obtient plus facilement. Surtout, beaucoup de systèmes conservent le mot de passe : si la clé d'accès échoue, l'utilisateur, ou un auteur de menace, se rabat sur lui.

Pourquoi ça compte

Parce que le risque se déplace de la connexion vers l'inscription et la récupération. Le NIST l'écrit : le point faible de bien des mécanismes d'authentification est le processus suivi quand l'abonné perd le contrôle d'un authentifiant et doit le remplacer, et dès que ce processus passe par un humain, l'ingénierie sociale devient un risque.

Sa réponse tient en quatre règles :

• permettre plusieurs authentifiants par compte et encourager chacun à en garder au moins deux, pour réduire le besoin de récupération ;
• exiger, avant de lier un nouvel authentifiant, une authentification au niveau où il servira, dans la limite de ce que le compte permet déjà ;
• aviser l'abonné, par un canal indépendant, de chaque ajout ;
• encadrer la récupération : au niveau AAL2, deux codes de récupération obtenus par des méthodes différentes, ou un code et un authentifiant à facteur unique déjà lié au compte, ou une nouvelle vérification d'identité.

L'annexe B applique la même logique aux clés synchronisées. Elles sont accessibles par les processus de récupération du compte infonuagique, une faiblesse potentielle selon le NIST. Leur révocation centrale est difficile, puisque chaque clé est propre à un service : le NIST recommande donc l'authentification unique et la fédération, qui limitent le nombre de clés à révoquer lors d'un incident.

Ce que nous en pensons chez Sentrix

Un déploiement de clés d'accès est un projet de cycle de vie avant d'être un projet d'authentification. Dans l'ordre :

1. Décider du type par population. Clés liées à l'appareil, sur clé de sécurité, pour les administrateurs et les comptes à privilèges ; clés synchronisées pour les autres, à condition que le compte de synchronisation soit géré par l'organisation.
2. Passer par l'authentification unique. Une clé inscrite chez le fournisseur d'identité plutôt que dans chaque application : moins d'inscriptions, et un seul endroit où révoquer.
3. Écrire la cérémonie d'inscription. Qui prouve quoi, devant qui, avant la première clé ? Deux authentifiants dès le premier jour, et un avis par un autre canal à chaque ajout.
4. Écrire la récupération avant le premier téléphone perdu. Codes de récupération remis à l'inscription, vérification d'identité imposée au soutien technique, aucun raccourci pour un appel « urgent ».
5. Commencer par un groupe restreint. La CISA observe qu'il peut être irréaliste de former, d'inscrire et de soutenir tout le monde en même temps ; elle suggère le soutien technique et les administrateurs comme première phase, sur les services qui prennent déjà FIDO en charge.
6. Fermer la porte de derrière. Tant que le mot de passe reste accepté, la clé d'accès améliore surtout l'ergonomie. Fixer une date de retrait par population et tenir la liste des exceptions.

La prochaine étape

Faites l'essai sur un seul compte : déclarez le téléphone perdu et suivez la procédure jusqu'au bout. Notez qui a été appelé, ce qui a été vérifié, et ce qu'un inconnu bien renseigné aurait obtenu au même guichet. C'est ce parcours qu'il faut corriger avant d'inscrire la première clé ; notre page identité et accès le reprend dans cet ordre.