MFA-Pflicht unter NIS 2 Art. 21(2)(j)
NIS 2 macht Multi-Faktor-Authentifizierung zu einer eigenen Pflicht. Art. 21(2)(j) ist der Rechtsanker, CIR (EU) 2024/2690 §11.7 sagt wo und wie stark, und §30 Abs. 2 Nr. 10 BSIG bringt die Regel ins deutsche Recht.
Die Kurzfassung
MFA ist nicht optional und nicht nur Best Practice. Art. 21(2)(j) führt sie als eine der zehn Cybersicherheitsmaßnahmen, die jede wesentliche und wichtige Einrichtung umsetzen muss. Derselbe Buchstabe deckt zusätzlich gesicherte Sprach-, Video- und Textkommunikation ab und, wo erforderlich, gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung.
CIR (EU) 2024/2690 §11.7 füllt das im Detail. Nutzer müssen über mehrere Authentifizierungsfaktoren oder über kontinuierliche Authentifizierung authentifiziert werden, soweit angemessen, im Einklang mit der Klassifizierung der Anlage bzw. des Werts, auf den zugegriffen wird. Die Stärke der Authentifizierung muss zu dieser Klassifizierung passen. Kronjuwelen verlangen stärkere Authentifizierung als ein Kantinen-Speiseplan.
CIR §11.3.2 zieht zusätzlich eine harte Untergrenze für privilegierte Konten. Starke Verfahren zur Identifizierung, Authentifizierung (Multi-Faktor-Authentifizierung ist das genannte Beispiel) und Genehmigung müssen für privilegierte Konten und Systemverwaltungskonten standardmäßig eingerichtet sein. §30 Abs. 2 Nr. 10 BSIG übernimmt die Pflicht fast wortgleich ins deutsche Recht.
Art. 21(2)(j) NIS-2-Richtlinie (2022/2555)
Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung.
Buchstabe (j) auf der Liste der zehn Cybersicherheitsmaßnahmen. Er tut zwei Dinge gleichzeitig: er benennt MFA (oder kontinuierliche Authentifizierung) als Standard für Zugriffskontrolle und zieht gesicherte interne Sprach-, Video-, Text- und Notfallkommunikation in dieselbe Pflicht.
CIR (EU) 2024/2690, Anhang §11.7 und §11.3
Die betreffenden Einrichtungen stellen sicher, dass die Nutzer – soweit angemessen – durch mehrere Authentifizierungsfaktoren oder kontinuierliche Authentifizierungsmechanismen für den Zugang zu den Netz- und Informationssystemen der betreffenden Einrichtungen im Einklang mit der Klassifizierung der Anlage bzw. des Werts, auf die zugegriffen werden soll, authentifiziert werden.
§11 ist das Zugriffskontroll-Kapitel der CIR und deckt Art. 21(2) Buchstaben (i) und (j) gemeinsam ab. §11.7 ist der MFA-spezifische Unterabschnitt. §11.3.2(a) geht für privilegierte und Verwaltungskonten weiter: starke Identifizierung, Authentifizierung (MFA als Beispiel) und Genehmigung sind verpflichtend. Da die CIR eine Verordnung ist, gilt sie für die im Anhang genannten Sektoren unmittelbar.
§30 Abs. 2 Nr. 10 BSIG (Deutschland)
Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung.
Deutschland übernimmt den EU-Text fast wortgleich. Operativ verweist die deutsche Praxis auf den IT-Grundschutz-Baustein ORP.4 (Identitäts- und Berechtigungsmanagement), den BSI-Referenzkatalog für sauber umgesetzte Authentifizierung.
MFA passend zur Anlagenklassifizierung
Nutzer authentifizieren sich mit mehreren Faktoren oder kontinuierlich für den Zugang zu Netz- und Informationssystemen, abgestimmt auf die Klassifizierung der Anlage bzw. des Werts. Die implizite Voraussetzung: die Anlagen sind klassifiziert. Ohne Klassifizierung lässt sich die Regel nicht erfüllen.
Privilegierte Konten: MFA als Standard
Für privilegierte Konten und Systemverwaltungskonten müssen starke Verfahren zur Identifizierung, Authentifizierung und Genehmigung eingerichtet sein. Die CIR nennt Multi-Faktor-Authentifizierung als Beispiel. Hier hängt MFA nicht mehr an der Klassifizierung, sondern ist die Default-Erwartung.
Authentifizierungsstärke folgt der Klassifizierung
Die Stärke der Authentifizierung muss für die Klassifizierung des Werts angemessen sein, auf den zugegriffen wird. Das ist der zweite Test. MFA ist nicht gleich MFA. SMS, App-TOTP, Push-Bestätigung, FIDO2-Hardwareschlüssel und zertifikatsbasierte Authentifizierung liegen sehr unterschiedlich hoch. Je höher die Klassifizierung, desto höher die nötige Stufe.
Gesicherte Kommunikation, nicht nur MFA (Art. 21(2)(j))
Buchstabe (j) ist breiter als reine Authentifizierung. Er nennt gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls Notfallkommunikationssysteme innerhalb der Einrichtung. Eine reine MFA-Einführung erfüllt die Pflicht nicht vollständig. Interne Videokonferenzen, Messaging und jeder Out-of-Band-Notfallkanal gehören zur selben Pflicht.
Anlagenklassifizierung treibt die Tiefe (Art. 21(1))
Art. 21(1) verlangt geeignete und angemessene Maßnahmen. Die CIR übersetzt das in einen konkreten Test für MFA: die Klassifizierung der Anlage bestimmt die Stärke. Ein kleines Stadtwerk braucht nicht für jedes interne Portal FIDO2-Hardwareschlüssel. Ein Steuerungsanlagen-Jumphost ist ein anderes Gespräch. Die Klassifizierung ist der Hebel, nicht allein die Unternehmensgröße.
BSI / §30 Abs. 2 Nr. 10 BSIG
Deutschland übernimmt den EU-Wortlaut fast wörtlich in §30 Abs. 2 Nr. 10 BSIG. Die operative Referenz des BSI ist der IT-Grundschutz-Baustein ORP.4 (Identitäts- und Berechtigungsmanagement). Er liefert konkrete Anforderungen zu Ausgabe von Zugangsdaten, MFA, Trennung privilegierter Konten und Notfallzugang. Wer ORP.4 sauber umsetzt, ist innerhalb der §30 Abs. 2 Nr. 10 Pflicht.
ENISA Technical Implementation Guidance
Die ENISA-TIG zur CIR übersetzt §11 in operative Sprache und mappt sie auf ISO/IEC 27001:2022, NIST CSF 2.0, ETSI EN 319 401 und CEN/TS 18026:2024. Wer ISO 27001 bereits betreibt (Controls A.5.16, A.5.17, A.8.5), ist weitgehend abgedeckt. Die TIG nennt auch die Evidenzen, die Prüfer sehen wollen: MFA-Richtlinie, Kontenklassifizierung, Einrichtungsnachweise, Ausnahmeregister.
Nationale Umsetzungsgesetze
Jeder Mitgliedstaat hat ein eigenes NIS-2-Umsetzungsgesetz (Niederlande: Cyberbeveiligingswet, Österreich: NISG, Belgien: NIS2-Wet). Die MFA-Pflicht selbst ist identisch, weil sie in der Richtlinie und der CIR steht. Unterschiede: der Referenzkatalog (Grundschutz in DE, BIO in den NL, kein formeller Katalog anderswo), der Meldekanal und die zuständige Aufsicht.
Wir haben MFA auf dem VPN, wir sind fertig.
VPN-MFA ist ein Zugangspfad. CIR §11.7 fragt nach Zugang zu Werten gemäß ihrer Klassifizierung, nicht nach einer einzelnen Perimeter-Tür. Wenn ein privilegierter Nutzer einen Domain Controller, eine Backup-Konsole, eine Cloud-Admin-Konsole oder einen SaaS-Tenant ohne MFA erreichen kann, ist die Pflicht nicht erfüllt. Maßstab ist die Klassifizierung des Werts hinter der Tür, nicht die Tür, durch die man gekommen ist.
SMS-MFA reicht für alle.
CIR §11.7.2 verlangt, dass die Authentifizierungsstärke zur Klassifizierung passt. SMS- und Voice-OTP sind der schwächste Faktor: SIM-Swap, SS7-Abfang und Phishing umgehen sie. Für einfachen internen Zugang akzeptiert ein Prüfer das eventuell. Für Kronjuwelen (Admin-Konsolen, Steuerungsanlagen, Identity Provider) braucht es phishing-resistente Authentifizierung (FIDO2 / WebAuthn / Smartcard). Die Stärke skaliert mit der Klassifizierung.
Service- und Systemkonten brauchen keine MFA.
CIR §11.3.2(a) erfasst privilegierte Konten und Systemverwaltungskonten ausdrücklich. Servicekonten fallen nur dann aus der menschlichen MFA heraus, wenn sie sauber klassifiziert sind und ein anderes starkes Verfahren nutzen (Managed Identities, kurzlebige Zugangsdaten, signierte Zertifikate, Vault-ausgestellte Secrets mit Rotation). 'Servicekonto, kann kein MFA, ist befreit' ist keine Verteidigung. Entweder ist es nutzergetrieben (dann MFA), oder es ist maschinengetrieben (dann ein dokumentiertes Maschinencredential-Modell).
Die meisten deutschen Mittelstands-Teams starten an derselben Stelle: MFA auf jeder Administratorenkennung zuerst (Cloud-Admin-Konsolen, Domain-Admin, Hypervisor, Backup, Netzwerktechnik, SaaS-Tenants), dann MFA auf E-Mail, dann MFA auf dem Identity Provider für alle menschlichen Nutzer. Damit sind §11.3.2 und die hochklassifizierten Zeilen in einer Bewegung abgedeckt. Der Rest wird im ersten Jahr auf alle menschlichen Nutzer mit Zugang zu klassifizierten Anlagen ausgerollt.
Was Prüfer tatsächlich aufschlagen: die Anlagenklassifizierung, den MFA-Einrichtungsreport des Identity Providers und das Ausnahmeregister. Decken sich diese drei, ist die Pflicht erfüllt. Das tiefste einzelne Loch, das wir sehen, ist nicht technisch, sondern dokumentarisch: die Anlagenklassifizierung fehlt, also gibt es keine Regel dafür, welche Anlage welche Authentifizierungsstärke verlangt. Erst die Klassifizierung sauber ziehen, dann liest sich der MFA-Rollout von selbst aus der Liste.
Das ACC-Modul (Zugriffskontrolle) trägt die §11-Pflicht durchgängig. Anlagen werden mit Klassifizierung erfasst, Nutzergruppen mit Zugangsbedarf hinterlegt und die Authentifizierungsstärke pro Zeile dokumentiert. Dieselbe Tabelle beantwortet beide Tests: §11.7.1 (MFA wo angemessen) und §11.7.2 (Stärke passt zur Klassifizierung). Die §11.3.2-Zeilen für privilegierte Konten werden separat ausgewiesen.
Die Freigabe des Zugriffskontroll-Inventars erfolgt namentlich. Ausnahmen (das Altsystem, das noch kein MFA kann, die Integration, die ein Servicekonto braucht) landen im selben Datensatz mit dokumentierter Kompensationsmaßnahme und Review-Datum. Audit-Trail und Evidence-Export liefern dem Prüfer die in der ENISA-TIG genannten Artefakte: Richtlinie, Klassifizierung, Einrichtungsnachweis, Ausnahmeregister, alles an einem Ort.
- Richtlinie (EU) 2022/2555 (NIS 2), Art. 21(2)(j) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Durchführungsverordnung (EU) 2024/2690 (CIR), Anhang §11.3 und §11.7 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- BSI-Gesetz (BSIG), §30 Abs. 2 Nr. 10 in der Fassung des NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes
- BSI IT-Grundschutz, Baustein ORP.4 'Identitäts- und Berechtigungsmanagement'
- ENISA Technical Implementation Guidance zur CIR (EU) 2024/2690 (Stand Mai 2026)