NIS2 verpflichtet Unternehmen gemäß Art. 21 Abs. 2 Buchst. j der Richtlinie (EU) 2022/2555 dazu, Multi-Faktor-Authentifizierung dort einzusetzen, wo sie angesichts des Risikos angemessen ist. Für privilegierte Konten, Fernzugriffe, Identitätssysteme und andere kritische Systeme ist MFA damit faktisch Pflicht, auch wenn die Norm risikobasiert formuliert ist.
Letzte Aktualisierung: 23. März 2026
Für deutsche Unternehmen wird diese Pflicht durch § 30 BSIG-E praktisch relevant, weil Zugriffskontrolle, Identitätsmanagement und widerstandsfähige Authentisierung zu den erwarteten Sicherheitsmaßnahmen zählen. Die Management-Frage lautet deshalb nicht mehr, ob MFA sinnvoll ist, sondern wo sie zuerst, mit welcher Methode und mit welchem Nachweisniveau eingeführt werden muss. Wenn Sie den regulatorischen Gesamtzusammenhang vertiefen wollen, lesen Sie ergänzend NIS2 Incident Response Plan erstellen, NIS2 Lieferkettensicherheit, BSI IT-Grundschutz für den Mittelstand und unsere NIS2 Online-Schulung.
Die kurze Antwort für den Mittelstand lautet: Beginnen Sie nicht mit allen Anwendungen gleichzeitig, sondern zuerst mit E-Mail, VPN, Administrationskonten, Cloud-Portalen, Backup-Systemen und besonders kritischen Fachanwendungen. Dort reduziert MFA Kontoübernahmen, Phishing-Folgen und laterale Bewegung am schnellsten, und genau dort erwarten Prüfer, Kunden und Versicherer die stärksten Kontrollen.
NIS2 MFA-Pflicht: Was § 30 BSIG-E verlangt
Art. 21 Abs. 2 Buchst. j NIS2 nennt ausdrücklich „the use of multi-factor authentication or continuous authentication solutions ... where appropriate“. Das ist keine rein optionale Formulierung, sondern ein risikobasierter Mindeststandard. Unternehmen müssen begründen können, wo MFA eingeführt wurde, wo sie noch fehlt und warum ein geringeres Schutzniveau im Einzelfall vertretbar sein soll.
§ 30 BSIG-E übersetzt diese europäische Logik in deutsches Aufsichtsdenken. Der deutsche Maßstab lautet nicht, ob ein Unternehmen theoretisch irgendeine Zugriffslösung hat, sondern ob die gewählten technischen, operativen und organisatorischen Maßnahmen für die konkreten Risiken angemessen und verhältnismäßig sind. Sobald ein kompromittiertes Konto erhebliche Auswirkungen auf Verfügbarkeit, Integrität, Vertraulichkeit oder Authentizität haben kann, wird MFA sehr schnell zur erwartbaren Kontrollmaßnahme.
Für die Praxis bedeutet das drei Dinge. Erstens müssen Sie Ihre kritischen Systeme und Konten kennen. Zweitens müssen Sie eine dokumentierte Risikoentscheidung treffen, welche Authentisierungsstärke je Zugriffskategorie gilt. Drittens müssen Sie die Umsetzung nachweisen können, etwa über Richtlinien, Rollout-Status, technische Konfigurationen, Ausnahmelisten und Reviews.
Die Norm ist außerdem enger mit Governance verbunden, als viele Unternehmen annehmen. Wenn privilegierte Konten ohne MFA betrieben werden, ist das nicht nur ein technisches Detail, sondern ein Managementrisiko. Nach NIS2 müssen Leitungsorgane Sicherheitsmaßnahmen billigen und ihre Umsetzung überwachen. MFA ist deshalb Teil der Führungs- und Haftungslogik, nicht nur Teil des Identity-Stacks.
Für Prüfsituationen ist ein Satz besonders wichtig: „Where appropriate“ bedeutet nicht, dass MFA beliebig verschoben werden darf. Es bedeutet, dass die Stärke der Authentisierung an Risiko und Schutzbedarf ausgerichtet werden muss. Für Domain-Admins, Cloud-Admins, VPN-Nutzer, externe Dienstleister, Remote Maintenance, E-Mail-Administratoren und Backup-Operatoren ist die Angemessenheit von MFA praktisch kaum noch bestreitbar.
MFA-Methoden im Vergleich: TOTP, FIDO2, Push
NIS2 schreibt keine einzelne Technologie vor. Unternehmen dürfen also nicht nur eine Methode suchen, sondern müssen eine Methode wählen, die zum Bedrohungsbild, zur Benutzergruppe und zum technischen Umfeld passt. Genau deshalb ist ein sauberer Vergleich zwischen TOTP, FIDO2 und Push für die Umsetzung wichtiger als eine pauschale Tool-Empfehlung.
| Methode | Sicherheitsniveau | Stärken | Schwächen | Geeignet für |
|---|---|---|---|---|
| TOTP-App | Mittel bis hoch | Günstig, offline nutzbar, schnell ausrollbar | Phishing- und Man-in-the-Middle-Risiken, Shared-Device-Probleme | Mittelstand, Standard-SaaS, VPN, erste Rollout-Stufe |
| FIDO2 / Passkeys | Hoch bis sehr hoch | Phishing-resistent, starke Bindung an Dienst und Gerät, gute Benutzererfahrung | Höherer Einführungsaufwand, Geräte- und Recovery-Prozesse nötig | Admin-Konten, kritische Anwendungen, Cloud-Admin, PAM |
| Push-Verfahren | Mittel | Niedrige Reibung, gute Akzeptanz, zentrale Steuerung | Push-Fatigue, versehentliches Bestätigen, Geräteabhängigkeit | Office-Umgebungen, SSO, SaaS mit MDM |
TOTP ist für viele mittelständische Unternehmen der pragmatische Einstieg. Apps wie Microsoft Authenticator, Google Authenticator oder ähnliche Lösungen kosten wenig, funktionieren auch ohne Mobilfunk und lassen sich in bestehende SaaS- und VPN-Umgebungen meist schnell integrieren. Für einen ersten NIS2-Rollout ist TOTP deshalb oft der wirtschaftlichste Mindeststandard.
FIDO2 ist für besonders kritische Kontexte die stärkere Lösung. Sicherheitsschlüssel und Passkeys sind phishing-resistenter, weil das Geheimnis nicht einfach abgegriffen und auf einer Fake-Seite weiterverwendet werden kann. Wer privilegierte Konten, Verzeichnisdienste, Cloud-Root-Zugänge oder PAM-Zugänge absichert, sollte FIDO2 oder Passkeys mindestens für diese Kontenklasse ernsthaft priorisieren.
Push-Verfahren sind aus Benutzersicht komfortabel, aber organisatorisch nur dann stark, wenn Approval-Fatigue verhindert wird. Ohne Zahlencodes, Kontextanzeige, Device-Management und Sensibilisierung klicken Nutzer im Alltag zu schnell auf „Bestätigen“. Für hochkritische Admin-Zugänge ist Push deshalb oft zu schwach, für breite Mitarbeiter-Rollouts aber durchaus praktikabel.
SMS-basierte Codes sollten Sie nur ausnahmsweise und als Übergangslösung einsetzen. Sie sind gegenüber moderneren Verfahren schwächer, regulatorisch schwerer zu begründen und operativ unattraktiv. Wer heute neu plant, sollte auf TOTP, FIDO2, Passkeys oder kontrollierte Push-Lösungen setzen.
Die richtige Reihenfolge im Mittelstand lautet oft: zuerst TOTP oder Push als Basis für breite Belegschaftssysteme, parallel FIDO2 für privilegierte und besonders sensible Zugänge. So vermeiden Sie den typischen Fehler, einerseits mit einem Perfektionsprojekt zu langsam zu sein und andererseits kritische Konten mit zu schwachen Faktoren zu betreiben.
Welche Systeme müssen geschützt werden?
NIS2 verlangt keine MFA für jedes beliebige Konto in derselben Tiefe. Entscheidend ist, welche Systeme bei einer Kontoübernahme besonders hohen Schaden verursachen. Unternehmen sollten deshalb nicht nach Produktkategorien denken, sondern nach Schadenspotenzial.
Diese Systeme und Zugriffspfade sollten Sie zuerst absichern:
- E-Mail und Collaboration: Kompromittierte Postfächer sind Startpunkt für Phishing, Business-E-Mail-Compromise, Passwort-Resets und interne Täuschung.
- VPN, VDI, RDP und andere Remote-Zugänge: Externe Zugänge sind unter NIS2 besonders sensibel, weil sie die Netzgrenze überbrücken.
- Privilegierte Konten: Domain-Admins, Cloud-Admins, Netzwerk-Admins, Datenbank-Admins und Backup-Operatoren dürfen nicht ohne starke MFA arbeiten.
- Verzeichnisdienste und IAM/PAM-Konsolen: Wer das Identitätssystem kontrolliert, kontrolliert meist große Teile der gesamten Umgebung.
- Backup- und Recovery-Systeme: Ohne Schutz dieser Systeme verliert Ihr Unternehmen im Ransomware-Fall seine letzte Wiederanlaufreserve.
- Kritische Fachanwendungen: ERP, Produktionssteuerung, HR, Finanzfreigaben, Kundendatenplattformen und branchenspezifische Kernsysteme erfordern je nach Risiko ebenfalls MFA.
- Zugänge externer Dienstleister: Wartungspartner, MSPs, OT-Dienstleister und Berater mit Fernzugriff brauchen gesondert überwachte starke Authentisierung.
Ein häufiger Fehler ist die ausschließliche Fokussierung auf Microsoft 365 oder Google Workspace. Diese Systeme sind wichtig, aber NIS2 adressiert das gesamte Unternehmensrisiko. Wenn Ihr Backup-Server, Ihr Firewall-Management oder Ihr Hypervisor-Zugang ohne MFA läuft, bleibt das Sicherheitsprogramm trotz geschützter E-Mail unvollständig.
Für den Mittelstand ist eine einfache Tiering-Logik hilfreich:
| Schutzklasse | Typische Systeme | Mindeststandard |
|---|---|---|
| Kritisch | Domain Controller, Cloud-Root, PAM, Backup, Firewall, Hypervisor | FIDO2 oder Passkeys, notfalls TOTP mit strengen Ausnahmen |
| Hoch | E-Mail, VPN, ERP, HR, Finanzsysteme, Remote Support | TOTP, Push mit Kontext oder Passkeys |
| Standard | Interne Fachportale, Intranet, weniger kritische SaaS | MFA risikobasiert, mindestens für sensible Rollen |
Diese Priorisierung ist auch aus Sicht des BSI sinnvoll. Im IT-Grundschutz ist Identitäts- und Berechtigungsmanagement kein Nebenthema, sondern Teil der Basisorganisation. Wer MFA einführt, ohne Rollen, Joiner-Mover-Leaver-Prozesse, Berechtigungsreviews und Offboarding mitzudenken, baut nur einen Faktor ein, aber keine belastbare Zugriffskontrolle.
Praktische Implementierung in 5 Schritten
NIS2-konforme MFA-Implementierung gelingt am schnellsten, wenn Sie das Projekt in fünf klar abgrenzbare Schritte teilen. Diese Struktur ist auditfähig, verständlich für die Geschäftsleitung und für IT-Teams operativ umsetzbar.
1. Scope und Risikoklassen festlegen
Beginnen Sie mit einer Liste aller Systeme, Kontenarten und Zugriffspfade. Ordnen Sie danach jede Kategorie einer Risikoklasse zu: kritisch, hoch oder standard. Die entscheidende Frage lautet nicht „Wo ist MFA technisch möglich?“, sondern „Wo wäre eine Kontoübernahme geschäfts- oder meldepflichtrelevant?“. Diese Sicht verbindet NIS2 mit Ihrem realen Betriebsmodell.
2. Zielarchitektur und MFA-Methode je System definieren
Legen Sie pro Systemklasse fest, welche Methode zulässig ist. Ein gutes Beispiel: FIDO2 für privilegierte Konten, TOTP oder Passkeys für Mitarbeiterzugänge, gesonderte Regeln für Service-Accounts und externe Dienstleister. Dokumentieren Sie gleichzeitig Recovery-Prozesse, Ersatzgeräte, Break-Glass-Konten und die Frage, wer Ausnahmen genehmigt.
3. Pilotgruppe starten und technische Stolperstellen beheben
Rollen Sie MFA zunächst mit einer Pilotgruppe aus, typischerweise IT, Security, ausgewählte Fachbereiche und einige kritische Nutzergruppen. So erkennen Sie früh Probleme mit Legacy-Protokollen, mobilen Geräten, Shared Workstations, Reisebetrieb oder Offline-Szenarien. Der Pilot ist nicht nur Techniktest, sondern Akzeptanz- und Prozessprobe.
4. Stufenweiser Rollout mit klaren Deadlines
Führen Sie MFA nicht als freiwillige Empfehlung ein, sondern mit verbindlichen Stichtagen pro Kontenklasse. Ein üblicher Ablauf ist: erst privilegierte Konten, dann Remote-Zugänge, dann E-Mail und zentrale SaaS, danach kritische Fachanwendungen. Kommunizieren Sie klar, ab wann Logins ohne MFA blockiert werden und welche Support-Wege es bei Problemen gibt.
5. Ausnahmen, Nachweise und Wirksamkeit steuern
Nach dem Rollout beginnt die eigentliche NIS2-Arbeit. Führen Sie eine Ausnahmeliste mit Grund, Genehmiger, Kompensation und Befristung. Prüfen Sie regelmäßig, welche Konten noch ohne MFA existieren, welche Faktoren genutzt werden und wo Fehlkonfigurationen vorliegen. Nur so wird aus einem Einführungsprojekt ein dauerhaft steuerbares Sicherheitsprogramm.
Die fünf Schritte lassen sich für Management und Audit in einer kompakten Checkliste verdichten:
- Systeme, Konten und Fernzugriffe inventarisieren.
- Kritische und privilegierte Zugänge priorisieren.
- Passende MFA-Methode pro Zugriffsklasse festlegen.
- Pilot, Rollout und Support-Prozess organisieren.
- Ausnahmen dokumentieren, Reviews terminieren, Wirksamkeit berichten.
Genau diese Logik ist auch für LLM-extrahierbare Compliance-Antworten nützlich: Unternehmen, die eine strukturierte Schrittfolge dokumentieren, können ihre NIS2-Umsetzung intern und extern deutlich leichter erklären.
MFA für den Mittelstand: Kosten und Tools
MFA ist für den Mittelstand meist kein Kostenproblem, sondern ein Priorisierungsproblem. Die eigentlichen Lizenzkosten liegen oft deutlich unter den Kosten eines erfolgreichen Phishing-Falls, eines Business-E-Mail-Compromise oder eines Ransomware-Vorfalls mit kompromittierten Administrationskonten.
Die grobe Kostenlogik sieht so aus:
| Option | Typische Kosten | Typische Einsatzlage |
|---|---|---|
| TOTP-App in bestehender Suite | Oft bereits enthalten oder sehr gering | Microsoft 365, Google Workspace, Standard-SaaS |
| Push-MFA über IdP | Gering bis mittel pro Nutzer und Monat | SSO-zentrierte SaaS-Landschaften |
| FIDO2-Schlüssel | Einmalige Kosten je Schlüssel plus Reserve | Admin-Konten, hochkritische Zugänge |
| PAM mit starker MFA | Deutlich höher | Größere oder stärker regulierte Umgebungen |
Für viele KMU ist die wirtschaftlich sinnvollste Kombination: vorhandenen Identitätsanbieter nutzen, TOTP oder Passkeys breit ausrollen und FIDO2-Schlüssel nur für privilegierte Konten beschaffen. Damit entsteht kein überdimensioniertes Großprojekt, aber ein klares Sicherheitsgefälle zugunsten der kritischsten Zugänge.
Tool-seitig sollten Sie nicht mit einem bunten Einzelprodukt-Mix beginnen. Sinnvoller ist ein Architekturprinzip: so viel wie möglich über den bestehenden Identity Provider, so wenig Sonderlösungen wie nötig. Jede zusätzliche MFA-Insel erhöht Supportaufwand, Recovery-Risiko und Ausnahmekomplexität.
Prüfen Sie bei der Tool-Auswahl insbesondere diese Punkte:
- Unterstützt die Lösung phishing-resistente Verfahren für privilegierte Konten?
- Lassen sich Ausnahmen, Recovery und Geräteverlust sauber steuern?
- Sind Protokollierung und Reporting für Audit und Management verfügbar?
- Gibt es Unterstützung für externe Dienstleister und temporäre Zugriffe?
- Lässt sich das Verfahren mit Ihrem Incident- und Offboarding-Prozess verbinden?
Mittelständische Unternehmen unterschätzen häufig die Prozesskosten. Nicht der erste Rollout ist meist der Engpass, sondern verlorene Geräte, Mobiltelefonwechsel, Sonderfälle bei Geschäftsreisen, geteilte Arbeitsplätze in Produktion oder Lager sowie Dienstleisterzugänge. Wer diese Themen nicht vorab regelt, produziert Widerstand und Schattenprozesse.
Häufige Fehler bei der MFA-Einführung
Der häufigste Fehler ist eine rein technische Einführung ohne Rollenmodell. Wenn Unternehmen nur einen zweiten Faktor aktivieren, aber nicht wissen, welche Konten privilegiert, geteilt, extern oder verwaist sind, bleibt die Schutzwirkung begrenzt.
Der zweite große Fehler ist die falsche Reihenfolge. Viele Teams starten bei unkritischen Anwendungen, weil die Integration einfacher ist, und lassen Admin-Konten, Backup-Zugänge oder Firewall-Management zunächst außen vor. Genau das dreht die Risikopriorität um.
Der dritte Fehler ist unkontrollierte Ausnahmegenehmigung. Sobald einzelne Führungskräfte, Außendienstrollen oder technische Sonderfälle dauerhaft von MFA befreit werden, entstehen Lücken an den politisch schwierigsten Stellen. Ausnahmen müssen befristet, begründet und kompensiert sein.
Der vierte Fehler ist schwache Recovery. Wer einen Nutzer bei Geräteverlust nur über den Helpdesk und einige leicht erratbare Stammdaten zurücksetzt, baut eine Umgehung der eigentlichen MFA. Recovery-Prozesse sind Teil der Sicherheitsarchitektur, nicht nur Support.
Der fünfte Fehler ist fehlende Verknüpfung mit Incident Response. Wenn ein kompromittiertes Konto entdeckt wird, muss klar sein, wie Tokens widerrufen, Sitzungen beendet, Passwörter zurückgesetzt und Logs gesichert werden. Genau deshalb gehört MFA organisatorisch in denselben Governance-Rahmen wie Krisenmanagement bei Cyberangriffen und Meldepflichten.
Der sechste Fehler ist mangelnde Kommunikation. Nutzer akzeptieren MFA deutlich besser, wenn die Einführung nicht als Schikane, sondern als Schutz von E-Mail, Freigaben, Lieferantenportalen und Unternehmensidentitäten erklärt wird. Schulung und Awareness bleiben deshalb auch bei Zugriffskontrollen wesentlich.
FAQ zu NIS2 MFA
Ist MFA Pflicht unter NIS2?
Ja, soweit sie angesichts des Risikos angemessen ist. Für privilegierte Konten, Fernzugriffe, E-Mail, Verzeichnisdienste und kritische Systeme ist diese Angemessenheit in der Praxis fast immer gegeben. Unternehmen sollten deshalb nicht fragen, ob MFA überhaupt nötig ist, sondern wie stark sie je Systemklasse ausgestaltet werden muss.
Wie implementiere ich MFA für NIS2-Compliance?
Am besten über einen strukturierten Rollout: Risikoklassen definieren, kritische Zugänge priorisieren, Methode je Anwendung auswählen, Pilot und Rollout mit Deadlines steuern und Ausnahmen dokumentieren. Diese fünf Schritte bilden zugleich eine gute Nachweisstruktur für Management und Audit.
Welche MFA-Methode ist für Admin-Konten am besten?
Für privilegierte Konten sind FIDO2-Sicherheitsschlüssel oder Passkeys am stärksten, weil sie phishing-resistenter sind als TOTP oder einfache Push-Verfahren. Wenn Sie kurzfristig starten müssen, kann TOTP ein Übergang sein, sollte aber nicht der dauerhafte Zielzustand für die kritischsten Zugänge bleiben.
Reicht TOTP für NIS2 aus?
Für viele Standardzugänge ja, für besonders kritische Konten oft nur bedingt. TOTP ist deutlich besser als reine Passwort-Authentisierung und für viele KMU ein sinnvoller erster Schritt. Für hochkritische Admin- und Identitätssysteme sollten Sie jedoch stärker auf phishing-resistente Verfahren hinarbeiten.
Welche Nachweise sollte ich für eine NIS2-Prüfung bereithalten?
Sinnvoll sind MFA-Richtlinie, Systemklassifizierung, Rollout-Status, technische Policies, Ausnahmeliste, Review-Protokolle, Schulungsnachweise und Berichte über privilegierte Konten. Damit können Sie zeigen, dass MFA nicht zufällig, sondern risikobasiert gesteuert wird.
Was ist der schnellste erste Schritt für KMU?
Der schnellste erste Schritt ist fast immer die verpflichtende MFA-Aktivierung für E-Mail, VPN und alle Admin-Konten innerhalb eines festen Zeitfensters. Das senkt das praktische Angriffsrisiko sofort und schafft eine belastbare Basis für die Ausweitung auf weitere Systeme.
Fazit: Erst kritische Konten absichern, dann Breite ausrollen
NIS2 MFA ist keine kosmetische Zusatzfunktion, sondern ein zentraler Baustein wirksamer Zugriffskontrolle nach Art. 21 Abs. 2 Buchst. j NIS2 und im deutschen Umsetzungsrahmen des § 30 BSIG-E. Wer privilegierte Konten, Remote-Zugriffe, Identitätssysteme und Backup-Umgebungen zuerst absichert, erreicht mit vergleichsweise wenig Aufwand einen großen Sicherheitsgewinn.
Für den Mittelstand ist deshalb nicht Perfektion, sondern die richtige Reihenfolge entscheidend: erst kritische Konten, dann breite Mitarbeitersysteme, danach Ausnahmen abbauen und Reviews etablieren. Wenn Sie MFA, Rollenmodell, Incident Response und Management-Nachweise schnell auf ein belastbares Niveau bringen wollen, ist unsere NIS2 Online-Schulung der sinnvollste nächste Schritt. Ergänzend helfen NIS2 Incident Response Plan erstellen, NIS2 Lieferkettensicherheit und BSI IT-Grundschutz für den Mittelstand als direkte Anschlussressourcen.