NIS2 MFA Requirements: What Article 21(2)(j) and CIR 11.7 Require

What NIS2 requires for MFA — CIR 11.5 identification, 11.6 authentication, 11.7 multi-factor and continuous authentication, phishing-resistant factors, and audit evidence.

← Back to hub · Prev: Identity lifecycle · Next: Privileged access →

Legal basis: NIS2 Art. 21(2)(j) (multi-factor / continuous authentication, secured communications) · CIR (EU) 2024/2690 Annex 11.5 (identification), 11.6 (authentication), 11.7 (multi-factor authentication).

TL;DR (🔧 Engineering): Three linked controls. Identification (11.5): every actor has a unique identity; no shared accounts. Authentication (11.6): strong, policy-governed authentication for access. MFA (11.7): multi-factor or continuous authentication, especially for remote access, sensitive information, and privileged/admin accounts (recital 23). NIS2 names MFA explicitly in the directive itself (Art. 21(2)(j)) — it is effectively non-negotiable. Aim for phishing-resistant MFA (FIDO2/passkeys, certificate-based) for high-value access.

1. Identification (CIR 11.5) 🔧

Every person, service, and device that accesses your systems must be uniquely identifiable. Concretely:

• One identity per actor. No shared or generic logins (e.g., a team "admin" account). Shared accounts break attribution and make the privileged-access logging in CIR 3.2 meaningless.
• Full lifecycle of identifiers — issued, managed, and revoked in step with the joiner-mover-leaver process (03).
• Non-human identities included. Service accounts, workload identities, API clients, and devices each need a distinct, attributable identifier and an owner.
• No identifier reuse in a way that re-attributes one person's history to another.

Unique identity is the foundation the other two controls stand on: you cannot meaningfully authenticate or log an actor you cannot uniquely name.

2. Authentication (CIR 11.6) 🔧

Entities must establish and apply authentication procedures and technologies based on the access control policy and a risk assessment of the resource. Expectations:

• Authentication strength proportionate to risk — stronger for sensitive data, critical systems, and elevated privileges.
• Secure credential management — secure issuance, storage (hashed/salted; secrets vaulted), recovery, and revocation. Session and token handling that supports prompt invalidation (critical for leavers and compromise response — see 03).
• A credential/password policy aligned to current good practice. Modern guidance (NIST SP 800-63B, aligned with the spirit of the CIR's "state of the art" standard) favours:
  • length over arbitrary complexity; screen against breached-password lists;
  • no forced periodic rotation without cause (rotate on indication of compromise);
  • reduce reliance on passwords by moving to passwordless/phishing-resistant methods where possible.
• Centralised authentication (SSO) to a single IdP, so policy is enforced consistently and credentials aren't scattered across apps.

3. Multi-factor & continuous authentication (CIR 11.7) 🔧 📋

MFA appears in the directive text itself (Art. 21(2)(j)) and again as CIR 11.7 — making it one of the few measures NIS2 names by technology. The CIR requires MFA or continuous authentication solutions where appropriate; recital 23 is explicit that MFA should be used in particular for:

• remote access,
• access to sensitive information, and
• privileged accounts and system-administration accounts.

Treat MFA as the default, not the exception

The defensible posture for an essential/important entity is MFA everywhere for interactive human access, with the strongest factors reserved for the high-risk cases above. "Where appropriate" is not a licence to skip it on internet-facing or privileged access — those are exactly where regulators expect it.

Prefer phishing-resistant MFA

Not all MFA is equal. Push-based and OTP MFA are bypassable via phishing, push-fatigue, and SIM-swap. For high-value access (admins, remote access, sensitive data), use phishing-resistant factors:

Continuous / adaptive (risk-based) authentication

NIS2 explicitly allows continuous authentication. Recital 23 endorses combining MFA with additional factors triggered by context — unusual location, unusual device, unusual time. Implement via conditional/adaptive access: step up authentication or block when risk signals fire, evaluate device posture, and shorten sessions for risky contexts. This satisfies 11.7 while reducing friction for low-risk access.

4. Secured communications — the rest of Art. 21(2)(j) 🔧

Point (j) doesn't stop at MFA. It also calls for secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate. For access-control purposes this means:

• Use encrypted, authenticated channels for internal collaboration and especially for incident/crisis communications (so responders can coordinate even if primary systems are compromised — links to business-continuity, CIR 4.3).
• Ensure out-of-band/emergency comms are pre-provisioned, access-controlled, and tested.

This is lighter-touch than MFA but auditors do check that crisis communications won't depend on the very systems that may be down or breached.

5. Implementation notes (vendor-neutral) 🔧

Examples, not endorsements.

• IdP / MFA platform: Microsoft Entra ID (Conditional Access + Authenticator/passkeys), Okta, Ping, Duo, Google.
• Phishing-resistant factors: FIDO2 keys (e.g., YubiKey), platform passkeys (Apple/Google/Windows Hello), certificate-based auth / smart cards (PIV/CAC).
• Adaptive access: Entra Conditional Access, Okta Adaptive MFA, risk engines using device posture + sign-in risk.
• Secrets / machine auth: vaults (HashiCorp Vault, cloud secret managers), workload identity federation, mTLS for service-to-service.
• Secured comms: end-to-end-encrypted collaboration tooling; a pre-agreed out-of-band channel for incident response.

Design rules:

1. Federate everything to one IdP; eliminate local app passwords.
2. Phishing-resistant MFA for all admins and remote access — no exceptions, no bypass groups left standing.
3. Token/session invalidation must be fast and centrally triggerable.
4. Machine identities authenticate with managed secrets or workload identity, never embedded static passwords.

6. Evidence an auditor will ask for 📋

• Authentication policy / password policy with approval and review dates.
• MFA coverage report: % of human accounts with MFA, broken out for admins and remote access (target 100% for both), and the factor types in use.
• List of any MFA exceptions/bypass accounts with justification and expiry — ideally empty.
• Evidence of phishing-resistant MFA for privileged/remote access.
• Conditional/adaptive access policy configuration (continuous-auth evidence for 11.7).
• Proof of unique identities / absence of shared accounts (shared-account exception register).
• Evidence of secured incident/crisis communications.

Common gaps that become findings

• MFA enabled "for most users" but admins, service accounts via interactive logon, or a legacy VPN are exempt.
• SMS OTP used for privileged or remote access.
• Shared admin accounts (breaks 11.5 and logging).
• Legacy/basic authentication protocols still enabled, bypassing MFA entirely.
• No adaptive controls; static auth regardless of risk signals.

Sources

• NIS2 Art. 21 — risk-management measures (point (j))
• Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex (Annex §11.5, §11.6, §11.7; recital 23)

FAQ

Does NIS2 require multi-factor authentication? Yes. MFA is one of the few controls named in the directive text itself, appearing in Article 21(2)(j). CIR 2024/2690 Annex section 11.7 then specifies it further, and recital 23 is explicit about the minimum scope: remote access, access to sensitive information, and privileged and system-administration accounts. For an essential or important entity, MFA everywhere for interactive human access is the defensible baseline.

What type of MFA satisfies NIS2? Any MFA satisfies the baseline, but NIS2 expects phishing-resistant factors for high-value access. FIDO2 security keys, passkeys (WebAuthn), certificate-based authentication, and platform authenticators (Windows Hello, Apple Touch/Face ID) are phishing-resistant and preferred for admins and remote access. Authenticator-app TOTP is acceptable for general workforce access. SMS and voice OTP should be phased out for anything sensitive — they are vulnerable to SIM-swap attacks and interception.

What does "continuous authentication" mean under NIS2? NIS2 Article 21(2)(j) allows "continuous authentication" as an alternative or complement to MFA. In practice this means risk-based or adaptive authentication: the system evaluates contextual signals — location, device, time, behaviour — and re-challenges or blocks sessions when risk increases, rather than relying solely on the initial login factor. Conditional and adaptive access policies in modern IdPs implement this. Recital 23 explicitly endorses combining MFA with additional contextual factors.

Are service accounts and non-human identities subject to NIS2 MFA requirements? CIR 11.5 requires unique identifiable identities for all actors including non-human ones (service accounts, workload identities, API clients). Interactive logon MFA is not applicable to machine-to-machine authentication, but the authentication equivalent — managed secrets, workload identity federation, mTLS — must be in place. Shared credentials and embedded static passwords are not acceptable under the CIR's credential-management requirements in 11.6.

What MFA coverage does an auditor expect? Auditors typically expect 100% MFA coverage for admin accounts and remote access, with phishing-resistant factors for both. For general workforce access, a high coverage rate with clear exception management (a register of bypass accounts with justification and expiry) is expected. Legacy authentication protocol disablement and absence of standing MFA-exempt accounts are also standard checks.

How KINT helps: KINT automates the joiner, mover, and leaver access lifecycle across your SaaS apps and produces signed, timestamped access-review evidence mapped to SOC 2 CC6 — the kind of evidence NIS2 Article 21 expects you to be able to show. It is early-stage and self-serve, and runs without an identity provider. See how KINT handles the lifecycle or book a 15-minute walkthrough.