Key takeaway: Article 21(2)(j) is the only Article 21 measure that names a specific control. Regulators love it because it is binary. Either MFA is on or it is off, and the coverage report is a screenshot. That makes it the easiest measure to audit and the most common source of early NIS2 findings. Most organisations have MFA. Few can produce a clean coverage report with documented exceptions.
If there is one Article 21 measure that a supervisor will check within 10 minutes of sitting down, it is multi-factor authentication. The question they ask is simple: "Show me your MFA coverage report, and the list of accounts not covered." The answer is almost always messier than it should be.
This article walks through what Article 21(2)(j) actually requires, where MFA is mandatory in practice, where it is still best-practice guidance, and the rollout pitfalls that cause organisations to fall short even when they have an MFA programme. It finishes with a practical readiness checklist.
What Article 21(2)(j) actually says
The text lists three things: multi-factor authentication or continuous authentication solutions, secured voice, video, and text communications, and secured emergency communication systems within the entity. All three are qualified by the phrase "where appropriate". That phrase is where most of the legal weight sits.
"Where appropriate" does not mean "where you feel like it". In early 2026 enforcement guidance, ENISA and several national competent authorities have converged on a simple test: if an account has access to systems that support the delivery of the entity's essential or important services, or to sensitive data, MFA is appropriate. That test captures almost every account in a typical enterprise.
Continuous authentication as an alternative: The directive lists MFA or continuous authentication solutions. Behaviour-based continuous authentication can substitute for classical MFA in narrow cases, typically high-throughput internal systems where multi-factor prompts would break operations. It must be demonstrably at least as strong, and be documented in the cryptographic and access control policies.
Where MFA is effectively mandatory
Regulators draw a clear boundary around accounts where MFA is no longer optional. In every supervisory case published so far in 2026, missing MFA on any of these account classes has counted as a finding.
1. All external-facing authentication
Email (M365, Google Workspace), VPN and zero-trust network access, remote desktop, SaaS consoles, customer-facing administrative portals, and any identity provider that federates to these. MFA must be enforced at the identity provider, not left as a per-application setting that users can skip.
2. All privileged accounts
Domain admins, cloud administrators (AWS, Azure, GCP root and privileged roles), database administrators, firewall and network engineers, SaaS tenant admins, and service desk accounts with delegated admin rights. Regulators increasingly expect phishing-resistant MFA (FIDO2 security keys, smart cards, or platform authenticators with TPM) for these accounts, not app-based push.
3. Accounts with access to sensitive data
Finance, HR, legal, R&D, and any role with standing access to personal data at scale or to the entity's most sensitive operational technology. The definition is sector-specific: a hospital's clinical system operators, an energy firm's SCADA users, a cloud provider's customer support with tenant-data access.
4. Third-party and vendor access
Any external supplier with an account in your environment needs MFA. The 2024 and 2025 supply chain incidents almost all started with an unprotected supplier account. Article 21(2)(d) (supply chain) and (j) (MFA) interact here: contract clauses should require the supplier to use MFA, but enforcement on the authentication provider is where it is actually policed.
Where MFA is still best-practice, not yet mandatory
A narrow set of accounts remains in a grey zone. MFA is recommended, but a documented risk-based decision can justify alternative controls. These are the cases to think carefully about.
- Service accounts. Non-interactive accounts used by applications cannot perform classical MFA. Regulators expect compensating controls: vault-managed credentials, short-lived tokens, per-host restrictions, and systematic secret rotation. "Service account, therefore no MFA" is a valid statement. "Service account, therefore no control" is not.
- Break-glass accounts. Emergency accounts are typically protected by a physical safe, sealed credentials, and split knowledge. This is accepted, but requires a written process, a log of any use, and an annual drill.
- Legacy OT and embedded systems. Some operational technology cannot accept modern MFA. Compensating controls include network segmentation, jump servers that do enforce MFA, and a documented migration roadmap with dates.
- Customer-facing end-user accounts. Where the entity's service has customer logins, MFA for those customers is strongly encouraged but not yet universally required under Article 21. Sector-specific regulations (financial services, digital identity) often add their own MFA rules on top.
Rollout pitfalls that produce findings
Across pre-enforcement reviews and early supervisory decisions, eight implementation mistakes show up repeatedly. Each one is avoidable with a structured rollout and a coverage report that reconciles to the directory of users.
- MFA exists but is optional. The policy is published, users can enrol, but enforcement is not on. Anyone who never enrols still logs in with a password alone. Enforcement must be on at the identity provider.
- Legacy authentication protocols are still enabled. IMAP, POP3, SMTP AUTH, and older NTLM paths bypass MFA silently. Disabling legacy auth is the single highest-value hardening step after MFA enforcement itself.
- Quiet exemptions. A handful of users are excluded from the MFA policy group because "they could not get it to work". The exclusions have no expiry and no risk acceptance record.
- Conditional access bypasses. Trusted network or trusted device policies were added to reduce friction, and grew into blanket exemptions. An office IP address should never skip MFA under Article 21.
- Push fatigue and MFA bombing. App-based push alone is insecure against repeated-prompt attacks. Number matching or, better, FIDO2 for privileged users is the current standard.
- SMS OTP as the only factor. SIM-swap attacks against individual executives and admins are common. SMS remains tolerated as an alternate factor, but not as the only option for privileged users.
- No coverage reporting. MFA is enforced, but there is no report that shows what percentage of accounts are enrolled, which are exempted, and who the exemption owners are. The coverage report is the primary evidence artefact.
- MFA for users, not for admin consoles. Identity admin, cloud admin, and SaaS tenant admin consoles sometimes sit outside the main MFA policy. Attackers target these first. They must be under the strongest policy available.
A practical Article 21(2)(j) readiness checklist
Use this short checklist to self-assess before a supervisor arrives. If any item cannot be answered with a document or a screenshot, it is a gap to close.
MFA readiness checklist
- A written MFA policy, approved by management, that lists which accounts are in scope and which factor types are approved.
- Enforcement at the identity provider for all external-facing authentication, with legacy protocols disabled.
- Phishing-resistant MFA (FIDO2 or smart card) for all privileged accounts.
- A monthly coverage report showing enrolment percentage, factor type distribution, and exception list.
- Documented exceptions with named risk owner, compensating controls, and review date.
- Contractual MFA requirements for third-party access, enforced on your identity provider.
- Number matching enabled on push-based MFA; SMS used only as a fallback, not the primary factor for privileged users.
- Secure emergency communications channel identified, tested, and documented (part of the same measure).
The secured-communications half of measure 10
Article 21(2)(j) does not stop at MFA. It also requires secured voice, video, and text communications and secured emergency communication systems within the entity, where appropriate. This is often overlooked, and is a frequent supervisory question in 2026.
In practice, this means two things. First, sensitive collaboration (incident response bridges, board communications, legal hold discussions) should happen on end-to-end encrypted channels. Enterprise-grade messaging suites, encrypted voice bridges, or dedicated tools such as Signal for Business or Wickr Enterprise are accepted. Unencrypted voice and SMS for sensitive conversations are not. Second, the incident response plan must identify an out-of-band communication channel that works when primary systems are compromised.
Frequently asked questions
Does NIS2 make MFA mandatory?
Effectively yes. Article 21(2)(j) requires the use of MFA or continuous authentication solutions 'where appropriate'. For external-facing, administrative, and sensitive-data accounts, 'where appropriate' covers essentially all of them. Regulators treat missing MFA on these classes as a finding.
What types of MFA does NIS2 accept?
The directive is technology-neutral. Any factor combination qualifies. In practice, regulators expect phishing-resistant MFA such as FIDO2, smart cards, or platform authenticators with TPM for privileged accounts, app-based push with number matching as a minimum for general users, and SMS only as a fallback.
Is SMS-based MFA acceptable under NIS2?
It is not banned, but it is recognised as the weakest common factor and is targeted by SIM-swap attacks. Regulators accept it as a stopgap for general users and expect a documented roadmap to move to stronger factors, especially for administrators and remote privileged access.
Do MFA exceptions need to be documented?
Yes. Every account without MFA needs a written justification, a named risk owner, compensating controls, and a review date. The single most common MFA finding in 2026 inspections is a cluster of quiet exceptions, usually service accounts or legacy apps, with no risk acceptance record.
What evidence does a supervisor ask for on MFA coverage?
An MFA policy approved by management, an enforcement configuration screenshot at the identity provider, a coverage report showing enrolment percentage by user class, and the list of documented exceptions with owners and review dates. The coverage report is usually the first item requested.
Does NIS2 require MFA for third-party and supplier access?
Yes. Article 21(2)(d) on supply chain security combined with measure (j) means any supplier or managed service provider with access to in-scope systems must authenticate with MFA. This is usually enforced through contractual clauses and verified during supplier assurance reviews.
Does NIS2 Article 21(2)(j) also cover secured communications?
Yes. Measure (j) pairs MFA with secured voice, video, and text communications and emergency communication systems. Incident response bridges, board communications, and out-of-band channels must run on encrypted tooling. Unencrypted voice or SMS for sensitive conversations is not accepted.
Need a clean MFA coverage report before your next audit?
We help organisations close the gap between "MFA deployed" and "MFA audit-ready": coverage reporting, exception management, phishing-resistant rollout for privileged accounts, and supplier enforcement.
Book an MFA readiness review