Adaptive MFA im NIS2-Audit: Wann die Policy zum Nachweis taugt

Eine adaptive MFA, die im Login funktioniert, fällt im Audit trotzdem durch, wenn niemand belegen kann, nach welcher Regel sie wann den zweiten Faktor verlangt. Genau diese Lücke rückt unter NIS2 in den Fokus: Die Richtlinie verlangt nicht nur, dass eine risikobasierte Authentifizierung existiert, sondern dass das Unternehmen die Wirksamkeit seiner Maßnahmen bewerten kann. Wer Entra ID, Okta oder Duo nur einschaltet und die Conditional-Access-Regeln im Kopf der IT-Abteilung lässt, hat eine Technik, aber im Zweifel keinen dokumentierten Nachweis.

Verwandt:Die Schwachstelle, die nur die KI gefunden hat  /  Der Notfallplan, den niemand geprobt hat

Warum NIS2 die MFA-Policy prüft, nicht das MFA-Feature

Was ist adaptive MFA? Adaptive oder risikobasierte Multi-Faktor-Authentifizierung bewertet jede Anmeldung anhand von Kontextsignalen und verlangt den zweiten Faktor nur dann, wenn das Risiko über einer definierten Schwelle liegt. Eine Anmeldung vom verwalteten Notebook im Büronetz läuft durch, dieselbe Kennung von einer neuen IP-Adresse in einem anderen Land löst eine Step-up-Abfrage aus oder wird blockiert. Die Technik dahinter ist in Entra ID, Okta und Duo seit Jahren verfügbar.

Der Punkt, an dem NIS2 ansetzt, liegt nicht allein bei der Technik. Artikel 21 Absatz 2 der Richtlinie verlangt risikoangemessene Maßnahmen, die dem Stand der Technik entsprechen, sowie Konzepte zur Bewertung ihrer Wirksamkeit. Multi-Faktor-Authentifizierung nennt die Richtlinie ausdrücklich als geeignete Maßnahme, wo angemessen. Für eine Prüfung verschiebt das die relevante Frage: Sie lautet weniger, ob eine MFA aktiv ist, sondern eher, nach welcher Regel der zweite Faktor ausgelöst wird, wer diese Regel verantwortet und ob die Schwelle zum Schutzbedarf der betroffenen Systeme passt.

Hier scheitern viele Konfigurationen, die im Betrieb tadellos laufen. Die Regeln existieren als Conditional-Access-Richtlinie im Tenant, aber niemand hat sie je als Dokument exportiert, niemand kann ihre Historie zeigen und die Schwellenwerte sind aus dem Standard übernommen, ohne dass jemand sie gegen das eigene Risiko begründet hätte. Die Maßnahme ist vorhanden, der Nachweis ihrer Wirksamkeit fehlt.

Die Policy als exportierbares Artefakt aufsetzen

Der erste praktische Schritt ist unspektakulär: Die Authentifizierungs-Policy muss aus dem Tool herausgeholt und in eine Form gebracht werden, die ein Prüfer ohne Admin-Zugang lesen kann. In Entra ID exportieren Sie die Conditional-Access-Richtlinien über Microsoft Graph als JSON, in Okta über die Policy-API, in Duo über die Admin-API. Dieser Export gehört versioniert in dasselbe Repository, in dem auch die übrige Sicherheitsdokumentation liegt.

Wichtiger als das Format ist die Begründung, die danebensteht. Zu jeder Step-up-Bedingung gehört ein Satz, der erklärt, warum die Schwelle so gewählt ist. Ein Beispiel: Für Konten mit Zugriff auf die Buchhaltung greift die Step-up-Abfrage schon bei einer unbekannten Geolokation, weil diese Systeme nach der eigenen Schutzbedarfsanalyse als hoch eingestuft sind. Für ein internes Wiki reicht eine schwächere Regel. Diese Verbindung zwischen Schutzbedarf und Authentifizierungsregel ist genau das, was die Maßnahme prüfbar macht.

Sinnvoll ist außerdem ein Änderungsprotokoll mit Vier-Augen-Prinzip. Wer eine Authentifizierungsregel lockert, etwa weil eine Abteilung über zu viele Abfragen klagt, sollte das nicht still im Tenant tun. Eine dokumentierte Freigabe schützt im Ernstfall vor dem Vorwurf, eine Schutzmaßnahme sei ohne Begründung abgeschwächt worden. Die persönliche Haftung der Leitung nach NIS2 macht diesen Nachweis zu mehr als einer Formalie.

Welche Signale die Risiko-Engine tatsächlich tragen

Eine adaptive MFA ist nur so gut wie die Signale, die sie auswertet. In der Praxis tragen vier Kategorien das meiste Gewicht: das Gerät und sein Verwaltungsstatus, der Netzwerk- und Standortkontext, das Anmeldeverhalten im Zeitverlauf und externe Bedrohungssignale wie bekannte schädliche IP-Adressen. Entscheidend ist nicht, möglichst viele Signale zu aktivieren, sondern zu wissen, welches Signal welche Aussage trifft.

Der Verwaltungsstatus des Geräts ist das verlässlichste Einzelsignal. Eine Anmeldung von einem über die Mobilgeräteverwaltung registrierten, konformen Notebook ist substanziell vertrauenswürdiger als von einem unbekannten Gerät, unabhängig vom Standort. Standortsignale dagegen sind schwächer, als sie wirken: VPN, Mobilfunk und Reisetätigkeit erzeugen ständig neue Geolokationen, die für sich genommen keinen Angriff bedeuten. Wer den Standort zu scharf gewichtet, produziert Frust ohne Sicherheitsgewinn.

Number-Matching und Break-Glass: zwei Stellschrauben mit Audit-Gewicht

Zwei Konfigurationen entscheiden überproportional darüber, ob eine adaptive MFA im Audit besteht. Die erste ist die Art der Bestätigung. Eine reine Push-Benachrichtigung, die der Nutzer mit einem Tippen akzeptiert, lädt zum sogenannten MFA-Fatigue-Angriff ein: Der Angreifer löst so lange Abfragen aus, bis jemand entnervt bestätigt. Microsoft, Okta und Duo bieten dagegen einen Zahlenabgleich, bei dem der Nutzer eine auf dem Anmeldebildschirm gezeigte Zahl in der App eingeben oder bestätigen muss. Diese Mechanik ist bei allen drei Anbietern seit Längerem verfügbar und sollte erzwungen sein, nicht optional.

Die zweite Stellschraube sind die Break-Glass-Konten. Jede adaptive MFA braucht Notfallzugänge, die von den blockierenden Conditional-Access-Regeln ausgenommen sind, damit ein Fehler in der Konfiguration das Unternehmen nicht komplett aussperrt. Ausgenommen heißt dabei nicht ungeschützt: Diese Konten sollten an einen besonders starken Faktor gebunden bleiben, idealerweise ein FIDO2-Hardware-Token oder ein Zertifikat, statt nur die risikobasierte Prüfung zu umgehen. Weil sie ein bekannter, privilegierter Angriffspunkt sind, gehören sie mit eigener, scharfer Protokollierung versehen, sodass jede Nutzung sofort einen Alarm auslöst. Ein ausgenommenes Konto ohne starke Bindung und ohne Überwachung ist im Prüfgespräch ein wiederkehrender Befund.

Das BSI-Mapping als gemeinsame Sprache mit dem Prüfer

Der letzte Schritt übersetzt die Konfiguration in die Sprache, die der Prüfer ohnehin verwendet. Der IT-Grundschutz des BSI führt im Baustein ORP.4 Identitäts- und Berechtigungsmanagement Anforderungen, die sich gut als Bezugsrahmen für eine adaptive MFA nutzen lassen. ORP.4 ist kein dediziertes MFA-Mapping, deckt aber Authentisierung, Berechtigungssteuerung und Notfallzugänge ab. Wer seine Step-up-Regeln, die Geräteanforderungen und die Notfallkonten gegen diese Anforderungen spiegelt, liefert keine Tool-Screenshots, sondern eine Zuordnung in einer Sprache, die der Prüfer kennt.

Dieses Mapping muss nicht aufwendig sein. Eine Tabelle, die jeder Grundschutz-Anforderung die konkrete Policy-Regel und den Speicherort des Nachweises gegenüberstellt, reicht in den meisten Prüfungen aus. Sie verlagert das Gespräch von der Frage, ob die Maßnahme dem Stand der Technik entspricht, zu der schon beantworteten Frage, wie sie umgesetzt ist. Genau diese Verschiebung trennt eine adaptive MFA, die nur läuft, von einer, die als Control trägt.

Häufige Fragen

Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.

Reicht für NIS2 eine aktivierte Standard-MFA aus?

Technisch erfüllt sie eine Grundanforderung, für einen belastbaren Nachweis reicht sie oft nicht. NIS2 Artikel 21 verlangt risikoangemessene Maßnahmen und eine Bewertung ihrer Wirksamkeit. Eine MFA ohne dokumentierte, gegen den Schutzbedarf begründete Policy ist vorhanden, aber schwer als wirksam zu belegen. Die adaptive Variante mit exportierbaren, versionierten Regeln macht diesen Nachweis leichter.

Was unterscheidet adaptive MFA von normaler MFA im Prüfkontext?

Normale MFA verlangt bei jeder Anmeldung denselben zweiten Faktor. Adaptive MFA entscheidet kontextabhängig und kann diese Entscheidung als Regel dokumentieren. Genau diese dokumentierbare Logik macht sie für eine NIS2-Prüfung wertvoller, weil sie die Verbindung zwischen Risiko und Maßnahme sichtbar macht.

Welche BSI-Vorgabe ist für adaptive MFA relevant?

Der IT-Grundschutz-Baustein ORP.4 zum Identitäts- und Berechtigungsmanagement bietet einen passenden Bezugsrahmen, auch wenn er kein eigenes Kapitel zu adaptiver MFA enthält. Wer Step-up-Regeln und Notfallkonten gegen die ORP.4-Anforderungen spiegelt, übersetzt die Tool-Konfiguration in eine Sprache, die das BSI im Prüfgespräch ohnehin verwendet.

Wie verhindert man, dass adaptive MFA die Mitarbeiter blockiert?

Über einen gestuften Rollout und eine sinnvolle Signalgewichtung. Standortsignale sollten schwächer gewichtet sein als der Geräte-Verwaltungsstatus, weil VPN und Reisetätigkeit ständig neue Geolokationen erzeugen. Ein Pilot mit einer abgegrenzten Nutzergruppe zeigt vor dem breiten Ausrollen, wo Schwellen zu scharf gesetzt sind.

Warum sind Break-Glass-Konten ein Audit-Thema?

Weil sie bewusst von blockierenden Richtlinien ausgenommen sind und damit einen privilegierten Angriffspunkt darstellen. Die Ausnahme ist nötig, sie sollte aber an einen besonders starken Faktor wie ein FIDO2-Token gebunden bleiben. Ein Notfallkonto ohne starke Bindung und ohne scharfe Protokollierung ist im Prüfgespräch ein typischer Befund.

Muss die MFA-Policy versioniert werden?

Für einen belastbaren Nachweis ja. Eine versionierte Policy mit Änderungshistorie und Vier-Augen-Freigabe belegt, dass Schutzmaßnahmen nicht unkontrolliert abgeschwächt wurden. Angesichts der persönlichen Haftung der Leitung nach NIS2 ist dieser Nachweis mehr als eine Formalie.

Lesetipps der Redaktion

• Passkeys im Mittelstand: das Ende des Passworts
• OAuth-Token-Diebstahl: Wie Angreifer MFA aushebeln
• Edge-Gerät als Ransomware-Tor: Warum MFA am VPN nicht reicht

Mehr aus dem MBF Media Netzwerk