En janvier 2026, le FBI a lancé l’opération Winter SHIELD, dont la première action recommandée est la suivante : déployer des méthodes résistantes au phishing, « des clés de sécurité conformes à FIDO2 ou des passkeys liées à l’appareil » (« FIDO2 compliant security keys or device-bound passkeys »), pour l’authentification, l’accès à distance et les systèmes critiques (FBI). Les lignes directrices de l’ENISA pour la mise en œuvre de NIS2 disent la même chose pour les VPN et des systèmes d’administration : « partout où c’est possible, utilisez un MFA résistant au phishing » (« wherever possible, use phishing-resistant MFA ») (ENISA, juin 2025). La documentation de Microsoft elle-même décrit désormais le MFA par SMS et par application d’authentification comme « exposé aux attaques de phishing à distance » (« prone to remote phishing attacks ») (Microsoft).
Si votre accès à distance passe par un concentrateur VPN qui vérifie les connexions via RADIUS, vous avez sans doute déjà constaté le problème : il n’y a nulle part où brancher une passkey. Cet article explique pourquoi, présente les trois options réalistes et précise, pour chacune, ce contre quoi elle ne protège pas.
Ce que fait réellement une passkey
Une passkey est un identifiant WebAuthn : une paire de clés générée sur l’appareil de l’utilisateur et enregistrée auprès d’un site web précis. Au moment de la connexion, le navigateur demande à l’appareil de signer un défi envoyé par le site, et la signature couvre l’origine de la page que le navigateur affiche réellement. Le site vérifie que l’origine contenue dans la signature est bien la sienne. Une fausse page de connexion hébergée sur un autre domaine obtient une signature pour la mauvaise origine, et le vrai site la rejette. L’utilisateur n’a rien à remarquer, puisque c’est le navigateur qui fait la vérification (W3C WebAuthn).
C’est ce que les normes entendent par « résistant au phishing ». La définition actuelle du NIST est « la capacité du protocole d’authentification à empêcher la divulgation des secrets d’authentification … sans dépendre de la vigilance du demandeur » (« the ability of the authentication protocol to prevent the disclosure of authentication secrets … without relying on the vigilance of the claimant »), et elle est explicite sur ce qui échoue au test : les mots de passe, les codes à usage unique, les approbations push et tout ce que l’utilisateur doit recopier sont « non résistants au phishing » (NIST SP 800-63B-4, 2025). La CISA classe les méthodes dans le même ordre : FIDO/WebAuthn et PKI en haut, puis les codes à usage unique et le push avec correspondance de numéros (number matching), puis le push sans correspondance, puis le SMS (CISA).
Dans la manière dont une passkey satisfait à cette définition, deux éléments comptent pour un VPN. La protection vient d’un navigateur ou d’un client de plateforme qui sait à quelle origine il s’adresse, et d’un défi et d’une signature qui voyagent à l’intérieur du protocole de connexion.
Pourquoi un VPN RADIUS n’a nulle part où la brancher
RADIUS, le protocole qu’utilisent la plupart des passerelles VPN pour demander à un serveur d’authentification « cette connexion est-elle valable ? », a été conçu pour les modems RTC. Un paquet Access-Request transporte un nom d’utilisateur et un mot de passe masqué par un flux de clé MD5, ou une réponse CHAP. Si le serveur veut davantage, il envoie un Access-Challenge, dont la passerelle « PEUT afficher » (« MAY display ») le texte à l’utilisateur ; celui-ci saisit alors une réponse qui repart dans le champ du mot de passe (RFC 2865). Voilà tout le vocabulaire : des chaînes de caractères tapées par un humain. Il n’existe aucun champ pour une assertion WebAuthn signée, aucune origine à signer puisqu’un client VPN n’a pas de page, et aucun agent utilisateur pour la faire respecter.
À eux seuls, aucun de ces systèmes ne peut donc prendre en charge les passkeys pour la connexion VPN :
- MikroTik RouterOS : client RADIUS uniquement, ni SAML ni OIDC (documentation MikroTik).
- WireGuard : authentifie les pairs par des clés publiques statiques et n’a aucune notion de connexion utilisateur ; aucune des options ci-dessous ne s’y applique donc : le problème, ici, c’est la distribution des clés (wireguard.com).
- OpenVPN Access Server : avec RADIUS, LDAP ou PAM, le second facteur est un code temporel, et seul son mode SAML peut confier la connexion à un navigateur (documentation OpenVPN).
FortiGate, Palo Alto GlobalProtect et Cisco Secure Client proposent bien des passkeys à la connexion VPN, et tous trois procèdent de la même façon : le client VPN ouvre un navigateur, le navigateur se connecte à un fournisseur d’identité SAML, c’est là que la passkey est utilisée, et le fournisseur d’identité indique à la passerelle que l’utilisateur est légitime. FortiClient le fait avec l’option « navigateur externe comme agent utilisateur », Cisco ASA, à partir de la version 9.17, lance le navigateur système précisément pour cette raison, et GlobalProtect intègre une vue de navigateur dans le client (Fortinet, Duo pour Cisco ASA, Palo Alto). Sur son propre chemin RADIUS, Microsoft le dit sans détour : l’extension NPS ne peut pas faire de correspondance de numéros, et MS-CHAPv2 ne peut pas transporter un code temporel (Microsoft).
La passkey ne touche jamais RADIUS. C’est le navigateur qui fait le travail, et la passerelle se fie à la parole du fournisseur d’identité.
Les trois options réalistes
1. Placer un fournisseur d’identité SAML devant le VPN et y utiliser des passkeys
Cette voie offre une résistance au phishing au sens strict pour les connexions VPN des utilisateurs, et si votre passerelle et vos clients la prennent en charge, c’est la bonne réponse pour la partie du problème qui passe par un navigateur.
Ce qu’elle coûte : un fournisseur d’identité qui prend en charge les passkeys, avec la licence qui l’accompagne, des versions de client assez récentes pour le SAML par navigateur externe, un déploiement de passkeys auprès de chaque utilisateur du VPN et une procédure de récupération en cas d’appareil perdu. Ce qu’elle laisse sans protection : tout système incapable de faire du SAML, y compris la connexion administrateur du pare-feu lui-même sur de nombreux équipements, MikroTik, WireGuard et tout ce qui se connecte sans navigateur.
2. Les certificats
L’authentification par certificat client (EAP-TLS sur le VPN, ou certificats machine sur l’appareil) est l’autre méthode que le NIST compte comme résistante au phishing, par ce qu’il appelle la liaison de canal (channel binding) (NIST). Il n’y a rien à saisir pour l’utilisateur et rien à relayer.
Ce qu’elle coûte : une autorité de certification, l’enrôlement de chaque appareil, un renouvellement et une révocation qui fonctionnent vraiment, et quelqu’un qui en porte la responsabilité. La CISA décrit le MFA fondé sur une PKI comme exigeant « des pratiques de gestion des identités très matures » (« highly mature identity management practices ») et relève qu’il n’est pas largement pris en charge (CISA). Et un certificat machine prouve quel appareil s’est connecté, pas qui était assis devant.
3. Garder RADIUS et ajouter une approbation sur le téléphone qui montre la connexion
La troisième voie conserve la passerelle et le serveur RADIUS exactement tels qu’ils sont et ajoute une seconde étape dans le chemin RADIUS : votre serveur RADIUS vérifie d’abord le mot de passe, et ce n’est qu’une fois la connexion acceptée que l’utilisateur reçoit une demande d’approbation sur son téléphone. La demande nomme le service, le compte et l’adresse IP d’origine, et la connexion n’aboutit que si l’utilisateur l’approuve. C’est ce que fait l’auth-proxy Notakey ; le guide d’installation le détaille pour FreeRADIUS, NPS et le User Manager de MikroTik.
C’est la voie la moins coûteuse à déployer, car rien ne change sur la passerelle hormis la destination de ses requêtes RADIUS, et elle fonctionne sur toute passerelle qui vérifie les connexions via RADIUS, y compris celles qui ne parleront jamais SAML. C’est aussi celle que nous devons décrire avec le plus de soin.
Ce qu’elle arrête. Un mot de passe divulgué, deviné par pulvérisation (password spraying) ou cassé ne suffit plus pour se connecter. FortiBleed, la campagne de 2026 contre les VPN FortiGate, n’a eu besoin de rien d’autre (notre analyse). L’interception de SMS et le SIM swap ne s’appliquent pas, puisqu’il n’y a pas de code. Le push-bombing a ouvert aux attaquants les VPN de Cisco et d’Uber en 2022 : ils ont envoyé des demandes d’approbation jusqu’à ce que quelqu’un appuie sur oui (Cisco Talos, Uber). Ici, il se heurte à une carte qui indique quel compte se connecte à quel service et depuis où, et à un limiteur de fréquence côté serveur (comment).
Ce qu’elle n’arrête pas. Elle n’arrête pas un relais en temps réel, où un faux portail VPN transmet la vraie connexion de la victime et où la victime approuve sa propre session sur la connexion de l’attaquant. La carte d’approbation affiche l’adresse IP d’origine, de sorte que le relais est visible pour un utilisateur qui regarde, mais la protection dépend du fait que l’utilisateur regarde, et c’est exactement ce type de dépendance que la définition du NIST exclut. L’approbation push n’est pas résistante au phishing au sens de la CISA, avec ou sans correspondance de numéros, et nous le disons sur notre page sécurité plutôt que de nous approprier le label.
À quoi ressemblaient réellement les intrusions
Il est utile de confronter les options à la manière dont les VPN et les accès à distance ont réellement été compromis, plutôt qu’à un modèle de menace.
| Incident | Comment l’attaquant est entré | Quelle option l’aurait arrêté |
|---|---|---|
| Colonial Pipeline, 2021 | Un ancien compte VPN avec un mot de passe et sans second facteur (témoignage) | N’importe laquelle des trois |
| Change Healthcare, 2024 | Un portail d’accès à distance Citrix sans MFA (témoignage) | N’importe laquelle des trois |
| FortiBleed, 2026 | Mots de passe FortiGate devinés par pulvérisation, divulgués ou cassés (FBI/USSS) | N’importe laquelle des trois |
| Cisco, Uber, 2022 | Mot de passe volé, puis demandes push jusqu’à ce que l’une soit acceptée | Passkeys, certificats ; une approbation lisible révèle la demande que personne n’a lancée |
| Scattered Spider, 2023 | Fausses pages SSO, SIM swaps, push-bombing contre des VPN et des webmails (CISA AA23-320A) | Passkeys et certificats, sans réserve ; l’approbation rend le relais visible |
| 0ktapus, 2022 | Fausses pages Okta relayant mots de passe et codes à usage unique en temps réel (Cloudflare) | Passkeys et certificats uniquement |
Trois des six incidents n’ont nécessité aucun contournement du MFA : il n’y avait pas de MFA. La lecture honnête du tableau est que l’écart entre « mot de passe seul » et « n’importe quel second facteur » reste là où se concentre l’essentiel des dégâts, et que l’écart entre une approbation lisible et une passkey compte surtout pour les comptes qu’un attaquant déterminé relaiera en temps réel.
Comment décider
- Comptes administrateur des pare-feu et des passerelles. Ce sont les comptes que FortiBleed a visés, et ceux que Winter SHIELD demande de traiter en priorité. Si l’interface de gestion prend en charge les clés FIDO2 ou une connexion SAML avec passkeys, utilisez-les. Si elle ne parle que RADIUS, une approbation sur le téléphone à la connexion administrateur vaut bien mieux qu’un mot de passe seul, et a fortiori qu’un mot de passe partagé.
- VPN utilisateur sur une passerelle capable de SAML avec navigateur externe. Placez les passkeys chez le fournisseur d’identité. C’est la réponse au sens strict, et elle est disponible dès aujourd’hui sur FortiGate, GlobalProtect et Cisco.
- VPN utilisateur sur du matériel RADIUS uniquement, comme MikroTik ou des concentrateurs anciens. Le choix se fait entre certificats et approbation sur le téléphone. Les certificats l’emportent sur la résistance au phishing si vous exploitez déjà une PKI. Sinon, avec une approbation lisible, un mot de passe seul ne suffit plus pour se connecter, les codes SMS et les demandes push aveugles sont remplacés dès aujourd’hui, et vous pourrez toujours faire passer plus tard aux passkeys les connexions qui passent par un navigateur.
- Quel que soit votre choix, regardez le chemin dans son ensemble. L’intrusion chez Cisco en 2022 a commencé par un compte Google personnel qui synchronisait un mot de passe professionnel ; le VPN n’était que la deuxième étape. Mettre du MFA sur le VPN sans en mettre sur le webmail ou le bureau à distance ne fait qu’envoyer l’attaquant frapper à la porte d’à côté.
Notakey couvre la troisième voie, et nous ne cachons pas sa place sur l’échelle de la CISA. Si votre passerelle parle RADIUS, le guide 2FA VPN vous mène à une première approbation sur le téléphone en un après-midi, et l’appliance s’exécute sur votre propre infrastructure ou dans notre cloud. Essayez la démo en ligne pour voir à quoi ressemble une approbation lisible sur votre propre téléphone, ou demandez une démo et nous intégrerons à un pilote vos connexions VPN, vos accès administrateur au pare-feu et vos connexions au bureau à distance.