NIS2-Mehrfaktor-Authentifizierung: 5 kritische Zugriffsklassen

Artikel 21 der Richtlinie (EU) 2022/2555 listet die Cybersicherheitsmaßnahmen auf, die jede NIS2-Einrichtung umsetzen muss. Buchstabe (j) nennt eine davon ausdrücklich beim Namen: die Mehrfaktor-Authentifizierung. Achtzehn Monate nach Inkrafttreten ist die NIS2-Mehrfaktor-Authentifizierung von der „guten Praxis" zur Rechtspflicht aufgestiegen — und die Durchführungsverordnung (EU) 2024/2690 hat geklärt, welche Faktoren eine Inspektion bestehen werden und welche nicht.

Die Verschiebung steckt nicht im Substantiv. Sie steckt im Adjektiv. Der Anhang der Durchführungsverordnung bringt NIS2 in Einklang mit dem aufsichtlichen Konsens nach 2023, den ENISA, ANSSI und BSI gemeinsam vertreten: Mehrfaktor ist notwendig, reicht aber nicht mehr aus. Maßstab ist nunmehr die phishing-resistente Authentifizierung — eine Kategorie, die die Richtlinie nicht namentlich nennt, auf die jedoch die Durchführungsverordnung, die nationalen Behörden und die Aufsichtspraxis zulaufen. Vorstände, die 2026 einen Artikel-21-Plan freigeben, erben dieses Urteil.

1. Was Artikel 21(2)(j) tatsächlich verlangt

Artikel 21(2)(j) verlangt „Mehrfaktor-Authentifizierungslösungen oder Lösungen für die kontinuierliche Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation". Die Formulierung ist knapp, der Anwendungsbereich weit. Sie gilt für jede Einrichtung in den achtzehn Sektoren der Richtlinie — nicht nur für solche, die personenbezogene Daten verarbeiten, nicht nur für solche, die Dienste am Endkunden anbieten.

Zwei Begriffe tragen die Pflicht. Kontinuierliche Authentifizierung — die Durchführungsverordnung präzisiert, dass damit eine Neuvalidierung auf Sitzungsebene gemeint ist, nicht nur die erste Anmeldung. Lösungen — im Plural, ein Signal, dass eine einzige Methode nicht jede Zugriffsklasse abdeckt. Die MFA-Entscheidung ist kein Häkchen in der IAM-Konsole. Sie ist ein Programm, das die Faktorstärke an das Risikoniveau über die gesamte Zugriffsoberfläche der Einrichtung anpasst.

Derselbe Artikel macht das Leitungsorgan — also den Vorstand — für die Genehmigung der daraus folgenden Richtlinie verantwortlich. Siehe die fünf nicht delegierbaren Verantwortlichkeiten des Vorstands nach NIS2 Artikel 20 für den Governance-Rahmen.

2. Die fünf Zugriffsklassen, die MFA tragen müssen

Die Durchführungsverordnung 2024/2690 listet nicht wörtlich „fünf Klassen". Ihr Anhang konstruiert die Anforderung durch Verbindung der Artikel-21-Grundsätze mit der technischen Grundlinie. Übersetzt in die Oberfläche, die ein CISO tatsächlich verteidigt:

1. Administrativer Zugriff — Domain-Administrator, Cloud-Root, Hypervisor, CLI von Netzgeräten. Jede privilegierte Sitzung, auf jedem System, bei jedem Login. Keine Ausnahmen für „vertrauenswürdige Netze" — Segmentierung ist eine Eindämmungs-, keine Authentifizierungsmaßnahme.
2. Fernzugriff — VPN, RDP, Jump-Hosts, SSH von außerhalb des Perimeters der Einrichtung. Die Aufsichtswelle 2024 von ANSSI und BSI hebt diese Kategorie besonders hervor — die meisten Ransomware-Angriffe, die in einer 72-Stunden-Meldung enden, sind über ungeschützten Fernzugriff eingetreten.
3. Zugriff auf öffentlich erreichbare Anwendungen — Webmail, Kundenportale mit administrativen oder finanziellen Funktionen, öffentliche Dienstoberflächen. Kunden und Bürger, nicht nur Mitarbeiter.
4. Zugriff auf sensible Daten — Produktionsdatenbanken, Finanzsysteme, Patientenakten, Quellcode-Repositorys. Die Grenze ist nicht „das interne Netz" — sie verläuft an der anwendungsseitigen Rollengrenze.
5. CI/CD- und Infrastructure-as-Code-Schnittstellen — Git am Build-Orchestrator, Deployment-Schlüssel, Secret-Manager. Diese Kategorie ist jünger und weniger kodifiziert, aber erfolgreiche Lieferketten-Angriffe treten dort immer häufiger ein. Dieselbe Logik, die die NIS2-Lieferantenklauseln in kritischen Verträgen begründet, gilt auch für interne Pipelines.

Wenn eine Aufsicht fragt „Wo wird MFA durchgesetzt?", muss die Antwort eine Liste sein — nicht „überall". Die Liste ist das Audit-Artefakt.

3. Warum SMS und TOTP allein nicht mehr genügen

Der Anhang der Durchführungsverordnung nennt SMS und TOTP nicht beim Namen. Er verweist die technische Spezifikation auf den „Stand der Technik" — eine Formel, die die Richtlinie bewusst verwendet, um zukunftsoffen zu bleiben. Gelesen 2026 ist der Stand der Technik für Hochrisikoklassen die phishing-resistente Authentifizierung: FIDO2- / WebAuthn-Sicherheitsschlüssel, Plattform-Authentikatoren mit Attestation (Windows Hello for Business, macOS Touch ID mit Attestation, aktuelles Android mit StrongBox) und über attestierte Cloud-Anbieter synchronisierte Passkeys.

Mehrfaktor ist das Wort in der Richtlinie. Phishing-resistent ist das Wort in jeder veröffentlichten Aufsichtsleitlinie seit 2023. NIS2-Einrichtungen sollten auf das zweite planen.

Die Authentifizierungsempfehlungen der ANSSI (Recommandations relatives à l'authentification multifacteur, 2023), die IT-Grundschutz-Anforderung ORP.4.A23 des BSI und die ENISA-Publikationen zur Identitätsverwaltung kommen zum selben Ergebnis: SMS-Einmalcodes sind anfällig für SIM-Swap und SS7-Abfang; TOTP-Apps schützen gegen Phishing nur, wenn der Nutzer eine falsche Domain bemerkt. Für administrative Zugriffe und Fernzugriffe erreicht keiner der Faktoren die implizite „Stand der Technik"-Latte, die eine Aufsicht 2026 anlegen wird.

Die praktische Folge: Der Rollout-Plan erbt eine Zielarchitektur. Phishing-resistent für die ersten drei Klassen (administrativ, Fern, exponierte Verwaltungsanwendungen), TOTP als Übergangsmaßnahme zulässig für die vierte (Zugriff auf sensible Daten durch nicht-privilegierte Beschäftigte), SMS bis zum Ende des nächsten Budgetzyklus aus dem Geltungsbereich. Die SP 800-63B Digital Identity Guidelines des NIST — formal eine US-Norm, aber die internationale Referenz für Authenticator-Sicherheitsstufen — liefert die Granularität, um diese Entscheidungen zu dokumentieren.

4. Die Audit-Spur, die eine Aufsicht liest

Eine NIS2-Inspektion verlangt selten Einblick in die Konfiguration des Identitäts-Providers. Sie verlangt die Audit-Spur. Drei Artefakte tauchen in den veröffentlichten Inspektionsberichten von BSI und ACN durchgängig auf:

• Die vom Vorstand genehmigte Authentifizierungsrichtlinie. Ein Dokument — keine Wiki-Seite — das die Faktorstärke je Zugriffsklasse definiert, die Ausnahmen mit ihren kompensierenden Maßnahmen auflistet und am Datum der letzten Überprüfung unterzeichnet ist.
• Das Faktor-Einschreibungsregister. Eine Liste je System der Konten, für die ein MFA-Faktor eingeschrieben ist, mit Faktortyp und Einschreibungsdatum. Das Register beantwortet „Ist MFA tatsächlich aktiv?" — nicht „Ist es vorgeschrieben?", was eine Richtlinie allein nicht belegen kann.
• Das Ausnahmen-Logbuch. Jedes System, in dem MFA nicht durchgesetzt wird — Legacy-Industriegeräte, Dienstkonten mit zertifikatsbasierter Authentifizierung — ist namentlich benannt, mit Grund, kompensierender Maßnahme und geplantem Abschaltdatum. Offene Ausnahmen, die älter als zwölf Monate sind, sind ein Warnsignal für die Aufsicht.

Der Verweis auf die jährliche unabhängige Prüfung des Sicherheitsprogramms in unserem Leitfaden zu den 21 NIS2-Maßnahmen schließt den Kreis — der Prüfer liest diese drei Dokumente und berichtet seine Feststellungen dem Vorstand. Ohne sie ist die technische Maßnahme für den Regulator unsichtbar.

5. Rollout, ohne den Betrieb zu brechen

Der Versagensmodus eines MFA-Rollouts ist nicht die Faktorwahl. Es ist die Aussperrung — ein privilegiertes Konto, das im schlechtesten Moment den Zugang zum zweiten Faktor verliert. Drei Maßnahmen aus den veröffentlichten Leitfäden senken dieses Risiko:

• Zwei Faktoren zweier unterschiedlicher Typen für jedes Administrator-Konto, der zweite Faktor offline gelagert und für das Incident-Response-Team der Einrichtung binnen zwei Stunden verfügbar.
• Stufenweises Einschreiben nach Zugriffsklasse, nicht nach Nutzergruppe. Administrativer Zugriff zuerst (kleine Population, hohe Auswirkung), exponierte Anwendungen zweitens, Zugriff auf sensible Daten zuletzt. Die NIS2-Selbsteinschätzungs-Checkliste gibt die Reihenfolge vor, die die Klassifizierungsmatrix des Regulators impliziert.
• Vorbereitete Break-Glass-Verfahren, dokumentiert und jährlich getestet. Das Break-Glass-Konto selbst wird bei jeder Nutzung überwacht; eine Nutzung, die keiner geplanten Änderung entspricht, wird als erheblicher Vorfall nach Artikel 23 behandelt und gemeldet.

Das 2026 beobachtbare Aufsichtsmuster ist gegenüber der Rollout-Geschwindigkeit nicht punitiv — sofern die Dokumentation vorliegt. Einrichtungen, die 2027 noch SMS für administrative Zugriffe einsetzen, werden in einem anderen Gespräch stehen.

Wie gute Umsetzung aussieht

Drei Signale tauchen in den veröffentlichten Inspektionsberichten nationaler Behörden, die ihre Vollzugsmethodik geteilt haben, immer wieder auf:

1. Eine vom Vorstand genehmigte Authentifizierungsrichtlinie — versioniert, datiert, unterzeichnet im Rahmen von Artikel 20 der Richtlinie, mit Differenzierung der Faktorstärke nach Zugriffsklasse und namentlich benannten Ausnahmen.
2. Ein lebendes Einschreibungsregister — exportiert aus dem Identitäts-Provider in die GRC-Plattform der Einrichtung, mindestens monatlich aktualisiert, mit Abdeckung von 100 % der administrativen und Fern-Zugriffskonten.
3. Ein Abschaltplan für schwächere Faktoren — verbindlich schriftlich festgehaltene Abkündigungstermine für SMS und nicht-attestiertes TOTP, mit vierteljährlichem Fortschrittsbericht an den Vorstand.

Keines dieser Dokumente verlangt eine neue Technologie. Sie verlangen, dass die in der Produktion bereits laufenden Maßnahmen schriftlich festgehalten werden — bevor die Aufsicht sie verlangt.

Quellen

1. Richtlinie (EU) 2022/2555, Artikel 21(2)(j) (Risikomanagementmaßnahmen für Cybersicherheit).
2. Durchführungsverordnung (EU) 2024/2690 der Kommission vom 17. Oktober 2024 (technische und methodische Anforderungen).
3. ENISA — Identity Management for Electronic Identification (namentlich genannt).
4. ANSSI — Recommandations relatives à l'authentification multifacteur et aux mots de passe (2023).
5. BSI — IT-Grundschutz-Kompendium, Baustein ORP.4.A23 (Mehrfaktor-Authentifizierung für administrative Zugriffe).
6. NIST — Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management.