Adaptive MFA in the NIS2 Audit: When the Policy is Suitable as Proof

8 min. read

An adaptive MFA that works at login can still fail an audit if no one can demonstrate which rule triggers the second factor and when. This is precisely the gap NIS2 brings into focus: the directive demands not only that risk-based authentication exists, but that organizations can evaluate the effectiveness of their measures. Anyone who simply switches on Entra ID, Okta, or Duo and keeps the Conditional Access rules in the IT department’s heads has a technology – but, when it counts, no documented proof.

Key Takeaways

Policy as evidence: NIS2 Art. 21 requires risk-appropriate measures and an assessment of their effectiveness. An adaptive MFA becomes considerably more defensible in an audit when its rules are exported, versioned, and justified against the protection requirement – even if the directive does not explicitly prescribe this format.
Break-glass and number matching: Two configuration choices determine whether the solution holds under real-world pressure: emergency accounts that are exempt from blocking rules yet bound to a strong factor and monitored, and number-matching confirmation that renders MFA fatigue attacks ineffective.
BSI mapping makes it auditable: Mapping your step-up logic against the IT-Grundschutz building block ORP.4 gives the auditor a language they already know, rather than a tool configuration they have to interpret.

Why NIS2 audits the MFA policy, not the MFA feature

What is adaptive MFA? Adaptive, or risk-based, multi-factor authentication evaluates every login against contextual signals and only demands the second factor when the risk exceeds a defined threshold. A sign-in from a managed laptop on the corporate network passes through; the same credentials from a new IP address in a different country trigger a step-up prompt or get blocked outright. The underlying technology has been available in Entra ID, Okta, and Duo for years.

The point where NIS2 intervenes goes beyond the technology itself. Article 21(2) of the directive requires risk-appropriate measures that reflect the state of the art, along with concepts for evaluating their effectiveness. The directive explicitly names multi-factor authentication as an appropriate measure where warranted. For an audit, this shifts the central question: it is less about whether MFA is active, and more about which rule triggers the second factor, who owns that rule, and whether the threshold is calibrated to the protection requirements of the systems concerned.

This is where many configurations that run flawlessly in production fall short. The rules exist as a Conditional Access policy in the tenant, but no one has ever exported them as a document, no one can show their history, and the thresholds were taken from the default settings without anyone having justified them against their own risk profile. The measure is in place; the evidence of its effectiveness is not.

Setting Up the Policy as an Exportable Artifact

The first practical step is unspectacular: the authentication policy must be extracted from the tool and brought into a form that an auditor without admin access can read. In Entra ID, export the Conditional Access policies via Microsoft Graph as JSON; in Okta via the Policy API; in Duo via the Admin API. This export belongs versioned in the same repository that holds the rest of the security documentation.

More important than the format is the rationale that sits alongside it. Every step-up condition needs a sentence explaining why that threshold was chosen. For example: accounts with access to the accounting system trigger a step-up prompt at the first sign of an unknown geolocation, because those systems are classified as high-protection under the organization’s own risk assessment. An internal wiki can get away with a weaker rule. That link between protection requirement and authentication rule is precisely what makes the measure auditable.

A change log with a four-eyes principle is also worth implementing. Anyone who relaxes an authentication rule – say, because a department is complaining about too many prompts – should not do so quietly in the tenant. Documented approval protects against the accusation, in a crisis, that a safeguard was weakened without justification. The personal liability of management under NIS2 makes that proof more than a formality.

Which Signals Actually Carry Weight in the Risk Engine

Adaptive MFA is only as good as the signals it evaluates. In practice, four categories carry most of the weight: the device and its management status, network and location context, sign-in behavior over time, and external threat signals such as known malicious IP addresses. What matters is not activating as many signals as possible, but knowing what each signal actually tells you.

Device management status is the most reliable single signal. A sign-in from a managed, compliant notebook enrolled in mobile device management is substantially more trustworthy than one from an unknown device – regardless of location. Location signals, by contrast, are weaker than they appear: VPN usage, mobile networks, and business travel constantly generate new geolocations that in themselves mean nothing malicious. Weight location too heavily and you produce frustration without any security gain.

Holds Up in an Audit

Device compliance as a mandatory signal for sensitive systems
Number matching enforced against MFA fatigue
Exported, versioned policy tied to protection requirements
Monitored break-glass accounts with alerting

Fails in an Audit

Default thresholds with no documented rationale
Push confirmation via simple tap without a code
Emergency accounts with no dedicated logging
Rule changes without approval and version history

Number Matching and Break-Glass: Two Configuration Levers That Carry Audit Weight

Two configurations determine, more than almost anything else, whether adaptive MFA holds up under audit scrutiny. The first is the type of confirmation. A plain push notification that the user accepts with a single tap is an open invitation for what’s known as an MFA fatigue attack: the attacker fires off authentication requests until someone, worn down, taps approve. Microsoft, Okta, and Duo counter this with number matching, which requires the user to enter or confirm a number displayed on the sign-in screen within the app. All three vendors have offered this mechanism for some time – it should be enforced, not optional.

The second lever is break-glass accounts. Every adaptive MFA deployment needs emergency access accounts that are exempted from blocking Conditional Access policies, ensuring that a misconfiguration doesn’t lock the entire organization out. Exempted, however, does not mean unprotected: these accounts should remain bound to a particularly strong authentication factor – ideally a FIDO2 hardware token or a certificate – rather than simply bypassing the risk-based evaluation. Because they represent a well-known, privileged attack surface, they require their own tight logging so that any use triggers an immediate alert. An exempted account with no strong binding and no monitoring is a recurring finding in audit conversations.

BSI Mapping as a Shared Language with the Auditor

The final step translates your configuration into the language the auditor already speaks. The BSI’s IT-Grundschutz framework, specifically the ORP.4 Identity and Access Management building block, contains requirements that serve well as a reference frame for adaptive MFA. ORP.4 is not a dedicated MFA mapping, but it covers authentication, access control, and emergency accounts. Organizations that align their step-up rules, device requirements, and break-glass accounts against these requirements deliver more than tool screenshots – they provide a mapping in a language the auditor already uses.

This mapping doesn’t have to be elaborate. A table that pairs each IT-Grundschutz requirement with the corresponding policy rule and the location of the supporting evidence is enough for most audits. It shifts the conversation away from whether the measure meets the current state of the art toward the already-answered question of how it has been implemented. That shift is precisely what separates an adaptive MFA that simply runs from one that holds up as a genuine control.

Frequently Asked Questions

Is a standard MFA setup sufficient for NIS2 compliance?

Technically it satisfies a baseline requirement, but it often falls short as robust evidence. NIS2 Article 21 demands risk-appropriate measures and an assessment of their effectiveness. An MFA deployment without a documented policy justified against the organization’s protection needs is present on paper but difficult to demonstrate as effective. The adaptive approach, with exportable and versioned rules, makes that demonstration considerably easier.

What distinguishes adaptive MFA from standard MFA in an audit context?

Standard MFA requires the same second factor at every sign-in. Adaptive MFA makes context-dependent decisions and can document that decision-making logic as a policy rule. It is precisely this documentable logic that makes it more valuable for a NIS2 audit, because it makes the connection between risk and control visible.

Which BSI requirement is relevant for adaptive MFA?

The IT-Grundschutz building block ORP.4 on Identity and Access Management provides a suitable reference frame, even though it does not contain a dedicated chapter on adaptive MFA. Organizations that map their step-up rules and break-glass accounts against ORP.4 requirements translate their tool configuration into a language the BSI already uses in audit discussions.

How do you prevent adaptive MFA from blocking employees?

Through a phased rollout and sensible signal weighting. Location signals should carry less weight than device management status, because VPN usage and business travel constantly generate new geolocations. A pilot with a defined user group reveals where thresholds are set too tightly before rolling out more broadly.

Why are break-glass accounts an audit issue?

Because they are deliberately exempted from blocking policies, which makes them a privileged attack surface. The exemption is necessary – but it should remain bound to a particularly strong factor such as a FIDO2 token. A break-glass account without strong binding and without tight logging is a typical finding in audit conversations.

Does the MFA policy need to be versioned?

For a credible audit trail: yes. A versioned policy with a change history and dual-control sign-off demonstrates that protective measures were never weakened without oversight. Given the personal liability of management under NIS2, this documentation is far more than a formality.