21. April 2026 | Artikel drucken |

Adaptive MFA in Entra, Okta und Duo: Wie Security-Teams den Rollout 2026 an NIS2 andocken

8 Min. Lesezeit

Adaptive MFA ist 2026 weniger eine Frage der Technologie als eine Frage der Evidenz. Seit das NIS2-Umsetzungsgesetz in Deutschland ohne Übergangsfrist wirkt, müssen Security-Teams nicht nur zeigen, dass sie Multi-Faktor-Authentifizierung haben. Sie müssen zeigen, dass sie wissen, welche Risiken sie damit abfedern. Dazu gehört, dass die Schwellwerte zur Entscheidung dokumentiert sind. Entra Conditional Access, Okta Adaptive MFA, Duo Risk-Based und Ping Identity bieten die Funktionen. Der Rollout scheitert trotzdem oft an der Lücke zwischen Feature und Evidenz.

Das Wichtigste in Kürze

  • NIS2 fordert MFA, aber nennt keine Parameter. Artikel 21 verlangt Multi-Faktor-Authentifizierung, überlässt Schwellwerte und Ausnahmen dem Unternehmen. Die Dokumentationspflicht ist konkret, der technische Rahmen bewusst breit.
  • Die Wahl zwischen Entra, Okta, Duo und Ping hängt am Stack. Wer bereits Microsoft 365 tief nutzt, landet meist bei Entra Conditional Access. Für Multi-IdP-Umgebungen bleibt Okta die flexibelste Plattform, Duo ist im Cisco-Kontext gesetzt, Ping Identity liefert im Enterprise-Segment.
  • MFA-Fatigue ist das operative Kernproblem. Push-Bombing und Number-Matching-Angriffe nehmen zu. Ohne Schwellwert-Kalibrierung und Benutzer-Training verliert Adaptive MFA den Effekt, den es haben soll.

VerwandtInfostealer 2026: Wie Session-Cookies MFA aushebeln  /  Identity-Sprawl im Mittelstand: AD-plus-Cloud-Setups

NIS2 Artikel 21 als Rahmen für Adaptive MFA

Das deutsche NIS2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft, ohne Übergangsfrist. Die Registrierung beim BSI war bis zum 6. März 2026 Pflicht. Artikel 21 der Richtlinie listet zehn Bereiche auf, in denen Unternehmen Maßnahmen nachweisen müssen, darunter Zugriffsrichtlinien, Lieferkettensicherheit und explizit Multi-Faktor-Authentifizierung. Die Formulierung in der Richtlinie ist bewusst offen: MFA ist „angemessen“ umzusetzen, ohne dass die EU oder das BSI konkrete Mindestschwellen vorgeben.

Diese Offenheit wird in Audits zum Problem, wenn Unternehmen MFA als aktiviert melden, aber keine Dokumentation zur Schwellwert-Logik haben. Ein Auditor fragt nicht, ob MFA eingeschaltet ist. Er fragt, unter welchen Bedingungen ein zweiter Faktor erzwungen wird, welche Ausnahmen konfiguriert sind, wie Notfall-Zugänge gesichert sind und welche Protokolle die Entscheidung eines Conditional-Access-Policys nachvollziehbar machen. Security-Teams, die MFA als Checkbox-Thema behandelt haben, sind in dieser Phase in der Defensive.

6. März 2026
Frist zur BSI-Registrierung unter NIS2. Wer bis dahin nicht registriert war, arbeitet ab sofort gegen Bußgeldrisiko und verliert Spielraum in der Evidenz-Diskussion.
Quelle: BSI, NIS2-Umsetzungsgesetz, in Kraft seit 6. Dezember 2025.

Die vier großen IAM-Plattformen im Adaptive-MFA-Vergleich

Microsoft Entra Conditional Access ist in Organisationen mit Microsoft 365 der naheliegende Weg, weil die Policy-Engine direkt in den Identitäts-Stack integriert ist und Signale wie Sign-in-Risk, User-Risk und Device-Compliance aus Microsoft Defender for Identity nutzt. Die Schwellwerte lassen sich granular pro Gruppe und Anwendung setzen. Der Aufwand liegt in der sauberen Zuordnung von Policies zu Benutzergruppen und der Dokumentation der Entscheidungs-Logik. Wer keine Policy-Hygiene betreibt, hat nach zwei Jahren einen Zoo aus hundert überlappenden Regeln, bei dem niemand mehr weiß, welche greift.

Okta Adaptive MFA positioniert sich als Multi-IdP-Plattform und ist stark, wenn mehrere Identitäts-Quellen zusammenlaufen (Active Directory, G Suite, HR-Systeme). Die Risk-Scoring-Engine nutzt Device-Fingerprinting, Netzwerkreputation und Verhaltensmuster. Für Unternehmen, die nicht tief in Microsoft stecken, ist Okta häufig die erste Wahl. Der Preis liegt über Entra, die Flexibilität ist dafür höher.

Duo Security, inzwischen Teil von Cisco, ist im Mittelstand und bei Unternehmen mit Cisco-Infrastruktur weit verbreitet. Die Risk-Based-Funktionen sind ausgereift, die Integration in Cisco ISE und Umbrella spart bei entsprechender Vorinvestition Geld und Zeit. Ping Identity spielt im Enterprise-Segment mit komplexen B2B-Integrationen, Customer Identity Access Management und föderierten Identitäten eine stärkere Rolle als im klassischen Mittelstand. Die vier Plattformen überschneiden sich in Kernfunktionen, unterscheiden sich aber deutlich in der Tiefe der Integration in bestehende Stacks.

In der Praxis entscheidet oft weniger die Feature-Matrix als der Support für Legacy-Anwendungen. Viele deutsche Mittelständler haben Anwendungen, die weder SAML noch OpenID Connect verstehen. Header-based Authentication, RADIUS-Proxy oder SSH-Zugriffe mit Zertifikaten sind in dem Kontext Standard. Duo und Ping haben in dem Feld mehr Tiefe, Entra hat in den letzten 18 Monaten durch Entra Application Proxy und Entra ID Governance aufgeholt. Okta deckt das Feld über den Access Gateway ab. Die Bewertung dieser Nischen sollte Teil der Auswahl-Phase sein, sonst platzt der Rollout, wenn die zentrale Warenwirtschaft oder eine Fachanwendung nicht eingebunden werden kann.

Die Lizenzierung ist der zweite Punkt, der im Vergleich schwankt. Microsoft Entra Conditional Access ist in Entra ID P1 und P2 enthalten, wobei P2 die Risk-Policies mit Identity Protection freischaltet. Okta lizenziert pro Benutzer mit verschiedenen Paketen für MFA, Adaptive MFA und Lifecycle Management. Duo hat ein übersichtliches Mehrstufen-Modell mit Duo Essentials, Advantage und Premier. Ping liegt im Enterprise-Bereich oft höher, bietet dafür tiefere Customizing-Optionen. Wer einen Benchmark-Preis sucht, vergleicht immer die konkrete Konfiguration, nicht die Listenpreise pro Benutzer.

Warum MFA-Fatigue das Rollout-Risiko Nummer eins ist

Ein produktiver Adaptive-MFA-Rollout steht und fällt nicht mit der Policy-Engine, sondern mit der User Experience. Push-Bombing-Angriffe, bei denen Angreifer wiederholt MFA-Prompts auslösen, bis der Benutzer aus Gewohnheit bestätigt, sind 2025 zum Standard-Playbook geworden. Die Antwort der Anbieter ist Number-Matching, bei dem der Benutzer eine angezeigte Zahl in der Authenticator-App eingeben muss. Microsoft hat das als Default aktiviert, Duo und Okta haben Varianten. Wer Number-Matching nicht erzwingt, hat die Tür offen.

Was MFA-Fatigue auslöst

  • Push-Prompts ohne Kontext (kein App-Name, keine Geolocation)
  • Zu niedrige Schwellwerte, die jeden Login auslösen
  • Fehlende User-Education zu Phishing-Versuchen
  • Fehlendes Reporting-Tooling für verdächtige Prompts

Was Fatigue-Attacken dämpft

  • Number-Matching als Default für alle Benutzer
  • Risiko-basierte Policies, die vertrauenswürdige Geräte entlasten
  • Self-Service Report-Button im Authenticator
  • SIEM-Integration für Push-Bombing-Muster-Erkennung

Die Schwellwert-Kalibrierung ist die zweite Baustelle. Wenn ein Adaptive-MFA-System bei jedem zweiten Login einen zweiten Faktor verlangt, entstehen Prompt-Müdigkeit und Workarounds. Wenn es zu selten nachfragt, verliert es den Sicherheitseffekt. Der pragmatische Ansatz ist, in den ersten drei Monaten mit konservativen Policies zu starten und über Telemetrie zu lernen, welche Login-Muster wirklich auffällig sind. Entra, Okta und Duo bieten dafür Dashboards, die die Prompt-Häufigkeit pro Benutzer und Risiko-Level sichtbar machen.

Ein oft übersehener Aspekt ist die Behandlung von Service-Konten und API-Zugriffen. Adaptive MFA ist auf interaktive Benutzer-Logins optimiert. Bei Automatisierungen braucht es Certificate-basierte Authentifizierung oder zeitlich begrenzte Tokens mit Rotation. Wer Service-Konten mit langlebigen Passwörtern ohne MFA stehen lässt, hat ein Einfallstor, das Angreifer 2026 gezielt suchen. Die Dokumentation der Service-Konten-Policy ist Teil der NIS2-Evidenz, nicht nur die Benutzer-MFA.

Eine dritte Komponente, die in Audits geprüft wird, ist die Behandlung externer Benutzer. Lieferanten, Dienstleister und Partner bekommen regelmäßig Zugriff auf interne Systeme, ohne dass sie im Standard-IAM-Prozess stehen. Entra B2B Collaboration, Okta External Identities und Ping DaVinci bieten dafür Funktionen, die Externen einen sauberen MFA-Pfad geben. Wer Externe in interne Benutzer-Konten zwingt, hat nicht nur ein Evidenzproblem, sondern auch eine Angriffsfläche, die gerade bei Supply-Chain-Angriffen 2025 mehrfach genutzt wurde.

Wie Security-Teams den Rollout sauber aufsetzen

Ein realistischer Rollout läuft in vier Phasen, die sich je nach Organisationsgröße zwischen zehn und zwanzig Wochen erstrecken. Die erste Phase ist Bestandsaufnahme, die letzte ist Audit-Readiness.

Adaptive-MFA-Rollout in vier Phasen
Phase 1 (Wo 1-4)
Bestandsaufnahme: Alle IAM-Quellen inventarisieren, Benutzergruppen nach Risikoklassen segmentieren, Service-Konten separat listen. Ohne sauberes Inventar werden Policies willkürlich.
Phase 2 (Wo 4-10)
Policy-Design: Conditional-Access- oder Risk-Based-Regeln definieren, pro Benutzergruppe und Anwendung. Number-Matching als Default. Notfall-Pfad für Break-Glass-Accounts dokumentieren.
Phase 3 (Wo 10-16)
Pilotierung: Eine Benutzergruppe als Pilot, zwei Wochen beobachten, Telemetrie auswerten, Schwellwerte anpassen. Support-Playbook für MFA-Sperrungen und Geräte-Registrierungen schreiben.
Phase 4 (Wo 16+)
Audit-Readiness: Policy-Dokumentation im IT-Governance-System ablegen, Nachweise über Schwellwert-Entscheidungen führen, Reviews mit CISO und DSB quartalsweise kalendern.

Die häufigste Schwachstelle im Rollout ist die fehlende Verknüpfung zu Incident Response. Wenn das SIEM verdächtige Login-Muster sieht, aber das IAM-Team nicht weiß, wie es Accounts schnell in Quarantäne schiebt, hat Adaptive MFA einen blinden Fleck. Die Integration zwischen Entra oder Okta und der SOC-Pipeline gehört in die erste Phase, nicht an den Schluss. Konkret heißt das: Splunk, Sentinel oder Elastic brauchen die Sign-in-Logs, Risk-Events und Policy-Change-Events in einer zentralen Ablage, mit Alerts auf Muster wie zehn fehlgeschlagene Logins in fünf Minuten oder einen Prompt aus einem ungewöhnlichen Land. Die Log-Formate unterscheiden sich zwischen Entra und Okta, die Normalisierung ist ein Arbeitspunkt, der nicht an den SIEM-Anbieter delegiert werden kann.

Zum Schluss der wichtigste Punkt: Adaptive MFA ist kein Projekt mit Abschluss, sondern ein Dauerbetrieb. Die Schwellwerte verschieben sich, weil Angreifer neue Techniken nutzen. Neue Anwendungen werden eingebunden, Benutzergruppen verändern sich. Wer den Rollout als einmaliges Projekt plant, bekommt nach achtzehn Monaten einen IAM-Stack, der die neueste Bedrohungslage nicht mehr abbildet. Eine feste Rolle für IAM-Betrieb und quartalsweise Policy-Reviews sind das, was aus Adaptive MFA eine produktive Evidenz macht.

Aus der Praxis ein konkreter Anker: Ein Maschinenbauer im Sauerland hat Ende 2025 den Rollout auf Entra Conditional Access gestartet. Die Pilotphase lief über zwei Wochen mit einer IT-Gruppe, inklusive bewusst konservativer Policies. In den ersten drei Tagen wurden 140 MFA-Prompts pro Benutzer und Tag registriert, weil ein Policy-Trigger auf jeden Wechsel zwischen VPN und Office-LAN reagiert hat. Nach einer Kalibrierung mit Compliant-Device-Status als Signal sank die Prompt-Anzahl auf 12 bis 18 pro Tag, was die Benutzer akzeptiert haben. Die Lehre: Telemetrie in der Pilotphase ist kein optionales Feature, sondern das Werkzeug, das über Akzeptanz entscheidet.

Ein weiterer Punkt, der in Audit-Gesprächen regelmäßig auftaucht: Die Trennung zwischen Authentifizierung und Autorisierung. MFA entscheidet, ob jemand sich sicher anmelden darf. Was er danach tun darf, regelt die Autorisierung über Role-Based Access Control, Privileged Access Management oder Just-in-Time-Zugriff. Viele Unternehmen werfen das in einen Topf, was zu dem Fehlschluss führt, starke MFA gleiche schwache Rollen-Konfiguration aus. Sie tut es nicht. NIS2 verlangt in Artikel 21 explizit Zugriffsrichtlinien. Diese Richtlinien müssen auf einer sauberen Rollen-Architektur sitzen, nicht allein auf dem MFA-Prompt.

Häufige Fragen

Verlangt NIS2 ausdrücklich Adaptive MFA oder reicht klassisches MFA?

Die Richtlinie fordert „angemessene“ MFA ohne genaue Parameter. Wer klassisches MFA mit starkem zweiten Faktor einsetzt, erfüllt die Pflicht, wenn die Dokumentation sauber ist. Adaptive MFA ist kein Muss, wird aber bei risikoexponierten Organisationen praktisch zum De-facto-Standard, weil sie Schwellwerte und Ausnahmen nachvollziehbar macht.

Wie läuft der Wechsel von Duo zu Entra Conditional Access in Microsoft-365-Umgebungen?

In der Regel parallel, nicht als Big-Bang. Conditional Access greift zuerst für Microsoft-Anwendungen, Duo bleibt für Cisco-Systeme und Legacy-Anwendungen. Nach sechs bis neun Monaten ist meist klar, ob sich der vollständige Wechsel lohnt oder ein hybrides Setup dauerhaft sinnvoll ist.

Welche Schwellwerte sind ein guter Startpunkt für Adaptive MFA?

Ein typischer Startpunkt ist: MFA-Prompt bei Login von neuem Gerät, von unbekannter Netzwerk-IP, außerhalb der Arbeitszeit oder bei Zugriff auf sensible Anwendungen. Nach drei Monaten werden die Schwellwerte anhand der Telemetrie angepasst, oft mit dem Ergebnis, dass einige Bedingungen verschärft und andere gelockert werden.

Wie gehe ich mit Service-Konten um, die keine interaktive MFA können?

Service-Konten bekommen Certificate-basierte Authentifizierung oder Managed Identities, kombiniert mit kurzlebigen Tokens und Secrets-Rotation im Vault. Die Schutzebene ist nicht MFA, aber äquivalent. Die Dokumentation dieser Entscheidung ist wichtig, damit der Auditor die Policy versteht.

Was sagt das BSI zu Number-Matching als Default?

Das BSI empfiehlt Number-Matching oder gleichwertige Verfahren in seinen aktuellen Handlungsempfehlungen, ohne es explizit als Pflicht zu formulieren. Microsoft hat Number-Matching für Entra Authenticator als Default konfiguriert, Duo und Okta empfehlen es stark und bieten es in aktuellen Releases prominent in den Admin-Konsolen an. Wer Push-Bestätigungen ohne Matching nutzt, muss die Entscheidung in der Risikoanalyse begründen und in der NIS2-Dokumentation hinterlegen.

Mehr aus dem MBF Media Netzwerk

cloudmagazin

Opus 4.7 gegen GPT-5.4: Lokale KI-Inference bei europäischen Cloud-Anbietern

mybusinessfuture

Predictive Analytics im ERP: Mittelstand-Kundenbindung 2026

digital-chiefs

NVIDIA-Dominanz und Alternativen: CIO-KI-Stack 2026

Quelle Titelbild: Pexels / indra projects (px:27742642)

Alec Chizhik

Hier schreibt Alec Chizhik für Sie

Mehr Artikel vom Autor

Ein Magazin der Evernine Media GmbH