NIS2 MFA Requirements: Directive Compliance Guide

NIS2 MFA Requirements at a Glance

• MFA is named directly in the directive: Article 21(2)(j) explicitly lists multi-factor authentication as a required cybersecurity risk management measure, making it one of the few controls named in the NIS2 text itself.
• It applies to essential and important entities: Any organization classified as an essential or important entity under NIS2 must implement appropriate MFA as part of its risk management measures.
• “Where appropriate” means risk-based, not optional: The directive’s “where appropriate” language requires a risk assessment to determine where MFA applies. It does not permit an organization to skip MFA across the board.
• An implementing regulation adds technical detail: Commission Implementing Regulation (EU) 2024/2690 clarifies the technical and methodological requirements, and supervisory practice increasingly expects phishing-resistant methods for high-risk access.
• Management is personally accountable: Under Article 20, an entity’s management body must approve and oversee cybersecurity measures and can be held personally liable for failures.
• Penalties are severe: Essential entities face fines up to €10 million or 2% of global annual turnover, and important entities up to €7 million or 1.4%, whichever is higher.

What is the NIS2 Directive?

The NIS2 Directive, formally Directive (EU) 2022/2555, is the European Union’s cybersecurity law for organizations that provide essential and important services. It was adopted on January 16, 2023, and replaced the original 2016 Network and Information Security Directive (NIS1). NIS2 was created to address the shortcomings of NIS1, which gave member states wide discretion and produced inconsistent cybersecurity standards and enforcement across the EU.
 
NIS2 raises the common level of cybersecurity across the Union in several ways. It expands the range of sectors and organizations in scope, covering roughly 160,000 organizations, which is a large increase over the original directive. It sets a baseline of mandatory cybersecurity risk management measures in Article 21, introduces harmonized incident reporting timelines, and places direct accountability on senior management. The member states were required to transpose NIS2 into national law by October 17, 2024, with the rules applying from October 18, 2024.
 
As a directive rather than a regulation, NIS2 is not directly applicable on its own. Each member state must transpose it into national law, which means the precise requirements, reporting routes, and penalty details vary somewhat by country. The core obligations, including the MFA requirement, are consistent across the EU, but organizations operating in multiple member states should review each relevant national law. In January 2026, the European Commission proposed targeted amendments intended to simplify some obligations for smaller entities, so organizations should also watch for changes as the framework matures.

Who Does NIS2 Apply To?

NIS2 applies to organizations that operate in one of its covered sectors and meet the size thresholds, generally medium and large enterprises with at least 50 employees or €10 million in annual turnover. Some organizations are in scope regardless of size, such as certain DNS providers, trust service providers, and public administration bodies. NIS2 divides in-scope organizations into two categories:

• Essential entities: Larger organizations in the most critical sectors, listed in Annex I. These include energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, public administration, and space. Essential entities face the strictest supervision, including proactive audits.
• Important entities: Organizations in the sectors listed in Annex II, and medium-sized organizations in Annex I sectors. These include postal and courier services, waste management, chemicals, food, manufacturing, digital providers such as online marketplaces and search engines, and research organizations. Important entities face supervision after a suspected problem or incident.

The distinction affects supervision and penalty levels, but both categories must implement the same core Article 21 measures, including MFA. The expansion of covered sectors is one of the most significant changes from NIS1, bringing many organizations into scope that were not previously regulated.
 
A note for Canadian and other non-EU organizations: NIS2 can reach organizations based outside the EU. A non-EU company that provides in-scope services within the European Union, such as a cloud provider or digital service provider serving EU customers, can fall within the directive’s scope and may be required to designate a representative in the EU. Even where NIS2 does not apply directly, EU customers increasingly require NIS2-aligned security measures from their suppliers through contracts, so organizations in the supply chain of an in-scope entity often need to meet the same standards.

What Are the NIS2 Requirements?

Article 21(2) of NIS2 sets out ten minimum cybersecurity risk management measures that essential and important entities must implement. The measures are technology-neutral and outcomes-based, and they must be proportionate to the entity’s risk exposure, size, and the potential impact of an incident. The table below maps the measures most relevant to MFA and authentication.
 

The Ten Article 21 Measures

The ten minimum measures cover risk analysis and information system security policies, incident handling, business continuity and crisis management, supply chain security, security in the acquisition and development of systems, policies to assess the effectiveness of cybersecurity measures, basic cyber hygiene and training, cryptography and encryption, human resources security and access control, and the use of multi-factor authentication and secured communications. Together they form a baseline that applies to every in-scope entity, scaled to the entity’s risk and size.

Article 21(2)(j): The MFA Requirement

Article 21(2)(j) is the provision that names MFA. It 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. This is the first time EU law has named multi-factor authentication directly as a cybersecurity risk management control, which means it cannot be interpreted away as an optional or derived measure.
 
NIS2 defines MFA in line with established practice: authentication using at least two independent factors from different categories, being something you know, such as a password or PIN; something you have, such as a hardware token, authenticator app, or smart card; and something you are, such as a biometric. Commission Implementing Regulation (EU) 2024/2690, adopted alongside the transposition deadline, adds technical and methodological detail on which authentication approaches are expected to satisfy the requirement.

Understanding “Where Appropriate”

The phrase “where appropriate” in Article 21(2)(j) is often misread as an opt-out. It is not. Supervisory authorities and ENISA guidance consistently treat it as a requirement to conduct a risk-based assessment that determines where MFA applies, not whether to deploy it at all. In practice, authorities conducting NIS2 inspections typically expect MFA at minimum on remote access, privileged accounts, cloud administration, and email, because these represent the most common attack vectors. An organization that concluded MFA was unnecessary across the board would not have a defensible position under the directive.

Is MFA Required by NIS2?

Yes. MFA is explicitly required under Article 21(2)(j) of the NIS2 Directive. It is one of the few security controls named directly in the text of the directive, rather than being derived from a general obligation or a delegated act. For any organization classified as an essential or important entity, implementing appropriate MFA is a legal requirement, not a best practice.
 
The requirement is shaped by the proportionality principle in Article 21(1) and the “where appropriate” language in 21(2)(j), which together call for a risk-based approach. This does not weaken the obligation. It means an organization must assess its access points and apply MFA where the absence of it would create meaningful risk, then be able to document and defend those decisions. Supervisory authorities expect to see a documented authentication policy that specifies where MFA is mandatory and which methods qualify. The absence of such a policy, or MFA gaps on obvious high-risk access such as remote and privileged access, is exactly what an inspection is designed to find.
 
The technical expectation is also rising. While SMS-based one-time codes technically meet the basic definition of MFA, ENISA guidance and national supervisory authorities increasingly regard them as insufficient for high-risk access because of their vulnerability to SIM-swapping and phishing. For privileged accounts and critical systems, phishing-resistant methods such as FIDO2 security keys are strongly preferred and are becoming the expected standard over time.
 
The bottom line for in-scope organizations is clear. MFA is legally required, it must cover the access points where its absence would create risk, and for the highest-risk access it should be phishing-resistant. A deployment that stops at basic MFA on a subset of systems is unlikely to satisfy a supervisory authority.

Consequences of NIS2 Non-Compliance

NIS2 introduces some of the most significant cybersecurity penalties in EU law, and it pairs financial penalties with personal accountability for senior management.
 
For essential entities, national authorities can impose fines of up to €10 million or 2% of the entity’s total worldwide annual turnover, whichever is higher. For important entities, the ceiling is €7 million or 1.4% of global annual turnover, whichever is higher. These are minimum maximums that member states must provide for, and some go further. Germany’s implementation, for example, allows fines up to €20 million for essential entities and personal fines of up to €500,000 for governance failures.
 
The personal accountability provisions are a major change from NIS1. Under Article 20, an entity’s management body must approve the cybersecurity risk management measures, oversee their implementation, and undergo cybersecurity training. Where an entity materially fails to comply, supervisory authorities can hold management personally liable, and for essential entities they can temporarily ban individuals from holding management positions. Authorities can also require an entity to make a violation public and can name the responsible individuals.
 
Enforcement is now active. By 2026, most member states had transposed NIS2, and authorities in Germany, France, the Netherlands, Belgium, and Italy had begun supervision and enforcement activity. Early enforcement has focused on registration and governance compliance first, with substantive security measures and penalties following, a pattern that mirrors how GDPR enforcement ramped up after 2018. Credential compromise remains one of the leading causes of breaches in the sectors NIS2 covers, which is precisely why authentication controls receive close attention during inspections.

How to Implement MFA for NIS2 Compliance

1. Confirm Your Scope and Classification

Determine whether your organization is in scope and whether it is an essential or important entity. This depends on your sector under Annex I or Annex II and your size. If you operate in multiple member states, review each relevant national transposition, since details vary. Confirming your classification tells you which supervisory regime and penalty levels apply and sets the context for the rest of your compliance work.

2. Assess Your Identity Attack Surface

The “where appropriate” standard requires a risk-based assessment, so map every access point across your environment: remote access, privileged and administrative accounts, cloud management consoles, email, internal applications, and any operational technology access. Identify where the absence of MFA would create a meaningful risk of breach. This assessment is both the basis for your deployment and the evidence that supports your decisions during an inspection.

3. Select an MFA Solution That Fits Your Environment

Choose a solution that can enforce MFA across the full range of access points in your assessment. Look for support for RADIUS, LDAP, and Active Directory to cover the systems common in essential and important entities, and consider whether you need cloud, on-premises, or hybrid deployment. For organizations in energy, manufacturing, and other sectors with operational technology, confirm that the solution can work in environments that cannot rely on cloud connectivity or personal mobile devices.

4. Prioritize Phishing-Resistant Factors for High-Risk Access

Because supervisory expectations are moving toward phishing-resistant authentication, deploy methods such as FIDO2 security keys or smart cards for privileged accounts, administrators, and other high-risk access. Reserve weaker methods, such as SMS codes, for lower-risk scenarios if at all. Phishing-resistant factors are cryptographically bound to the legitimate service, which makes intercepted credentials useless to an attacker.

5. Deploy MFA Across the Assessed Scope

Roll out MFA across the access points identified in your assessment, starting with the highest-risk and highest-impact areas. Administrative and remote access should come first, followed by externally facing applications and then sensitive-data access. Include third-party and vendor access, which falls under the supply chain security expectations of Article 21(2)(d). Verify that no high-risk access path is left on single-factor authentication.

6. Document Your Authentication Policy and Get Board Approval

NIS2 expects a documented authentication policy that specifies where MFA is mandatory and which methods qualify. Because Article 20 makes the management body accountable, that policy should be formally approved and overseen at board level. Keep the risk assessment, the policy, and evidence of board approval together, since these are the documents an auditor will ask for.

7. Enable Logging and Review Regularly

Ensure your MFA solution generates authentication logs that support incident detection and provide evidence of enforcement. NIS2 expects entities to assess the effectiveness of their measures over time, so establish a regular review of your authentication controls, and revisit your risk assessment when your systems, access model, or threat environment changes.

Where NIS2 MFA Deployments Get Difficult

For many in-scope organizations, especially in energy, utilities, manufacturing, and other operational technology sectors, the hardest part of NIS2 MFA compliance is covering environments that conventional cloud-based authentication cannot reach.
 
Operational technology systems, including SCADA, industrial control systems, and the equipment that runs critical infrastructure, were often designed decades ago without modern authentication in mind. Many run on legacy operating systems, sit on air-gapped or internet-isolated networks, and cannot depend on a cloud service or a smartphone to authenticate. A cloud-only MFA product simply cannot function in these environments, yet these are exactly the systems whose compromise NIS2 is most concerned with.
 
The practical answer is an MFA solution that can operate entirely within the organization’s own environment, using authentication factors that generate credentials locally. Hardware tokens and FIDO2 security keys work without any network connection, which makes them suitable for air-gapped OT networks and for staff working in environments where personal devices are not permitted. Organizations in these sectors should confirm that their approach to MFA can reach operational technology, not just corporate IT, because a gap in OT coverage is both a compliance risk and a serious security risk.

NIS2 MFA Best Practices

• Treat “where appropriate” as a documented decision, not an exemption: Conduct and record a risk-based assessment of where MFA applies. The assessment itself is key evidence during an inspection, and it should clearly cover remote access, privileged accounts, cloud administration, and email at minimum.
• Prioritize phishing-resistant authentication for privileged access: FIDO2 security keys and smart cards align with the direction of supervisory expectations and offer strong protection for the high-value accounts attackers target first.
• Extend MFA to the supply chain: Article 21(2)(d) makes supplier security part of your obligations. Ensure third-party and vendor remote access uses MFA, and address authentication expectations in supplier contracts.
• Plan for operational technology from the start: If you operate OT or air-gapped systems, choose an approach that can enforce MFA in those environments rather than leaving them as an exception. Local, network-independent authentication factors are the practical solution.
• Get board approval and keep the evidence: Because Article 20 makes management personally accountable, have the management body formally approve your authentication policy and keep documented evidence of that approval and oversight.
• Prepare for offline recovery: A privileged account that loses access to its second factor during an incident is a real operational risk. Plan secure, documented recovery procedures that do not create a bypass of the MFA requirement, and make sure a backup factor is available to your incident response team.

How LoginTC Helps with NIS2 MFA Compliance

LoginTC is well suited to the range of environments NIS2 covers, from corporate IT to the operational technology that underpins energy, utilities, and manufacturing. It integrates through RADIUS, LDAP, and Active Directory, so organizations can enforce MFA across remote access, privileged accounts, applications, and infrastructure without replacing the systems they already run.
 
For the Article 21(2)(j) requirement, LoginTC enforces MFA on the access points supervisory authorities focus on first, including remote access, Windows logon, VPNs, and administrative accounts. It supports phishing-resistant factors such as FIDO2 security keys and hardware tokens, which align with the direction of supervisory expectations for privileged and high-risk access, and which work for staff who cannot use a personal mobile device.
 
For essential and important entities that operate operational technology or air-gapped networks, LoginTC’s on-premises deployment option keeps all authentication infrastructure within the organization’s own environment, with no dependency on external connectivity. This makes it possible to extend MFA into the OT environments that conventional cloud-based solutions cannot reach. Detailed authentication logs and centralized administration provide the evidence needed to document MFA coverage and to demonstrate the effectiveness of controls to a supervisory authority, supporting both the technical and the governance sides of NIS2.
 
Explore LoginTC for Energy and Utilities | View All Connectors

Frequently Asked Questions

Article 21(2)(j) of the NIS2 Directive explicitly names multi-factor authentication as a required cybersecurity risk management measure for essential and important entities. It is one of the few controls named directly in the directive text, which makes it a clear legal requirement rather than a recommendation. The “where appropriate” language calls for a risk-based assessment of where MFA applies, not whether to deploy it at all.

Who does NIS2 apply to?

NIS2 applies to essential and important entities operating in its covered sectors that meet the size thresholds, generally medium and large enterprises. Essential entities are larger organizations in the most critical Annex I sectors such as energy, transport, banking, health, and digital infrastructure. Important entities include organizations in Annex II sectors such as manufacturing, food, chemicals, and digital providers, along with medium-sized organizations in Annex I sectors. Some organizations are in scope regardless of size.

What types of MFA are acceptable under NIS2?

NIS2 requires at least two independent factors from different categories: something you know, something you have, and something you are. Commission Implementing Regulation (EU) 2024/2690 adds detail on which methods are expected to qualify. While SMS-based codes technically meet the basic definition, ENISA and national authorities increasingly regard them as insufficient for high-risk access. Phishing-resistant methods such as FIDO2 security keys are strongly preferred for privileged accounts and critical systems.

Does NIS2 apply to organizations outside the EU?

It can. A non-EU organization that provides in-scope services within the European Union, such as a cloud or digital service provider serving EU customers, can fall within NIS2 and may need to designate an EU representative. Even where NIS2 does not apply directly, EU customers frequently require NIS2-aligned security measures, including MFA, from their suppliers through contracts, so non-EU organizations in the supply chain often need to meet the same standards.

What does “where appropriate” mean for MFA under NIS2?

It means MFA scope is determined by a risk-based assessment, not that MFA is optional. Supervisory authorities and ENISA guidance are consistent that the assessment determines where MFA applies, and that an organization cannot conclude MFA is unnecessary across the board. Inspections typically expect MFA at minimum on remote access, privileged accounts, cloud administration, and email.

Does LoginTC need to be cloud-based to support NIS2 compliance?

No. NIS2 does not require a specific hosting model. Both cloud-based and on-premises LoginTC deployments can support NIS2 compliance. For essential and important entities that operate operational technology or air-gapped networks, LoginTC’s on-premises option is particularly useful because it keeps authentication infrastructure within the organization’s own environment and can enforce MFA in systems that cloud-based solutions cannot reach.

How do the NIS2 management liability provisions affect MFA?

Under Article 20, an entity’s management body must approve and oversee its cybersecurity measures, which includes the authentication policy that governs MFA. Management can be held personally liable for failures, and for essential entities supervisory authorities can temporarily ban individuals from management roles. In practice, this means your MFA policy should be formally approved at board level and supported by documented evidence of oversight.

Get a Free NIS2 MFA Strategy Session

Meeting the NIS2 MFA requirement means more than switching on multi-factor authentication. It means assessing where MFA is needed, deploying phishing-resistant factors on high-risk access, extending coverage into operational technology where conventional tools cannot reach, and documenting all of it for a supervisory authority and your own board.
 
Our team helps essential and important entities deploy MFA that meets NIS2 requirements across IT and operational technology, without disrupting the services that customers and the public depend on. If you are preparing for supervision or closing gaps in your authentication coverage, we are ready to help.