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

Die rechtliche Grundlage in Art. 21 Abs. 2

Die 11 Mindestmaßnahmen aus Art. 21 NIS2 enthalten unter lit. j) die Authentifizierungs-Pflicht. Der genaue Wortlaut: „die Verwendung von Lösungen zur sicheren Authentifizierung mit mehreren Faktoren oder kontinuierlicher Authentifizierung, gesicherten Sprach-, Video- und Textkommunikationen sowie gesicherten Notfall-Kommunikationssystemen innerhalb der Einrichtung, sofern angemessen".

Drei Stichworte sind hier zentral:

• „mehrere Faktoren oder kontinuierliche Authentifizierung" — klassisches MFA oder moderne risikobasierte/kontinuierliche Authentifizierung
• „sofern angemessen" — Verhältnismäßigkeit als Begrenzung
• „innerhalb der Einrichtung" — bezieht sich auf die internen Systeme, nicht nur auf Kunden-Frontends

Die Konkretisierung erfolgt in der nationalen Umsetzung und in den Implementing Acts der EU-Kommission. Für die deutsche Praxis sind die BSI-IT-Grundschutz-Empfehlungen und die ENISA Authentication Methods Recommendations die etablierten Bezugsdokumente.

Wo MFA Pflicht ist: Risiko-basierter Ansatz

Die Aufsichtspraxis (in DE noch im Aufbau, in FR/IT bereits etabliert) folgt einem klaren Stufen-Modell:

Pflicht-Stufe 1 (immer MFA):

• Administrative und privilegierte Accounts (Domain-Admins, Datenbank-Owner, Cloud-Admin-Konten)
• Remote-Zugriffe über VPN oder Zero-Trust-Lösungen
• Zugriffe auf das BSI-Meldeportal und ähnliche kritische Systeme
• Geschäftsleitungs-Accounts mit Zugang zu sensitiven Daten

Pflicht-Stufe 2 (regelmäßig MFA):

• E-Mail-Zugänge aller Mitarbeitenden (Hauptangriffsvektor)
• Zugriffe auf Personaldaten, Finanzdaten, geistiges Eigentum
• Vertriebssysteme und CRM mit Kundendaten
• Cloud-Anwendungen mit produktiven Daten

Empfohlen, je nach Risiko:

• Standard-Office-Accounts ohne erhöhtes Risiko
• Gäste-/Lieferanten-Zugänge mit eingeschränkter Rechte-Lage

Die Differenzierung erfolgt nach Schutzbedarf der Daten und Kritikalität der Anwendungen. Dokumentation der Risikoeinschätzung ist Pflicht.

Akzeptable MFA-Methoden im Vergleich

BSI-/ENISA-Empfehlung: SMS-OTP wird zunehmend als Mindeststandard eingestuft, der nur in Übergangsphasen akzeptabel ist. Für privilegierte Accounts sollte Hardware-Token oder Plattform-Authenticator verwendet werden. Push-Notifications mit Number-Matching haben sich in 2023/2024 als praktischer Mittelweg etabliert — sehr hoher Komfort bei deutlich verbesserter Phishing-Resistenz gegenüber klassischen Push-Benachrichtigungen.

Praktische Umsetzung in Microsoft 365 und Google Workspace

Für die meisten KMU laufen die kritischen Anwendungen über Microsoft 365 oder Google Workspace. Die MFA-Umsetzung ist dort technisch trivial:

Microsoft 365:

• Conditional Access Policies aktivieren (M365 Business Premium oder höher)
• MFA für alle Nutzer in einer einzigen Policy konfigurieren
• Number Matching aktivieren (seit 2023 Standard)
• Geräte-basierte Compliance-Checks (Intune) für privilegierte Accounts
• FIDO2-Hardware-Keys für Admin-Accounts ausrollen

Google Workspace:

• Mandatory 2-Step Verification auf Domain-Level
• Authenticator-App oder Security Keys als Methode
• Advanced Protection Program für Admin-Konten
• Context-Aware Access für sensitive Apps

In beiden Plattformen ist der technische Roll-out in wenigen Stunden machbar. Die organisatorische Vorbereitung — Kommunikation, Schulung, Helpdesk-Bereitschaft — braucht 2-4 Wochen.

Sonderfall: OT-Umgebungen und Industrie-Anlagen

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

• Maschinen-Login-Konten lassen sich nicht klassisch mit MFA versehen
• Schichtwechsel mit MFA-Codes funktioniert nur mit Hardware-Token an der Anlage
• Notfall-Zugriffe brauchen Ausnahme-Prozesse

Die Lösung: Privileged Access Management (PAM) für privilegierte OT-Zugänge. PAM-Lösungen authentifizieren den Administrator/Servicetechniker mit MFA, übernehmen dann die Login-Vorgänge in die OT-Systeme automatisch und protokollieren die Aktivität. Damit ist MFA „upstream" gesichert, ohne dass jede einzelne OT-Komponente angefasst werden muss.

Für die NIS2-Aufsicht ist die Kombination MFA + PAM + Audit-Logging der akzeptierte Standard in OT-Umgebungen.

Praxis: MFA-Roll-out in zwei Wochen

Detaillierter Plan:

1. Inventar privilegierter Accounts — wer hat Admin-Rechte? Welche Accounts greifen auf welche Systeme zu?
2. MFA-Methode pro Risiko-Klasse festlegen — Hardware für Admin, Push für Standard, Token-App als Fallback
3. Pilot mit IT-Team — eine Woche, alle Edge-Cases aufdecken
4. Kommunikations-Welle — Geschäftsleitung-Briefing, Mitarbeiter-Schreiben, Helpdesk-FAQ, Schulungs-Video
5. Roll-out in Wellen — Admin-Konten zuerst, dann Geschäftsleitung, dann breite Belegschaft
6. OT-Sonderprojekt — PAM einführen, falls nicht vorhanden
7. Audit und Dokumentation — Conditional Access Policies, Ausnahmen, Begründungen — alles für die NIS2-Selbstprüfung dokumentieren

FAQ

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

Nein. Die Pflicht aus Art. 21 lit. j) zielt auf alle Authentifizierungen mit erhöhtem Risiko — das umfasst E-Mail-Zugänge der gesamten Belegschaft (häufigster Angriffsvektor) und Zugänge zu sensitiven Anwendungen. Eine reine Admin-MFA reicht für die Pflichterfüllung nicht aus, ist aber der wichtigste erste Schritt.

Was ist mit Lieferanten und externen Dienstleistern?

Externe, die auf eure Systeme zugreifen, müssen ebenfalls MFA verwenden. Das ist im Lieferanten-Vertrag zu regeln (Art. 21 lit. d) — Lieferketten-Sicherheit). Bei Zero-Trust-Architekturen wird der externe Zugriff durch die eigene Authentifizierungs-Infrastruktur geleitet — MFA ist dann automatisch eingebettet.

Sind biometrische Verfahren akzeptabel?

Biometrie als zweiter Faktor (z.B. Fingerprint zur Entsperrung des Authenticators) ist State-of-the-Art und wird von BSI und ENISA empfohlen. Reine Biometrie ohne Wissens- oder Besitzfaktor reicht in den meisten Standards nicht aus — daher die Kombination „etwas, das du weißt + etwas, das du bist" oder „etwas, das du hast + etwas, das du bist".

Wie oft muss MFA neu durchlaufen werden?

Das hängt vom Risiko ab. Standard-Office-Anwendungen: typisch 14-30 Tage Session-Lifetime. Privilegierte Aktionen (Admin-Tasks, Zugang zu sensitiven Daten): jede Session, ggf. mit kürzerer Lifetime. Die Microsoft-Conditional-Access-Standards orientieren sich an diesen Werten.

Wer trägt die Hardware-Token-Kosten?

Bei Mitarbeiter-Hardware-Token (typisch 30-80 € pro Stück) trägt der Arbeitgeber die Kosten. Für 50 Mitarbeitende mit 2 Token pro Person (Haupt + Backup) ergeben sich Investitions-Kosten von 3.000-8.000 € einmalig. Push-basierte Authenticator-Apps auf dem privaten Smartphone der Mitarbeitenden sind eine günstigere Alternative — erfordern aber eine arbeitsrechtliche Vereinbarung.