Skip to main content
NIS2Certify
Back to overview

NIS2 MFA Requirements: Why "We Have MFA" No Longer Passes an Audit

By NIS2Certify
nis2mfaphishing-resistantarticle-21enisa
NIS2 MFA Requirements: Why "We Have MFA" No Longer Passes an Audit

NIS2 MFA Requirements: Why "We Have MFA" No Longer Passes an Audit

A client tells you they're covered on authentication. Everyone has Microsoft Authenticator, push approval is enforced, job done. Then an auditor opens ENISA's technical guidance and asks one question: is the MFA on your privileged accounts phishing-resistant? And suddenly the answer is no.

This is the gap most organisations don't see coming. NIS2 names multi-factor authentication directly, but the supervisory consensus has already moved past basic MFA. If you advise European entities on NIS2 compliance, the MFA conversation you had eighteen months ago is out of date.

Article 21(2)(j) Names MFA — But Doesn't Define "Good Enough"

NIS2 Article 21(2)(j) requires "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."

Two phrases in that sentence trip people up. The first is "where appropriate." This is not optionality. It means the entity must make a documented, risk-based decision about where MFA applies. An auditor who finds privileged accounts without MFA and no risk assessment explaining the omission will treat that as a finding, not a judgement call.

The second problem is what the directive doesn't say. Article 21 names MFA but never defines which factors qualify. That detail lives in Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024, which sets the technical and methodological requirements for the risk-management measures. The Directive tells you that you need MFA. The Implementing Regulation, and the guidance built on top of it, tells you what kind.

ENISA Has Already Set the Bar at Phishing-Resistant

In June 2025, ENISA published version 1.0 of its Technical Implementation Guidance on Implementing Regulation 2024/2690. This is the document supervisory authorities lean on when they assess whether your controls actually meet the standard.

The guidance is explicit: choose an authentication method whose assurance level matches the classification of the data and systems it protects, and use phishing-resistant options "wherever possible." It names FIDO2 security keys and passkeys, built on the FIDO and W3C WebAuthn standards, as the strongest available method — ahead of passwords, SMS codes, and app-based one-time passwords.

The reasoning is technical, not fashionable. Push notifications, OTP codes, and SMS all rely on a shared secret or an approval the user can be tricked into handing over. Attackers defeat them every day with MFA-fatigue prompts, adversary-in-the-middle proxies, and SIM swaps. Passkeys and FIDO2 keys are domain-bound by design: the credential simply will not release against a spoofed domain. There is no code to phish and no prompt to fatigue.

For an essential entity, this matters financially as well as technically. Non-compliance exposes essential entities to fines up to €10 million or 2% of global annual turnover. "We had MFA" is a weak defence when the regulator's own agency has documented that the MFA you deployed was the weak kind.

Article 21 — 10 NIS2 Cybersecurity Measures
Article 21
10 Cybersecurity Measures
Governance & Strategy
1Risk analysis & information security policies
6Effectiveness assessment of security measures
Incident & Continuity
2Incident handling & notification
3Business continuity & disaster recovery
Supply Chain & Systems
4Supply chain security
5Security in network & information systems development
Technical Controls
8Cryptography & encryption
10Multi-factor authentication & secure communications
People & Assets
7Cyber hygiene & training
9HR security & access control

Not Every Account Needs the Same Factor

The practical mistake in the other direction is treating phishing-resistant MFA as an all-or-nothing rollout and stalling because hardware keys for 4,000 staff look expensive. The guidance is risk-tiered, and so should your advice be.

Privileged and high-impact access is where phishing-resistant MFA is effectively non-negotiable: domain admins, cloud tenant administrators, hypervisor and backup console access, and any account that can disable security controls. If one of these is compromised, the incident is over before it starts. Deploy FIDO2 keys or platform passkeys here first.

Remote access and external-facing identities come next — VPN, RDP gateways, and any system reachable from the internet. These are the front door attackers actually knock on, so the assurance level should be high.

Standard workforce accounts can move to phishing-resistant MFA on a planned timeline, but the direction of travel should be clear in your documentation. An auditor wants to see that you know where the weak MFA still lives and have a dated plan to retire it, not that you've solved everything overnight.

This tiering is also how you keep budget conversations sane. A consultant who walks in demanding €200,000 of hardware keys loses the room. A consultant who says "thirty FIDO2 keys for your fifteen privileged admins this quarter, passkeys for everyone else next" gets a signature.

How to Make This Auditable, Not Just Deployed

Deployment is half the job. The half that survives an audit is the paperwork that proves the deployment was a deliberate, risk-based decision under Article 21.

Three artefacts carry most of the weight. First, an access classification that maps account types to required assurance levels — this is the document that operationalises "where appropriate." Second, evidence of enforcement, meaning conditional access or equivalent policies that actually block non-compliant sign-ins rather than merely recommending MFA. A policy in "report-only" mode is not a control. Third, an exception register: every account that cannot use phishing-resistant MFA yet, why, the compensating control, and the remediation date.

Get those three right and the MFA section of an audit becomes short. Skip them and even a technically strong rollout looks like luck rather than governance.

Does NIS2 Apply to Your Organisation?
1
Does your organisation operate in an essential or important sector (energy, transport, health, digital infrastructure, etc.)?
Yes ↓No →
2
Does your organisation have 50 or more employees, or an annual turnover exceeding €10 million?
Yes ↓No →
3
Is your organisation a critical infrastructure provider or a qualified trust service provider?
Yes ↓No →
✗
NIS2 does not directly apply to your organisation.
✓
NIS2 applies to your organisation as an Essential or Important Entity.
!
NIS2 may apply to your organisation — seek legal advice to confirm your status.
Applies
Possibly applies
Does not apply

What This Means for MSPs Managing Multiple Tenants

If you run identity for several clients, the phishing-resistant shift is an operational programme, not a per-client fix. The clients who will struggle are the ones still on legacy MFA across the board, and they tend to be your smaller engagements where budget resistance is highest.

Standardise now. Pick a phishing-resistant method you can deploy and support at scale — platform passkeys plus a hardware-key fallback for admins is a defensible default — and make it your baseline for every tenant. Build the access classification once as a template and adapt it per client rather than reinventing it each engagement. And put the exception register into your normal reporting cadence so remediation dates don't quietly slip past an audit deadline.

The cost of getting this wrong is not evenly distributed. When a breach lands on a managed client and the root cause is phishable MFA on an admin account, the supply-chain provisions of NIS2 pull the conversation toward your contract, not just theirs.

NIS2 Penalty Escalation — Beyond the Fine
!
Trigger event
Non-Compliance Detected or Incident Occurs
A supervisory authority identifies a compliance gap or an organisation fails to meet NIS2 requirements
Authorities can impose
▼
Non-Monetary Penalties
1
Compliance orders with binding deadlines
2
Mandatory security audits at your expense
3
Public disclosure of violations
4
Binding instructions on specific security measures
Escalates to
▼
Operational & Personal Consequences
1
Suspension of certifications or operating licences
2
Temporary ban on management functions for individuals
3
Public naming of responsible natural persons
Trigger
Non-monetary
Operational / personal

The Move to Make This Quarter

Stop treating MFA as a checkbox that's already ticked. The question that matters under NIS2 is no longer "do we have MFA" but "is our MFA phishing-resistant where it counts, and can we prove the decision was deliberate."

Start with privileged accounts, document the risk tiers, enforce in blocking mode, and keep an honest exception register. That's the difference between a clean authentication finding and an expensive one.

If you're not sure where your clients' MFA actually stands against the ENISA guidance, a structured readiness assessment will surface the gaps before an auditor does. Run a free NIS2 quick scan to see where authentication and the rest of the Article 21 measures sit today.

For the broader picture on what Article 21 demands, see our breakdown of the ten Article 21 measures. To pressure-test your overall posture, work through our step-by-step gap analysis guide.