Identity Controls for NIS2

NIS2, Directive (EU) 2022/2555, puts identity controls into law for essential and important entities across sectors such as energy, transport, health, digital infrastructure, and manufacturing. Article 21(2) lists the minimum risk-management measures, and two of them are identity measures by name: "access control policies" under point (i) and "multi-factor authentication or continuous authentication solutions" under point (j). For cloud, data centre, managed service, and other digital providers, Implementing Regulation (EU) 2024/2690 turns those words into specific requirements: unique identities, privileged account policies, logged access rights, and MFA matched to asset classification. This guide maps both texts to controls and evidence.

What the law says

Member States had to adopt and publish their transposing measures by 17 October 2024 and apply them from 18 October 2024 (Article 41). Track national status on the regulations calendar.

What Implementing Regulation 2024/2690 adds

Adopted on 17 October 2024, the regulation applies to the digital entity types listed in its Article 1. Its annex section 11, "Access control", is the most detailed identity text in EU cybersecurity law:

• 11.2 Access rights: assign and revoke on need-to-know, least privilege, and separation of duties; modify on termination or change of employment; limit third-party access "in scope and in duration"; keep a register of access rights; log access rights management; review at planned intervals and document the changes.
• 11.3 Privileged accounts: strong identification and authentication "such as multi-factor authentication"; dedicated accounts used only for administration; individualised admin privileges; admin accounts used only to connect to administration systems; documented periodic review.
• 11.4 Administration systems: used only for administration, logically separated, protected by authentication and encryption.
• 11.5 Identification: unique identities for systems and users, each user identity linked to a single person, shared identities only with explicit approval and documentation, and deactivation "without delay" when no longer needed.
• 11.6 Authentication: strength matched to asset classification, lockout after failed attempts, inactive session termination, separate credentials for privileged access.
• 11.7 MFA: multiple factors or continuous authentication "where appropriate, in accordance with the classification of the asset".

Section 3.2.3 lists what logs should include, among them user creation, modification and deletion, permission extensions, authentication events, and all privileged access. Article 3(1)(e) treats a successful, suspectedly malicious unauthorised access capable of causing severe operational disruption as a significant incident, which makes identity compromise a direct reporting trigger. Article 2(2) requires entities to document their reasoning wherever they decide a "where appropriate" requirement does not apply.

Decision table: where MFA strength goes first

One owner decision: section 11.6.2(c) requires credential changes "at predefined intervals". NIST SP 800-63B-4 (section 3.1.1.2) says verifiers "SHALL NOT require subscribers to change passwords periodically", so document an interval that fits your risk model, such as long intervals for passwordless or MFA-backed accounts, rather than ignoring the clause.

Evidence an auditor will ask for

NIS2 attaches management accountability, which changes what "we have MFA" needs to mean. Be able to produce:

• MFA coverage as a number, with the exemption list, why each exemption exists, and when it was last reviewed. An unreviewed exemption list is the finding.
• Privileged access records: who holds standing elevated rights, session recordings for OT and IT administration, and the approval trail for elevation.
• Access review output showing revocations, not just completion. See access certification.
• A register of access rights and the log of changes to it (11.2.2(e)-(f)).
• Third-party access inventory with time-bounded grants and an owner per vendor.
• Shared account approvals for every identity used by more than one person (11.5.3). See shared account.
• Detection coverage mapped to the 24-hour early warning, which is unachievable if nobody sees the identity attack.

The OT gap

The sectors NIS2 covers include energy, manufacturing, transport, and water, where the hard problem is not the corporate directory but operational technology: shared operator accounts, engineering workstations with local credentials, and vendor remote access into plant systems.

Those environments frequently cannot take an agent, which is why inline authentication controls that extend MFA to protocols agents cannot reach, such as Silverfort, matter more here than in a pure IT estate. Vendor and contractor remote access is the specific supply-chain exposure the directive names, and it is usually the least governed path in the organization.

Failure modes NIS2 controls are meant to stop

• Remote access without MFA. Colonial Pipeline was entered through a legacy VPN profile with single-factor authentication, Change Healthcare through a Citrix portal without MFA, and Medibank through contractor credentials on a VPN that did not require MFA.
• Dormant accounts never deactivated. The Colonial profile was believed to be out of use, which is exactly what 11.5.4 targets. Technique: orphaned account abuse.
• Supplier credentials as the way in. At the US Treasury a remote support vendor's key was used to reach workstations, and stolen ConnectWise application credentials opened customer Microsoft 365 tenants. Technique: static API key abuse.
• Help desk resets. Attackers bypass MFA by talking support into re-enrolling it. Technique: help desk social engineering.

Where to start

1. Confirm your status. Check whether you are essential or important under your national law and whether 2024/2690 applies directly.
2. Inventory identities and access paths. Human, service, shared, and vendor accounts, with the remote paths into IT and OT. See non-human identities.
3. Close remote and admin MFA gaps first. Every exception gets a documented reason (Article 2(2) of the regulation).
4. Move privileged access into PAM with dedicated admin accounts and recorded vendor sessions. Compare options in how to choose a PAM solution.
5. Automate joiner-mover-leaver through IGA, with reviews that produce revocations. See joiner-mover-leaver.
6. Log identity events listed in 3.2.3 and route them to ITDR detection.
7. Rehearse the 24-hour clock with an admin account compromise scenario.
8. Report upward. Give the management body MFA coverage, standing privilege counts, and open exceptions each quarter.

Related

Energy & utilities and manufacturing verticals. Guides: identity controls for DORA, identity controls for ISO 27001, zero standing privileges rollout. Vendors: PAM, ITDR, IGA, MFA.