NIS2 MFA and Secure Communications Requirements

Multi-factor authentication (MFA) is one of the few specific technical controls explicitly named in the NIS2 Directive itself — not just in the implementing regulation. Article 21(2)(j) of Directive 2022/2555 places MFA, continuous authentication, and secured communications at the same legislative level as the ten cybersecurity risk management measures. For compliance teams, this matters: unlike controls derived solely from delegated acts, this one cannot be interpreted away.

This guide explains exactly what NIS2 requires for MFA and secure communications, how the Commission Implementing Regulation (CIR) 2024/2690 adds technical detail, which authentication methods qualify, and how to build a proportionate implementation programme.

What Article 21(2)(j) Actually Says

Article 21(2) of NIS2 lists the ten cybersecurity risk management measures that essential and important entities must implement. Point (j) reads:

“the use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate”

Free Download

Get the NIS2 Article 21 Compliance Checklist

90+ assessment items mapped to CIR 2024/2690 — instant PDF, no payment.

Download Free Checklist I agree to receive the checklist and occasional NIS2 updates. Unsubscribe anytime. Privacy Policy.

✓ Check your inbox — the PDF is on its way.

Three obligations sit within this single provision:

1. MFA or continuous authentication — entities must deploy one of these for access to their network and information systems
2. Secured voice, video and text communications — the channels used for day-to-day operations must be appropriately secured
3. Secured emergency communication systems — the channels used during incidents must be secured and must remain functional when primary infrastructure is compromised

The phrase “where appropriate” modifies how and where these controls apply — it does not create an option to skip them entirely. Your risk assessment determines scope; the obligation to act exists for every in-scope entity.

For entities subject to the CIR 2024/2690 (DNS providers, TLD registries, cloud and data centre services, managed service providers, and online platforms), Sections 11.5 through 11.7 of the Annex provide binding technical requirements on top of the directive text.

Why NIS2 Names MFA at the Directive Level

Most EU legislation avoids naming specific technical controls, preferring outcome-based language. NIS2’s explicit reference to MFA in the directive text — not just in delegated acts — reflects a deliberate policy decision.

The data supports it. The Verizon 2025 Data Breach Investigations Report found that 54% of breaches involving web applications used stolen credentials as the initial access vector. Across the energy, healthcare, and public administration sectors covered by NIS2 Annex I, credential compromise has been a top-three attack vector consistently. MFA is the single most effective control against credential-based attacks: Google’s internal research found that device-based MFA blocks 99% of automated phishing attempts.

By embedding MFA in the directive text rather than leaving it to delegated acts, the legislature achieved three things:

• National supervisory authorities cannot interpret the requirement away during transposition
• MFA cannot be treated as optional for lower-risk entities — the risk assessment determines scope, not whether to deploy
• The requirement applies to all in-scope entities, not only those subject to the CIR

The full suite of Article 21 measures sets the broader compliance framework, but Article 21(2)(j) is distinctive in combining a specific technical control with a communications security requirement in a single provision.

CIR Technical Requirements — Sections 11.5, 11.6, and 11.7

For CIR-subject entities, Sections 11.5 through 11.7 of the Annex set out the binding technical requirements for identification, authentication, and MFA. Taken together, they form the technical backbone of your authentication programme.

CIR Reference	Topic	Key Requirements	Templates
11.5.1–11.5.4	Identification	Unique identities per user/system; identity lifecycle management; shared identities only with documented justification; prompt deactivation of unused identities	Doc 28 (Access Control), Doc 29 (Authentication)
11.6.1–11.6.4	Authentication	Authentication strength calibrated to asset classification; credential rotation on initial setup and upon suspected compromise; lockout after failed attempts; session termination after inactivity; separate credentials for privileged accounts; state-of-the-art methods	Doc 29 (Authentication), Doc 30 (Password Policy)
11.7.1–11.7.2	MFA	Multiple authentication factors or continuous authentication mechanisms, where appropriate, per asset classification; authentication strength appropriate for asset classification	Doc 29 (Authentication)

Section 11.5 — Identification

The CIR requires that entities manage the full lifecycle of identities for both users and systems. Every user and every system must have a unique identity. In the case of users, that identity must be linked to a single individual — shared accounts (such as generic “admin” accounts used by multiple team members) are permitted only where there is a documented business reason, explicit approval, and the sharing is accounted for in risk management.

The practical implications are significant. Many organisations operate with:

• Shared mailboxes accessed with shared credentials
• Service accounts whose passwords are known across the IT team
• Generic administrator accounts used interchangeably

All of these require remediation under CIR 11.5. Unused identities must be deactivated without delay — dormant accounts are a common initial access vector in ransomware attacks.

Section 11.6 — Authentication

Authentication strength must be proportionate to the classification of the asset being accessed. The CIR sets out six specific technical sub-requirements:

1. Credential confidentiality — allocation and management of secret authentication information must ensure credentials remain confidential at all times
2. Credential rotation — credentials must be changed at initial setup, at predefined intervals, and immediately upon suspected compromise
3. Lockout controls — accounts must be locked or challenged after a predefined number of unsuccessful authentication attempts
4. Session termination — inactive sessions must be terminated after a predefined period
5. Separate privileged credentials — privileged and administrator accounts must use credentials separate from standard user credentials
6. State-of-the-art methods — to the extent feasible, state-of-the-art authentication methods must be used per the assessed risk and asset classification

The “state-of-the-art” requirement has direct implications for SMS-based one-time passwords. SMS OTP is increasingly considered sub-optimal due to SIM-swapping attacks and SS7 protocol vulnerabilities. For high-risk systems and privileged access, supervisory authorities are likely to view it as insufficient. For lower-risk, internal systems with documented justification, it may remain acceptable.

Section 11.7 — Multi-Factor Authentication

Section 11.7 contains two requirements:

• 11.7.1: Users must be authenticated by multiple authentication factors or continuous authentication mechanisms, where appropriate, per asset classification
• 11.7.2: Authentication strength must be appropriate for asset classification

The “or” is deliberate. The CIR is designed to be technology-neutral. Traditional step-up MFA (present an additional factor at login) and continuous authentication (ongoing behavioural monitoring throughout the session) are both compliant pathways. The choice should be risk-based and documented in your Authentication Policy.

MFA Methods: What Qualifies Under NIS2?

MFA combines two or more factors from distinct categories. Combining two factors from the same category — for example, two passwords — does not meet the requirement.

Factor Category	Examples	Notes
Knowledge (something you know)	Password, PIN, passphrase, security question	Weakest factor alone; must be combined with possession or inherence
Possession (something you have)	Hardware security key (FIDO2/WebAuthn), smart card, authenticator app (TOTP), push notification app	FIDO2 hardware keys are phishing-resistant and considered state-of-the-art
Inherence (something you are)	Fingerprint, face recognition, iris scan, voice print	Convenient for mobile and device-based workflows; strong when combined with possession

MFA Method	Security Level	Recommended For
Password + hardware security key (FIDO2)	Highest — phishing-resistant	Privileged accounts, remote admin, sensitive systems
Password + authenticator app (TOTP/HOTP)	High	Standard employee access, VPN, email
Password + push notification app	High	General access, Microsoft 365, SaaS platforms
Password + smart card / PIV certificate	High	Government, regulated environments, OT admin
Passkey (FIDO2 — device + biometric/PIN)	High — phishing-resistant	Modern workloads; satisfies MFA as a single credential
Password + SMS OTP	Moderate (not state-of-the-art)	Lower-risk internal systems only with documented justification; not for privileged access

Passkeys deserve special attention. A FIDO2 passkey combines something you have (the enrolled device or security key) with something you are or know (biometric or PIN). It satisfies the multi-factor requirement from a single credential interaction and is phishing-resistant by design — the credential cannot be replayed against a fake site. NIST SP 800-63B classifies this as authenticator assurance level 2 (AAL2). For organisations rolling out new authentication infrastructure, passkeys should be the default recommendation.

The choice of method must be documented in your Authentication Policy with a justification tied to your asset classification. Supervisory authorities will look for this evidence of proportionate decision-making.

Continuous Authentication — The Alternative Pathway

Article 21(2)(j) and CIR 11.7.1 both explicitly offer continuous authentication as an alternative to traditional MFA. This is not a lesser option — for certain environments, it is more appropriate than step-up prompts at login.

Continuous authentication monitors signals throughout a session to maintain assurance that the authenticated user remains who they claimed to be at login:

• Behavioural biometrics — keystroke dynamics, mouse movement patterns, scroll behaviour, typing cadence
• Device posture assessment — continuous verification that the accessing device remains trusted, compliant, and uncompromised
• Risk-based adaptive authentication — real-time evaluation of context signals (location, IP reputation, access patterns, time of day) to step up authentication or terminate sessions when risk changes
• Zero Trust Network Access (ZTNA) — continuous re-verification of user identity and device posture at every access request, not only at the session boundary

Continuous authentication is particularly valuable in two scenarios. First, in operational technology (OT) and industrial control system (ICS) environments where authentication prompts mid-operation are impractical or unsafe. Second, in long administrative sessions where a step-up MFA event at login provides no assurance about what the authenticated principal does over the next eight hours.

If your organisation opts for continuous authentication as an alternative pathway, the mechanism, the risk assessment supporting this choice, and the review process must be documented in your Authentication Policy.

NIS2 Secure Communications Requirements

Article 21(2)(j)’s second and third obligations — secured communications and secured emergency communications — are frequently under-addressed in NIS2 implementation projects. They are not advisory: the directive names them alongside MFA as mandatory elements of the same provision.

Secured Voice, Video and Text Communications

The communications channels used for day-to-day operations must employ appropriate security controls. “Secured” means:

Communication Type	Minimum Security Requirements	Compliant Examples
Internal messaging / text	End-to-end encryption, access authentication, data-at-rest encryption	Microsoft Teams (E2EE enabled), Signal, encrypted Slack Enterprise
Voice calls (internal / B2B)	Encrypted transport (SRTP), authenticated participants	Cisco Webex, encrypted VoIP, Microsoft Teams calls
Video conferencing	E2EE where available, waiting rooms, host controls, authenticated participants	Zoom (E2EE mode), Microsoft Teams, Cisco Webex
Email (sensitive content)	TLS in transit; S/MIME or sensitivity labels for sensitive content; DMARC/DKIM/SPF	Microsoft 365 with sensitivity labels, Proton Mail Business

Consumer-grade free tools without authentication controls, retention policies, or encryption guarantees do not meet the standard. This particularly affects smaller organisations that have relied on WhatsApp or personal Gmail for internal communications.

Secured Emergency Communication Systems

This requirement is the most commonly overlooked in implementation projects. Article 21(2)(j) explicitly mandates that emergency communications — the channels used to coordinate incident response — must be secured and must function when normal infrastructure is compromised.

The rationale is straightforward. If attackers have compromised your primary communications (email, internal messaging, VoIP), they can observe your incident response, intercept out-of-band credentials, and misdirect remediation efforts. Numerous major breaches have been prolonged because response teams inadvertently used compromised channels.

A compliant emergency communications capability requires:

• Out-of-band channel — independent of the infrastructure that may be compromised (not hosted on your corporate systems)
• Encrypted — communication content protected in transit and at rest
• Authenticated — only authorised incident responders can access or join the channel
• Tested — exercised as part of your business continuity and incident response exercises
• Documented — included in your Incident Handling Policy and Crisis Management Plan

At minimum: document a dedicated Signal group, satellite communicator, or pre-agreed secondary mobile network for your incident response team. Reference it in your Incident Handling Policy (Template 48) and test it during your annual business continuity exercise. This links directly to your obligations under Article 21(2)(b) and (c).

Where Must MFA Apply? Risk-Based Scoping

The “where appropriate” language in Article 21(2)(j) requires a risk-based assessment of where MFA applies. It does not permit organisations to conclude that MFA is inapplicable across the board. The ENISA Technical Implementation Guidance and supervisory authority guidance consistently confirm that the assessment determines scope, not whether to deploy.

System / Access Type	MFA Requirement	Rationale
Remote access (VPN, RDP, SSH)	Mandatory for all users	High-exposure surface; single compromise enables full network access
Privileged / administrator accounts	Mandatory for all admin access	CIR 11.3.2(a) explicitly requires strong authentication including MFA for privileged accounts
Cloud administration portals	Mandatory	Single compromise gives full tenant or infrastructure access
Email (Microsoft 365, Google Workspace)	Mandatory	Business email compromise is among the highest-probability NIS2-relevant threat vectors
Internal systems (standard users)	Required — risk-based	Risk assessment must justify any single-factor access to internal systems
OT / SCADA / ICS	Required — method must suit operational constraints	Consider continuous authentication or certificate-based alternatives to interactive prompts
Customer-facing systems	Required — proportionate to data sensitivity	Personal data or critical service access warrants MFA; document risk basis

Supervisory authorities conducting NIS2 inspections will typically start with remote access, privileged accounts, cloud administration, and email. These four areas cover the dominant attack vectors and represent the minimum defensible MFA deployment for any in-scope entity.

Step-by-Step Implementation

A proportionate MFA and secure communications programme can be built in seven steps, aligned with the CIR requirements and the templates available in the NIS2 Templates pack.

Step 1 — Asset classification. Using your IT Asset Register (Template 18), classify all systems by security tier based on sensitivity, criticality, and regulatory relevance. This classification drives every subsequent decision about authentication strength.

Step 2 — Identity audit. Review all user accounts, service accounts, shared accounts, and system-to-system identities. Disable unused accounts immediately. Document any shared identities with explicit justification. This is the baseline for your Authentication Policy.

Step 3 — Draft your Authentication Policy (Template 29). Define which systems require MFA; which methods are approved at each tier; rules for privileged account credentials; session timeout and lockout thresholds; and any continuous authentication mechanisms in scope. Reference your risk assessment and asset classification throughout.

Step 4 — Draft your Password Policy (Template 30). Align with current guidance. NIST SP 800-63B recommends against mandatory periodic rotation unless compromise is suspected; minimum 12 characters; block known-compromised passwords. Many legacy policies (90-day rotation, mandatory complexity characters) produce predictable patterns that weaken security.

Step 5 — Deploy MFA in priority order. Remote access first, then privileged accounts, then cloud administration, then email. Use a phased timeline with defined completion dates. Document each phase in your risk treatment plan.

Step 6 — Implement secure communications controls. Identify current communications platforms and verify E2EE configuration. Establish and test an out-of-band emergency channel. Update your Incident Handling Policy and Crisis Management Plan to reference it explicitly.

Step 7 — Schedule review. CIR 11.6.4 requires periodic review of authentication procedures. Tie this to your annual NIS2 management review cycle. Document results.

Common Implementation Mistakes

Treating “where appropriate” as optional. The proportionality qualifier defines deployment scope — it is not a licence to conclude that MFA is unnecessary. Every NIS2-compliant organisation must deploy MFA; the risk assessment determines where and at what strength.

Accepting SMS OTP as state-of-the-art. CIR 11.6.3 requires state-of-the-art methods per assessed risk. SMS OTP is vulnerable to SIM-swapping and SS7 protocol interception. For privileged access, remote administration, and cloud portals, supervisory authorities are unlikely to accept SMS OTP as sufficient. For lower-risk internal systems with documented justification it may be acceptable as an interim position.

Ignoring non-human identities. Service accounts, API keys, CI/CD pipeline credentials, and machine-to-machine identities are covered by CIR 11.5 as well as user identities. They require lifecycle management even though they cannot use interactive MFA. Use secrets management platforms (HashiCorp Vault, AWS Secrets Manager) and certificate-based authentication for machine identities.

Overlooking emergency communications. Organisations frequently complete their MFA programme while leaving the secured emergency communication systems requirement entirely unaddressed. In a major incident this becomes the most operationally critical control. It must be documented, authenticated, and tested — not just noted.

No documented link to risk assessment. Your Authentication Policy must reference your risk assessment. The justification for which systems require which authentication strength — and which MFA methods are approved at each tier — must flow from documented risk analysis, not from IT preference alone. Supervisory authorities conducting audits will look for this evidence trail. See the NIS2 compliance checklist for the full documentation requirements.

Legacy password policies. Mandatory 90-day password rotation and complex character requirements are not aligned with current NIST guidance. They typically produce predictable patterns (Password1! → Password2!) that are weaker than longer, stable passphrases. Update your Password Policy (Template 30) before supervisory review.

Templates You Will Need

The following documents from the NIS2 Templates compliance pack directly address the Article 21(2)(j) requirements:

Template	Purpose	CIR Reference
Doc 29 — Authentication Policy	MFA requirements, approved methods, privileged account rules, session controls, continuous authentication provision	11.5, 11.6, 11.7
Doc 30 — Password Policy	Credential standards, rotation rules, complexity requirements aligned with NIST 800-63B	11.6
Doc 25 — Secure Communication Policy	Approved encrypted communications platforms, emergency out-of-band channel requirements	11.4 (supporting), Art. 21(2)(j)
Doc 28 — Access Control Policy	Overall access framework within which MFA sits; privileged account policy	11.1–11.5
Doc 18 — IT Asset Register	Asset classification that drives MFA tier assignment	12.1 (supporting 11.7)

The Authentication Policy (Doc 29) is the core document for this requirement. It should be reviewed and approved by management at least annually per CIR 1.1.2, and updated whenever significant changes to systems, access patterns, or threat landscape occur. Review the NIS2 access control guide for the broader CIR Section 11 framework that MFA sits within, and the training requirements guide for how to ensure staff understand and follow your authentication policies.

Frequently Asked Questions

Sources

1. EUR-Lex — NIS2 Directive 2022/2555, Article 21(2)(j): https://eur-lex.europa.eu/eli/dir/2022/2555/oj
2. EUR-Lex — Commission Implementing Regulation (EU) 2024/2690, Annex Sections 11.5–11.7: https://eur-lex.europa.eu/eli/reg_impl/2024/2690/oj/eng
3. ENISA — Technical Implementation Guidance for NIS2 v1.0 (June 2025): https://www.enisa.europa.eu/publications/technical-implementation-guidance-for-nis2
4. NIST — Special Publication 800-63B: Digital Identity Guidelines — Authentication and Lifecycle Management: https://pages.nist.gov/800-63-3/sp800-63b.html
5. Verizon — 2025 Data Breach Investigations Report: https://www.verizon.com/business/resources/reports/dbir/