NIS2 multi-factor authentication: 5 access classes that need it

Article 21 of Directive (UE) 2022/2555 lists the cybersecurity measures every NIS2 entity must implement. Point (j) names one of them by name: multi-factor authentication. Eighteen months after entry into force, NIS2 multi-factor authentication has moved from "industry best practice" to a legal floor — and Implementing Regulation (UE) 2024/2690 clarified which factors will pass an inspection and which will not.

The shift is not in the noun. It is in the adjective. The IR's annex aligns NIS2 with the post-2023 supervisory consensus across ENISA, ANSSI and BSI: multi-factor is necessary but no longer sufficient. The default is now phishing-resistant — a category the directive does not name, but that the implementing regulation, the national authorities and the supervisory practice all converge on. Boards approving an Article 21 plan in 2026 inherit that judgement.

1. What Article 21(2)(j) actually requires

Article 21(2)(j) requires "multi-factor authentication or continuous authentication solutions, secured voice, video and text communications". The wording is short and the scope wide. It applies to every entity within the directive's eighteen sectors, not only those that handle personal data, not only those running customer-facing services.

Two operative phrases load the obligation. Continuous authentication — the IR clarifies this covers session-level revalidation, not just initial login. Solutions — plural, signalling that one method does not cover every access class. The MFA decision is not a checkbox at the IAM layer. It is a programme that maps factor strength to risk level across the entity's full access surface.

The same article makes the management body — i.e., the board — accountable for approving the resulting policy. See the five non-delegable responsibilities of NIS2 Article 20 for the governance framing.

2. The five access classes that must carry MFA

Implementing Regulation 2024/2690 does not list "five classes" verbatim. Its annex builds the requirement by combining Article 21's principles with the technical baseline. Translated into the surface a CISO actually defends:

1. Administrative access — domain admin, cloud root, hypervisor, network device CLI. Every privileged session, on every system, every time. No exceptions for "trusted networks" — segmentation is a containment control, not an authentication control.
2. Remote access — VPN, RDP, jump hosts, SSH from outside the entity's perimeter. The 2024 supervisory wave from ANSSI and BSI singles this category out — most ransomware that ends in a 72-hour notification entered through unprotected remote access.
3. Externally-facing application access — webmail, customer portals with administrative or financial functions, public service interfaces. Customers and citizens, not only employees.
4. Sensitive-data access — production databases, financial systems, patient records, source code repositories. The boundary is not "internal network" — it is the application's role boundary.
5. CI/CD and infrastructure-as-code interfaces — Git on the build orchestrator, the deploy key, the secret manager. This category is younger and less codified, but a successful supply-chain attack increasingly enters here. The same logic that drives the supply-chain clauses NIS2 wants in supplier contracts extends to internal pipelines.

When a supervisor asks "where is MFA enforced?", the answer should be a list, not "everywhere". The list is the audit artefact.

3. Why SMS and TOTP no longer pass on their own

The IR's annex does not mention SMS or TOTP by name. It defers the technical specification to "state of the art", a term the directive uses repeatedly to keep itself future-proof. Read in 2026, state of the art for high-risk access classes is phishing-resistant authentication: FIDO2 / WebAuthn security keys, platform authenticators with attestation (Windows Hello for Business, macOS Touch ID with attestation, modern Android with strong-box keys), and passkeys synchronised through provider-attested clouds.

Multi-factor is the word in the directive. Phishing-resistant is the word in every supervisor's published guidance since 2023. NIS2 entities should plan for the second.

ANSSI's published authentication guidance (the 2023 Recommandations relatives à l'authentification multifacteur), BSI's IT-Grundschutz control ORP.4.A23, and ENISA's identity-management publications all reach the same conclusion: SMS one-time codes are vulnerable to SIM swap and SS7 interception; TOTP applications protect against phishing only when the user notices the wrong domain. For administrative and remote access, neither factor meets the implicit "state of the art" bar a supervisor will apply in 2026.

The practical consequence: the rollout plan inherits a target architecture. Phishing-resistant for the top three classes (admin, remote, externally-facing administrative roles), TOTP acceptable as a transitional control for the fourth (sensitive-data access for non-privileged employees), SMS deprecated across the entity by the end of the next budget cycle. NIST's SP 800-63B Digital Identity Guidelines — formally a US standard but the international reference for authenticator assurance levels — gives the granularity for documenting these decisions.

4. The audit trail a supervisor will read

A NIS2 inspection rarely asks to see the identity-provider configuration. It asks for the audit trail. Three artefacts come up consistently in published inspection summaries from BSI and ACN:

• The authentication policy approved by the board. A document — not a wiki page — that defines factor strength per access class, lists the exceptions and their compensating controls, and is signed at the date of last review.
• The factor enrolment register. A list, per system, of the accounts that have an MFA factor enrolled, the factor type, and the enrolment date. The register answers "is MFA actually enabled?" — not "is it required?", which a policy alone cannot prove.
• The exception log. Every system where MFA is not enforced — legacy industrial endpoints, service accounts using certificate-based authentication — is named, with the reason, the compensating control, and the planned removal date. Open exceptions older than twelve months are a supervisor red flag.

The reference to the annual independent review of the security programme in our guide of the 21 NIS2 measures closes the loop — the auditor reads these three documents and reports findings to the board. Without them, the technical control is invisible to the regulator.

5. Rolling out without breaking operations

The failure mode of an MFA rollout is not the factor choice. It is the lockout — a privileged account that loses access to its second factor at the worst possible moment. Three measures from the published guidance reduce that risk:

• Two factors of two different types for every administrative account, with the second factor stored offline and accessible to the entity's incident-response team within a two-hour service level.
• Phased enrolment by access class, not by user population. Administrative access first (small population, high impact), externally-facing applications second, sensitive-data access last. The NIS2 compliance self-assessment checklist gives the order the regulator's classification matrix implies.
• Pre-staged break-glass procedures, documented and tested annually. The break-glass account itself is monitored on every use; a use that did not match a planned change is treated as a significant incident under Article 23 and reported.

The supervisory pattern observed in 2026 is not punitive on rollout speed — provided the documentation exists. Entities still relying on SMS for administrative access in 2027 will be in a different conversation.

What good looks like

Three signals appear consistently in published inspection reports from national authorities that have shared their enforcement methodology:

1. A board-approved authentication policy — versioned, dated, signed under Article 20 of the directive, distinguishing factor strength by access class with named exceptions.
2. A live enrolment register — exported from the identity provider into the entity's GRC platform, refreshed at least monthly, covering 100% of administrative and remote-access accounts.
3. A retirement plan for weaker factors — SMS and unattested TOTP deprecation dates committed in writing, with a quarterly progress report to the board.

None of these documents requires new technology. They require that the controls already running in production be written down — before the supervisor asks.

Sources

1. Directive (UE) 2022/2555, Article 21(2)(j) (cybersecurity risk-management measures).
2. Commission Implementing Regulation (UE) 2024/2690 of 17 October 2024 (technical and methodological requirements).
3. ENISA — Identity Management for Electronic Identification (referenced by name).
4. ANSSI — Recommandations relatives à l'authentification multifacteur et aux mots de passe (2023).
5. BSI — IT-Grundschutz-Kompendium, control ORP.4.A23 (multi-factor authentication for administrative access).
6. NIST — Special Publication 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management.