MFA unter NIS2: wo ist sie wirklich Pflicht und wie umsetzen?

Die rechtliche Grundlage

Art. 21 Abs. 2 NIS2 zählt unter den Buchstaben a bis j zehn Mindestmaßnahmen auf. Buchstabe j lautet: „Verwendung von Lösungen zur Multi-Faktor-Authentifizierung oder kontinuierlichen Authentifizierung, gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls gesicherte Notfallkommunikationssysteme innerhalb der Einrichtung". Das deutsche Recht übernimmt diesen Wortlaut in § 30 Abs. 2 Nr. 10 BSIG.

Drei Punkte sind für die Praxis entscheidend:

• „Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierung": Das Gesetz lässt beide Wege zu. Das BSI ordnet kontinuierliche Authentifizierung allerdings als reaktiv ein: Sie könne eine Kompromittierung nicht verhindern, sondern nur den Schaden reduzieren.
• „gegebenenfalls" bezieht sich nur auf die gesicherten Notfallkommunikationssysteme, nicht auf die Authentifizierung.
• Verhältnismäßigkeit ergibt sich aus Art. 21 Abs. 1 NIS2 und § 30 Abs. 1 BSIG. Sie erlaubt es, Umfang und Stärke der Maßnahmen an Risiko und Größe anzupassen. Die Pflicht zur Maßnahme selbst hebt sie nicht auf.

Wo MFA ansetzen sollte: risikobasiert priorisieren

Das BSI empfiehlt, die eigenen Systeme in der Risikoanalyse auf die potenzielle Schadensauswirkung bei einer Kompromittierung zu untersuchen. Eine mögliche Priorisierung, die aus einer solchen Analyse folgen kann (keine BSI-Vorgabe):

Zuerst:

• administrative und privilegierte Konten (Domain-Admins, Datenbank-Owner, Cloud-Admin-Konten),
• Fernzugriffe über VPN oder Zero-Trust-Lösungen,
• Konten der Geschäftsleitung mit Zugang zu sensiblen Daten.

Danach:

• E-Mail-Zugänge aller Mitarbeitenden,
• Zugriffe auf Personal-, Finanz- und Kundendaten,
• Cloud-Anwendungen mit produktiven Daten.

Je nach Risiko:

• Konten ohne Zugriff auf sensible Daten,
• Gäste- und Lieferantenzugänge mit eingeschränkten Rechten.

Die Einordnung und ihre Begründung gehören in die Dokumentation nach § 30 Abs. 1 BSIG.

MFA-Methoden im Vergleich

Microsoft hat Number Matching für alle Push-Benachrichtigungen im Microsoft Authenticator aktiviert; Nutzer können es nicht abschalten (Microsoft Learn). Der Nutzer muss dabei eine auf dem Anmeldebildschirm angezeigte Zahl in der App eingeben, was Angriffe durch massenhafte Push-Anfragen erschwert.

Umsetzung in Microsoft 365 und Google Workspace

Für viele KMU laufen die kritischen Anwendungen über Microsoft 365 oder Google Workspace.

Microsoft 365:

• MFA über Conditional-Access-Richtlinien steuern. Dafür ist eine Lizenz mit Microsoft Entra ID P1 oder P2 nötig.
• Für Admin-Konten phishingresistente Methoden wie FIDO2-Schlüssel oder Passkeys hinterlegen.
• Die Anmeldehäufigkeit bewusst festlegen: Der Standard von Entra ID ist ein rollierendes Fenster von 90 Tagen. Für kritische Anwendungen lässt sich per Conditional Access eine kürzere Anmeldefrequenz erzwingen.

Google Workspace:

• Bestätigung in zwei Schritten für die Domain verpflichtend machen,
• Sicherheitsschlüssel oder Passkeys für Admin-Konten vorschreiben,
• für Konten mit hohem Risiko das Advanced Protection Program prüfen.

Die technische Konfiguration ist in beiden Umgebungen überschaubar. Den größeren Aufwand machen in der Regel Kommunikation, Registrierung der Geräte und die Erreichbarkeit des Helpdesks am Umstellungstag.

Sonderfall: OT-Umgebungen und Industrieanlagen

In Produktionsumgebungen, SCADA-Systemen und industriellen Steuerungen ist MFA oft technisch schwieriger:

• Maschinen- und Dienstkonten lassen sich nicht klassisch mit MFA versehen,
• gemeinsam genutzte Bedienplätze im Schichtbetrieb erschweren persönliche Faktoren,
• Notfallzugriffe brauchen dokumentierte Ausnahmeprozesse.

Ein verbreiteter Ansatz ist Privileged Access Management (PAM): Der Administrator oder Servicetechniker authentifiziert sich mit MFA am PAM-System, das den Zugang zu den OT-Systemen vermittelt und die Sitzung protokolliert. MFA sitzt damit vor den Anlagen, ohne dass jede einzelne Komponente angepasst werden muss. Die Begründung für diese Lösung gehört ebenfalls in die Dokumentation.

Praxis: Roll-out in Etappen

1. Inventar: Wer hat Admin-Rechte, welche Konten greifen auf welche Systeme zu?
2. Methode je Risikoklasse festlegen: phishingresistente Verfahren für Admins, Push mit Number Matching oder App für die Belegschaft, Rückfallmethode definieren.
3. Pilot mit dem IT-Team, um Sonderfälle zu finden.
4. Kommunikation: Information der Geschäftsleitung, Anleitung für Mitarbeitende, FAQ für den Helpdesk.
5. Roll-out in Wellen: Admin-Konten, Geschäftsleitung, dann die Belegschaft.
6. OT und Sonderkonten als eigenes Teilprojekt.
7. Dokumentation: Richtlinien, Ausnahmen und Begründungen festhalten (§ 30 Abs. 1 BSIG).

FAQ

Reicht es, wenn nur die Admin-Konten MFA haben?

Das Gesetz nennt keine Kontenliste, entscheidend ist die dokumentierte Risikoanalyse. E-Mail-Konten sind ein häufiger Angriffsweg und erlauben oft das Zurücksetzen weiterer Passwörter. Eine Analyse, die sie ohne Begründung ausklammert, ist schwer zu vertreten. Admin-MFA ist der wichtigste erste Schritt.

Was ist mit Lieferanten und externen Dienstleistern?

Wer als Externer auf eigene Systeme zugreift, sollte denselben Anforderungen unterliegen. Die Sicherheit der Lieferkette ist eine eigene Mindestmaßnahme (Art. 21 Abs. 2 lit. d NIS2, § 30 Abs. 2 Nr. 4 BSIG) und wird üblicherweise im Vertrag geregelt.

Sind biometrische Verfahren zulässig?

Biometrie kommt meist als Entsperrung eines Besitzfaktors zum Einsatz, etwa bei Passkeys auf dem Smartphone oder bei Windows Hello. Das BSI führt Biometrie als eigene Faktor-Kategorie neben Wissen und Besitz, empfiehlt aber, eine Authentifizierung allein anhand von Biometrie zu deaktivieren (Checkliste zum NIS-2-Infopaket MFA, BER.5.2).

Wie oft muss MFA neu abgefragt werden?

Das Gesetz legt keine Frequenz fest. In Microsoft Entra ID ist der Standard ein rollierendes Fenster von 90 Tagen. Microsoft weist darauf hin, dass zu häufige Abfragen Nutzer daran gewöhnen, Anmeldedaten gedankenlos einzugeben. Für kritische Anwendungen und privilegierte Aktionen lässt sich die Anmeldefrequenz per Conditional Access verkürzen.

Wer trägt die Kosten für Hardware-Schlüssel?

Die Maßnahme ist eine Pflicht der Einrichtung, die Beschaffung trägt daher üblicherweise der Arbeitgeber. Sinnvoll ist ein Ersatzschlüssel je Person, damit ein Verlust nicht zu unsicheren Rückfallwegen führt. Wer stattdessen Authenticator-Apps auf privaten Smartphones nutzen will, sollte das mit den Beschäftigten und gegebenenfalls dem Betriebsrat regeln.