Adaptive MFA: NIS2 Pressure as a Zero-Trust

By Alec Chizhik · May 7, 2026 · 10 min read

NIS2 was transposed into German law as of October 2024, with the implementing act entering into force in January 2026. For mid-sized operators of essential and critical infrastructure, compliance pressure is now shifting from paper-based documentation to a concrete identity architecture. Adaptive MFA is no longer just a feature – it’s the lever enabling SMEs to turn this obligation into a Zero Trust strategy capable of withstanding audits without disrupting daily operations.

07.05.2026

Key takeaways

Adaptive MFA meets NIS2 requirements: Article 21, paragraph 2, point j mandates phishing-resistant multi-factor authentication. Adaptive MFA with risk signals (device posture, geolocation, behavior, time) complies under the BSI’s January 2026 implementation guidance.
Escalate instead of always-on: Enforcing MFA on every login floods support queues with tickets and workarounds. Risk-based escalations (critical action, new device, unusual geolocation) cut MFA volume by 60–75% without weakening protection.
FIDO2 hardware keys over SMS: Per the BSI’s 2026 guidance, SMS OTP is no longer considered phishing-resistant. To authenticate NIS2-compliantly, organizations need FIDO2/WebAuthn or passkeys. SMS backup remains permitted only as a documented, time-limited recovery path.

What adaptive MFA should achieve in the context of NIS2

What is adaptive MFA? Adaptive multi-factor authentication is a type of MFA that requests a second factor based on risk signals. Instead of blocking every login attempt with a hardware key or OTP, the system evaluates device compliance, IP reputation, geographic distance, time of day, behavioral patterns, and resource sensitivity. A known user on a compliant MDM-enabled device at their usual location won’t receive an MFA prompt, while a login from a new device in Lagos at 03:40 triggers a hardware key request and escalation to the support team.

NIS2 explicitly requires, in Article 21 and within its minimum technical measures, multifactor or continuous authentication solutions. The BSI’s January 2026 implementation guidance specifies these as phishing-resistant procedures and lists FIDO2, WebAuthn passkeys, and certificate-based smart cards as acceptable methods. SMS OTP, unprotected TOTP apps, and push approvals without numeric matching are no longer considered sufficient.

For mid-sized operators, this means an architectural decision. A classic always-on MFA using TOTP apps can be implemented but fails to meet the requirement. In contrast, an adaptive solution with a risk engine, FIDO2 keys, and escalation logic satisfies the requirement while also reducing support-service load – a major driver of shadow IT and workarounds.

Three levers mid-market NIS2 entities must pull now

Adaptive MFA is often framed in DACH SMEs as a tooling question. In reality, it’s an architectural challenge with three levers that must be applied in sequence.

First, identity consolidation. Layering adaptive MFA over disconnected directories multiplies risk engines without coherent oversight. Before rolling out MFA, a centralized identity plan is essential. Microsoft Entra ID, Okta, or open-source options like Authentik are technically comparable; the critical point is offboarding on-prem Active Directory domains and integrating third-party access. Failure to centralize risks losing control of the risk engine entirely.

Second, device posture. Adaptive MFA hinges on whether devices are trustworthy. This assessment comes from MDM and EDR telemetry. Allowing MFA bypass for trusted devices without MDM compliance is formally adaptive MFA, yet practically a Swiss-cheese model. Typical DACH routes include Microsoft Intune, Jamf, Workspace ONE, or pairing Entra Conditional Access with third-party EDRs like CrowdStrike.

Third, recovery procedures. NIS2 demands not only strong authentication but also its availability. Issuing FIDO2 keys to every employee must account for loss scenarios. Recovery via backup keys, support-team verification with documented liveness checks, time-bound recovery windows, and audit trails are mandatory. Without these, the model collapses at the first lost hardware key in production.

68 %

Share of DACH SMEs affected by NIS2 that, as of early 2026, still rely on SMS-OTP or unprotected TOTP apps as their primary second factor. According to the BSI’s January 2026 guidance, this no longer meets audit requirements.

Source: Our industry survey, DACH SMEs, Q1 2026

Key milestones in a 90-day migration to adaptive MFA

A full migration to adaptive MFA with FIDO2 typically takes 80–100 days in a mid-size enterprise environment. Skipping or reordering steps creates audit gaps or forces escalations to the helpdesk.

90-day roadmap: adaptive MFA for SMEs under NIS2

Weeks 1–2

Identity inventory: directories, shadow systems, vendor access, service accounts. Flag privileged vs. non-central accounts. Without this visibility, any MFA logic fails at the edges.

Weeks 3–5

Pilot with privileged accounts: migrate 20–40 admin accounts to FIDO2 keys, configure conditional-access policies (Okta), and test helpdesk recovery paths. Run the pilot as a stress test, not a marketing demo.

Weeks 6–9

Device-posture integration: enforce MDM compliance, EDR health, and conditional-access rules that demand MFA on unknown devices and escalate authentication for critical actions on MDM-compliant devices. Tune the risk engine with real-world data.

Weeks 10–11

Broad rollout: standard employees, phased by department, using hardware FIDO2 keys with Passkey fallback. Deploy pre-support scripts, run team training sessions, and watch for login-failure spikes.

From week 12

Audit logging & reporting: document NIS2 compliance, map BSI guidelines, perform quarterly risk-engine reviews, and adjust triggers in response to CISA-KEV entries or new BSI advisories.

What Keeps SMEs Secure – and What Breaks Them

What Breaks

Adaptive MFA scattered across disconnected directories. The risk engine only sees fragments; compliance audits look formally correct but are riddled with gaps.
SMS-OTP as the default factor with no documented sunset plan. The BSI 2026 guidance no longer tolerates it, and a first audit dismantles the certification basis.
Service accounts without an MFA path. Excluding service accounts from MFA by default doesn’t create adaptive MFA – it creates MFA with a backdoor.
Recovery processes that allow help-desk tickets without liveness checks. Social engineering undermines the model without leaving a trace.

What Keeps

FIDO2 hardware keys backed by Passkeys. Phishing-resistant, BSI-compliant, fast in daily use, and free of SMS-roaming traps.
Escalation for critical actions instead of always-on. Help-desk volume drops by 60–75 percent; protection remains intact.
Risk engine with device posture, geolocation, and behavioral signals. Consistent audit trails instead of spotty logs.
Recovery path with documented liveness checks and time limits. Auditable, social-engineering-resistant, and audit-proof.

Who Holds the Levers Now

Three profiles gain sharper clarity. Mid-sized energy providers, municipal IT suppliers, and manufacturers with OT links because NIS2 classifies them as essential entities with stricter penalties. Hospitals and outpatient medical-center groups (MVZ) because patient-data criticality and KRITIS status overlap there. And IT vendors serving clients in NIS2-relevant sectors because Article 21 explicitly widens supplier obligations. Anyone without these triggers should start the SMS-OTP retirement debate before the first BSI audit forces the issue.

An honest observation: the biggest friction in such projects comes from top management. If the C-suite doesn’t lead by example with the first FIDO2 key – and instead dodges its own responsibility – it sabotages the mandate. Adaptive MFA is decided in week three, when someone asks whether the CFO really needs a hardware key. The answer is yes. The follow-up discussion reveals whether the company takes Zero-Trust seriously or is merely staging the next compliance theater. Those who don’t patch active BSI warnings such as cPanel CVE-2026-41940 have only grasped half of NIS2.

Frequently Asked Questions

Every question is locked. A tap unlocks the answer.

Is an existing TOTP solution like Authy or Google Authenticator enough for NIS2?

No longer. The BSI implementation guidance from January 2026 mandates phishing-resistant procedures as the minimum standard. Plain TOTP without anti-phishing safeguards is out because an attacker can intercept the OTP code in real time via a phishing proxy and forward it. FIDO2/WebAuthn is cryptographically bound to the origin and therefore immune to this attack. If you must keep TOTP, add layers such as number-matching with device verification or FIDO2 backups for privileged accounts.

What is a realistic budget for migrating to adaptive MFA for a mid-sized company?

For a company with 500 to 2,000 employees, implementation costs range from €65,000 to €180,000, depending on whether the identity framework is already centralized. Hardware keys cost between €35 and €75 per employee, while licenses for Conditional Access or Okta range from €4 to €12 per user per month. The largest expense is typically for consulting services during the first twelve weeks, as pilot phases and recovery procedures rarely run smoothly without external expertise.

What happens if an FIDO2 key is lost within the organization?

There are three fallback options, in order: the documented backup key in the desk drawer, the access key on the mobile device as a recovery method, and verification via the helpdesk with documented liveness checks. The latter is the most politically sensitive and requires a defined four-eyes principle, video verification, and mandatory logging in the audit trail. Without this protocol, losing a key within the organization can lead to compliance violations or audit findings.

How does adaptive MFA relate to Zero-Trust architectures?

Adaptive MFA is a prerequisite for Zero Trust, but it doesn’t cover the entire stack. Zero Trust also demands micro-segmentation, continuous device assessment, data-layer policies, and a strict least-privilege model. Adaptive MFA provides the identity component without which the rest is unworkable. Anyone treating Zero Trust merely as a marketing term for a single sign-on project has missed the mark entirely.

What obligations do NIS2 requirements place on Adaptive MFA providers?

Article 21 obliges operators of essential and important facilities to integrate their suppliers into their own risk management. In practice, this means that IT service providers, cloud providers, and SaaS vendors must demonstrate the same Adaptive MFA standards on their own tenant access paths. Anyone operating VPNs through third-party providers or admin consoles without Adaptive MFA risks triggering a supply-chain audit. Contractual addenda from mid-2026 will include increasingly explicit MFA clauses.

More from the MBF Media Network

cloudmagazinMini-PCs Supplant 1U Servers: Edge MyBusinessFutureAI in Accounting: 78% Dark Entries in SMEs Digital ChiefsGartner: 13.5% IT Growth by 2026 – CIOs Must Shift Strategies