In January 2026 the FBI launched Operation Winter SHIELD, and its first recommended action reads: deploy phishing-resistant methods, “FIDO2 compliant security keys or device-bound passkeys”, for authentication, remote access and critical systems (FBI). ENISA’s NIS2 implementation guidance says the same for VPNs and administration systems: “wherever possible, use phishing-resistant MFA” (ENISA, June 2025). Microsoft’s own documentation now describes SMS and authenticator-app MFA as “prone to remote phishing attacks” (Microsoft).
If your remote access is a VPN concentrator that checks logins over RADIUS, you have probably noticed the problem: there is no place to plug a passkey in. This post explains why that is, what the three realistic options are, and what each of them does not protect against.
What a passkey actually does
A passkey is a WebAuthn credential: a key pair generated on the user’s device and registered to one website. When the user signs in, the browser asks the device to sign a challenge from the site, and the signature covers the origin of the page the browser is actually showing. The site checks that the origin in the signature is its own. A fake login page on another domain gets a signature for the wrong origin, and the real site rejects it. The user never has to notice anything, because the browser does the checking (W3C WebAuthn).
That is what the standards mean by phishing-resistant. The current NIST definition is “the ability of the authentication protocol to prevent the disclosure of authentication secrets … without relying on the vigilance of the claimant”, and it is explicit about what fails the test: passwords, one-time codes, push approvals and anything the user has to type over are “not phishing-resistant” (NIST SP 800-63B-4, 2025). CISA ranks the methods the same way: FIDO/WebAuthn and PKI at the top, then one-time codes and push with number matching, then push without it, then SMS (CISA).
Two things about how a passkey meets that definition matter for a VPN. The protection comes from a browser or platform client that knows which origin it is talking to, and from a challenge and signature that travel inside the login protocol.
Why a RADIUS VPN has nowhere to put one
RADIUS, the protocol most VPN gateways use to ask an authentication server “is this login good?”, was designed for dial-up modems. An Access-Request carries a username and a password hidden with an MD5 keystream, or a CHAP response. If the server wants more, it sends an Access-Challenge whose text the gateway “MAY display” to the user, who then types an answer that goes back in the password field (RFC 2865). That is the whole vocabulary: strings a human typed. There is no field for a signed WebAuthn assertion, no origin to sign over because a VPN client has no page, and no user agent to enforce it.
So on their own, none of these can do passkeys for VPN login:
- MikroTik RouterOS: RADIUS client only, no SAML or OIDC (MikroTik docs).
- WireGuard: authenticates peers by static public keys and has no user login at all, so none of the options below apply to it; the problem there is key distribution (wireguard.com).
- OpenVPN Access Server: with RADIUS, LDAP or PAM the second factor is a time-based code, and only its SAML mode can hand the login to a browser (OpenVPN docs).
FortiGate, Palo Alto GlobalProtect and Cisco Secure Client do offer passkeys on VPN login, and all three do it the same way: the VPN client opens a browser, the browser signs in to a SAML identity provider, the passkey is used there, and the IdP tells the gateway that the user is good. FortiClient does this with the “external browser as user agent” option, Cisco ASA 9.17 and later launch the system browser for exactly this reason, and GlobalProtect embeds a browser view in the client (Fortinet, Duo for Cisco ASA, Palo Alto). Microsoft’s own RADIUS path says it plainly: the NPS extension cannot do number matching, and MS-CHAPv2 cannot carry a time-based code (Microsoft).
The passkey never touches RADIUS. The browser does the work, and the gateway trusts the IdP’s word.
The three realistic options
1. Put a SAML identity provider in front of the VPN and use passkeys there
This route gives phishing resistance in the strict sense for user VPN logins, and if your gateway and clients support it, it is the right answer for the browser-shaped part of the problem.
What it costs: an identity provider that supports passkeys and the licence that comes with it, client versions new enough for external-browser SAML, a rollout of passkeys to every VPN user, and a recovery process for lost devices. What it leaves uncovered: every system that cannot do SAML, including the firewall’s own administrator login on many devices, MikroTik, WireGuard, and anything that logs in without a browser.
2. Certificates
Client-certificate authentication (EAP-TLS on the VPN, or machine certificates on the device) is the other method NIST counts as phishing-resistant, through what it calls channel binding (NIST). There is nothing for a user to type and nothing to relay.
What it costs: a certificate authority, enrolment for every device, renewal and revocation that actually work, and someone who owns all of that. CISA describes PKI-based MFA as requiring “highly mature identity management practices” and notes it is not widely supported (CISA). And a machine certificate proves which device connected, not who was sitting at it.
3. Keep RADIUS and add a phone approval that shows the login
The third route keeps the gateway and the RADIUS server exactly as they are and adds a second step in the RADIUS path: your RADIUS server checks the password first, and only after it accepts the login does the user get an approval request on their phone. The request names the service, the account and the source IP address, and the login succeeds only if they approve. This is what the Notakey auth-proxy does; the setup guide walks through it for FreeRADIUS, NPS and MikroTik’s User Manager.
It is the cheapest route to deploy, because nothing on the gateway changes except where it sends RADIUS, and it works on any gateway that checks logins over RADIUS, including the ones that will never speak SAML. It is also the route we have to be most careful describing.
What it stops. A leaked, sprayed or cracked password is no longer a login. FortiBleed, the 2026 campaign against FortiGate VPNs, needed nothing more than that (our analysis). SMS interception and SIM swaps do not apply, because there is no code. Push-bombing got attackers into Cisco’s and Uber’s VPNs in 2022: they sent approval prompts until someone tapped yes (Cisco Talos, Uber). Here it runs into a card that shows which account is logging in to which service from where, and into a rate limiter on the server (how).
What it does not stop. It does not stop a real-time relay, where a fake VPN portal forwards the victim’s real login and the victim approves their own session on the attacker’s connection. The approval card shows the source IP address, so the relay is visible to a user who looks, but the protection depends on the user looking, and NIST’s definition rules out exactly that kind of reliance. Push approval is not phishing-resistant in the CISA sense, with or without number matching, and we say so on our security page rather than borrow the label.
What the breaches actually looked like
It helps to check the options against the way VPN and remote access were actually broken into, rather than against a threat model.
| Incident | How the attacker got in | Which option would have stopped it |
|---|---|---|
| Colonial Pipeline, 2021 | A legacy VPN account with a password and no second factor (testimony) | Any of the three |
| Change Healthcare, 2024 | A Citrix remote-access portal with no MFA (testimony) | Any of the three |
| FortiBleed, 2026 | Sprayed, leaked and cracked FortiGate passwords (FBI/USSS) | Any of the three |
| Cisco, Uber, 2022 | Stolen password, then push prompts until one was accepted | Passkeys, certificates; a readable approval shows the prompt nobody started |
| Scattered Spider, 2023 | Fake SSO pages, SIM swaps, push-bombing against VPNs and webmail (CISA AA23-320A) | Passkeys and certificates outright; approval shows the relay |
| 0ktapus, 2022 | Fake Okta pages relaying passwords and one-time codes in real time (Cloudflare) | Passkeys and certificates only |
Three of the six needed no MFA bypass at all: there was no MFA. The honest reading of the table is that the gap between “password only” and “any second factor” is still where most of the damage is, and that the gap between a readable approval and a passkey matters most for the accounts a determined attacker will relay in real time.
How to decide
- Firewall and gateway administrator accounts. These are the accounts FortiBleed went after, and the ones Winter SHIELD says to prioritise. If the management interface supports FIDO2 keys or a SAML login with passkeys, use them. If it only speaks RADIUS, a phone approval on the admin login is far better than a password alone, and especially better than a shared one.
- User VPN on a gateway that can do SAML with an external browser. Put passkeys at the identity provider. This is the strict answer, and it is available today on FortiGate, GlobalProtect and Cisco.
- User VPN on RADIUS-only gear such as MikroTik or legacy concentrators. The choice is certificates or a phone approval. Certificates win on phishing resistance if you already run a PKI. If you do not, a readable approval means a password alone is no longer a login and replaces SMS codes and blind push prompts today, and you can still move the browser-shaped logins to passkeys later.
- Whatever you pick, look at the whole path. The 2022 Cisco intrusion started with a personal Google account syncing a work password; the VPN was the second step. MFA on the VPN that is missing on webmail or remote desktop just moves the attacker next door.
Notakey covers the third route, and we are clear about where it sits on the CISA ladder. If your gateway speaks RADIUS, the VPN 2FA guide gets you to a first phone approval in an afternoon, and the appliance runs on your own infrastructure or in our cloud. Try the live demo to see what a readable approval looks like on your own phone, or request a demo and we will map your VPN, firewall admin and remote-desktop logins to a pilot.