Passkeys et multi-comptes : isolation des clés en 2026

À partir du 1er septembre 2026, Microsoft a commencé à inclure les passkeys comme méthode de connexion par défaut dans Entra ID, et à partir du 1er février 2027, elle désactivera l'envoi de codes SMS et vocaux. Google a fait des clés d'accès l'option principale de connexion pour les comptes personnels dès octobre 2023. Pour une personne avec un seul compte, c'est pratique. Pour ceux qui gèrent des dizaines de comptes en anti-détection, le passkey devient facilement un fil invisible qui relie des profils isolés. Nous allons voir ci-dessous comment cela se passe et comment établir un schéma dans lequel les clés ne « fuient » pas entre les comptes.

Pourquoi la question se pose-t-elle maintenant

Les passkeys existent depuis 2022, mais en 2026, elles sont passées de « vous pouvez les activer » à « vous serez invité à le faire ». Trois raisons spécifiques :

Microsoft Entra ID. À partir de septembre 2026, les utilisateurs qui confirmaient leur connexion par SMS ou appel se verront automatiquement proposer des passkeys : lors de la prochaine vérification MFA, une invitation à enregistrer une clé apparaîtra. Jusqu'au 31 janvier 2027, il est possible de le reporter, à partir du 1er février 2027, il ne sera plus possible de le faire. Microsoft justifie cela par une statistique : les campagnes de phishing utilisant l'IA obtiennent 54 % de clics contre 12 % pour les méthodes classiques.
Google. Depuis octobre 2023, dans les comptes personnels, l'option « Ignorer la saisie du mot de passe lorsque cela est possible » est activée par défaut. Si une clé est créée, Google propose de se connecter avec celle-ci.
Transfert de clés entre gestionnaires. La FIDO Alliance a publié la norme Credential Exchange (formats CXF et CXP). Dans iOS 26 et macOS 26, il est possible de transférer des passkeys entre Apple Passwords, 1Password, Bitwarden, Dashlane et d'autres applications de manière chiffrée, sans exporter de fichier. La clé n'est plus rigidement liée à un seul stockage. Pour le multi-comptes, c'est à la fois une opportunité et un risque.

Comment fonctionne un passkey et pourquoi il brise l'isolement des profils

Un passkey est une paire de clés cryptographiques. La clé publique est stockée par le site, la clé privée est conservée par l'« authentificateur ». La clé est liée à un domaine (dans la spécification, c'est rpId), donc un site de phishing ne pourra pas l'obtenir. La question principale pour le multi-comptes est où se trouve physiquement la clé privée. L'anti-détection isole les cookies, localStorage, IndexedDB et les empreintes. Le stockage des clés se trouve souvent en dehors du profil de navigateur :

Windows Hello stocke les clés au niveau du compte Windows. N'importe quel navigateur et n'importe quel profil sous ce compte accède au même stockage.
Le trousseau de clés iCloud sur macOS appartient à l'Apple ID. Chrome et Safari sur le même Mac voient un seul ensemble de clés.
Le gestionnaire de mots de passe Google est lié au compte Google avec lequel le navigateur ou le téléphone est connecté. Un compte Google professionnel pour vingt profils — c'est un seul coffre commun.
Les gestionnaires d'extensions (Bitwarden, 1Password et autres) stockent les clés dans le coffre de leur compte. Un seul coffre pour tous les profils fonctionne comme un point unique, à travers lequel tout est visible.

Voici donc un échec typique. Vous cliquez sur « Se connecter avec une clé d'accès » dans le profil du compte n°7, et le système affiche les clés des comptes n°3 et n°12 sur le même site. Le site ne voit pas cette liste : il ne reçoit que la clé sélectionnée. Mais une mauvaise pression — et le compte n°3 se connecte depuis le profil, l'IP et l'empreinte du compte n°7. Ce lien ne peut plus être annulé.

Que sait réellement le site lors de la connexion avec un passkey

Le passkey n'annule pas le scoring de risque, il remplace simplement le mot de passe. Lors de la connexion, la plateforme voit toujours l'IP, l'empreinte du navigateur et l'historique des sessions. De plus, elle reçoit plusieurs signaux WebAuthn :

Identifiant de clé (credential ID). Il est unique pour la paire « compte — authentificateur ».
AAGUID — identifiant du modèle d'authentificateur. Les sites comme Google signent la clé dans les paramètres du compte : « créé dans iCloud Keychain », « dans le gestionnaire de mots de passe Google », etc. Ce n'est pas un numéro unique de votre appareil, mais c'est une autre caractéristique qui doit correspondre à la légende du profil.
Drapeaux BE et BS (backup eligibility et backup state) indiquent si cette clé est synchronisée ou liée à un appareil.

Conclusion : un profil « mobile » qui se connecte avec une clé de Windows Hello semble aussi illogique qu'un iPhone avec un fuseau horaire du Brésil et une IP d'Allemagne. La clé doit correspondre à la même légende que le proxy et l'empreinte.

Schéma étape par étape : un compte — un profil — un stockage — une IP

Faites l'inventaire. Notez les plateformes où vos comptes ont déjà des passkeys ou ont reçu une invitation à les créer : Google, Microsoft, grandes places de marché et réseaux sociaux. Dans les paramètres de sécurité de chaque compte, vous pouvez voir combien de clés sont enregistrées et où elles ont été créées. Toutes les entrées inattendues « Windows Hello » et « iCloud Keychain » sont des candidates à la suppression.
Désactivez le stockage système des clés pour les profils de travail. Dans le navigateur où les profils fonctionnent, désactivez la sauvegarde des mots de passe et des clés d'accès dans le gestionnaire intégré. Sur la machine de travail, ne créez pas de clés dans Windows Hello ou le trousseau iCloud. Si la fenêtre de création de clé propose « cet ordinateur », choisissez une autre méthode.
Choisissez un stockage pour chaque compte. La règle est simple : le stockage doit être séparé de la même manière que les profils. Options :
- un stockage de gestionnaire de mots de passe séparé par compte ou par groupe de comptes d'un même client ;
- une clé matérielle (FIDO2) pour quelques comptes les plus précieux ;
- pour l'automatisation — un authentificateur logiciel, dont nous parlerons à l'étape 6.
Un seul stockage pour tous — c'est la méthode la plus courante pour relier soi-même les comptes entre eux.
Enregistrez la clé uniquement depuis le profil « natif ». Même profil, même empreinte, même proxy avec session fixée, même géo que lors du fonctionnement normal du compte. L'enregistrement de la clé est une action sensible, et les plateformes y prêtent attention. Changer d'IP au milieu de la procédure entraîne souvent une vérification supplémentaire. Comment maintenir une adresse fixe pour un profil, nous l'avons détaillé dans l'article session sticky ou rotation pour le profil anti-détection.
Laissez une méthode de connexion de secours. Un stockage perdu signifie un compte perdu. Pour chaque compte, il faut un deuxième moyen de connexion : un deuxième passkey dans un autre stockage, un mot de passe avec TOTP ou des codes de récupération, qui sont conservés séparément de la clé. Microsoft dans Entra exige directement de transférer les utilisateurs vers des méthodes résistantes au phishing avant février 2027. N'attendez pas que la fenêtre d'enregistrement cesse de se fermer.
Dans l'automatisation, utilisez un authentificateur virtuel. Dans le Chrome DevTools Protocol, il existe un domaine WebAuthn. La méthode addVirtualAuthenticator crée un authentificateur logiciel avec le protocole ctap2 et le transport internal (plateforme) ou usb/hybrid. Les paramètres hasResidentKey et hasUserVerification incluent le stockage de la clé sur l'authentificateur et la vérification de l'utilisateur. getCredentials après l'enregistrement renvoie la clé dans son intégralité : credentialId, rpId, userHandle, signCount et la clé privée au format PKCS#8. addCredential lors du prochain lancement la remet en place. Cela donne une clé qui vit uniquement dans votre coffre secret et se connecte à la session d'un compte spécifique. Deux réserves : le domaine est marqué comme expérimental et créé pour tester WebAuthn, et la clé privée exportée est un secret de niveau mot de passe, et doit donc être conservée en conséquence.
Transférez les clés via Credential Exchange, pas manuellement. Si vous changez de gestionnaire ou répartissez les comptes dans différents stockages, utilisez l'exportation intégrée selon la norme FIDO : elle est prise en charge dans Apple Passwords, 1Password, Bitwarden, Dashlane, DuckDuckGo, Devolutions. Notez que sur macOS, certaines applications n'ont pas encore intégré ce mécanisme.

Les pièges

Synchronisation par défaut. Une clé créée « sur cet appareil » peut immédiatement aller dans le cloud iCloud ou Google et apparaître sur tous les appareils de ce compte, y compris sur votre téléphone personnel.
Connexion cross-device par QR. Le scénario « scannez le QR avec votre téléphone » (transport hybrid) connecte à la session du profil un vrai téléphone avec ses propres clés. Pour les profils de travail, c'est un lien supplémentaire.
Avoir le même AAGUID pour toute la ferme — c'est normal. Des millions de personnes utilisent le même gestionnaire. Ce n'est pas le même fournisseur qui est dangereux, mais la clé commune ou le stockage commun.
Le passkey ne guérit pas les connexions « sales ». Si un compte se connecte avec une IP qui a déjà été exposée sur des comptes voisins, ou depuis un centre de données que la plateforme n'aime pas, une forte cryptographie ne sera d'aucune aide. Le risque est évalué en fonction de l'ensemble des signaux.
Le deuxième facteur doit également être isolé. Si la connexion de secours est TOTP, les secrets doivent également être répartis entre les comptes, et ne pas être conservés dans une seule application sur votre téléphone personnel. Comment relier 2FA et proxy, nous l'avons examiné dans l'article sur l'authentification à deux facteurs dans le travail via proxy.

Quel proxy est nécessaire et pourquoi

Pour se connecter avec une clé, la constance est primordiale : le compte doit enregistrer la clé puis se connecter avec elle depuis le même réseau, dans la même zone géographique. Donc :

Profils web en anti-détection — proxies résidentiels avec session fixée dans le pays du compte. Ce sont des adresses de fournisseurs domestiques, et elles correspondent à la légende « utilisateur ordinaire à la maison ».
Plateformes mobiles et comptes avec une légende mobile — proxies mobiles. Un profil mobile qui enregistre une clé depuis un réseau domestique à l'autre bout du pays sort de son historique.
Rotation à chaque requête convient pour le parsing, mais pas pour la connexion aux comptes. Mettez un intervalle suffisant pour toute la session de travail.

Conclusion

Les passkeys rendent la connexion résistante au phishing, mais déplacent le point de liaison entre les comptes des cookies et des mots de passe vers le stockage des clés. Ce point se trouve souvent en dehors du profil anti-détection : dans Windows Hello, iCloud, le compte Google ou le stockage commun du gestionnaire. Le schéma de travail est le suivant : chaque compte a son propre profil, son propre stockage de clés, sa propre IP permanente et un moyen de connexion de secours. Pour l'automatisation, il existe un authentificateur virtuel dans le CDP. Occupez-vous de cela avant février 2027, lorsque Microsoft cessera de permettre de reporter l'enregistrement. Ensuite, il faudra se débrouiller dans l'urgence et directement sur des comptes actifs.