MFA nach NIS2 Art. 21(2)(j): Was die CIR 2024/2690 konkret fordert – und wie Sie sich an BSI-Empfehlungen orientieren

Was NIS2 Artikel 21(2)(j) tatsächlich vorschreibt

Artikel 21(2)(j) der NIS2-Richtlinie, in Deutschland umgesetzt als § 30 Abs. 2 Satz 2 Nr. 10 BSIG (seit 6. Dezember 2025 in Kraft), verpflichtet besonders wichtige und wichtige Einrichtungen zur „Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung“. Das umfasst:

• Mehrfaktorauthentifizierung (MFA) oder kontinuierliche Authentifizierung für Zugänge zu Netz- und Informationssystemen
• Gesicherte Sprach-, Video- und Textkommunikation innerhalb der Einrichtung
• Gesicherte Notfallkommunikationssysteme, sofern erforderlich („gegebenenfalls“)

Im deutschen Gesetzeswortlaut bezieht sich „gegebenenfalls“ nur auf die Notfallkommunikation; die englische Fassung der Richtlinie stellt „where appropriate“ an das Ende der Aufzählung. Wie weit MFA im Einzelnen reichen muss, ergibt sich in Deutschland vor allem aus § 30 Abs. 1 BSIG: Die Maßnahmen müssen „geeignet, verhältnismäßig und wirksam“ sein, zu berücksichtigen sind unter anderem das Ausmaß der Risikoexposition, die Größe der Einrichtung, die Umsetzungskosten sowie Eintrittswahrscheinlichkeit und Schwere von Sicherheitsvorfällen. Außerdem ist die Einhaltung „durch die Einrichtungen zu dokumentieren“. Eine pauschale MFA-Aktivierung ohne nachvollziehbare Begründung, welche Konten und Systeme wie geschützt werden, lässt sich daher nur schwer belegen – etwa wenn das BSI gegenüber einer besonders wichtigen Einrichtung Audits anordnet (§ 61 Abs. 1 BSIG) oder bei einer wichtigen Einrichtung Tatsachen die Annahme rechtfertigen, dass sie ihre Pflichten nicht richtig umsetzt (§ 62 BSIG).

Die Durchführungsverordnung (EU) 2024/2690 (CIR) präzisiert diese Anforderungen in Abschnitt 11 ihres Anhangs – allerdings nur für die in Art. 1 CIR genannten Einrichtungsarten (u. a. DNS- und Cloud-Anbieter, Rechenzentren, Managed (Security) Service Provider, Online-Marktplätze und Vertrauensdiensteanbieter; vollständige Liste in den FAQ unten). Für diese Einrichtungsarten hat die CIR nach § 30 Abs. 3 BSIG Vorrang. Für alle anderen Einrichtungen bleibt § 30 Abs. 2 Satz 2 Nr. 10 BSIG die Rechtsgrundlage; BSI-Empfehlungen und die Bausteine des IT-Grundschutzes können dabei als Orientierung dienen, sind aber nicht gesetzlich verbindlich.

Die drei Authentifizierungskategorien: Grundlagen der BSI-Empfehlungen

Das BSI unterscheidet drei Kategorien von Authentisierungsfaktoren, die miteinander kombiniert werden können:

Kategorie	Beispiele	Typische Angriffsvektoren
Wissen	Passwörter, PINs, Passphrasen	Phishing, Credential-Stuffing, Brute-Force
Besitz	Smartcards, Hardware-Token, RFID-Chips, Software-Token/-Zertifikate, Authenticator-App	Physischer Diebstahl, Device-Kompromittierung
Biometrie	Fingerabdruck, Gesichtserkennung, Retina-Scan	Spoofing, Deepfake-Angriffe

Entscheidend ist eine Unterscheidung, die in vielen Implementierungen übersehen wird: Das BSI trennt die mehrstufige Authentisierung, bei der die Faktoren nacheinander separat geprüft werden und „dadurch getrennt voneinander angreifbar“ sind, von der Multi-Faktor-Authentisierung, bei der die Faktoren miteinander verknüpft sind – etwa wenn die PIN-Eingabe eine Chipkarte entsperrt. Für die Vertrauensniveaus „substanziell“ und „hoch“ hält das BSI einen mehrstufigen Anmeldeprozess für ungeeignet. Eine Rückmeldung zum Erfolg eines Authentisierungsversuchs sollte daher erst erfolgen, wenn alle Faktoren präsentiert wurden; sonst kann ein Angreifer jeden Faktor einzeln angreifen. Hinzu kommt das Prinzip des „schwächsten Glieds“: Das Gesamtsystem – einschließlich Registrierung, Ausgabe der Authentisierungsmittel und Wiederherstellung – ist nach seinem schwächsten Element zu bewerten.

CIR 2024/2690 Anhang Abschnitt 11: Die technische Präzisionsschicht

Die Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024 konkretisiert für die in ihrem Art. 1 genannten Einrichtungsarten, was Art. 21(2)(j) verlangt. Abschnitt 11 des Anhangs – „Zugriffskontrolle (Artikel 21 Absatz 2 Buchstaben i und j der Richtlinie (EU) 2022/2555)“ – enthält unter anderem folgende Kernpflichten:

Multifaktor-Authentifizierung (Nr. 11.7). Nach Nr. 11.7.1 stellen die betreffenden Einrichtungen 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“. Nr. 11.7.2 ergänzt, dass die Stärke der Authentifizierung für diese Klassifizierung angemessen sein muss. Maßstab ist also die Schutzklassifizierung der Anlagen und Werte (Nr. 12.1) – keine pauschale Pflicht für jedes Konto.

Privilegierte Konten und Systemverwaltungskonten (Nr. 11.3). Nach Nr. 11.3.2 Buchst. a müssen für diese Konten „starke Verfahren zur Identifizierung, Authentifizierung (z. B. Multifaktor-Authentifizierung) und Genehmigung“ eingerichtet werden. MFA wird hier als Beispiel genannt; für Administratorkonten ist sie in der Praxis das naheliegende Mittel. Hinzu kommen eigene Konten ausschließlich für Systemverwaltungsvorgänge (Buchst. b), möglichst eng zugeschnittene Verwaltungsrechte (Buchst. c) und gesonderte Authentifizierungsdaten für privilegierte Konten (Nr. 11.6.2 Buchst. f).

Zugang nur nach angemessener Authentifizierung. Die Zugriffskontrollkonzepte müssen für den Zugang von Personen ebenso gelten wie für den Zugang von Netz- und Informationssystemen und „sicherstellen, dass der Zugang nur Nutzern gewährt wird, die angemessen authentifiziert wurden“ (Nr. 11.1.2). Die Authentifizierungsstärke richtet sich nach der Klassifizierung des Werts (Nr. 11.6.2 Buchst. a); soweit durchführbar, sind modernste Authentifizierungsmethoden zu verwenden (Nr. 11.6.3).

Eindeutige Benutzeridentitäten. Nach Nr. 11.5.2 sind eindeutige Kennungen einzurichten und jede Nutzerkennung mit einer einzigen Person zu verknüpfen. Gemeinsam genutzte Kennungen sind nach Nr. 11.5.3 nur zu genehmigen, wenn sie aus geschäftlichen oder operativen Gründen erforderlich sind, einem ausdrücklichen Genehmigungsverfahren unterliegen und dokumentiert werden.

Gesicherte Kommunikation und Notfallkommunikation. Abschnitt 11 regelt die gesicherte Sprach-, Video- und Textkommunikation und die Notfallkommunikation nicht gesondert, obwohl er Art. 21(2)(j) in der Überschrift nennt. Bezüge finden sich an anderer Stelle des Anhangs, etwa in Nr. 4.3.2 Buchst. b (geeignete Kommunikationsmittel zwischen den Einrichtungen und den zuständigen Behörden im Krisenmanagement) und Nr. 6.7.2 Buchst. k (Durchführungsplan für moderne E-Mail-Kommunikationsnormen). Für alle übrigen Einrichtungen ergibt sich die Pflicht unmittelbar aus § 30 Abs. 2 Satz 2 Nr. 10 BSIG.

Wer sich am BSI IT-Grundschutz orientiert, findet passende Anforderungen im Baustein ORP.4 „Identitäts- und Berechtigungsmanagement“ (Edition 2023). Die Basis-Anforderung ORP.4.A2 verlangt, Kennungen und Berechtigungen nur nach dem tatsächlichen Bedarf zu vergeben (Least-Privilege- und Need-to-know-Prinzip); nach der Standard-Anforderung ORP.4.A10 SOLLTEN Kennungen mit weitreichenden Berechtigungen mit einer Mehr-Faktor-Authentisierung, „z. B. mit kryptografischen Zertifikaten, Chipkarten oder Token“, geschützt werden. Die MUSS- und SOLLTE-Stufen beschreiben die Grundschutz-Methodik; eine gesetzliche Pflicht, den IT-Grundschutz anzuwenden, enthält das BSIG nicht. Im #nis2know-Infopaket bildet das BSI die MFA-Anforderungen zudem auf die Praktiken des neuen Grundschutz++ ab.

Die drei BSI-Vertrauensniveaus: Angemessenheit operationalisieren

Die häufigste Frage in der NIS2-Praxis lautet: Für welche Systeme und Konten muss MFA aktiviert sein? Das BSI stellt dazu klar: „Im NIS-2-Umsetzungsgesetz ist nicht vorgegeben, dass die eingesetzte Authentisierungslösung ein bestimmtes Vertrauensniveau erreichen muss.“ Die Einrichtung entscheidet auf Basis ihrer Risikoanalyse. Als Orientierungshilfe nennt das BSI die Vertrauensniveaus der Technischen Richtlinie BSI TR-03107 „Elektronische Identitäten und Vertrauensdienste im E-Government“ – eine Pflicht zur Konformität mit dieser Richtlinie besteht nach Angaben des BSI nicht.

Vertrauensniveau	Authentifizierungsanforderung	Angriffsresistenz
Normal	Ein entsprechend ausgestalteter Faktor	Angriffspotenzial „enhanced-basic“
Substanziell (Substantial)	Zwei Faktoren aus verschiedenen Kategorien, nicht unabhängig voneinander angreifbar	Angriffspotenzial „moderate“
Hoch (High)	Zwei Faktoren + manipulationssicheres Authentisierungsmittel	Angriffspotenzial „high“

Kontoklassen-Matrix: Beispielhafte Vertrauensniveau-Zuordnung

Kontoklasse	Empfohlenes Niveau	Begründung
Standard-Benutzer (lokale Systeme, niedrige Sensitivität)	Normal	Schadenpotenzial begrenzt; kompensatorische Kontrollen möglich
Remote-Zugang / VPN / Homeoffice	Substanziell	Erweiterte Angriffsoberfläche durch öffentliche Netze
Zugang zu sensiblen Daten (Kundendaten, Finanzdaten)	Substanziell	Datenschutzverletzungsrisiko, mögliche Meldepflicht
Privilegierte Konten / Administratoren (on-premise)	Hoch	Vollzugriff auf Systeme, maximales Schadenpotenzial
Cloud-Konsolen und SaaS-Administratorzugänge	Hoch	Extern erreichbar, Single-Vendor-Ausfallrisiko

Diese Matrix ist ein Beispiel und kein Dokument, das 1:1 aus einer Norm übernommen werden kann – sie ist das Ergebnis einer Risikoanalyse, die jede Einrichtung für ihre konkrete Infrastruktur erstellen sollte. Abweichungen sind zulässig, sollten aber begründet und dokumentiert sein.

Was Angemessenheit in der Nachweisführung bedeutet. Für einen belastbaren Nachweis genügt es in der Regel nicht, dass MFA aktiviert ist. Nachvollziehbar sein sollte auch: Welche Kontoklassen erhalten welches Vertrauensniveau? Welche Ausnahmen wurden gewährt und warum? Welche kompensatorischen Maßnahmen gelten, wo MFA technisch nicht umsetzbar ist – etwa in älteren OT-Systemen oder Legacy-Anwendungen? Ein Protokoll dieser Entscheidungen, idealerweise als Bestandteil des Informationssicherheitsmanagementsystems (ISMS), erfüllt zugleich die Dokumentationspflicht nach § 30 Abs. 1 Satz 3 BSIG und ist die Grundlage, wenn das BSI nach §§ 61, 62 BSIG Nachweise oder Prüfungen verlangt. Für CIR-Einrichtungen gilt ergänzend: Halten sie bestimmte Anforderungen des Anhangs für nicht angemessen, nicht anwendbar oder nicht durchführbar, sollen sie ihre Begründung nach Erwägungsgrund 6 der CIR „in verständlicher Weise dokumentieren“.

Gesicherte Kommunikation: Der oft übersehene Teil des Art. 21(2)(j)

Während MFA in der Diskussion dominiert, enthält § 30 Abs. 2 Satz 2 Nr. 10 BSIG eine zweite Pflicht, die in vielen Compliance-Projekten zu spät adressiert wird: die Sicherung von Sprach-, Video- und Textkommunikation. Der Fehler liegt in der Annahme, dass Kommunikationssicherheit ein Randthema sei – tatsächlich steht sie im Gesetzestext gleichrangig neben der MFA.

TLS nach BSI TR-02102-2: Der maßgebliche Stand der Technik. Für die gesicherte Kommunikation verweist das BSI auf das TLS-Protokoll und die Technische Richtlinie TR-02102-2 (aktuell Version 2026-01). Die TR enthält Empfehlungen; verbindlich ist der darauf aufbauende Mindeststandard zur Verwendung von TLS nur für die Bundesverwaltung. Für die NIS2-Umsetzung sind vor allem folgende Punkte relevant:

• TLS-Versionen: TLS 1.3 sollte bevorzugt werden; TLS 1.2 wird nur noch bis Ende 2031 empfohlen. TLS 1.0 und TLS 1.1 werden nicht empfohlen – das BSI rät, ältere Versionen vollständig zu deaktivieren, nicht nur als Fallback zu belassen.
• Schlüssellängen: RSA ≥ 3000 Bit, ECDSA bzw. ECDH ≥ 250 Bit.
• Cipher-Suiten: Suiten mit Perfect Forward Secrecy (ECDHE, DHE) werden grundsätzlich empfohlen; veraltete Verfahren wie RC4, 3DES oder NULL-Cipher gehören nicht zu den empfohlenen Suiten und sollten deaktiviert werden.
• Zertifikatsmanagement: Ablaufende Zertifikate und schwache Cipher-Suites sollten im Monitoring erfasst und zeitnah erneuert werden.
• Konfigurationsdokumentation: Das BSI empfiehlt, die TLS-Konfiguration regelmäßig zu überprüfen und zu dokumentieren.

Ende-zu-Ende-Verschlüsselung für sensible Inhalte. Nachrichten mit sensiblen Inhalten sollten nach BSI-Empfehlung gegebenenfalls zusätzlich Ende-zu-Ende-verschlüsselt werden, für E-Mail etwa mit PGP oder S/MIME; für interne Textkommunikation bieten sich Ende-zu-Ende-verschlüsselte Messaging-Lösungen an. Eine reine Transport-Verschlüsselung über TLS schützt nicht vor einer Kompromittierung des Mail-Servers oder der Messaging-Plattform selbst.

Videokonferenz und VoIP. Ob Unternehmenstools wie Microsoft Teams, Zoom oder Cisco Webex den Anforderungen genügen, hängt von ihrer Konfiguration und der eigenen Risikoanalyse ab – eine pauschale „NIS2-Konformität“ eines Produkts gibt es nicht. Prüfen Sie, ob die Transportverschlüsselung durchgängig erzwungen wird und ob für vertrauliche Besprechungen Ende-zu-Ende-Verschlüsselung verfügbar und aktiviert ist. Wo die Risikoanalyse E2EE für bestimmte Inhalte vorsieht, sollte sie über Richtlinien und technische Konfiguration durchgesetzt werden, nicht durch freiwillige Nutzerentscheidung.

Kontinuierliche Authentifizierung: Reaktive Kontrolle im laufenden Betrieb

Artikel 21(2)(j) nennt kontinuierliche Authentifizierung als Alternative zur MFA („oder“) – nicht als Ergänzung. In der Praxis funktionieren beide Ansätze am besten kombiniert: MFA beim initialen Login, kontinuierliche Kontrolle als zweite Verteidigungslinie.

Kontinuierliche Authentifizierung überwacht aktive Sitzungen auf Anomalien. Folgende Ereignisse können eine erneute Authentifizierung oder eine Sitzungsbeendigung auslösen:

• Geografische Standortveränderung (IP-Wechsel, Gerät aus anderem Land/Region)
• Gerätewechsel (neuer Browser-Fingerprint, veränderte User-Agent-Parameter)
• Abweichende Zugriffszeiten (Zugriff außerhalb üblicher Arbeitszeiten)
• Ungewöhnlicher Ressourcenverbrauch (hohe Datenmenge, unerwartete API-Call-Frequenz)

Das BSI bewertet kontinuierliche Authentifizierung als reaktiven Ansatz, der eine Kompromittierung nicht verhindern, sondern lediglich den Schaden reduzieren kann; explizite Empfehlungen oder Umsetzungshinweise gibt das BSI dafür nicht. Die Reaktionsmöglichkeiten reichen von einer erneuten Authentifizierungsaufforderung über die vorübergehende Einschränkung von Rechten bis zur sofortigen Sitzungsbeendigung – abhängig vom Schweregrad der erkannten Anomalie. Für die Dokumentation im ISMS sollten diese Schwellenwerte und Reaktionen festgelegt und nachvollziehbar sein.

Umsetzungsfahrplan in 5 Schritten

Dieser Fahrplan richtet sich an CISOs und IT-Sicherheitsbeauftragte, die MFA nach Art. 21(2)(j) nachweisfähig implementieren wollen. Die Reihenfolge ist bewusst gewählt: Schritt 1 und 2 liefern die Datengrundlage für alle nachfolgenden Entscheidungen.

Schritt 1: Kontoinventur und Kontoklassenbildung [Aufwand: Mittel]

Erfassen Sie alle Benutzerkonten, Dienstkonten und Systemidentitäten. Klassifizieren Sie jedes Konto nach drei Dimensionen: Zugriffstyp (lokal/remote/hybrid), Berechtigungsumfang (Standard/erhöht/privilegiert) und Datensensitivität (gering/mittel/hoch/sehr hoch). Diese Inventur ist die Grundlage für alle nachfolgenden Schritte und ein zentraler Baustein für Nachweise gegenüber dem BSI.

Schritt 2: Vertrauensniveau-Zuordnung in Anlehnung an BSI TR-03107 [Aufwand: Niedrig]

Ordnen Sie jeder Kontoklasse ein Vertrauensniveau zu. Begründen Sie Abweichungen schriftlich – insbesondere Ausnahmen für Legacy-Systeme oder OT-Umgebungen, in denen MFA technisch nicht realisierbar ist. Diese Begründungen sind keine Kulanzentscheidungen, sondern Teil der Dokumentation nach § 30 Abs. 1 Satz 3 BSIG.

Schritt 3: MFA-Technologieauswahl nach Vertrauensniveau [Aufwand: Hoch]

Methode	Orientierung Vertrauensniveau	Hinweis
FIDO2-Sicherheitsschlüssel (gerätegebundener Passkey)	Substanziell; „hoch“ nach BSI TR-03188 derzeit nur teilweise erreichbar	Phishing-resistent. TR-03188 lässt für „hoch“ nur gerätegebundene Passkeys mit geprüfter Attestation zu (z. B. FIDO-L3-Authenticator); gegen einzelne Angreifermodelle dieser Stufe ist laut TR mit WebAuthn derzeit kein Schutz sicherzustellen. Synchronisierte Passkeys sind für „hoch“ ausgeschlossen.
Smartcard / PKI-Zertifikat (z. B. mit PIN)	Substanziell bis hoch (bei zertifiziertem, manipulationssicherem Chip)	PIN entsperrt den Schlüssel auf der Karte; die Manipulationssicherheit lässt sich laut BSI über Zertifizierungen (z. B. Common Criteria) nachweisen. IT-Grundschutz ORP.4.A10 nennt Zertifikate, Chipkarten oder Token für privilegierte Kennungen.
Hardware-Token (OATH HOTP/TOTP)	Substanziell, sofern Passwort und Code gemeinsam geprüft werden	Für OT-Umgebungen ohne Smartphone-Nutzung; wie alle Einmalcode-Verfahren nicht phishing-resistent
TOTP (Authenticator-App)	Substanziell	Laut BSI-Vergleich kein Schutz vor Echtzeit-Phishing; Codes nicht per SMS übermitteln
Push-Notification mit Number-Matching	Substanziell	Number-Matching dringend empfohlen: Reine Bestätigungs-Push hält NIST SP 800-63B-4 wegen „Authentication Fatigue“-Angriffen nicht mehr für akzeptabel
SMS-OTP	Eher geringes Schutzniveau	Keine gesetzliche Regelung zu SMS; aus Risikosicht nur Rückfall- oder Übergangslösung: kein Schutz vor Echtzeit-Phishing (BSI), Umleitungsrisiko durch SIM-Tausch oder Rufnummernportierung; NIST SP 800-63B-4 führt SMS als „restricted“

Die Einordnung in der mittleren Spalte ist eine eigene, an TR-03107 und TR-03188 angelehnte Orientierung; das BSI veröffentlicht keine verbindliche Zuordnung einzelner Verfahren zu Vertrauensniveaus, maßgeblich ist die konkrete Implementierung einschließlich Registrierung und Wiederherstellung. Für administrative Zugänge sind phishing-resistente Verfahren mit Besitzfaktor – gerätegebundene FIDO2-Sicherheitsschlüssel oder Smartcards mit PKI-Zertifikat – die naheliegende Wahl. Push-Notification ohne Number-Matching ist für privilegierte Konten nicht zu empfehlen.

Wichtig: „Passkey“ ist nicht automatisch ein Hardware-Key. Ob ein Passkey überhaupt als zweiter Faktor zählt und warum synchronisierte Passkeys aus iCloud oder dem Google Password Manager nach BSI TR-03188 das Vertrauensniveau „hoch“ nicht erreichen, erklärt unser Leitfaden Passkeys und NIS2: wann sie als MFA zählen.

Schritt 4: TLS-Härtung und gesicherte Kommunikation [Aufwand: Mittel]

Auditieren Sie alle erreichbaren TLS-Endpunkte mit einem Tool wie testssl.sh oder SSL Labs. Deaktivieren Sie TLS 1.0 und 1.1 vollständig. Prüfen Sie Cipher-Suiten gegen BSI TR-02102-2. Setzen Sie E2EE für sensible interne Kommunikationskanäle dort, wo Ihre Risikoanalyse sie vorsieht, über Konfigurationsrichtlinien durch, nicht als Nutzerentscheidung. Dokumentieren Sie die Konfiguration und den Prüfzeitpunkt.

Schritt 5: Dokumentation des Angemessenheits-Nachweises [Aufwand: Niedrig]

Erstellen Sie ein Dokument, das je Kontoklasse festhält: Risikobewertung, gewähltes Vertrauensniveau, eingesetzte MFA-Methode, bestehende Ausnahmen und die jeweiligen Kompensationsmaßnahmen. Dieses Dokument ist Bestandteil Ihres ISMS, wird regelmäßig aktualisiert und sollte jederzeit vorgelegt werden können, wenn das BSI Nachweise anfordert. Es ist – neben dem technischen MFA-Rollout selbst – ein zentraler Einzelnachweis für die Umsetzung von Art. 21(2)(j) bzw. § 30 Abs. 2 Satz 2 Nr. 10 BSIG.

Die weiterführenden Anforderungen an technische und organisatorische Sicherheitsmaßnahmen finden Sie in unserem Leitfaden zu den NIS2-Anforderungen im Überblick, die Zugangskontrollanforderungen im Detail unter NIS2 Zugangskontrolle, und den vollständigen Rechtstext der Durchführungsverordnung erläutern wir in unserem Artikel zur NIS2-Durchführungsverordnung (EU) 2024/2690.

Häufige Fragen zu NIS2 MFA

Muss MFA für alle Benutzerkonten aktiviert sein?
Nicht zwingend. § 30 Abs. 2 Satz 2 Nr. 10 BSIG verlangt den Einsatz von Lösungen zur MFA oder kontinuierlichen Authentifizierung, schreibt aber weder bestimmte Konten noch ein Vertrauensniveau vor; der Umfang richtet sich nach der Risikoanalyse und dem Verhältnismäßigkeitsmaßstab des § 30 Abs. 1 BSIG. Für privilegierte Konten und Fernzugänge ist MFA in der Praxis kaum verzichtbar; CIR-Einrichtungen müssen für privilegierte Konten nach Nr. 11.3.2 Buchst. a des Anhangs starke Authentifizierungsverfahren einrichten. Standardbenutzer mit lokal begrenztem Zugriff können bei entsprechender Begründung mit einem gut ausgestalteten Einzelfaktor ausreichend gesichert sein.

Welche MFA-Methoden sind NIS2-konform?
Das Gesetz schreibt keine Methode vor. Das BSI empfiehlt eine MFA „unter Verwendung von geeigneten Wissens- und Besitzfaktoren“ und bezeichnet Passkeys als sehr sichere Lösung. Phishing-resistente Verfahren wie FIDO2-Sicherheitsschlüssel oder Smartcards mit PKI-Zertifikat eignen sich für hohen Schutzbedarf; TOTP-Apps und Push mit Number-Matching sind verbreitete Lösungen mittlerer Stärke. SMS-Codes schützen nach BSI-Bewertung nicht vor Echtzeit-Phishing und sollten nach eigener Risikoabwägung allenfalls als Übergangs- oder Rückfalllösung dienen.

Was bedeutet „gesicherte Kommunikation“ konkret?
TLS (bevorzugt TLS 1.3; TLS 1.2 nach BSI TR-02102-2 noch bis Ende 2031 empfohlen) für alle Transportverbindungen, gegebenenfalls E2EE für sensible Inhalte. Ältere Protokollversionen wie TLS 1.0 und 1.1 sollten nach BSI-Empfehlung vollständig deaktiviert sein. Die Anforderung betrifft ausdrücklich die Kommunikation innerhalb der Einrichtung, nicht nur extern erreichbare Dienste.

Wie dokumentiere ich die Angemessenheit für Nachweise gegenüber dem BSI?
Mit einem Kontoklassen-Dokument, das Risikobewertung, zugewiesenes Vertrauensniveau, eingesetzte Kontrollen und Ausnahmen mit Begründung enthält. Es dient der Dokumentationspflicht nach § 30 Abs. 1 Satz 3 BSIG und sollte vorgelegt werden können, wenn das BSI nach §§ 61, 62 BSIG Nachweise oder Prüfungen verlangt.

Gilt die CIR 2024/2690 für mein Unternehmen?
Die CIR 2024/2690 gilt verbindlich nur für die in Art. 1 CIR genannten Einrichtungsarten: DNS-Diensteanbieter, TLD-Namenregister, Cloud-Computing- und Rechenzentrumsdienste, Inhaltszustellnetze, Managed (Security) Service Provider, Online-Marktplätze, Online-Suchmaschinen, Plattformen für soziale Netzwerke und Vertrauensdiensteanbieter. Für alle anderen besonders wichtigen und wichtigen Einrichtungen in Deutschland ist § 30 Abs. 2 Satz 2 Nr. 10 BSIG die Rechtsgrundlage; BSI-Orientierungshilfen und IT-Grundschutz unterstützen bei der Umsetzung, sind aber nicht verbindlich.

Dieser Artikel dient ausschließlich der allgemeinen Information und stellt keine Rechts- oder Compliance-Beratung dar. Die Anforderungen können je nach Branche, Unternehmensstruktur und Mitgliedstaat variieren. Bitte konsultieren Sie einen qualifizierten Rechts- oder Compliance-Spezialisten für eine auf Ihre Situation zugeschnittene Beurteilung.

Quellen

• BSI. (o. J., abgerufen 14.10.2026). #nis2know: Multi-Faktor-Authentisierung, kontinuierliche Authentifizierung und gesicherte Kommunikation. Bundesamt für Sicherheit in der Informationstechnik.
• Europäische Kommission. (2024). Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024. EUR-Lex.
• Bundesministerium der Justiz. § 30 BSIG – Risikomanagementmaßnahmen besonders wichtiger Einrichtungen und wichtiger Einrichtungen. Gesetze im Internet.
• BSI. Technische Richtlinie BSI TR-03107: Elektronische Identitäten und Vertrauensdienste im E-Government. Bundesamt für Sicherheit in der Informationstechnik.
• BSI. Technische Richtlinie BSI TR-03188: Passkey Server – Version 1. Bundesamt für Sicherheit in der Informationstechnik.
• BSI. (2026). BSI TR-02102-2: Kryptographische Verfahren – Verwendung von Transport Layer Security (TLS), Version 2026-01. Bundesamt für Sicherheit in der Informationstechnik.
• BSI. (2023). IT-Grundschutz-Kompendium ORP.4: Identitäts- und Berechtigungsmanagement (Edition 2023). Bundesamt für Sicherheit in der Informationstechnik.
• BSI. Vergleich gängiger Verfahren der Zwei-Faktor-Authentisierung (2FA). Bundesamt für Sicherheit in der Informationstechnik.
• NIST. (2025). SP 800-63B-4: Digital Identity Guidelines – Authentication and Authenticator Management. National Institute of Standards and Technology.