NIS2 Maßnahme 10 — Multi-Faktor-Authentifizierung (MFA)

NIS2 Multi-Faktor-Authentifizierung: Maßnahme 10 umsetzen

Letzte Aktualisierung: 21. März 2026

Die NIS2-Maßnahme 10 gemäß Art. 21(2)(j) der Richtlinie (EU) 2022/2555 verpflichtet betroffene Unternehmen, NIS2 Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierungslösungen sowie gesicherte Sprach-, Video- und Textkommunikation einzusetzen. Praktisch heißt das: Für privilegierte Konten, externe Zugriffe, VPN, E-Mail, Administrationsoberflächen und andere kritische Systeme ist MFA regelmäßig Pflicht; FIDO2 oder Passkeys sind heute meist die stärkste Option, und im verbreiteten ISO-Mapping wird das Thema typischerweise Annex A.9.4 zur Zugriffskontrolle sowie Annex A.13 zur Kommunikationssicherheit zugeordnet.

Für Ihr Unternehmen ist entscheidend, dass Art. 21(2)(j) keine bloße Empfehlung formuliert, sondern eine umzusetzende Sicherheitsmaßnahme mit Risikobezug. Wer weiterhin nur auf Passwörter, geteilte Administrationskonten oder ungeschützte Remote-Zugänge setzt, kann gegenüber Aufsicht, Geschäftsleitung und interner Revision kaum plausibel erklären, warum dieser Schutz ausreichen soll. Im deutschen Umsetzungsumfeld taucht die Anforderung entsprechend als Maßnahme zu Multi-Faktor-Authentifizierung, gesicherter Kommunikation und gegebenenfalls Notfallkommunikation in § 30 Abs. 2 Nr. 10 BSIG-E auf.

Die sinnvolle Management-Kernaussage lautet deshalb: Rollen mit hohem Schadenspotenzial zuerst absichern, Kommunikationskanäle parallel härten und den Rollout nicht als Einzeltechnik, sondern als Teil Ihres Zugriffs- und Krisenmanagements planen. Wenn Sie die vorgelagerte Zugriffsperspektive vertiefen möchten, ist die Einordnung zur NIS2-Maßnahme Zugangskontrolle ebenso relevant wie der Beitrag zur NIS2-Maßnahme Kryptografie und die operative NIS2-Checkliste. Für die Schulung von Management und Fachbereichen ist außerdem die NIS2-Schulung der naheliegende nächste Schritt.

Was verlangt Art. 21(2)(j) NIS2 zu MFA?

Art. 21(2)(j) NIS2 verlangt den Einsatz von Multi-Faktor-Authentifizierung oder kontinuierlicher Authentifizierung, gesicherter Sprach-, Video- und Textkommunikation sowie gegebenenfalls gesicherter Notfallkommunikationssysteme. Der Artikel nennt damit ausdrücklich nicht nur Login-Schutz, sondern ein zusammenhängendes Identitäts- und Kommunikationskontrollpaket.

Der entscheidende Begriff ist dabei nicht „für alle Nutzer ausnahmslos“, sondern „soweit angemessen“. Unternehmen dürfen MFA also nicht pauschal ignorieren, sondern müssen risikobasiert entscheiden, wo Identitätskompromittierungen besonders schwere Schäden auslösen können. Genau deshalb ist MFA für viele hochkritische Anwendungsfälle faktisch Pflicht: Ein kompromittiertes Administratorkonto, eine übernommene Cloud-Konsole oder ein ungeprüfter VPN-Zugang kann unmittelbar zu Betriebsunterbrechung, Datenabfluss, Ransomware-Ausbreitung oder Missbrauch von Meldekanälen führen.

In der Praxis sollten Sie Art. 21(2)(j) als Mindestauftrag in fünf Prüfschritte übersetzen:

1. Identifizieren Sie alle Systeme und Konten mit hohem Schadenspotenzial bei Kontenübernahme.
2. Ordnen Sie diese Zugriffe nach Kritikalität, Exponierung und Privilegierungsgrad.
3. Erzwingen Sie für die oberen Risikostufen MFA oder kontinuierliche Authentifizierung.
4. Härten Sie parallel Sprach-, Video- und Textkommunikation technisch und organisatorisch.
5. Dokumentieren Sie Ausnahmen, Übergangslösungen und geplante Restmaßnahmen nachvollziehbar.

Besonders wichtig ist die Abgrenzung zwischen „MFA vorhanden“ und „MFA wirksam“. Ein optional aktivierbarer zweiter Faktor, eine ausgenommene Administratorgruppe oder ein veraltetes SMS-Verfahren auf besonders sensiblen Konten reichen für eine belastbare NIS2-Argumentation oft nicht aus. Entscheidend ist, ob Ihr Schutzmodell Angriffe mit realistischem Aufwand erschwert und ob Sie diese Entscheidung im Risikomanagement begründen können.

Die folgende Tabelle zeigt ein praxistaugliches Mapping von NIS2 Maßnahme 10 auf verbreitete ISO-27001-Bezugspunkte:

Dieses Mapping ist bewusst pragmatisch. NIS2 schreibt Ihnen kein starres formales Nachweisschema vor, wohl aber einen nachweisbaren Sicherheitszustand. Wenn Ihr Unternehmen bereits mit ISO-27001-Kontrollen, BSI-Grundschutz oder einem internen Kontrollsystem arbeitet, lässt sich Maßnahme 10 deshalb gut in bestehende Rollen-, Rezertifizierungs- und Auditprozesse integrieren.

MFA-Methoden im Vergleich — TOTP, FIDO2, Push, Biometrie

Nicht jede MFA-Methode bietet denselben Schutz. Für NIS2 zählt deshalb nicht nur, ob überhaupt ein zweiter Faktor vorhanden ist, sondern wie widerstandsfähig er gegen Phishing, Social Engineering, Malware, Sitzungsdiebstahl und operative Umgehungen ist.

Für die Priorisierung ist eine einfache Grundregel sinnvoll: phishing-resistente Verfahren zuerst, softwarebasierte Einmalcodes als pragmatischen Standard nutzen und schwache Methoden nur übergangsweise akzeptieren. ENISA ordnet FIDO2, WebAuthn und Passkeys technisch besonders stark ein; das BSI verweist parallel darauf, dass Zwei-Faktor-Authentisierung zusätzlichen Schutz bietet und Kommunikationssicherheit mit aktuellen kryptographischen Empfehlungen zusammen gedacht werden muss.

FIDO2 und Passkeys sind für NIS2 deshalb so attraktiv, weil sie den häufigsten Angriffspfad moderner Kontenübernahmen direkt adressieren: phishing-resistente Anmeldung ohne abfangbaren Einmalcode. Gerade bei Administratoren, Cloud-Plattformen, Identitätssystemen und Fernzugriffen ist diese Eigenschaft wichtiger als reine Bequemlichkeit. Wer einen Helpdesk, eine Produktionsumgebung oder einen Domain-Controller schützt, braucht nicht nur zwei Faktoren, sondern robuste Faktoren.

TOTP bleibt trotzdem relevant. Für viele mittelständische Unternehmen ist TOTP der schnellste Weg, um in wenigen Wochen ein belastbares Mindestniveau aufzubauen. Das gilt besonders für Standardanwender, Fachbereiche, SaaS-Portale und erste Rollout-Wellen. Wichtig ist dann aber, dass TOTP nicht als Endpunkt jeder Diskussion missverstanden wird. Für hochprivilegierte Konten sollte das Zielbild regelmäßig stärker sein als ein App-Code.

Push-Verfahren wirken im Alltag angenehm, sind aber nur dann belastbar, wenn Push-Müdigkeit technisch gebremst wird. Number Matching, Gerätekontext, Geolokation, Re-Authentifizierung bei Risikoereignissen und klare Schulung gegen ungefragte Bestätigungen sind hier Pflicht. Ohne diese Kontrollen wird aus bequemem Login schnell ein Angriffsvektor für Social Engineering.

Biometrie ist für NIS2 kein Selbstzweck, sondern eine Verpackungstechnologie. Fingerabdruck oder Gesichtserkennung sind dann stark, wenn sie lokal an einen sicheren Authentifikator gebunden sind, etwa an einen Passkey auf einem gehärteten Endgerät. Biometrie allein ersetzt also weder den Identitätsprozess noch eine belastbare Geräte- und Recovery-Strategie.

SMS sollten Sie nüchtern bewerten. Für unkritische Übergangsszenarien mag SMS operativ noch vorkommen, für privilegierte Rollen, externe Administratoren, VPN oder besonders schützenswerte Anwendungen ist sie aber regelmäßig nicht der Zielzustand. Wer SMS weiter nutzt, sollte eine dokumentierte Ablöseplanung und technische Kompensationen vorweisen können.

Zero-Trust-Ansatz und kontinuierliche Authentifizierung

NIS2 Maßnahme 10 lässt sich am wirksamsten in einem Zero-Trust-Ansatz umsetzen. Der Grund ist einfach: Moderne Angriffe enden nicht am Login, sondern nutzen gestohlene Sitzungen, kompromittierte Geräte, seitliche Bewegung und missbrauchte Kommunikationskanäle. Ein einmaliger Anmeldemoment reicht deshalb für kritische Umgebungen häufig nicht aus.

Kontinuierliche Authentifizierung bedeutet in diesem Zusammenhang nicht, dass Benutzerinnen und Benutzer alle fünf Minuten erneut Passwörter eingeben müssen. Gemeint ist vielmehr eine laufende Neubewertung der Vertrauenslage anhand von Signalen wie Gerätegesundheit, Standort, Netzwerk, Uhrzeit, Verhalten, Rollenwechsel, Sensitivität des Ziels und konkreten Risikoindikatoren. Wenn sich diese Lage ändert, muss die Zugriffsstärke automatisch nachgezogen werden.

Für die Praxis entstehen daraus vier Kernprinzipien:

1. Vertrauen Sie keinem Zugriff allein wegen des Netzwerkstandorts.
2. Prüfen Sie Identität, Gerätekontext und Risikosignal gemeinsam.
3. Erzwingen Sie stärkere Authentifizierung bei privilegierten oder sensiblen Aktionen.
4. Verkürzen Sie Sessions und erhöhen Sie die Re-Authentifizierung bei Risikowechseln.

Ein typisches Beispiel: Ein Administrator meldet sich morgens mit Passkey an, arbeitet zunächst im internen Ticketsystem und öffnet später die Cloud-Konsole, um Rollenrechte zu ändern. Für die zweite Aktion sollte das System den Kontext neu bewerten und eine stärkere oder erneute Bestätigung verlangen. Genau an dieser Stelle verbindet Zero Trust die MFA-Anforderung aus Art. 21(2)(j) mit Privileged Access Management, Sitzungssteuerung und Protokollierung.

Auch für Standardanwender ist Zero Trust relevant. Wenn sich ein Konto plötzlich aus einem neuen Land anmeldet, wenn ein verwaltetes Gerät fehlt, wenn ein Browser unbekannt ist oder wenn ein Zugriff auf besonders vertrauliche Daten erfolgt, muss Ihr Identitätssystem reagieren. Das kann eine zusätzliche MFA-Abfrage, eine Blockierung, eine Session-Verkürzung oder eine Eskalation an das Security-Team sein.

Wichtig ist dabei die Balance zwischen Sicherheit und Betriebsfähigkeit. Zero Trust ist kein Freibrief für unkontrollierte Reibung. Ein gutes Modell erhöht die Sicherheitsstufe gezielt dort, wo das Risiko steigt, und hält Routinevorgänge schlank. Genau deshalb gehören Rollenmodell, Applikationsklassifizierung und Kommunikationsszenarien zwingend in die Planung.

MFA-Rollout planen — Priorisierung nach Risiko

Ein erfolgreicher MFA-Rollout beginnt nicht mit „alle sofort“, sondern mit einer nachvollziehbaren Reihenfolge nach Risiko. Unternehmen verlieren Zeit und Akzeptanz, wenn sie zunächst einfache Office-Zugänge absichern, während Domain-Admins, VPN, Backup-Konsole und E-Mail-Administratoren weiter nur mit Passwort arbeiten.

Die richtige Priorisierung startet deshalb bei den Konten, deren Übernahme unmittelbar großen Schaden auslösen kann. Dazu zählen typischerweise:

1. Identitäts- und Verzeichnisadministration
2. Cloud- und Infrastrukturadministration
3. VPN, RDP, Fernwartung und externe Dienstleister
4. E-Mail-Administrations- und Postfachzugriffe
5. Backup-, Security- und PAM-Systeme
6. Fachanwendungen mit hohem Schutzbedarf

Ein praxistauglicher Rollout besteht meist aus drei Wellen. In Welle eins sichern Sie privilegierte Konten und externe Zugriffe ab, idealerweise mit FIDO2 oder Passkeys plus belastbaren Notfallverfahren. In Welle zwei folgen Schlüsselrollen außerhalb der IT, etwa Finance, HR, Geschäftsleitung, Einkauf mit Zahlungsfreigaben oder Produktionsverantwortliche. In Welle drei härten Sie breite Standardanwenderpopulationen und weniger kritische Portale nach.

Die folgende Priorisierungsmatrix hilft bei der Umsetzung:

Ein Rollout scheitert oft nicht an der Technik, sondern an Recovery und Betrieb. Sie brauchen deshalb vor Go-live klare Prozesse für verlorene Geräte, Ersatzschlüssel, Helpdesk-Verifikation, Notfallkonten, Offboarding und Ausnahmefreigaben. Gerade privilegierte Bereiche dürfen nicht in eine Lage geraten, in der ein verlorener Token ungeprüft durch eine telefonische Zuruf-Freigabe ersetzt wird.

Ebenso wichtig ist die Kommunikationsplanung. Mitarbeitende akzeptieren MFA deutlich besser, wenn der Nutzen, der Ablauf und die Unterstützung klar sind. Für besonders kritische Gruppen sollten Sie kurze, verbindliche Anleitungen mit echten Szenarien bereitstellen: Was tun bei Gerätewechsel, was tun bei Auslandsreise, was tun bei verlorener Authentifizierungsmethode, wer darf Ausnahmen freigeben und wie wird die Identität im Störfall geprüft?

Wer NIS2 MFA sauber umsetzen will, sollte außerdem Legacy-Risiken offen benennen. Wenn alte Anwendungen moderne Authentifizierung nicht direkt unterstützen, ist die richtige Reaktion nicht Schweigen, sondern dokumentierte Übergangsarchitektur: vorgelagerter Identity Provider, VPN-Schutz, Bastion Host, PAM-Gateway oder mittelfristige Ablösung. Die Aufsicht erwartet keine Magie, aber nachvollziehbare Priorisierung und Restmaßnahmen.

Gesicherte Kommunikation — Sprache, Video, Text

Art. 21(2)(j) verlangt ausdrücklich nicht nur MFA, sondern auch gesicherte Sprach-, Video- und Textkommunikation. Unternehmen dürfen Maßnahme 10 deshalb nicht auf Login-Dialoge verengen. Wenn Kommunikationskanäle kompromittiert, mitgelesen oder durch Social Engineering missbraucht werden können, bleibt die Identitätskontrolle unvollständig.

Für die Praxis bedeutet gesicherte Kommunikation drei Dinge gleichzeitig: erstens geeignete Verschlüsselung und Protokolle, zweitens saubere Identitätsbindung der Kommunikationspartner und drittens klare organisatorische Regeln für sensible Inhalte. Ein Videotool mit schwacher Meeting-Freigabe, ein Messenger ohne belastbare Administrationskontrolle oder ein Telefonprozess ohne Rückruf- und Verifikationsschema erfüllt die Normidee nur unzureichend.

Das BSI ordnet Kommunikationssicherheit regelmäßig über aktuelle kryptographische Verfahren und Transportprotokolle ein. Für Unternehmen ist daraus die naheliegende Konsequenz: Sprach-, Video- und Textplattformen sollten auf aktuelle, gut dokumentierte kryptographische Standards gestützt sein, Mandanten sauber trennen, MFA für Administratoren erzwingen und Protokollierung, Rollenmodell sowie Export- und Löschkonzepte mitbringen.

Besonders relevant sind diese Fragen:

1. Ist der Kommunikationsdienst durchgängig transportverschlüsselt und administrativ gehärtet?
2. Sind sensible Konferenzen, Chats und Freigaben an starke Identitäten gekoppelt?
3. Gibt es Schutz gegen unbefugte Gastzugänge, Session-Hijacking und Meeting-Missbrauch?
4. Sind Administratorzugriffe auf Kommunikationsplattformen selbst mit starker MFA geschützt?
5. Gibt es definierte Alternativen, wenn Standardkanäle im Incident nicht mehr vertrauenswürdig sind?

Ein häufiger Fehler in Unternehmen ist die Trennung von IAM und Kollaborationsplattform. Genau diese Trennung ist aber riskant: Wenn Ihr E-Mail- oder Kollaborationskonto übernommen wird, lassen sich Freigaben, Passwort-Resets, Zahlungsanweisungen oder Krisenkommunikation manipulieren. Kommunikationssicherheit ist deshalb kein Nebenthema, sondern Kernstück der Resilienz.

Notfallkommunikationssysteme bei Cyberangriffen

NIS2 erwähnt gesicherte Notfallkommunikationssysteme nicht zufällig. Bei Ransomware, Identitätskompromittierung oder Cloud-Ausfällen fallen oft gerade die Standardwerkzeuge zuerst aus oder werden unzuverlässig. Ohne belastbaren Alternativkanal verlieren Unternehmen dann Zeit, Lagebild und Entscheidungsfähigkeit.

Ein Notfallkommunikationssystem muss nicht automatisch ein eigenes Rechenzentrum bedeuten. Es muss aber zwei Anforderungen erfüllen: Es muss im Krisenfall erreichbar sein und es muss gegenüber dem kompromittierten Primärkanal ausreichend entkoppelt sein. Wenn Ihre gesamte Krisenkommunikation auf derselben Identitätsplattform liegt, die gerade angegriffen wird, fehlt diese Entkopplung.

Ein belastbares Modell umfasst deshalb typischerweise:

1. Einen sekundären Kommunikationskanal außerhalb des Primärmandanten
2. Vorab definierte Teilnehmerkreise, Rollen und Eskalationsstufen
3. Authentifizierte Kontaktlisten mit regelmäßiger Pflege
4. Einen dokumentierten Aktivierungsprozess für Cybervorfälle
5. Regeln für sensible Informationen, Freigaben und Protokollierung

Besonders kritisch sind Entscheidungen mit hohem Missbrauchspotenzial, etwa Zahlungsfreigaben, externe Incident-Kommunikation, Abschaltung von Produktionssystemen oder Behördenmeldungen. Für solche Schritte genügt ein Messenger-Chat ohne Identitätsprüfung nicht. Hier sollten Sie Rückrufverfahren, Mehr-Augen-Prinzip, Rollenbestätigung und unabhängige Kontaktwege kombinieren.

Notfallkommunikation ist zudem eine Übungsfrage. Ein Kanal, den niemand kennt oder der nie getestet wurde, existiert nur auf dem Papier. Unternehmen sollten deshalb in Tabletop-Übungen und Krisentests konkret prüfen, ob Erreichbarkeit, Identitätsprüfung, Freigaben und Dokumentation auch unter Zeitdruck funktionieren. Genau hier schließt sich der Kreis zu NIS2-Governance: Nicht die Theorie zählt, sondern die nachweisbare Betriebsfähigkeit.

Häufig gestellte Fragen (FAQ)

Ist MFA nach NIS2 Pflicht?

Ja, in der Praxis für viele kritische Anwendungsfälle. Art. 21(2)(j) NIS2 verlangt Multi-Faktor-Authentifizierung oder kontinuierliche Authentifizierungslösungen, soweit dies angemessen ist. Für privilegierte Konten, externe Zugriffe, VPN, Administrationsoberflächen, E-Mail und andere besonders risikoreiche Systeme ist MFA regelmäßig faktisch Pflicht.

Welche MFA-Methode empfiehlt NIS2?

NIS2 nennt keine einzelne Produktpflicht, aber technisch sind phishing-resistente Verfahren wie FIDO2, WebAuthn und Passkeys regelmäßig die stärkste Option. TOTP ist für viele Unternehmen ein praktikabler Mindeststandard. SMS sollte nur als Übergangslösung und nicht für hochkritische Zugriffe verwendet werden.

Reicht SMS als zweiter Faktor für NIS2?

Für besonders kritische oder administrative Zugriffe regelmäßig nicht. SMS ist gegenüber SIM-Swapping, Abfangen und Social Engineering schwächer als FIDO2, Passkeys oder TOTP. Wenn SMS vorübergehend genutzt wird, sollten Unternehmen dokumentieren, warum stärkere Verfahren noch nicht ausgerollt sind und wann die Ablösung erfolgt.

Für welche Systeme muss MFA aktiviert werden?

Vorrangig für privilegierte Konten, Identitäts- und Administrationssysteme, VPN, Fernzugriffe, E-Mail, Cloud-Konsolen, PAM-, Backup- und Sicherheitsplattformen sowie alle Systeme mit hohem Schadenspotenzial bei Kontenübernahme. Die Priorisierung muss risikobasiert dokumentiert werden.

Was fordert NIS2 zu verschlüsselter Kommunikation?

Art. 21(2)(j) verlangt gesicherte Sprach-, Video- und Textkommunikation sowie gegebenenfalls gesicherte Notfallkommunikationssysteme. Unternehmen brauchen daher nicht nur MFA, sondern auch belastbar geschützte Kommunikationskanäle mit geeigneter Transport- und Inhaltsabsicherung, klaren Freigaberegeln und Notfallverfahren.

Fazit: NIS2 MFA ist Identitäts- und Kommunikationssicherheit in einem

Die richtige Kurzfassung zu NIS2 Maßnahme 10 lautet: Unternehmen müssen Identitäten stärker absichern, privilegierte und externe Zugriffe priorisieren, Kommunikationskanäle härten und für den Krisenfall einen vertrauenswürdigen Alternativkanal vorhalten. Art. 21(2)(j) ist deshalb keine isolierte Login-Vorschrift, sondern ein konkreter Auftrag zu belastbarer Zugriffs-, Kommunikations- und Resilienzsteuerung.

Wenn Sie jetzt starten, beginnen Sie nicht mit einer Vollabdeckung aller Sonderfälle, sondern mit der Risikospitze: Administratoren, VPN, E-Mail, Cloud und besonders kritische Fachsysteme. Danach erweitern Sie Ihr Modell auf Standardanwender, Kommunikationsplattformen und Krisenprozesse. Für eine strukturierte Einordnung von Verantwortlichkeiten, Nachweisen und Mindestmaßnahmen ist die NIS2-Schulung der pragmatische nächste Schritt.