Adaptive MFA als NIS2-Standard 2026: Wie die ENISA-Guidance die where-appropriate-Klausel klargestellt hat

NIS2 fordert Multi-Faktor-Authentifizierung (MFA) „where appropriate“ und in Deutschland tritt das BSI-Vollzugsmandat im Mai 2026 in die operative Phase. Die zentrale Frage für Sicherheits- und Compliance-Verantwortliche ist nicht „haben wir MFA“, sondern „haben wir die richtige MFA an den richtigen Stellen mit dokumentierter Risiko-Begründung“. Wer 2026 noch eine Pauschal-MFA-Aufstellung pflegt, hat im BSI-Audit ein offenes Finding.

TL;DR: Adaptive MFA wird zum NIS2-Compliance-Standard 2026

• NIS2 §2(j) fordert MFA oder kontinuierliche Authentifizierung „where appropriate“. Die ENISA-Guidance Q1 2026 hat klargestellt, dass „appropriate“ nicht „optional“ bedeutet, sondern eine dokumentierte Risiko-Bewertung pro Konto-Klasse.
• BSI-Vollzugsmandat tritt in Deutschland im Mai 2026 in die operative Phase, Belgien war am 18. April 2026 voraus. Die ersten Audits laufen ab Q3 2026, vor allem in Energie-, Gesundheit-, Verwaltung-, Banken-, Telco- und Anlagenbau-Sektoren.
• Adaptive MFA (Risiko-basierte Authentifizierung mit Kontext-Signalen statt Pauschal-MFA) ist 2026 der pragmatische Pfad. Sie reduziert User-Friction um 40 bis 70 Prozent und liefert gleichzeitig eine bessere Audit-Spur.
• Drei Bausteine sind 2026 BSI-relevant: Identity-Risiko-Inventory mit Konto-Klassifizierung, Adaptive-MFA-Engine mit Kontext-Signalen, Audit-Trail mit forensischer Tiefe für mindestens 12 Monate.
• Wer die Compliance-Architektur jetzt sauber aufstellt, vermeidet 2027 die Bußgeld-Risiken bis 10 Millionen Euro und positioniert sich gleichzeitig für die kommende DORA-Resilienz-Welle.

Was die ENISA-Guidance Q1 2026 zur „where appropriate“-Klausel klargestellt hat

Die NIS2-Klausel „where appropriate“ hat seit der Verabschiedung der Richtlinie 2022 für Verwirrung gesorgt. Viele Compliance-Verantwortliche haben sie als Ermessens-Spielraum interpretiert, in dem die Organisation selbst entscheiden darf, wo MFA sinnvoll ist. Die ENISA-Guidance aus dem ersten Quartal 2026 hat diese Lesart klar zurückgewiesen. „Where appropriate“ bedeutet, dass die Organisation eine dokumentierte Risiko-Bewertung pro Konto-Klasse vorlegen muss, in der für jede Klasse begründet wird, warum MFA gilt oder warum sie nicht angewendet wird. Eine „wir haben MFA in Outlook“-Aufstellung reicht 2026 nicht mehr aus.

Die strukturelle Anforderung lautet: Identity-Risiko-Inventory. Jede Konto-Klasse (Mitarbeiter-Konto, Admin-Konto, Service-Account, externer Lieferanten-Zugang, Notfall-Konto, Maschinen-Konto) muss in einer Tabelle stehen, mit Risiko-Bewertung, MFA-Mechanismus, Begründung und Review-Datum. Die ENISA-Guidance nennt explizit Privileged-Access (Admin-Accounts), Remote-Access und externe Lieferanten-Konten als Bereiche, in denen MFA praktisch immer „appropriate“ ist. Wer für diese Klassen keine MFA hat, hat ein BSI-Audit-Finding.

Die NIS2-Messenger-Pflichten aus April 2026 zeigen, wie sehr die Compliance-Architektur 2026 in Detail-Tiefe geht. MFA ist dabei einer der zentralen Bausteine, weil sie sowohl die Identity-Sicherheit als auch die Forensik-Fähigkeit bei Vorfällen direkt beeinflusst.

Warum Adaptive MFA der pragmatische Pfad ist

Pauschale MFA für alle Konten klingt zunächst sicher, hat in der Praxis aber zwei Probleme: User-Friction und Audit-Schwäche. User-Friction führt zu Workaround-Verhalten (Push-Bombing-Akzeptanz, schwache Passwort-Reset-Pfade, Shadow-Accounts), das die Sicherheit netto reduzieren kann. Audit-Schwäche entsteht, weil pauschale MFA keinen Kontext-Audit liefert, also nicht differenziert, ob ein Login aus einer ungewöhnlichen Konstellation oder aus dem Standard-Setup kam.

Adaptive MFA löst beide Probleme. Sie nutzt Kontext-Signale (Geräte-Identität, Standort, Tageszeit, Verhaltens-Profile, Ressourcen-Sensitivität) und entscheidet pro Anmelde-Versuch, welche MFA-Stärke angewendet wird. Bei einem Standard-Login aus dem registrierten Geräte-Profil reicht ein einfacher zweiter Faktor. Bei einem Login aus einem unbekannten Standort oder mit ungewöhnlichem Verhaltens-Profil greift ein verschärfter Faktor (FIDO2-Hardware-Key, biometrische Bestätigung) oder eine zusätzliche Step-up-Stufe. Das Ergebnis: weniger Friction für Standard-Anmeldungen, mehr Sicherheit für Risiko-Anmeldungen, deutlich bessere Audit-Spur.

In zwei DACH-Mandaten der vergangenen sechs Monate hat die Umstellung von pauschaler auf adaptive MFA die Anzahl der täglichen MFA-Prompts um 40 bis 70 Prozent reduziert, gleichzeitig die Erkennung verdächtiger Logins um den Faktor drei bis fünf gesteigert. Wirtschaftlich ist die Entscheidung damit nicht nur Compliance-getrieben, sondern auch User-Experience- und Sicherheits-getrieben. Die Adaptive-MFA-Schwerpunkte aus dem April 2026 zeigen die operative Wirksamkeit gegen aktuelle Angriffsvektoren wie Device-Code-Phishing.

Drei Compliance-Bausteine, die in der NIS2-Architektur 2026 stehen müssen

Baustein 1: Identity-Risiko-Inventory mit Konto-Klassifizierung. Der erste Baustein ist eine Tabelle aller Konto-Klassen im Unternehmen, mit Anzahl, Risiko-Bewertung (niedrig, mittel, hoch, kritisch), MFA-Mechanismus, Begründung der Wahl und Review-Datum. Im NIS2-Audit ist diese Tabelle das erste Dokument, das geprüft wird. Wer sie nicht hat, hat sofort ein offenes Finding. Wer sie hat, aber Privileged-Konten ohne starke MFA aufweist, ebenfalls. Eine seriöse Inventarisierung dauert in einem mittelständischen Unternehmen mit 250 bis 1.000 Beschäftigten zwischen vier und acht Wochen.

Baustein 2: Adaptive-MFA-Engine mit Kontext-Signalen. Der zweite Baustein ist die technische MFA-Schicht. Die marktüblichen Optionen 2026 sind Microsoft Entra ID Conditional Access, Okta Adaptive MFA, Cisco Duo Beyond, Ping Identity oder spezialisierte Lösungen wie Silverfort und Rublon. Die Wahl hängt vom bestehenden Identity-Stack ab, die zentralen Anforderungen sind aber identisch: Risiko-basierte Policy-Engine, FIDO2- und WebAuthn-Unterstützung, Step-up-Mechanismen, Audit-fähige Logs. Wer diesen Baustein nicht innerhalb der nächsten 12 Monate auf adaptive Logik umstellt, lebt mit einem netto schwächeren Sicherheits- und Compliance-Niveau.

Baustein 3: Audit-Trail mit forensischer Tiefe. Der dritte Baustein ist der häufig unterschätzte. NIS2 fordert nicht nur die Anwendung von MFA, sondern die Nachweisbarkeit über mindestens 12 Monate. Wer im Vorfalls-Fall nicht rekonstruieren kann, welcher Login mit welchem Faktor wann von wo erfolgte, hat ein Forensik-Problem und ein Compliance-Problem zugleich. Die Audit-Trail-Architektur muss deshalb über das Identity-Provider-Log hinausgehen und die Logs in einem zentralen, manipulations-sicheren System aggregieren (SIEM, dediziertes Audit-Log-Repository). Die Aufbewahrungs-Pflicht endet 2026 nicht bei 12 Monaten, sondern verlängert sich für kritische Sektoren auf 24 oder 36 Monate.

Wie ein 90-Tage-Compliance-Plan konkret aussieht

Aus der Beratungspraxis hat sich ein 90-Tage-Plan etabliert, der die drei Bausteine in der richtigen Reihenfolge umsetzt. Tag 1 bis 30: Identity-Risiko-Inventory. Erfassung aller Konto-Klassen, Risiko-Bewertung, Lückenanalyse gegenüber NIS2 §2(j) und ENISA-Guidance. Output: Identity-Risiko-Tabelle mit klarer Aktions-Liste. Tag 31 bis 60: Adaptive-MFA-Architektur-Entscheidung. Marktscan, Proof-of-Concept mit zwei Lösungen, Architektur-Entscheidung mit IT, Sicherheit, HR und Datenschutz. Output: Architektur-Entscheidung mit Roll-out-Plan. Tag 61 bis 90: Pilot-Roll-out für Privileged-Konten und Remote-Access. Begleitende Schulung der Anwender, Eskalations-Wege bei Friction, schrittweises Hochfahren der Policy-Strenge. Output: Pilot-Bericht mit Erweiterungs-Roadmap auf alle Konto-Klassen.

Wer diesen 90-Tage-Plan systematisch durchläuft, ist bis Ende des dritten Quartals 2026 in einer Position, in der das BSI-Audit die wesentlichen Anforderungen erfüllt findet. Wer den Plan nicht durchläuft, wird in der Audit-Phase ab Q3 2026 die offenen Findings nachholen müssen, häufig unter Zeitdruck und mit höheren Kosten.

Was passiert, wenn das BSI-Audit Mängel feststellt?

Die Eskalations-Logik des BSI-Vollzugs sieht ein dreistufiges Verfahren vor. Erste Stufe: Auflagen mit Frist (üblicherweise drei bis sechs Monate) zur Behebung der Mängel. Zweite Stufe: Bußgeld bei Nicht-Erfüllung der Auflagen, Rahmen bis 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes. Dritte Stufe: Persönliche Haftung der Geschäftsführung mit Privatvermögen, falls Sorgfaltspflichten erkennbar verletzt wurden. Die ersten Bußgeld-Fälle in den NIS1-Vorgänger-Verfahren haben gezeigt, dass das BSI bei MFA-Versagen in Privileged-Konten den vollen Rahmen ausschöpfen kann, wenn der Mangel als grob fahrlässig eingestuft wird. Die Architektur-Investition in adaptive MFA mit Audit-Trail ist im Vergleich zur Bußgeld-Höhe immer wirtschaftlich.

Wie DORA die MFA-Anforderungen zusätzlich verschärft

Für Finanzunternehmen kommt DORA als zusätzliche Schicht. DORA verlangt Operational Resilience und schreibt in den ICT-Risk-Management-Bestimmungen explizit MFA für privilegierte Zugriffe und Remote-Sessions vor. Während NIS2 die „where appropriate“-Logik nutzt, ist die DORA-Anforderung schärfer: Privileged-MFA ist Pflicht, nicht Option. Banken, Versicherer und kritische IKT-Drittanbieter müssen 2026 also nicht nur die NIS2-Logik erfüllen, sondern parallel die DORA-Schärfe. Die DORA-2-Linie aus UK FCA April 2026 liefert dazu die regulatorische Operational-Resilience-Begleitlinie. Wer die NIS2-Architektur DORA-tauglich aufstellt, hat die Compliance-Doppelschicht in einem Aufwasch erledigt.

Was die typischen Audit-Findings 2026 sind

Aus den ersten Vor-Audit-Workshops mit Sicherheits-Verantwortlichen mittelständischer Unternehmen lassen sich vier wiederkehrende Findings identifizieren, die im echten BSI-Audit zu Auflagen führen werden. Erstens: Service-Accounts ohne MFA und ohne Secret-Rotation. In den meisten DACH-Unternehmen gibt es zwischen 30 und 200 Service-Accounts mit Standard-Passwörtern, die seit Jahren nicht rotiert wurden. Diese sind Eskalations-Pfad Nummer eins für Angreifer und im Audit ein offenes Finding. Zweitens: Externe Lieferanten-Zugänge ohne starke MFA. Wartungs-Zugänge von Maschinenbauern, IT-Dienstleistern und Software-Anbietern laufen häufig ohne FIDO2 oder Hardware-Token. Drittens: Notfall-Konten ohne dokumentierte Verfahrens-Logik. Wer Break-Glass-Accounts hat, muss die Aktivierungs- und Deaktivierungs-Verfahren schriftlich dokumentieren und im Audit vorlegen. Viertens: Cloud-Admin-Konsolen ohne Step-up-MFA für sensitive Operationen. Microsoft Azure Privileged Identity Management, AWS IAM Identity Center und Google Cloud Privileged Access Manager bieten die Werkzeuge, sie werden aber nur in der Hälfte der DACH-Setups konsequent genutzt.

Wer diese vier Findings vor dem ersten BSI-Audit systematisch abräumt, ist bereits in der oberen Hälfte der Compliance-Reife. Aus Erfahrung dauert die Abarbeitung in einem mittelständischen Setup zwischen acht und sechzehn Wochen, je nachdem, wie tief die Service-Account-Landschaft fragmentiert ist. Wer das Thema 2026 noch nicht angefasst hat, sollte die nächste Sicherheits-Roadmap-Runde dafür reservieren.

Welche Rolle Phishing-resistente MFA spielt

Ein zentraler Aspekt der ENISA-Guidance Q1 2026 ist die Empfehlung Phishing-resistenter MFA-Verfahren für privilegierte Zugriffe. Standard-Push-Notifications und SMS-OTPs sind durch Phishing-Tools wie Evilginx, Modlishka oder das im April 2026 in einer Welle dokumentierte Tycoon-2FA-Toolkit kompromittierbar. FIDO2-Hardware-Keys, Passkeys und biometrische Authentifizierung mit Origin-Binding gelten dagegen als Phishing-resistent. Für privilegierte Zugriffe und Remote-Sessions ist die Empfehlung 2026 klar: Nur Phishing-resistente Faktoren. In der NIS2-Architektur sollte das Inventory deshalb für jede privilegierte Klasse den Phishing-Resistance-Status dokumentieren. Wer noch SMS oder Push-MFA für Admin-Konten einsetzt, hat 2026 ein erkennbares Restrisiko, das im Audit-Gespräch häufig direkt thematisiert wird.

Aus operativer Sicht lohnt sich der Übergang auf FIDO2-Hardware-Keys oder Passkeys gerade für die Privileged-User-Klassen, weil diese Anwender ohnehin sicherheitssensibel sind und die zusätzliche Friction nicht als Belastung empfinden. Bei breiten Mitarbeiter-Klassen ist Passkey die ergonomisch elegantere Variante, weil sie keine zusätzliche Hardware erfordert und nahtlos mit modernen Endgeräten integriert. Eine gemischte Strategie (Hardware-Keys für Admins, Passkeys für die Belegschaft, klassische TOTP-Apps als Übergangs-Faktor für Legacy-Zugänge) ist 2026 der pragmatische Pfad und erfüllt die ENISA-Guidance vollständig.

Häufige Fragen

Netzwerk: Weiterlesen auf Security Today

• Operative Praxis aus dem Healthcare-Incident-Report April 2026
• Messenger-NIS2-Pflichten aus dem Whatsapp-Signal-Compliance-Bericht
• Adaptive-MFA gegen 7 Millionen Device-Code-Phishing-Versuche

Quelle Titelbild: Pexels / Dan Nelson (px:4973899)

Hier schreibt Benedikt Langer für Sie

Mehr Artikel vom Autor Benedikt Langer