Adaptive MFA in Entra, Okta and Duo: How Security Teams Hook the 2026 Rollout to NIS2

8 min. read

In 2026, adaptive MFA is less a question of technology than a question of evidence. Since Germany’s NIS2 Implementation Act took effect without a transition period, security teams must not only demonstrate that they have multi-factor authentication in place — they must show they understand which risks they are mitigating with it. That means the thresholds used to drive decisions need to be documented. Entra Conditional Access, Okta Adaptive MFA, Duo Risk-Based, and Ping Identity all offer the capabilities. Yet rollouts still fail at the same gap: the space between feature and evidence.

RelatedInfostealer 2026: How Session Cookies Bypass MFA  /  Identity Sprawl in Mid-Sized Businesses: AD-Plus-Cloud Setups

NIS2 Article 21 as the Framework for Adaptive MFA

Germany’s NIS2 Implementation Act has been in force since December 6, 2025, with no transition period. Registration with the BSI (Federal Office for Information Security) was mandatory by March 6, 2026. Article 21 of the directive lists ten areas in which organisations must demonstrate measures — among them access policies, supply chain security, and, explicitly, multi-factor authentication. The directive’s wording is deliberately open: MFA must be implemented “appropriately,” without the EU or BSI prescribing any specific minimum thresholds.

That openness becomes a liability in audits when companies report MFA as active but have no documentation of their threshold logic. An auditor does not simply ask whether MFA is switched on. They ask under what conditions a second factor is enforced, what exceptions are configured, how emergency access is secured, and which logs make the decision behind a conditional access policy traceable. Security teams that have treated MFA as a checkbox item are now firmly on the back foot.

The Four Major IAM Platforms Compared: Adaptive MFA Head-to-Head

Microsoft Entra Conditional Access is the obvious choice for organisations running Microsoft 365, because the policy engine integrates directly into the identity stack and draws on signals such as sign-in risk, user risk, and device compliance from Microsoft Defender for Identity. Thresholds can be set at a granular level per group and application. The real effort lies in cleanly mapping policies to user groups and documenting the decision logic. Without proper policy hygiene, you end up two years down the road with a zoo of a hundred overlapping rules that nobody can untangle.

Okta Adaptive MFA positions itself as a multi-IdP platform and excels when multiple identity sources converge — Active Directory, G Suite, HR systems, and more. Its risk-scoring engine relies on device fingerprinting, network reputation, and behavioural patterns. For organisations that aren’t deeply embedded in Microsoft, Okta is often the first choice. It costs more than Entra, but the flexibility is correspondingly greater.

Duo Security, now part of Cisco, is widely deployed in the mid-market and among companies running Cisco infrastructure. Its risk-based features are mature, and integration with Cisco ISE and Umbrella saves money and time for those who have already invested in that stack. Ping Identity plays a stronger role in enterprise environments with complex B2B integrations, Customer Identity Access Management (CIAM), and federated identities than it does in the classic mid-market. The four platforms overlap in core functionality but differ considerably in how deeply they integrate with existing stacks.

In practice, legacy application support often matters more than any feature matrix. Many German mid-sized companies run applications that understand neither SAML nor OpenID Connect. Header-based authentication, RADIUS proxies, and certificate-based SSH access are standard in that context. Duo and Ping have more depth in this area, while Entra has caught up significantly over the past 18 months through Entra Application Proxy and Entra ID Governance. Okta covers the gap via its Access Gateway. Evaluating these edge cases should be part of the selection phase — otherwise the rollout stalls the moment a core ERP system or a specialist application can’t be onboarded.

Licensing is the second variable that shifts significantly in any comparison. Microsoft Entra Conditional Access is included in Entra ID P1 and P2, with P2 unlocking risk-based policies through Identity Protection. Okta licenses per user across multiple packages covering MFA, Adaptive MFA, and Lifecycle Management. Duo offers a clear tiered model with Duo Essentials, Advantage, and Premier. Ping tends to sit higher in enterprise pricing, but provides deeper customisation options in return. Anyone looking for a benchmark price should always compare the specific configuration being deployed, not headline per-user list prices.

Why MFA Fatigue Is the Number One Rollout Risk

A successful Adaptive MFA rollout hinges not on the policy engine, but on user experience. Push bombing attacks — where attackers repeatedly trigger MFA prompts until a user confirms out of habit — became standard playbook material in 2025. The industry’s answer is number matching, which requires users to enter a displayed code into the authenticator app. Microsoft has enabled this by default; Duo and Okta have their own variants. Any organization not enforcing number matching is leaving the door wide open.

Threshold calibration is the second challenge. When an Adaptive MFA system demands a second factor on every other login, prompt fatigue sets in and workarounds emerge. When it challenges too rarely, the security benefit evaporates. The pragmatic approach is to launch with conservative policies in the first three months and use telemetry to learn which login patterns are genuinely anomalous. Entra, Okta, and Duo all offer dashboards that make prompt frequency visible per user and risk level.

One frequently overlooked area is the handling of service accounts and API access. Adaptive MFA is optimized for interactive user logins. Automated processes require certificate-based authentication or short-lived tokens with rotation. Organizations leaving service accounts protected only by long-lived passwords — with no MFA — are maintaining an attack vector that adversaries will actively target in 2026. Documenting the service account policy is part of NIS2 evidence requirements, not just user-facing MFA.

A third component scrutinized during audits is the handling of external users. Suppliers, contractors, and partners regularly gain access to internal systems without going through the standard IAM process. Entra B2B Collaboration, Okta External Identities, and Ping DaVinci provide dedicated functions that give external parties a clean MFA path. Organizations forcing external users into internal accounts face not just an evidence gap, but an attack surface that was actively exploited in multiple supply chain incidents throughout 2025.

How Security Teams Can Execute a Clean Rollout

A realistic rollout runs in four phases spanning ten to twenty weeks depending on organizational size. The first phase is inventory; the last is audit readiness.

The most common weakness in any rollout is the missing link to incident response. When the SIEM spots suspicious login patterns but the IAM team doesn’t know how to quarantine accounts quickly, Adaptive MFA develops a blind spot. The integration between Entra or Okta and the SOC pipeline belongs in phase one, not bolted on at the end. In practice, that means Splunk, Sentinel, or Elastic need sign-in logs, risk events, and policy-change events in a central store, with alerts on patterns like ten failed logins in five minutes or a prompt originating from an unusual country. Log formats differ between Entra and Okta, and normalization is a workstream that cannot be delegated to the SIEM vendor.

Finally, the most important point: Adaptive MFA is not a project with a finish line — it is an ongoing operation. Thresholds shift as attackers adopt new techniques. New applications get onboarded, user groups evolve. Organizations that treat the rollout as a one-time project will find themselves, eighteen months later, with an IAM stack that no longer reflects the current threat landscape. A dedicated IAM operations role and quarterly policy reviews are what turn Adaptive MFA into productive, auditable evidence.

A concrete real-world reference: a mechanical engineering firm in the Sauerland region launched its rollout on Entra Conditional Access in late 2025. The pilot ran for two weeks with an IT user group and deliberately conservative policies. In the first three days, 140 MFA prompts per user per day were recorded because a policy trigger fired on every switch between VPN and the office LAN. After calibrating with compliant-device status as a signal, the prompt count dropped to 12 to 18 per day — a level users accepted. The lesson: telemetry during the pilot phase is not an optional feature; it is the instrument that determines whether people will actually embrace the system.

Another issue that surfaces regularly in audit discussions is the distinction between authentication and authorization. MFA decides whether someone is allowed to log in securely. What they can do afterward is governed by authorization — through Role-Based Access Control (RBAC), Privileged Access Management (PAM), or just-in-time access. Many organizations conflate the two, leading to the mistaken belief that strong MFA compensates for weak role configuration. It does not. NIS2 explicitly requires access policies under Article 21. Those policies must rest on a sound role architecture, not on the MFA prompt alone.

Frequently Asked Questions

Does NIS2 explicitly require Adaptive MFA, or is classic MFA sufficient?

The directive calls for “appropriate” MFA without specifying exact parameters. Organisations using classic MFA with a strong second factor meet the requirement — provided the documentation is clean. Adaptive MFA is not mandatory, but for risk-exposed organisations it has become the de facto standard in practice, because it makes thresholds and exceptions auditable and transparent.

How does a migration from Duo to Entra Conditional Access work in Microsoft 365 environments?

Typically in parallel, not as a big bang. Conditional Access kicks in first for Microsoft applications, while Duo remains in place for Cisco systems and legacy applications. After six to nine months it usually becomes clear whether a full switch is worthwhile or whether a hybrid setup makes more sense long term.

What thresholds are a good starting point for Adaptive MFA?

A typical starting point: trigger an MFA prompt on login from a new device, an unknown network IP, outside working hours, or when accessing sensitive applications. After three months, thresholds are adjusted based on telemetry — often resulting in some conditions being tightened and others relaxed.

How do I handle service accounts that can’t support interactive MFA?

Service accounts use certificate-based authentication or Managed Identities, combined with short-lived tokens and secrets rotation in the vault. The protection level is not MFA, but it is equivalent. Documenting this decision is important so that auditors understand the policy rationale.

What does the BSI say about Number Matching as a default?

The BSI recommends Number Matching or equivalent methods in its current guidance documents, without framing it as an explicit obligation. Microsoft has configured Number Matching as the default for Entra Authenticator; Duo and Okta strongly recommend it and feature it prominently in the admin consoles of current releases. Anyone using push confirmations without matching must justify that decision in their risk analysis and record it in their NIS2 documentation.

More from the MBF Media Network

Cover image source: Pexels / indra projects (px:27742642)

About the author: Alec Chizhik

More articles by Alec Chizhik