NIS2 compliance is now an identity governance problem

At a glance

What this is: This is a compliance guide on NIS2 that reframes the directive as an identity and access governance problem with organisational accountability at its core.

Why it matters: It matters because IAM practitioners must align human access, NHI controls, and governance evidence to meet resilience and reporting expectations under one regulatory lens.

By the numbers:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

👉 Read Netwrix's NIS2 compliance guide for scope, penalties, and obligations

Context

NIS2 compliance is fundamentally about proving that access, resilience, and accountability are managed in a way regulators can test. For identity teams, that means the directive is not only a security or legal issue, but an operating model issue for how humans, service accounts, and third-party access are governed across the enterprise.

The compliance gap appears when organisations treat NIS2 as a policy exercise instead of a control evidence problem. If access reviews, privileged access, incident reporting, and supplier oversight are fragmented, the organisation may meet the language of compliance without being able to demonstrate the control chain behind it.

Key questions

Q: How should organisations prepare identity controls for NIS2 compliance?

A: Start by mapping critical services, privileged users, service accounts, and supplier access to a single control owner and review cadence. Then make sure each entitlement has evidence for approval, use, and revocation. NIS2 is easier to defend when access records are complete enough to support incident reporting and audit requests without manual reconstruction.

Q: Why do non-human identities matter under NIS2?

A: Because NIS2 covers supply chain security, incident response, and operational resilience, and NHIs are often the access path to critical systems. If service accounts, tokens, and API keys are not governed with the same discipline as human access, organisations can lose control of third-party exposure and fail to produce reliable evidence during an incident.

Q: What do teams get wrong about NIS2 and access reviews?

A: They often treat access reviews as a documentation task instead of a control that must prove scope, ownership, and remediation. Under NIS2, a review that cannot show who approved access, what changed, and when privileges were removed is weak evidence. The review must be tied to real access reduction, not just completed on schedule.

Q: Who is accountable when supplier access contributes to a NIS2 incident?

A: Accountability sits with the organisation that owns the service, because NIS2 expects supplier risk to be governed inside operational resilience processes. In practice, that means business owners, identity teams, and security leadership must share responsibility for access issuance, review, and revocation, especially when third-party credentials touch critical systems.

Technical breakdown

NIS2 compliance and access control evidence

NIS2 pushes organisations to show that access is controlled, reviewed, and tied to operational responsibility. In practice, that means the identity layer must prove who can access critical systems, how privileges are approved, and how exceptions are tracked. For service accounts and API credentials, the evidence must extend beyond human workflows into machine identity governance, because regulators and auditors will care about the ability to restrict high-risk access, not just document a policy.

Practical implication: map NIS2 evidence requests to access certification, privileged access, and NHI entitlement records before audit season begins.

Third-party access and supply chain identity risk

NIS2 places supply chain security in scope, which changes how organisations think about external access. Third-party identities, delegated credentials, and vendor-issued service accounts can no longer sit outside the same governance model used for internal users. The technical issue is not simply trust, but scope and lifecycle control: who issued the credential, where it is used, when it expires, and whether revocation is provable. That is a governance question with identity mechanics behind it.

Practical implication: include vendor identities, API keys, and service accounts in supplier assurance and offboarding workflows.

Incident reporting and identity telemetry

The reporting burden under NIS2 depends on whether the organisation can reconstruct what happened quickly enough to classify and report the event. That requires identity telemetry across authentication, privileged activity, and secret use, not just perimeter alerts. If access events cannot be correlated across human and non-human actors, the response team will struggle to prove impact, scope, and timing. Identity evidence becomes part of incident management, not a separate audit artifact.

Practical implication: ensure logs from IAM, PAM, secret stores, and workload identities are centralised and searchable for incident triage.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

NIS2 turns identity governance into a compliance boundary, not a back-office control. The directive is often discussed as a cybersecurity mandate, but its operational test is whether access can be governed, evidenced, and recovered across business-critical systems. That pulls IAM, PAM, supplier access, and machine identity controls into the same control plane. Practitioners should treat identity evidence as part of resilience, not a separate audit exercise.

Supply chain risk under NIS2 is partly an NHI governance problem. Third-party users are only one part of the exposure. Service accounts, API keys, and delegated credentials issued to suppliers can outlive the business relationship, creating access that is technically valid but operationally unjustified. The governance failure is not just weak review cadence, but missing lifecycle ownership for non-human credentials. Practitioners should align supplier assurance with credential lifecycle control.

Identity telemetry is what makes NIS2 reporting defensible. You cannot report, scope, or recover effectively if authentication and privileged activity are fragmented across separate tools with no shared record. NIS2 pressure will expose organisations that can describe policies but cannot reconstruct access paths. The practical conclusion is that identity logs are evidence, not just monitoring data.

Regulatory convergence is forcing teams to stop managing NIS2, DORA, and access control as separate projects. The same identity controls now support resilience, third-party oversight, and incident evidence across multiple regimes. That convergence simplifies the control architecture but raises the bar for governance discipline. Practitioners should build one evidence model that serves audit, operations, and incident response together.

Identity evidence debt: NIS2 exposes organisations that have access controls on paper but cannot prove who had access, when, and why. The issue is not lack of policy, but lack of defensible records across humans and NHIs. Practitioners should close the gap between entitlement, approval, and traceable use.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• From our research: Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For a broader control lens, NIST Cybersecurity Framework 2.0 helps teams connect identity evidence to governance, detect, respond, and recover outcomes.

What this signals

Identity evidence debt: NIS2 will expose programmes that can name controls but cannot produce traceable access records across users, service accounts, and suppliers. That gap matters because regulatory readiness now depends on proving entitlement, use, and revocation with the same evidence chain, not separate artifacts for audit and operations.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, NIS2 readiness is also a secrets governance problem. Teams should expect audit questions to reach beyond human IAM into the operational lifetime of machine credentials.

Practitioners should prepare for convergence between NIS2, supplier assurance, and identity logging by aligning controls to NIST Cybersecurity Framework 2.0. The organisations that can join identity telemetry to governance ownership will be better placed to answer auditors and incident responders with the same record set.

For practitioners

• Map NIS2 scope to identity controls Inventory critical systems, privileged users, service accounts, API keys, and supplier-issued credentials, then tie each to an owner and review cadence.
• Extend supplier assurance into NHI lifecycle controls Require offboarding, expiry, and revocation evidence for third-party service accounts and shared secrets, not just contractual attestations.
• Centralise identity evidence for incident reporting Aggregate IAM, PAM, and workload identity logs so the response team can reconstruct access paths, privilege use, and credential activity quickly.
• Align access reviews with regulatory proof points Make recertification outputs usable for NIS2 audits by linking approvals, exceptions, and remediation outcomes to named systems and identities.

Key takeaways

• NIS2 is not only a security directive, it is a governance test for whether identity controls can be evidenced across critical systems and suppliers.
• Third-party access and non-human identities materially increase NIS2 exposure because they often lack the lifecycle discipline required for defensible oversight.
• Teams that centralise identity telemetry, supplier offboarding, and access review evidence will be better positioned to satisfy both audit and incident-reporting demands.

Key terms

• Non-Human Identity: A non-human identity is any credentialed entity used by software, infrastructure, or automation rather than a person. It includes service accounts, API keys, tokens, certificates, and workload identities. In governance terms, it needs ownership, lifecycle control, and evidence just like human access.
• Identity Evidence: Identity evidence is the record set that proves who had access, why access existed, and what happened during use. For NIS2, evidence must be strong enough to support audit, incident reporting, and accountability across both human and non-human identities.
• Supplier Access Lifecycle: Supplier access lifecycle is the end-to-end handling of third-party credentials from issuance to revocation. It covers approval, expiry, monitoring, offboarding, and proof of removal. Weak lifecycle control is a common reason supplier access persists after the business need has ended.
• Access Certification: Access certification is the process of reviewing and affirming whether access should continue. For regulated environments, it must be tied to actual entitlement ownership, remediation, and revocation. A completed review without change to unnecessary access is documentation, not governance.

Deepen your knowledge

NIS2 compliance and access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building evidence-ready controls for service accounts and supplier access, it is worth exploring.

This post draws on content published by Netwrix: NIS2 compliance: what it means, who's affected, and how to comply. Read the original.