Warum Passkeys an einem RADIUS-VPN nicht funktionieren – und was stattdessen hilft

Im Januar 2026 startete das FBI die Operation Winter SHIELD. Die erste empfohlene Maßnahme lautet: phishing-resistente Verfahren einführen, „FIDO2-konforme Sicherheitsschlüssel oder gerätegebundene Passkeys“ („FIDO2 compliant security keys or device-bound passkeys“), für die Authentifizierung, den Fernzugriff und kritische Systeme (FBI). Die NIS2-Umsetzungsleitlinien der ENISA sagen dasselbe für VPNs und Administrationssysteme: „Wo immer möglich, phishing-resistente MFA einsetzen“ („wherever possible, use phishing-resistant MFA“) (ENISA, Juni 2025). Microsofts eigene Dokumentation beschreibt SMS- und Authenticator-App-MFA inzwischen als „anfällig für Remote-Phishing-Angriffe“ („prone to remote phishing attacks“) (Microsoft).

Wenn Ihr Fernzugriff über einen VPN-Konzentrator läuft, der Anmeldungen per RADIUS prüft, ist Ihnen das Problem wahrscheinlich schon aufgefallen: Es gibt keine Stelle, an der sich ein Passkey anschließen ließe. Dieser Beitrag erklärt, woran das liegt, welche drei realistischen Optionen es gibt und welche Lücken jede davon lässt.

Was ein Passkey tatsächlich leistet

Ein Passkey ist ein WebAuthn-Credential: ein Schlüsselpaar, das auf dem Gerät des Benutzers erzeugt und bei genau einer Website registriert wird. Meldet sich der Benutzer an, bittet der Browser das Gerät, eine Challenge der Website zu signieren, und die Signatur deckt den Origin der Seite ab, die der Browser tatsächlich anzeigt. Die Website prüft, ob der Origin in der Signatur ihr eigener ist. Eine gefälschte Anmeldeseite auf einer anderen Domain erhält eine Signatur für den falschen Origin, und die echte Website lehnt sie ab. Der Benutzer muss nichts davon bemerken, denn die Prüfung übernimmt der Browser (W3C WebAuthn).

Genau das meinen die Standards mit phishing-resistent. Die aktuelle NIST-Definition lautet: „die Fähigkeit des Authentifizierungsprotokolls, die Offenlegung von Authentifizierungsgeheimnissen … zu verhindern, ohne auf die Wachsamkeit der sich authentifizierenden Person angewiesen zu sein“ („the ability of the authentication protocol to prevent the disclosure of authentication secrets … without relying on the vigilance of the claimant“). Und sie benennt ausdrücklich, was den Test nicht besteht: Passwörter, Einmalcodes, Push-Bestätigungen und alles, was der Benutzer abtippen muss, sind „nicht phishing-resistent“ („not phishing-resistant“) (NIST SP 800-63B-4, 2025). Die CISA ordnet die Verfahren genauso: FIDO/WebAuthn und PKI ganz oben, dann Einmalcodes und Push mit Number Matching, dann Push ohne Number Matching, dann SMS (CISA).

Zwei Aspekte daran, wie ein Passkey diese Definition erfüllt, sind für ein VPN entscheidend. Der Schutz kommt von einem Browser oder Plattform-Client, der weiß, mit welchem Origin er spricht, und von einer Challenge und einer Signatur, die innerhalb des Anmeldeprotokolls übertragen werden.

Warum ein RADIUS-VPN keinen Platz dafür hat

RADIUS, das Protokoll, mit dem die meisten VPN-Gateways bei einem Authentifizierungsserver nachfragen, ob eine Anmeldung in Ordnung ist, wurde für Einwahlmodems entworfen. Ein Access-Request transportiert einen Benutzernamen und ein Passwort, verborgen unter einem MD5-Keystream, oder eine CHAP-Antwort. Will der Server mehr, schickt er eine Access-Challenge, deren Text das Gateway dem Benutzer anzeigen „kann“ („MAY display“); der Benutzer tippt dann eine Antwort ein, die im Passwortfeld zurückgeht (RFC 2865). Das ist das gesamte Vokabular: Zeichenketten, die ein Mensch eingetippt hat. Es gibt kein Feld für eine signierte WebAuthn-Assertion, keinen Origin, über den signiert werden könnte, weil ein VPN-Client keine Seite hat, und keinen User Agent, der das durchsetzen würde.

Für sich genommen kann daher keines dieser Systeme Passkeys für die VPN-Anmeldung:

• MikroTik RouterOS: nur RADIUS-Client, kein SAML und kein OIDC (MikroTik-Dokumentation).
• WireGuard: authentifiziert Peers über statische öffentliche Schlüssel und kennt gar keine Benutzeranmeldung; keine der Optionen unten ist darauf anwendbar, das Problem liegt dort in der Schlüsselverteilung (wireguard.com).
• OpenVPN Access Server: mit RADIUS, LDAP oder PAM ist der zweite Faktor ein zeitbasierter Code; nur der SAML-Modus kann die Anmeldung an einen Browser übergeben (OpenVPN-Dokumentation).

FortiGate, Palo Alto GlobalProtect und Cisco Secure Client bieten Passkeys bei der VPN-Anmeldung durchaus an, und alle drei lösen es auf dieselbe Weise: Der VPN-Client öffnet einen Browser, der Browser meldet sich bei einem SAML-Identity-Provider an, dort kommt der Passkey zum Einsatz, und der IdP teilt dem Gateway mit, dass der Benutzer in Ordnung ist. FortiClient tut das mit der Option „external browser as user agent“, Cisco ASA ab Version 9.17 startet genau aus diesem Grund den Systembrowser, und GlobalProtect bettet eine Browseransicht in den Client ein (Fortinet, Duo für Cisco ASA, Palo Alto). Für den eigenen RADIUS-Weg sagt Microsoft es unverblümt: Die NPS-Erweiterung kann kein Number Matching, und MS-CHAPv2 kann keinen zeitbasierten Code transportieren (Microsoft).

Der Passkey berührt RADIUS nie. Der Browser erledigt die Arbeit, und das Gateway verlässt sich auf das Wort des IdP.

Die drei realistischen Optionen

1. Einen SAML-Identity-Provider vor das VPN setzen und dort Passkeys verwenden

Dieser Weg liefert Phishing-Resistenz im strengen Sinn für die VPN-Anmeldungen der Benutzer, und wenn Ihr Gateway und Ihre Clients ihn unterstützen, ist er die richtige Antwort für den browserbasierten Teil des Problems.

Was er kostet: einen Identity-Provider, der Passkeys unterstützt, samt der zugehörigen Lizenz; Client-Versionen, die neu genug für SAML über einen externen Browser sind; die Einführung von Passkeys bei jedem VPN-Benutzer; und einen Wiederherstellungsprozess für verlorene Geräte. Was er offenlässt: jedes System, das kein SAML kann, darunter auf vielen Geräten die Administratoranmeldung der Firewall selbst, MikroTik, WireGuard und alles, was sich ohne Browser anmeldet.

2. Zertifikate

Die Authentifizierung mit Client-Zertifikaten (EAP-TLS am VPN oder Maschinenzertifikate auf dem Gerät) ist das zweite Verfahren, das NIST als phishing-resistent einstuft, über das, was dort Channel Binding heißt (NIST). Der Benutzer muss nichts eintippen, und es gibt nichts, was sich weiterleiten ließe.

Was es kostet: eine Zertifizierungsstelle, die Registrierung jedes Geräts, Verlängerung und Sperrung, die tatsächlich funktionieren, und jemanden, der das alles verantwortet. Die CISA beschreibt PKI-basierte MFA als Verfahren, das „sehr ausgereifte Praktiken im Identitätsmanagement“ („highly mature identity management practices“) voraussetzt, und merkt an, dass es nicht breit unterstützt wird (CISA). Und ein Maschinenzertifikat beweist, welches Gerät sich verbunden hat, nicht, wer davor saß.

3. RADIUS behalten und eine Bestätigung am Telefon ergänzen, die die Anmeldung anzeigt

Der dritte Weg lässt Gateway und RADIUS-Server genau so, wie sie sind, und fügt im RADIUS-Pfad einen zweiten Schritt hinzu: Ihr RADIUS-Server prüft zuerst das Passwort, und erst wenn er die Anmeldung akzeptiert, erhält der Benutzer eine Bestätigungsanfrage auf seinem Telefon. Die Anfrage nennt den Dienst, das Konto und die Quell-IP-Adresse, und die Anmeldung gelingt nur, wenn er bestätigt. Genau das tut der Notakey Auth-Proxy; die Einrichtungsanleitung führt für FreeRADIUS, NPS und den User Manager von MikroTik durch das Setup.

Es ist der am günstigsten einzuführende Weg, weil sich am Gateway nichts ändert außer der Adresse, an die es RADIUS schickt, und er funktioniert auf jedem Gateway, das Anmeldungen per RADIUS prüft, auch auf denen, die nie SAML sprechen werden. Es ist zugleich der Weg, den wir am sorgfältigsten beschreiben müssen.

Was er stoppt. Ein geleaktes, per Spraying erratenes oder geknacktes Passwort reicht für eine Anmeldung nicht mehr aus. FortiBleed, die Kampagne gegen FortiGate-VPNs von 2026, brauchte nicht mehr als das (unsere Analyse). Abgefangene SMS und SIM-Swaps greifen nicht, weil es keinen Code gibt. Push-Bombing brachte Angreifer 2022 in die VPNs von Cisco und Uber: Sie schickten Bestätigungsaufforderungen, bis jemand auf Ja tippte (Cisco Talos, Uber). Hier stößt es auf eine Karte, die zeigt, welches Konto sich bei welchem Dienst von wo anmeldet, und auf eine Ratenbegrenzung auf dem Server (wie das funktioniert).

Was er nicht stoppt. Er stoppt kein Echtzeit-Relay, bei dem ein gefälschtes VPN-Portal die echte Anmeldung des Opfers weiterleitet und das Opfer seine eigene Sitzung auf der Verbindung des Angreifers bestätigt. Die Bestätigungskarte zeigt die Quell-IP-Adresse, das Relay ist also für einen Benutzer sichtbar, der hinsieht – aber der Schutz hängt davon ab, dass der Benutzer hinsieht, und genau diese Art von Abhängigkeit schließt die NIST-Definition aus. Push-Bestätigung ist im Sinne der CISA nicht phishing-resistent, mit oder ohne Number Matching, und das sagen wir auf unserer Sicherheitsseite offen, statt uns mit dem Etikett zu schmücken.

Wie die Einbrüche tatsächlich aussahen

Es hilft, die Optionen daran zu messen, wie VPN und Fernzugriff tatsächlich kompromittiert wurden, statt an einem Bedrohungsmodell.

Drei der sechs brauchten gar keine MFA-Umgehung: Es gab keine MFA. Die ehrliche Lesart der Tabelle ist, dass der größte Schaden nach wie vor in der Lücke zwischen „nur Passwort“ und „irgendein zweiter Faktor“ entsteht – und dass die Lücke zwischen einer lesbaren Bestätigung und einem Passkey vor allem bei den Konten zählt, die ein entschlossener Angreifer in Echtzeit weiterleiten wird.

Wie Sie entscheiden

• Administratorkonten von Firewall und Gateway. Das sind die Konten, auf die FortiBleed zielte, und die, die Winter SHIELD an die erste Stelle setzt. Unterstützt die Management-Oberfläche FIDO2-Schlüssel oder eine SAML-Anmeldung mit Passkeys, nutzen Sie sie. Spricht sie nur RADIUS, ist eine Bestätigung am Telefon für die Admin-Anmeldung weit besser als ein Passwort allein – und erst recht als ein geteiltes.
• Benutzer-VPN auf einem Gateway, das SAML mit externem Browser kann. Setzen Sie die Passkeys beim Identity-Provider ein. Das ist die strenge Antwort, und sie ist heute auf FortiGate, GlobalProtect und Cisco verfügbar.
• Benutzer-VPN auf Geräten, die nur RADIUS sprechen, etwa MikroTik oder ältere Konzentratoren. Zur Wahl stehen Zertifikate oder eine Bestätigung am Telefon. Zertifikate gewinnen bei der Phishing-Resistenz, wenn Sie bereits eine PKI betreiben. Wenn nicht, sorgt eine lesbare Bestätigung schon heute dafür, dass ein Passwort allein für eine Anmeldung nicht mehr ausreicht, und ersetzt SMS-Codes und blinde Push-Aufforderungen; die browserbasierten Anmeldungen können Sie später immer noch auf Passkeys umstellen.
• Was immer Sie wählen: Betrachten Sie den gesamten Pfad. Der Cisco-Einbruch von 2022 begann mit einem privaten Google-Konto, das ein Arbeitspasswort synchronisierte; das VPN war erst der zweite Schritt. MFA am VPN, die bei Webmail oder Remotedesktop fehlt, schiebt den Angreifer nur eine Tür weiter.

Notakey deckt den dritten Weg ab, und wir sagen klar, wo er auf der CISA-Leiter steht. Spricht Ihr Gateway RADIUS, bringt Sie die Anleitung zu VPN-2FA an einem Nachmittag zur ersten Bestätigung am Telefon, und die Appliance läuft in Ihrer eigenen Infrastruktur oder in unserer Cloud. Testen Sie die Live-Demo, um zu sehen, wie eine lesbare Bestätigung auf Ihrem eigenen Telefon aussieht, oder fordern Sie eine Demo an, und wir bilden Ihre VPN-, Firewall-Admin- und Remotedesktop-Anmeldungen in einem Pilotprojekt ab.