Adaptive MFA as NIS2 Standard 2026: How ENISA Guidance Clarified the Where-Appropriate Clause

NIS2 requires multi-factor authentication (MFA) “where appropriate,” and in Germany, the BSI enforcement mandate enters its operational phase in May 2026. For security and compliance officers, the central question is no longer “do we have MFA?” but rather “do we have the right MFA in place at the right locations, backed by documented risk justification?” Organizations still relying on a blanket MFA setup in 2026 will face an open finding during BSI audits.

Key Takeaways: Adaptive MFA Becomes the NIS2 Compliance Standard in 2026

• NIS2 §2(j) requires multi-factor authentication (MFA) or continuous authentication “where appropriate.” The ENISA guidance issued in Q1 2026 clarified that “appropriate” does not mean optional, but rather mandates a documented risk assessment for each account class.
• The BSI enforcement mandate enters its operational phase in Germany in May 2026, following Belgium’s implementation on April 18, 2026. The first audits will begin in Q3 2026, focusing primarily on the energy, healthcare, public administration, banking, telecommunications, and industrial plant manufacturing sectors.
• In 2026, adaptive MFA-risk-based authentication using contextual signals instead of blanket MFA-emerges as the pragmatic compliance path. It reduces user friction by 40 to 70 percent while simultaneously delivering stronger audit trails.
• Three components are critical under BSI requirements in 2026: an identity risk inventory with account classification, an adaptive MFA engine leveraging contextual signals, and an audit trail with forensic-level detail retained for at least 12 months.
• Organizations that properly establish their compliance architecture now will avoid potential fines of up to €10 million in 2027 and simultaneously position themselves for the upcoming wave of DORA resilience requirements.

What the ENISA Q1 2026 Guidance Clarified About the “Where Appropriate” Clause

The NIS2 clause “where appropriate” has caused confusion since the directive was adopted in 2022. Many compliance officers interpreted it as granting discretionary leeway, allowing organizations to decide for themselves where multi-factor authentication (MFA) makes sense. The ENISA guidance issued in the first quarter of 2026 has clearly rejected this interpretation. “Where appropriate” now means organizations must provide a documented risk assessment for each account class, justifying why MFA applies-or why it does not. A simple statement like “we have MFA enabled in Outlook” is no longer sufficient in 2026.

The structural requirement is an identity risk inventory. Each account class-employee accounts, admin accounts, service accounts, external vendor access, emergency accounts, and machine accounts-must be listed in a table with corresponding risk assessments, MFA mechanisms, justifications, and review dates. The ENISA guidance explicitly identifies privileged access (admin accounts), remote access, and external vendor accounts as areas where MFA is practically always considered “appropriate.” Organizations lacking MFA for these categories will face findings during a BSI (Federal Office for Information Security) audit.

The NIS2 messaging requirements effective April 2026 illustrate how deeply compliance architectures now extend into operational detail. MFA is one of the central components, as it directly impacts both identity security and forensic capabilities during security incidents.

Why Adaptive MFA Is the Pragmatic Path

Universal MFA for all accounts sounds secure at first glance, but in practice faces two challenges: user friction and weak auditability. User friction leads to workaround behaviors-such as accepting push-bombing alerts, relying on weak password reset pathways, or creating shadow accounts-that can actually reduce overall security. Audit weakness arises because blanket MFA provides no contextual logging, meaning it cannot distinguish whether a login originated from an unusual scenario or a standard setup.

Adaptive MFA resolves both issues. It leverages contextual signals-device identity, location, time of day, behavioral patterns, and resource sensitivity-to dynamically determine the required MFA strength for each login attempt. A standard login from a registered device profile may only require a simple second factor. In contrast, logins from unfamiliar locations or exhibiting anomalous behavior trigger stronger authentication methods-such as a FIDO2 hardware key or biometric verification-or an additional step-up challenge. The result: reduced friction for routine access, enhanced security for high-risk logins, and a significantly stronger audit trail.

In two DACH-region client engagements over the past six months, switching from universal to adaptive MFA reduced daily MFA prompts by 40 to 70 percent while increasing detection of suspicious logins by a factor of three to five. Economically, this shift is therefore driven not only by compliance requirements but also by improved user experience and stronger security outcomes. The April 2026 Adaptive MFA spotlight demonstrates its operational effectiveness against emerging threats like device-code phishing.

Three Compliance Components That Must Be in Place for NIS2 Compliance by 2026

Component 1: Identity Risk Inventory with Account Classification. The first component is a comprehensive table listing all account classes within the organization, including the number of accounts, risk rating (low, medium, high, critical), MFA mechanism in use, justification for the chosen method, and the last review date. During a NIS2 audit, this table is the very first document requested. Organizations without it will immediately receive a non-compliance finding. Even those with the inventory will face findings if privileged accounts lack strong multi-factor authentication (MFA). A thorough inventory process typically takes four to eight weeks in a mid-sized company with 250 to 1,000 employees.

Component 2: Adaptive MFA Engine with Contextual Signals. The second component is the technical MFA layer. By 2026, standard market solutions will include Microsoft Entra ID Conditional Access, Okta Adaptive MFA, Cisco Duo Beyond, Ping Identity, or specialized platforms such as Silverfort and Rublon. The choice depends on the existing identity stack, but core requirements remain consistent across solutions: a risk-based policy engine, support for FIDO2 and WebAuthn standards, step-up authentication mechanisms, and audit-ready logging. Organizations that do not transition to adaptive MFA logic within the next 12 months will operate with a net weaker security and compliance posture.

Component 3: Audit Trail with Forensic Depth. The third component is often underestimated. NIS2 mandates not only the use of MFA but also the ability to prove its application for at least 12 months. In the event of a security incident, if an organization cannot reconstruct which login occurred, with which authentication factor, from where, and when, it faces both forensic and compliance failures. Therefore, the audit trail architecture must go beyond basic identity provider logs and aggregate logs into a centralized, tamper-proof system-such as a SIEM or a dedicated audit log repository. Moreover, the retention requirement in 2026 will not stop at 12 months; for critical sectors, it will extend to 24 or even 36 months.

What a 90-day compliance plan looks like in practice

From consulting practice, a 90-day plan has been established that implements the three building blocks in the right order. Day 1 to 30: Identity Risk Inventory. Capture of all account classes, risk assessment, gap analysis against NIS2 §2(j) and ENISA guidance. Output: Identity risk table with clear action list. Day 31 to 60: Adaptive MFA Architecture Decision. Market scan, proof-of-concept with two solutions, architecture decision with IT, security, HR and data protection. Output: Architecture decision with rollout plan. Day 61 to 90: Pilot rollout for privileged accounts and remote access. Accompanying training for users, escalation paths for friction points, gradual increase of policy strictness. Output: Pilot report with extension roadmap for all account classes.

Those who systematically complete this 90-day plan will be in a position by the end of the third quarter of 2026 where the BSI audit finds that essential requirements are met. Those who do not complete the plan will need to address the open findings in the audit phase starting Q3 2026, often under time pressure and with higher costs.

What happens if the BSI audit identifies deficiencies?

The escalation logic of BSI enforcement provides for a three-stage process. First stage: Requirements with deadlines (typically three to six months) to remedy deficiencies. Second stage: Penalty for non-compliance with requirements, up to 10 million euros or 2 percent of worldwide annual turnover. Third stage: Personal liability of management with private assets, if due diligence obligations have been clearly violated. The first penalty cases in the NIS1 predecessor procedures have shown that the BSI can fully utilize the maximum penalty range in case of MFA failures for privileged accounts if the deficiency is classified as gross negligence. The architectural investment in adaptive MFA with audit trail is always economically viable compared to the penalty amount.

How DORA further strengthens MFA requirements

For financial institutions, DORA adds an additional layer. DORA requires operational resilience and explicitly mandates MFA for privileged access and remote sessions in its ICT risk management provisions. While NIS2 uses the “where appropriate” logic, the DORA requirement is stricter: Privileged MFA is mandatory, not optional. Banks, insurers and critical ICT third-party providers must therefore not only meet the NIS2 logic in 2026, but also simultaneously address the DORA stricter requirements. The DORA-2 line from UK FCA April 2026 provides the regulatory operational resilience guidance for this purpose. Those who set up the NIS2 architecture to be DORA-compliant have addressed the compliance double layer in one go.

What the typical audit findings for 2026 are

From the first pre-audit workshops with security managers of medium-sized enterprises, four recurring findings can be identified that will lead to requirements in the actual BSI audit. First: Service accounts without MFA and without secret rotation. In most DACH companies, there are between 30 and 200 service accounts with standard passwords that have not been rotated for years. These are escalation path number one for attackers and an open finding in the audit. Second: External vendor access without strong MFA. Maintenance access from machinery manufacturers, IT service providers and software vendors often runs without FIDO2 or hardware tokens. Third: Emergency accounts without documented procedural logic. Those who have break-glass accounts must document the activation and deactivation procedures in writing and present them during the audit. Fourth: Cloud admin consoles without step-up MFA for sensitive operations. Microsoft Azure Privileged Identity Management, AWS IAM Identity Center and Google Cloud Privileged Access Manager provide the tools, but they are only consistently used in half of the DACH setups.

Those who systematically address these four findings before the first BSI audit are already in the upper half of compliance maturity. From experience, processing this in a medium-sized setup takes between eight and sixteen weeks, depending on how fragmented the service account landscape is. Those who have not yet addressed this topic in 2026 should reserve the next security roadmap round for it.

The role of phishing-resistant MFA

A central aspect of the ENISA guidance Q1 2026 is the recommendation for phishing-resistant MFA methods for privileged access. Standard push notifications and SMS OTPs are compromisable through phishing tools like Evilginx, Modlishka or the Tycoon-2FA toolkit documented in a wave in April 2026. FIDO2 hardware keys, passkeys and biometric authentication with origin binding are considered phishing-resistant. For privileged access and remote sessions, the 2026 recommendation is clear: Only phishing-resistant factors. In the NIS2 architecture, the inventory should therefore document the phishing resistance status for each privileged class. Those who still use SMS or push MFA for admin accounts have a recognizable residual risk in 2026 that is often directly addressed in audit discussions.

From an operational perspective, the transition to FIDO2 hardware keys or passkeys is particularly worthwhile for privileged user classes, because these users are security-sensitive anyway and do not perceive the additional friction as a burden. For broad employee classes, passkey is the ergonomically more elegant variant because it requires no additional hardware and integrates seamlessly with modern end devices. A mixed strategy (hardware keys for admins, passkeys for the workforce, classic TOTP apps as a transitional factor for legacy access) is the pragmatic path in 2026 and fully satisfies the ENISA guidance.

Frequently Asked Questions

Network: More to read on Security Today

• Operational practices from the Healthcare Incident Report April 2026
• Messenger NIS2 obligations from the WhatsApp-Signal Compliance Report
• Adaptive MFA against 7 million device code phishing attempts

Source title image: Pexels / Dan Nelson (px:4973899)

About the author: Benedikt Langer

More articles by Benedikt Langer