Passkeys und NIS2: Ein Flag entscheidet, ob sie als MFA nach Artikel 21 zählen

Kurzantwort: Ein Passkey zählt als Multi-Faktor-Authentifizierung im Sinne von § 30 Abs. 2 Nr. 10 BSIG und Art. 21 Abs. 2 Buchst. j NIS2 dann, wenn bei jeder Anmeldung eine Nutzerverifikation per PIN oder Biometrie stattfindet und Ihr Anmeldesystem das prüft. Technisch erkennbar ist das an einem einzigen Bit in der Antwort des Authenticators, dem User-Verified-Flag (UV). Fehlt es, bleibt vom Passkey ein einzelner Faktor übrig: der Besitz eines privaten Schlüssels.

Das Gesetz selbst nennt keine Technologie. Die Regel stammt aus den beiden Regelwerken, die den Stand der Technik für Passkeys inzwischen ausbuchstabieren: der BSI TR-03188 und NIST SP 800-63B-4. Für die Prüfung zählt eine zweite Frage mindestens so viel: Ob Ihre Passkeys synchronisiert oder gerätegebunden sind, entscheidet, für welche Systeme sie nach deren Klassifizierung ausreichen. Dieser Leitfaden zeigt, was gilt, wo Passkey-Einführungen in der Praxis aufweichen und wie Sie die Entscheidung so dokumentieren, dass sie hält.

Was § 30 BSIG und die Durchführungsverordnung tatsächlich verlangen

Im Klartext: Verlangt sind „Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung“ – keine bestimmte Methode. Passkeys sind weder vorgeschrieben noch ausgeschlossen. Entscheidend ist, ob die gewählte Lösung zum Schutzbedarf des Systems passt und ob Sie das belegen können.

Der Wortlaut von § 30 Abs. 2 Nr. 10 BSIG deckt sich mit Art. 21 Abs. 2 Buchst. j der Richtlinie. Zwei weitere Sätze derselben Norm sind für Passkeys wichtiger, als sie aussehen: Nach Abs. 2 Satz 1 „sollen“ die Maßnahmen den Stand der Technik einhalten, und nach Abs. 1 Satz 3 ist die Einhaltung zu dokumentieren. Eine Passkey-Einführung, die funktioniert, aber nirgends begründet ist, erfüllt also nur die Hälfte.

Deutlich genauer wird es für die Einrichtungsarten, für die nach § 30 Abs. 3 BSIG die Durchführungsverordnung (EU) 2024/2690 Vorrang hat. Ihr Anhang regelt die Authentifizierung in den Nummern 11.6 und 11.7:

Fundstelle	Kern der Anforderung	Gilt für
§ 30 Abs. 2 Nr. 10 BSIG	Lösungen zur MFA oder kontinuierlichen Authentifizierung	alle besonders wichtigen und wichtigen Einrichtungen
§ 30 Abs. 2 Satz 1 BSIG	Maßnahmen „sollen“ den Stand der Technik einhalten	alle besonders wichtigen und wichtigen Einrichtungen
DVO-Anhang Nr. 11.7.1, 11.7.2	mehrere Faktoren „soweit angemessen“, Stärke passend zur Klassifizierung der Anlage	DVO-Einrichtungsarten: DNS, TLD, Cloud, Rechenzentren, CDN, MSP, MSSP, Online-Marktplätze, Suchmaschinen, soziale Netzwerke, Vertrauensdienste
DVO-Anhang Nr. 11.6.3	„soweit durchführbar“ modernste Authentifizierungsmethoden und eindeutige Authentifizierungsinformationen	DVO-Einrichtungsarten
DVO-Anhang Nr. 11.6.2 Buchst. c	Änderung der Authentifizierungsdaten zu Beginn, in vorab festgelegten Zeitabständen und bei Verdacht – ohne Angemessenheitsvorbehalt	DVO-Einrichtungsarten
DVO-Anhang Nr. 11.6.2 Buchst. f	gesonderte Authentifizierungsdaten für privilegierte Konten und Verwaltungskonten	DVO-Einrichtungsarten

Wo der Anhang eine Anforderung unter den Vorbehalt „soweit angemessen“ oder „soweit durchführbar“ stellt und Sie sie nicht anwenden, verlangt Art. 2 Abs. 2 Unterabs. 2 DVO, die Begründung „in verständlicher Weise“ zu dokumentieren. Für Unternehmen außerhalb dieser Einrichtungsarten ist der Anhang nicht unmittelbar verbindlich; als die genaueste amtliche Auslegung derselben Art.-21-Maßnahmen ist er nach unserer Einschätzung trotzdem der naheliegende Maßstab. Ob die Verordnung Sie direkt erfasst, klärt der Abschnitt dazu in unserem Beitrag Zero Trust und NIS2. Die allgemeinen Faktor- und Methodenfragen behandelt der Leitfaden MFA nach NIS2 und CIR 2024/2690; hier geht es nur um Passkeys.

Warum ein Passkey zwei Faktoren sein kann – oder nur einer

Im Klartext: Ein Passkey ist immer ein Besitzfaktor. Zum zweiten Faktor kommt es erst durch die lokale Entsperrung mit PIN, Fingerabdruck oder Gesichtsscan – und nur dann verlässlich, wenn Ihr Server darauf besteht.

Bei der Einrichtung erzeugt das Gerät ein Schlüsselpaar. Der private Schlüssel bleibt beim Nutzer, der öffentliche wird beim Dienst gespeichert; bei jeder Anmeldung signiert das Gerät eine zufällige Herausforderung des Servers. Das BSI beschreibt den Ablauf so, dass der Nutzer die Anmeldung „durch einen weiteren Sicherheitsfaktor, zum Beispiel einen Fingerabdruck“ bestätigt. Diese Prüfung findet ausschließlich auf dem Gerät statt. Der Server erfährt nur ihr Ergebnis: ob das UV-Flag gesetzt ist oder nicht.

Genau daran knüpfen beide Referenzwerke an. NIST SP 800-63B-4, Anhang B, schreibt US-Bundesbehörden vor, das UV-Flag in jeder Antwort zu kontrollieren: Ist der Nutzer nicht verifiziert, „SHALL“ der Authenticator als Ein-Faktor-Verfahren behandelt werden. Die BSI TR-03188 „Passkey Server“ (Version 1.0) sagt dasselbe in der Systematik der deutschen Vertrauensniveaus: Für „normal“ genügt ein einzelner Faktor, der Besitz des privaten Schlüssels. „Substantiell“ fordert Zwei-Faktor-Authentisierung, und Anforderung SBT-1 legt fest, dass die Relying Party „userVerification“ bei Registrierung und Anmeldung auf „required“ setzen und das UV-Flag prüfen MUSS.

Ob Ihr Passkey ein MFA-Verfahren ist, entscheidet sich also nicht beim Kauf, sondern in einer Konfigurationszeile Ihres Identity Providers oder Ihrer Anwendung. Selbst die ENISA-Umsetzungshilfe vom Juni 2025 führt „passkeys“, „MFA“ und „FIDO2 security keys“ in ihrer Liste zu Nr. 11.6.1 als getrennte Einträge. Ihre Einstufung „Strong“ vergibt sie nicht an ein Produkt, sondern an Eigenschaften: keine geteilten Geheimnisse, keine Anfälligkeit für Attacker-in-the-Middle, ein privater Schlüssel, der nach FIDO und W3C WebAuthn an eine Domain gebunden ist. Push-Verfahren und Authenticator-Apps stehen dort als „Medium“, SMS- und E-Mail-Codes als „Last resort“.

Diese Domainbindung ist der eigentliche Sicherheitsgewinn. Auf einer gefälschten Anmeldeseite wird der geheime Schlüssel laut BSI „niemals preisgegeben“, weil er für eine andere Domain gar nicht existiert. Die US-Cybersicherheitsbehörde CISA nennt FIDO/WebAuthn deshalb die einzige breit verfügbare phishing-resistente Authentifizierung. Passkeys schließen damit den Zugangsdaten-Diebstahl technisch aus, nicht aber Phishing insgesamt: Schadanhänge oder gefälschte Zahlungsanweisungen fängt kein Authenticator ab. Die Pflicht zur Sensibilisierung bleibt, wie unser Beitrag Phishing-Mails erkennen zeigt.

Synchronisiert oder gerätegebunden: die Frage nach dem Vertrauensniveau

Im Klartext: Synchronisierte Passkeys sind bequem und phishing-resistent, ihr Schlüssel liegt aber verschlüsselt bei einem Cloud-Anbieter. Für das höchste Schutzniveau lassen das BSI und NIST deshalb nur gerätegebundene Passkeys zu.

Die TR-03188 unterscheidet zwei Kategorien: Synced Passkeys, deren Schlüsselmaterial verschlüsselt in Cloud-Speicherdiensten liegt und zwischen Geräten synchronisiert wird, und Device Bound Passkeys, die an eine bestimmte Hardware gebunden bleiben. Beispiele für die erste Gruppe sind iCloud-Schlüsselbund und Google Password Manager, für die zweite FIDO2-Sicherheitsschlüssel. Die Unterschiede im Überblick:

Merkmal	Synchronisierter Passkey	Gerätegebundener Passkey
Privater Schlüssel	verschlüsselt beim Cloud-Anbieter, auf mehreren Geräten nutzbar	verlässt das Gerät bzw. den Sicherheitsschlüssel nicht
Attestation (Herkunftsnachweis)	laut Microsoft-Dokumentation nicht unterstützt	möglich, Modell über AAGUID prüfbar
BSI TR-03188	„hoch“ ausgeschlossen; „substantiell“ verlangt zusätzlich eine verifizierbare Attestation (SBT-6)	einzige zulässige Variante für „hoch“ (Sicherheitsziel SG-21)
NIST SP 800-63B-4	bis AAL2; Synchronisierung „violates the non-exportability requirements of AAL3“	AAL3 möglich, wenn die übrigen Anforderungen erfüllt sind
Geräteverlust	Wiederherstellung über das Cloud-Konto	Ersatzschlüssel nötig; das BSI rät zu einem zweiten FIDO2-Stick
Weitergabe an Dritte	bei manchen Anbietern vorgesehen (NIST)	nicht kopierbar

Das BSI begründet die Grenze mit einem eigenen Angreifermodell (AM-6): Credentials werden zu einem nicht vertrauenswürdigen Cloud-Dienst synchronisiert, die zugehörige Bedrohung heißt „Synchronised Credential Leak“. Ehrlicherweise gehört dazu der zweite Teil der TR-Aussage: Auch gerätegebundene Passkeys erreichen „hoch“ nur teilweise. Gegen ein kompromittiertes Endgerät (AM-4) und einen offengelegten TLS-Schlüssel des Servers (AM-5) könne ein Schutz „aktuell nicht sichergestellt werden“, weil die dafür vorgesehenen WebAuthn-Mechanismen in aktuellen Browsern nicht mehr implementiert sind.

Drei Folgen für NIS2-Einrichtungen ergeben sich aus der Tabelle. Erstens wird beim synchronisierten Passkey das Cloud-Konto des Anbieters Teil Ihrer Authentifizierungskette; NIST verlangt deshalb, dass der Zugang dazu selbst MFA-geschützt ist. Wir halten es für folgerichtig, den Sync-Anbieter in die Risikobetrachtung der Lieferkettensicherheit nach § 30 Abs. 2 Nr. 4 BSIG aufzunehmen – eine ausdrückliche Vorgabe dazu gibt es nicht. Zweitens kollidiert die Weitergabefunktion mit den „eindeutigen Authentifizierungsinformationen“ aus Nr. 11.6.3: Ein Dienst-Passkey, der in einem privaten Apple- oder Google-Konto mit Dritten geteilt werden kann, ist nicht mehr personengebunden. NIST nennt Gerätemanagement als wirksame Gegenmaßnahme im Unternehmen. Drittens ist die Frage, welcher Typ tatsächlich im Einsatz ist, ohne Attestation nicht beantwortbar. Microsoft schreibt für Entra ID, dass ohne erzwungene Attestation keine Eigenschaft eines Passkeys garantiert werden kann, „including if it’s synced or device-bound“ – und dass synchronisierte Passkeys bereits aktiv sind, solange keine Passkey-Profile eingerichtet und keine Attestation erzwungen ist. Die Aussage „unsere Administratoren nutzen nur Hardware-Schlüssel“ ist dann eine Behauptung, kein Nachweis.

Drei Stellen, an denen Passkey-Einführungen in der Prüfung aufweichen

Im Klartext: Ein Konto ist nur so stark wie sein schwächster zugelassener Anmelde- oder Wiederherstellungsweg. Die häufigsten Lücken liegen nicht beim Passkey, sondern daneben.

Befund	Warum er die MFA-Aussage entwertet	Abhilfe
Wiederherstellung per E-Mail-Link oder Passwort	Der Angreifer nimmt den Wiederherstellungsweg statt des Passkeys. Die TR-03188 untersagt für „substantiell“ ausdrücklich passwort- und E-Mail-basierte Wiederherstellung (SBT-4).	Zweiten Passkey oder Ersatzschlüssel registrieren lassen; Helpdesk-Wiederherstellung nur nach Identitätsprüfung. Auch ENISA fordert „secure fallback methods“.
Passwort plus SMS-Code bleibt als paralleler Anmeldeweg aktiv	Die effektive Stärke entspricht der schwächsten erlaubten Methode. SMS-Codes führt ENISA nur als „Last resort“.	Alternativmethoden je Systemklasse per Richtlinie sperren; verbleibende Ausnahmen nach Art. 2 Abs. 2 DVO begründen.
Nutzerverifikation nicht erzwungen	Ohne UV-Flag ist der Passkey nach NIST und TR-03188 ein einzelner Faktor.	„userVerification: required“ setzen, UV-Flag serverseitig prüfen, Anmelde-Logs mit Methode aufbewahren.

Ein vierter Punkt betrifft nur DVO-Einrichtungen, ist dafür aber unbequem: Nr. 11.6.2 Buchst. c verlangt die Änderung der Authentifizierungsdaten „in vorab festgelegten Zeitabständen“, und anders als Nr. 11.7.1 steht diese Pflicht nicht unter einem Angemessenheitsvorbehalt. Einen Passkey „ändert“ man nicht wie ein Passwort. Die naheliegende Umsetzung ist, nach unserer Lesart, eine festgelegte Neuregistrierung – etwa beim Gerätetausch und spätestens nach einem definierten Zeitraum – plus sofortiger Widerruf bei Verlust, Verdacht oder Austritt. Behördlich bestätigt ist diese Lesart nicht. Die ENISA-Hilfe selbst formuliert für Passwörter pragmatisch, Wechsel seien „as necessary“ zu erzwingen, etwa nach einem Sicherheitsvorfall. Wichtig ist, dass ein Intervall schriftlich festgelegt ist; eine Lücke an dieser Stelle fällt bei jeder Dokumentenprüfung auf.

Welcher Passkey für welches System

Im Klartext: Nicht jedes Konto braucht einen Hardware-Schlüssel. Die Klassifizierung der Anlage bestimmt die Variante – so verlangen es Nr. 11.6.2 Buchst. a und Nr. 11.7.2.

Zugriff	Passkey-Variante	Begründung
Administratoren, Systemverwaltung, Identity Provider	gerätegebunden, Attestation erzwungen, gesonderte Admin-Kennung	Nr. 11.6.2 Buchst. f; TR-03188 „hoch“ (SG-21); Microsofts Beispielprofil für IT-Admins und Führungskräfte
E-Mail, VPN, Remote Desktop	Passkey mit erzwungener UV; synchronisiert nur auf verwalteten Geräten	ENISA zu Nr. 11.7.2: MFA auf allen aus dem Internet erreichbaren Systemen
Interne Anwendungen mit normalem Schutzbedarf	synchronisiert oder gerätegebunden, UV erzwungen	NIST: synchronisierte Passkeys bis AAL2
Externe Dienstleister mit Fernzugriff	personengebundener Passkey, keine Sammelkonten	Nr. 11.6.3: eindeutige Authentifizierungsinformationen

Für die Geschäftsleitung ist die Kernentscheidung, welche Systemklassen gerätegebundene Schlüssel erhalten. Das ist eine Budgetfrage: pro berechtigter Person mindestens zwei Sicherheitsschlüssel, weil das BSI einen Ersatz-Stick empfiehlt. Für CISO und IT-Leitung liegt die Arbeit in der Konfiguration – UV erzwingen, Attestation und erlaubte Modelle festlegen, Altverfahren abschalten. Kleinere Unternehmen ohne eigenes Identity-Team fahren am besten, wenn sie mit Administratorkonten und E-Mail beginnen: Dort wirkt die Phishing-Resistenz am stärksten, und die Zahl der Schlüssel bleibt überschaubar.

Umsetzung in fünf Schritten

1. Klassifizierung prüfen [Aufwand: Mittel]. Ohne Anlagenklassifizierung nach DVO-Anhang Nr. 12.1 lässt sich keine Authentifizierungsstärke begründen – sie ist der Bezugspunkt von Nr. 11.6.2 Buchst. a und Nr. 11.7.2.
2. Passkey-Typ je Klasse festlegen [Mittel]. Matrix wie oben in die Authentifizierungsrichtlinie übernehmen, inklusive Attestation-Pflicht und zugelassener Modelle für privilegierte Konten. Welche Rollen welche Systeme erreichen, steht bereits in Ihrem Berechtigungskonzept.
3. UV erzwingen und Altverfahren sperren [Mittel]. „userVerification“ auf „required“; Passwort-plus-SMS je Klasse deaktivieren oder als begründete Ausnahme dokumentieren.
4. Wiederherstellung neu bauen [Hoch]. Ersatz-Passkey oder Zweitschlüssel bei der Registrierung, Identitätsprüfung im Helpdesk, keine E-Mail-Links.
5. Nachweise ablegen [Niedrig]. Richtlinie, Konfigurationsexporte, Anmelde-Logs mit Methode, Ausnahmebegründungen und das Ergebnis der Überprüfung „in geplanten Zeitabständen“ nach Nr. 11.6.4.

Der letzte Schritt ist kein Formalismus. § 65 Abs. 2 BSIG führt die nicht ergriffene Maßnahme (Nr. 2) und die fehlende Dokumentation (Nr. 3) als getrennte Ordnungswidrigkeiten; beide können mit bis zu 10 Mio. Euro bei besonders wichtigen und 7 Mio. Euro bei wichtigen Einrichtungen geahndet werden, bei mehr als 500 Mio. Euro Gesamtumsatz mit bis zu 2 bzw. 1,4 Prozent des Umsatzes (Abs. 5 bis 7). Wie sich die Rahmen zusammensetzen, erklärt unsere Übersicht zur Bußgeldstaffel.

Häufige Fragen

Erfüllen Passkeys die MFA-Pflicht nach NIS2?
Ja, wenn bei jeder Anmeldung eine Nutzerverifikation per PIN oder Biometrie erzwungen und serverseitig geprüft wird. Ohne sie gelten Passkeys nach NIST SP 800-63B-4 und BSI TR-03188 als ein einzelner Faktor.

Reichen synchronisierte Passkeys aus iCloud oder Google?
Für Systeme mit normalem Schutzbedarf in der Regel ja – NIST lässt sie bis AAL2 zu –, sofern UV erzwungen und die Wiederherstellung abgesichert ist. Für Administratorkonten und hoch eingestufte Systeme lassen BSI und NIST nur gerätegebundene Passkeys zu.

Ist ein Passkey dasselbe wie ein FIDO2-Sicherheitsschlüssel?
Nein. Beide beruhen auf FIDO2 und WebAuthn. Ein Sicherheitsschlüssel speichert gerätegebundene Passkeys, die sich nicht kopieren lassen; ein Passkey im Passwortmanager eines Smartphones ist häufig synchronisiert.

Müssen wir Passwörter vollständig abschaffen?
Nein. Das Gesetz verlangt MFA, nicht Passwortlosigkeit. Bleiben Passwörter als zweiter Anmeldeweg bestehen, muss die Richtlinie aber festlegen, für welche Systeme sie noch zugelassen sind – sonst bestimmt der schwächste Weg das Schutzniveau.

Ist die BSI TR-03188 für NIS2-Einrichtungen verbindlich?
Nein. Sie richtet sich an Betreiber von Webseiten und Online-Diensten und enthält Empfehlungen. Das BSI erklärt aber ausdrücklich das Ziel, mit ihr „einen Stand der Technik zu definieren“ – und § 30 Abs. 2 BSIG knüpft an den Stand der Technik an.

Dieser Artikel bietet ausschließlich allgemeine Informationen und stellt keine Rechts- oder Regulierungsberatung dar. Die Anforderungen können je nach Rechtsraum und Unternehmensart variieren. Wenden Sie sich für eine auf Ihre Situation zugeschnittene Beratung an eine qualifizierte Rechts- oder Compliance-Fachkraft.

Quellen

• § 30 BSIG – Risikomanagementmaßnahmen besonders wichtiger und wichtiger Einrichtungen, gesetze-im-internet.de
• § 65 BSIG – Bußgeldvorschriften, gesetze-im-internet.de
• Durchführungsverordnung (EU) 2024/2690, amtliche deutsche Fassung, Art. 2 und Anhang Nr. 11.6–11.7 – EUR-Lex
• Richtlinie (EU) 2022/2555 (NIS-2-Richtlinie), amtliche deutsche Fassung, Art. 21 – EUR-Lex
• BSI TR-03188 Passkey Server – Sicherheits- und Handlungsempfehlung, Version 1.0 (PDF), Bundesamt für Sicherheit in der Informationstechnik
• Technische Richtlinie BSI TR-03188 Passkey Server – Übersichtsseite, BSI
• Passkeys – anmelden ohne Passwort, BSI (Verbraucherinformation)
• ENISA: Technical implementation guidance on cybersecurity risk management measures, Version 1.0, Juni 2025 (PDF)
• NIST SP 800-63B-4, Appendix B: Syncable Authenticators
• CISA: Implementing Phishing-Resistant MFA, Fact Sheet, Oktober 2022 (PDF)
• Microsoft Learn: How to enable passkeys (FIDO2) in Microsoft Entra ID