MFA nach NIS2: Smartphone mit Authentifizierungscode und Fingerabdruck-Symbol

MFA nach NIS2 Artikel 21(2)(j): Was die CIR 2024/2690 konkret fordert – und wie Sie BSI-konform umsetzen

Vonadmin

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

Seit dem 6. Mai 2026 ist die BSI-Vollzugsphase operativ. Wer als wesentliche oder wichtige Einrichtung im BSI-Audit mit einer pauschalen MFA-Aktivierung erscheint – ohne dokumentierte Schwellenlogik, ohne Kontoklassen-Risikoanalyse, ohne Ausnahmeregelung – riskiert eine offene Prüffeststellung. Artikel 21(2)(j) der NIS2-Richtlinie, in Deutschland umgesetzt als § 30 Abs. 2 Satz 2 Nr. 10 BSIG, verpflichtet betroffene Einrichtungen zur Einführung von:

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

Der Zusatz „sofern angemessen“ gilt für alle drei Komponenten – er ist jedoch kein Befreiungstatbestand. Das BSI macht in seiner Vollzugspraxis seit Mai 2026 deutlich: Für jede Kontoklasse muss eine dokumentierte Risikoabwägung vorliegen, die erklärt, warum MFA gilt oder warum alternative Kontrollen das Risiko gleichwertig senken. Wer im Audit keine solche Dokumentation vorlegen kann, erhält die MFA-Anforderung als offenen Befund – unabhängig davon, ob MFA faktisch aktiviert ist.

Die Durchführungsverordnung (EU) 2024/2690 (CIR) präzisiert diese Anforderungen in Abschnitt 11 ihres Anhangs mit verbindlichen technischen Vorgaben für Anbieter digitaler Infrastruktur. Für alle anderen betroffenen Einrichtungen gelten die BSI-IT-Grundschutz-Bausteine als anerkannte Methodik zur Erfüllung der NIS2-Pflichten.

Die drei Authentifizierungskategorien: Grundlagen der BSI-Anforderung

Das BSI definiert drei Kategorien von Authentifizierungsfaktoren, die kombiniert werden müssen:

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

Entscheidend ist eine Anforderung, die in vielen Implementierungen fehlt: Die Faktoren müssen kryptografisch miteinander verknüpft sein – nicht nur sequenziell abgefragt. Ein System, das nach Passworteingabe separat auf den Token prüft, ohne kryptografische Bindung zwischen beiden Faktoren, erfüllt die BSI-Anforderung nicht. Das Zwischenergebnis der Authentifizierung – ob das Passwort richtig oder falsch war – darf einem Angreifer nie preisgegeben werden, da dies unabhängige Angriffe auf jeden Faktor ermöglicht. Hinzu kommt das „Weakest-Link“-Prinzip: Die Sicherheit des gesamten MFA-Systems entspricht dem schwachsten eingesetzten Faktor.

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 Anbieter digitaler Infrastruktur und vertrauenswürdiger Dienste, was Art. 21(2)(j) verlangt. Abschnitt 11 des Anhangs – „Identifizierung, Authentifizierung und Zugangskontrolle“ – enthält folgende Kernpflichten:

Privilegierte Konten und Systemadministration. Für privilegierte Konten und Systemadministrationskonten schreibt die CIR eine starke Identifizierung und Authentifizierung vor – MFA ist für diese Kontoklasse keine Option, sondern Pflicht. Die Regelung gilt ausnahmslos: Dienstkonten, Break-Glass-Konten und Shared-Accounts mit administrativen Rechten fallen sämtlich darunter.

Zugang nur nach adequater Authentifizierung. Systeme dürfen nur Nutzern Zugang gewähren, die sich angemessen authentifiziert haben. Dies schließt automatisierte Prozesse und Service-Accounts ein.

Eindeutige Benutzeridentitäten. Jede Person, die auf Netz- und Informationssysteme zugreift, benötigt eine eindeutige, ihr persönlich zugewiesene Identität. Shared-Accounts sind nur zulässig, wenn individuelle Zuordnung technisch ausgeschlossen ist und das Risiko durch kompensatorische Maßnahmen beherrscht wird.

Gesicherte interne Kommunikation. Abschnitt 11 verlangt ausdrücklich gesicherte Kommunikationslösungen für Sprache, Video und Text innerhalb der Einrichtung – nicht nur für externe Verbindungen. Instant-Messaging-Tools, Videokonferenzsysteme und interne E-Mail-Infrastrukturen sind betroffen.

Gesicherte Notfallkommunikation. Für Einrichtungen, bei denen ein Ausfall der Kommunikation kritische Dienste gefährdet, schreibt die CIR zusätzlich gesicherte Notfallkommunikationssysteme vor. Das betrifft insbesondere Betreiber kritischer Infrastruktur, Energieversorger und Anbieter digitaler Kerndienste.

Die operative Umsetzungsschicht dieser CIR-Anforderungen bildet das BSI IT-Grundschutz-Kompendium, Baustein ORP.4 „Identitäts- und Berechtigungsmanagement“. ORP.4 schreibt das Least-Privilege-Prinzip vor: Zugriffsrechte werden ausschließlich auf Basis des dokumentierten Aufgabenbedarfs vergeben, Berechtigungen werden regelmäßig überprüft und nicht mehr benötigte Rechte entzogen.

Die drei BSI-Vertrauensniveaus: „sofern angemessen“ operationalisieren

Die häufigste Frage in der NIS2-Praxis lautet: Für welche Systeme und Konten muss MFA aktiviert sein? Das NIS2-Umsetzungsgesetz gibt kein konkretes Vertrauensniveau vor – die Einrichtung entscheidet auf Basis ihrer Risikoanalyse. Die Technische Richtlinie BSI TR-03107 „Elektronische Identitäten und Vertrauensdienste“ bietet den anerkannten Bewertungsrahmen.

Vertrauensniveau Authentifizierungsanforderung Angriffsresistenz
Normal Ein angemessen konfigurierter Faktor Erhöhtes Basisniveau (enhanced-basic)
Erheblich (Substantial) Zwei Faktoren aus verschiedenen Kategorien Moderates Angriffspotenzial
Hoch (High) Zwei Faktoren + manipulationsresistentes Gerät Hohes Angriffspotenzial

Kontoklassen-Matrix: Empfohlene 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 Erheblich Erweiterte Angriffsoberfläche durch öffentliche Netze
Zugang zu sensiblen Daten (Kundendaten, Finanzdaten) Erheblich 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 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 muss. Abweichungen sind zulässig, müssen aber begründet und dokumentiert sein.

Was „sofern angemessen“ im BSI-Audit bedeutet. Seit Mai 2026 prüft das BSI nicht mehr nur, ob MFA aktiviert ist, sondern ob eine dokumentierte Schwellenlogik vorliegt: 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), ist die wichtigste Einzeldokumentation für das MFA-Thema. Fehlt dieses Protokoll, erhält die Einrichtung die Anforderung als Prüffeststellung – unabhängig davon, ob MFA faktisch aktiviert ist.

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

Während MFA in der Diskussion dominiert, enthält § 30(2) Nr. 10 BSIG eine zweite Pflicht, die in den meisten 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 ist sie gleichrangig mit MFA formuliert.

TLS nach BSI TR-02102-2: Die verbindliche Mindestanforderung. Das BSI definiert in der Technischen Richtlinie TR-02102-2 die Mindestanforderungen für TLS-Implementierungen. Für die NIS2-Compliance sind folgende Punkte maßgeblich:

  • Zulässige TLS-Versionen: Nur TLS 1.2 und TLS 1.3 sind erlaubt. TLS 1.0 und TLS 1.1 müssen vollständig deaktiviert sein – nicht nur als Fallback, sondern aus der Konfiguration entfernt.
  • Schlüssellängen: RSA ≥ 3000 Bit, EC ≥ 250 Bit (Kurven P-256 oder höher).
  • Cipher-Suiten: Nur Forward-Secrecy-fähige Suiten (ECDHE) sind zulässig; RC4, 3DES und NULL-Cipher vollständig deaktivieren.
  • Zertifikatsmanagement: Ablaufende Zertifikate und schwache Cipher-Suites müssen im Monitoring erfasst und zeitnah erneuert werden.
  • Konfigurationsdokumentation: Regelmäßige Prüfung aller TLS-Endpunkte mit dokumentiertem Ergebnis.

Ende-zu-Ende-Verschlüsselung für sensible Inhalte. Für besonders sensible Kommunikation empfiehlt das BSI Ende-zu-Ende-Verschlüsselung: PGP oder S/MIME für E-Mail, Ende-zu-Ende-verschlüsselte Messaging-Lösungen für interne Textkommunikation. Eine reine Transport-Verschlüsselung über TLS schützt nicht vor einer Kompromittierung des Mail-Servers oder der Messaging-Plattform selbst.

Videokonferenz und VoIP. Unternehmenstools wie Microsoft Teams, Zoom oder Cisco Webex sind dann NIS2-konform, wenn Ende-zu-Ende-Verschlüsselung aktiviert ist und keine unverschlüsselten Verbindungen toleriert werden. Für wesentliche Einrichtungen, die über diese Systeme sicherheitsrelevante Informationen austauschen, ist E2EE intern durchzusetzen – über Richtlinien und technische Konfiguration, nicht durch freiwillige Nutzerentscheidung.

Kontinuierliche Authentifizierung: Reaktive Kontrolle im laufenden Betrieb

Artikel 21(2)(j) nennt kontinuierliche Authentifizierung als Alternative zur MFA – 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 ohne präventive Wirkung beim initialen Login. Die Reaktionsmöglichkeiten reichen von einer erneuten Authentifizierungsaufforderung bis zur automatischen Sitzungsbeendigung – abhängig vom Schweregrad der erkannten Anomalie. Für die Dokumentation im ISMS müssen 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) audit-fähig implementieren müssen. Die Reihenfolge ist nicht verhandelbar: 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 die zentrale Dokumentation für das BSI-Audit.

Schritt 2: Vertrauensniveau-Zuordnung nach 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 Pflichtdokumentation.

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

Methode Vertrauensniveau Hinweis
FIDO2/Passkeys (Hardware-Key) Hoch Phishing-resistent; keine Netzwerk-Abhängigkeit; BSI-Empfehlung für Administratoren
Hardware-Token (OATH/HOTP) Hoch Für OT-Umgebungen ohne Smartphone-Nutzung
TOTP (Authenticator-App) Erheblich Nicht über SMS; TOTP-Codes nicht per Push-Benachrichtigung
Push-Notification mit Number-Matching Erheblich Number-Matching ist obligatorisch; ohne Number-Matching anfällig für MFA-Fatigue-Angriffe
SMS-OTP Normal (Fallback) Anfällig für SIM-Swapping; nur als temporäre Übergangslösung zulässig

Für administrative Zugänge ist FIDO2 die einzige Methode, die Vertrauensniveau „Hoch“ zugänglich erfüllt und gleichzeitig gegen Phishing immun ist. Push-Notification ohne Number-Matching ist für das höchste Vertrauensniveau nicht ausreichend.

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. Implementieren Sie E2EE für sensitive interne Kommunikationskanäle über Konfigurationsrichtlinie, nicht als Nutzerentscheidung. Dokumentieren Sie die Konfiguration und den Prüfzeitpunkt.

Schritt 5: Dokumentation des „sofern angemessen“-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 muss bei BSI-Audits unaufgefordert vorliegen. Es ist – neben dem technischen MFA-Rollout selbst – der wichtigste Einzelnachweis für die NIS2-Konformität im Bereich Art. 21(2)(j).

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?
Nein. Die Pflicht gilt „sofern angemessen“. Für jede Kontoklasse ist eine dokumentierte Risikoabwägung erforderlich. Privilegierte Konten und Remote-Zugänge erfordern zwingend mindestens Vertrauensniveau „Erheblich“. Standardbenutzer mit lokal begrenztem Zugriff können bei entsprechender Begründung mit einem gut konfigurierten Einzelfaktor ausreichend gesichert sein.

Welche MFA-Methoden sind NIS2-konform?
Das Gesetz schreibt keine Methode vor. Das BSI empfiehlt FIDO2-Hardware-Keys für das höchste Vertrauensniveau, TOTP-basierte Authenticator-Apps für Vertrauensniveau „Erheblich“. SMS-OTP gilt nur noch als Übergangslösung und sollte mittelfristig abgelöst werden.

Was bedeutet „gesicherte Kommunikation“ konkret?
TLS 1.2 oder 1.3 (nach BSI TR-02102-2) für alle Transportverbindungen, E2EE für sensible Inhalte. TLS 1.0 und 1.1 müssen vollständig deaktiviert sein. Die Anforderung gilt auch für interne Kommunikationskanäle, nicht nur für extern erreichbare Dienste.

Wie dokumentiere ich „sofern angemessen“ für das BSI-Audit?
Mit einem Kontoklassen-Dokument, das Risikobewertung, zugewiesenes Vertrauensniveau, eingesetzte Kontrollen und Ausnahmen mit Begründung enthält. Dieses Dokument ist die wichtigste Einzelnachweisdokumentation für das MFA-Thema und muss bei Audits unaufgefordert vorgelegt werden können.

Gilt die CIR 2024/2690 für mein Unternehmen?
Die CIR 2024/2690 gilt verbindlich für Anbieter digitaler Infrastruktur und vertrauenswürdige Dienste im Sinne von Art. 2 der CIR. Für alle anderen wesentlichen und wichtigen Einrichtungen nach NIS2 gilt Art. 21(2)(j) der NIS2-Richtlinie direkt, konkretisiert durch § 30 BSIG und die BSI-Orientierungshilfen.

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

Ähnliche Beiträge