NIS2 Identity Access Management Requirements: What Organisations Actually Need to Do

NIS2 and Identity — What the Directive Actually Says

Directive (EU) 2022/2555, known as NIS2, entered into force on 16 January 2023 and required transposition into EU member state law by 17 October 2024. It replaces the original NIS Directive (2016/1148) and significantly expands both the scope of organisations covered and the depth of security obligations imposed on them.

The original NIS Directive was criticised for leaving too much discretion to member states and for generating inconsistent implementation across the EU. NIS2 addresses this through more prescriptive requirements, especially in Article 21, which sets out the minimum security measures that covered entities must implement.

Identity and access management sits at the centre of those requirements. Article 21(2) lists ten categories of security measure, and several of them bear directly on how organisations manage identities, control access, and protect privileged accounts. The most explicit is Article 21(2)(j), which requires the use of multi-factor authentication or continuous authentication solutions, secure voice, video and text communications, and secured emergency communication systems where appropriate. This is not a recommendation — it is a minimum security measure.

Article 21 also draws from Annex considerations around risk analysis and information system security policies, supply chain security, access control, and asset management. Taken together, these provisions create a coherent — if not fully detailed — framework for identity governance that covered organisations must meet.

Who NIS2 Applies To

NIS2 introduces two categories of covered entity: essential entities and important entities. The distinction matters because supervisory arrangements and enforcement powers differ between them.

Essential entities are drawn from sectors including energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management (business-to-business), public administration, and space. Important entities include postal and courier services, waste management, manufacturing of certain products, food, chemicals, and digital providers such as online marketplaces, online search engines, and social networking services.

The size threshold for coverage is organisations with 50 or more employees or an annual turnover or balance sheet total exceeding €10 million. Certain entities are covered regardless of size — including providers of public electronic communications networks, trust service providers, top-level domain name registries, and DNS service providers.

Member states may extend coverage further. Several have done so during transposition. Organisations should not assume that because they fall below the headline thresholds, they are not affected — particularly if they are a supplier into the supply chain of a covered entity, where NIS2's supply chain security requirements will flow down indirectly.

The Ten Minimum Security Measures Under Article 21

Article 21(2) specifies ten categories of measure that covered entities must implement. These are minimums — supervisors expect proportionate implementation based on the risk profile of the organisation, but cannot be contractually or procedurally avoided. The ten categories are:

• (a) Policies on risk analysis and information system security — Requires documented, maintained risk analysis processes covering information systems. For identity, this means formal assessment of identity-related risks including credential compromise, privilege escalation, and account takeover.
• (b) Incident handling — Procedures for detecting, managing, and reporting security incidents. Identity incidents — compromised accounts, unauthorised privilege changes, directory attacks — must be within scope of incident handling procedures.
• (c) Business continuity — Including backup management, disaster recovery, and crisis management. Identity infrastructure — directory services, privileged access management platforms, MFA systems — must be covered by business continuity arrangements.
• (d) Supply chain security — Security aspects of relationships between entities and their direct suppliers or service providers. This includes identity risks introduced by third parties: shared credentials, standing access, supplier-managed accounts.
• (e) Security in network and information systems acquisition, development and maintenance — Including vulnerability handling and disclosure. Relevant to identity where systems are procured, developed, or maintained by third parties who may hold privileged access.
• (f) Policies and procedures to assess the effectiveness of cybersecurity risk management measures — Requires ongoing assurance, not just point-in-time compliance. Identity controls must be subject to regular review and effectiveness testing.
• (g) Basic cyber hygiene practices and cybersecurity training — Includes awareness of phishing and social engineering, which are the primary vectors for credential theft. Training must cover identity-specific threat scenarios.
• (h) Policies and procedures regarding the use of cryptography and, where appropriate, encryption — Relevant to how credentials, authentication tokens, and identity-related data are protected in transit and at rest.
• (i) Human resources security, access control policies and asset management — This is the primary locus of formal access control obligations under NIS2. Least privilege, joiner/mover/leaver processes, and asset-linked access provisioning are all within scope.
• (j) Use of multi-factor authentication or continuous authentication solutions — Explicitly named. Also covers secure voice, video and text communications and secured emergency communication systems where appropriate.

Of these, (a), (d), (i), and (j) have the most direct bearing on identity and access management programmes. But (b), (c), (f), and (h) all create identity-adjacent obligations that are frequently underestimated during compliance scoping exercises.

Access Control Requirements Under NIS2

Article 21(2)(i) groups human resources security, access control policies, and asset management together. That grouping is deliberate: NIS2 treats access to systems as inseparable from the people and assets involved. An access control programme that is not connected to an asset inventory and an HR lifecycle process does not meet the intent of the directive.

Least Privilege

The principle of least privilege is not named explicitly in NIS2's text, but it is implicit in Article 21(2)(i) and is consistently referenced in ENISA guidance and in the implementing acts under preparation. Supervisors in member states that have transposed NIS2 have begun setting out expectations that access rights are scoped to what is needed for the role, are reviewed periodically, and are revoked promptly when no longer required. Standing administrative access and broad group memberships that survive role changes are the two most commonly cited control failures in early supervisory assessments.

Privileged Access Management

Administrative and privileged accounts receive particular attention under NIS2's risk-based framework. Where access control policies are required, supervisors expect those policies to address privileged accounts specifically — including how they are provisioned, what controls govern their use (separate accounts for privileged activity, session recording, just-in-time access where appropriate), and how they are reviewed and deprovisioned.

The use of shared administrative credentials, generic service accounts with broad rights, and administrator accounts used for everyday tasks are all patterns that conflict with NIS2's access control intent, even if the directive does not enumerate them explicitly.

Multi-Factor Authentication

Article 21(2)(j) is one of the most concrete identity requirements in NIS2. It requires the use of MFA or continuous authentication solutions. The phrase "where appropriate" in the article relates to secure communications channels, not to MFA itself — MFA is stated as a requirement without qualification.

In practice, supervisors interpret this as requiring MFA for remote access, administrative access, and access to critical or sensitive systems. Some member state transpositions and their associated national guidance go further, specifying MFA requirements for all user authentication to covered systems. Organisations should not treat the absence of granular specification in the directive as an invitation to apply MFA narrowly.

Remote Access Controls

Remote access is a specific concern for NIS2 supervisors, consistent with the post-pandemic recognition that perimeter-based security models are insufficient. Remote access must be subject to strong authentication (MFA as a minimum), and the use of personal devices for remote access to critical systems requires clear policy and technical controls. VPN alone, without MFA, does not meet NIS2's intent.

Third-Party and Supply Chain Identity Risks

Article 21(2)(d) — supply chain security — creates specific obligations around the identity risks introduced by suppliers and service providers. This includes how third parties are granted access, whether that access is time-limited, whether shared credentials are used, and what controls govern third-party privileged access. Organisations must be able to demonstrate that they have assessed and mitigated identity risks in their supply chain relationships, not simply that they have a supplier security questionnaire process.

UK vs EU NIS2 — the Divergence

NIS2 is an EU directive. It applies in EU member states through national transposition. The UK is not an EU member state and NIS2 does not have direct effect in the UK.

The UK's current framework is the Network and Information Systems (NIS) Regulations 2018, which transposed the original NIS Directive before Brexit. These regulations apply to operators of essential services and relevant digital service providers and remain in force.

The UK government announced a Cyber Security and Resilience Bill in the King's Speech in July 2024, with the intent of updating and expanding the UK NIS framework. As of early 2026, the Bill is progressing through Parliament. Early indications suggest it will expand the scope of covered entities, strengthen incident reporting requirements, and introduce more robust enforcement powers — broadly tracking NIS2 in intent if not in identical implementation.

What This Means for UK Organisations Operating in EU Markets

A UK-headquartered organisation that operates in EU member states — through subsidiaries, branch offices, or as a provider of services to EU entities — may be subject to NIS2 obligations in those member states directly. The relevant test is whether the organisation provides services that are covered by NIS2 within the EU, not where it is incorporated.

UK organisations that are suppliers into the supply chains of NIS2-covered EU entities will face NIS2 requirements flowing through contractual obligations from their customers, even if they are not directly covered entities themselves. Article 21(2)(d) requires covered entities to address supply chain security, and that requirement will translate into supplier contract terms and assessment requirements.

The practical effect is that many UK organisations need to understand NIS2 even though it does not apply to them directly. Either because they have EU operations, because they supply EU-covered entities, or because the forthcoming UK Cyber Security and Resilience Bill is likely to create equivalent domestic obligations in the near term.

Supervisory Enforcement Under NIS2

NIS2 significantly strengthens enforcement compared to the original directive. For essential entities, supervisors have powers to impose fines of up to €10 million or 2% of global annual turnover, whichever is higher. For important entities, the maximum is €7 million or 1.4% of global annual turnover.

Beyond financial penalties, NIS2 introduces supervisory powers including the ability to require security audits, issue binding instructions, and — for essential entities — temporarily restrict the ability of management bodies to exercise their functions. This last power is notable: it makes senior management personally exposed to the consequences of inadequate cybersecurity governance in a way that was not present under the original directive.

What Supervisors Will Examine

Early enforcement patterns from member states that transposed NIS2 on schedule — including Germany, whose BSIG reform implemented NIS2 requirements, and the Netherlands, which transposed through its Cybersecurity Act (Wbni) amendment — point to supervisory attention focused on:

• Whether a documented risk analysis process exists and is current
• Whether security measures are proportionate to the assessed risk
• Whether access control policies exist and are enforced in practice
• Whether MFA is deployed on remote and administrative access
• Whether incident reporting obligations are understood and tested
• Whether senior management have approved and are accountable for security measures

Article 20 of NIS2 places explicit accountability on management bodies: they are required to approve the cybersecurity risk management measures taken by the entity and to oversee their implementation. Management bodies that delegate this entirely without oversight are in breach of Article 20, not just good practice.

The Difference Between NIS2 Compliance and NIS2 Readiness

Compliance and readiness are not the same thing, and the distinction matters under NIS2's supervisory model.

Compliance means having the policies, procedures, and technical controls in place that Article 21 requires. Readiness means being able to demonstrate that those controls are operating effectively — and being able to produce that evidence when a supervisor asks, or when an incident triggers a review.

The evidence standard under NIS2 is higher than many organisations assume. It is not sufficient to have an access control policy in a document management system. Supervisors expect to see that the policy is implemented in practice: that access rights are regularly reviewed, that MFA deployment is verifiable, that privileged account inventories are current, and that the joiner/mover/leaver process actually results in timely account deprovisioning.

What Happens When an Incident Triggers Supervisory Review

NIS2's incident reporting obligations (Article 23) require significant incidents to be reported to the relevant national authority within 72 hours of becoming aware of them. Following that report, a supervisory examination of the organisation's security posture is a predictable consequence — particularly if the incident involved a failure of identity or access controls.

In post-incident supervisory reviews, the questions centre not just on what went wrong in the incident, but on what controls were in place before it. Were access rights reviewed? Was MFA deployed? Were privileged accounts managed to an appropriate standard? The answers to those questions determine whether a fine or binding instruction follows. Organisations that can demonstrate effective controls — even when a breach occurs — are in a materially different position to those that cannot.

This means that the work done before an incident is what determines the supervisory outcome after one. Readiness is not a precaution; under NIS2, it is a direct mitigant of regulatory exposure.

NIS2 Identity Controls Readiness Checklist

The following ten items represent the minimum baseline an organisation should be able to confirm before considering itself ready for NIS2 supervisory scrutiny on identity and access management.

• 1. Scope is confirmed. The organisation has assessed whether it meets the NIS2 threshold criteria (sector, employee count, turnover) and has documented its conclusion — including whether it operates in EU member states or supplies NIS2-covered entities.
• 2. A documented access control policy exists. The policy covers all user categories (standard users, administrators, service accounts, third parties), specifies the principle of least privilege, and has been approved by management.
• 3. MFA is deployed on all remote access. Remote access to any covered system requires MFA. VPN access alone without a second factor does not meet Article 21(2)(j).
• 4. MFA is deployed on privileged and administrative accounts. All accounts with elevated rights require MFA regardless of whether access is local or remote.
• 5. A privileged account inventory exists and is current. The organisation can enumerate all accounts with administrative or elevated rights, including service accounts and shared accounts, and can confirm whether each is still required.
• 6. Access rights are reviewed at defined intervals. Formal access reviews covering all user categories are conducted at least annually, with evidence retained. Privileged account reviews are conducted more frequently.
• 7. Joiner/mover/leaver processes include timely account action. Leavers' accounts are disabled or deleted within a defined period. Role changes trigger access reviews. New joiners receive only the access required for their role.
• 8. Third-party access is controlled and reviewed. Supplier and service provider access is time-limited, individually attributed (no shared accounts), subject to MFA, and reviewed at contract renewal or at defined intervals.
• 9. Identity risks are included in the risk analysis process. The organisation's Article 21(2)(a) risk analysis explicitly addresses identity-related risks: credential compromise, privilege escalation, account takeover, directory attacks.
• 10. Management body oversight is documented. The management body has formally approved security measures including access control policies and MFA deployment, consistent with the Article 20 obligation. Board minutes or equivalent records demonstrate this.