TL;DR: NIS2 broadens cybersecurity obligations across EU sectors and adds clearer expectations for risk management, access control, supply chain security, incident reporting, and management accountability, according to Arcon. For IAM, PAM, and NHI teams, the practical shift is that privileged access governance is now a compliance issue, not just an operational control issue.
At a glance
What this is: NIS2 widens the EU cybersecurity scope and ties access control, reporting, and management accountability to resilience requirements.
Why it matters: It matters because IAM, PAM, and NHI programmes now have to prove they can support regulatory obligations across more entities, suppliers, and privileged access paths.
By the numbers:
- NIS2 includes a 24-hour early warning notification requirement for significant incidents.
- The NIS2 Directive can trigger penalties of up to 2% of global turnover for non-compliance.
👉 Read Arcon's analysis of NIS2 access control and compliance requirements
Context
NIS2 is the EU’s updated cybersecurity directive for organisations that support essential and important services. It widens the scope of covered entities and turns access control, incident handling, supply chain security, and business continuity into explicit governance obligations, which puts identity programmes directly in the compliance path.
For identity teams, the important change is not just stricter regulation. NIS2 makes privileged access, third-party access, MFA, logging, and account governance part of the evidence set that regulators and auditors will expect to see, especially where non-human identities support critical operations.
Key questions
Q: How should organisations prepare IAM for NIS2 compliance?
A: They should treat IAM as part of regulatory evidence production, not only authentication. That means documenting privileged access, enforcing multifactor authentication, reviewing supplier and service-account access, and ensuring logs can support incident reporting. The goal is to show continuous control over who can access regulated systems and why.
Q: Why does NIS2 make third-party access harder to ignore?
A: Because supplier and partner access can create the same operational risk as internal privilege, but with weaker oversight. NIS2 treats supply chain security as part of resilience, so organisations need offboarding, logging, and accountability for external identities. If a vendor account stays live after the relationship ends, the control failure is both security and governance related.
Q: What breaks when organisations rely on standing privilege for support and legacy access?
A: Standing privilege breaks because the access often outlives the task, the user, or the system state that justified it. In practice, that means compromised legacy or support identities can reach more systems than intended, and those permissions are hard to reason about during an incident. JIT access and tier isolation reduce that blast radius.
Q: Who is accountable when identity controls fail under NIS2?
A: Accountability sits with the organisation and its management structure, because NIS2 is built around governance, supervision, and demonstrable risk management. Operational teams may run the controls, but leadership remains responsible for ensuring the controls are defined, monitored, and evidenced well enough to withstand regulatory review.
Technical breakdown
How NIS2 turns access control into a governance requirement
NIS2 moves access control out of the purely technical domain and into corporate accountability. Organisations are expected to implement risk management measures across authentication, encryption, incident handling, and supply chain controls, with management oversight and approval. In practice, this means privileged access is no longer judged only by operational convenience or security design. It becomes part of the organisation’s demonstrable resilience posture, especially where access is used by suppliers, administrators, or machine identities supporting essential services.
Practical implication: align IAM, PAM, and NHI controls to named business owners and audit evidence, not only technical policy.
Why third-party access is central to NIS2 compliance
NIS2 explicitly elevates supply chain and third-party security because a covered entity cannot be resilient if its partners can introduce uncontrolled access paths. This matters for service accounts, vendor credentials, and API-based integrations that sit outside normal employee identity processes. Third-party access often bypasses human lifecycle controls, so offboarding, review, and logging must be treated as governance requirements rather than ad hoc operational tasks.
Practical implication: inventory every external identity path and tie it to supplier risk review, offboarding, and evidence capture.
Why just-in-time privilege and MFA matter under NIS2
The directive’s baseline measures include access control and authentication, which makes standing privilege harder to justify in high-risk environments. JIT access reduces the duration of elevated exposure, while MFA helps reduce credential abuse, but neither is sufficient on its own if account ownership, session logging, and approval workflows are weak. For machine and privileged non-human identities, these controls only work when they are linked to lifecycle governance and usable audit trails.
Practical implication: use JIT, MFA, and session recording together where elevated access supports essential services.
NHI Mgmt Group analysis
NIS2 turns access governance into regulatory evidence, not just security hygiene. The directive’s scope, reporting, and management accountability requirements mean IAM and PAM teams must produce proof, not assumptions. That changes the role of identity controls in the organisation: they now support regulatory defensibility for essential services and suppliers alike. Practitioners should treat access governance as part of the compliance control plane.
Third-party access without lifecycle offboarding is the core governance gap NIS2 exposes. The directive’s supply chain emphasis is a direct response to access that outlives the business relationship. When vendor accounts, API keys, or delegated privileged access remain active after a contract changes, accountability becomes impossible to demonstrate. Practitioners should map every external identity to an explicit owner and offboarding trigger.
Standing privilege is harder to defend under NIS2 than many teams assume. The directive pushes organisations toward risk-based access control, incident readiness, and documented oversight. That makes persistent elevated access especially difficult to justify where ephemeral or task-scoped access would reduce exposure and improve auditability. Practitioners should expect regulators and auditors to question long-lived privileged credentials in critical environments.
Identity governance for NIS2 must include non-human identities, not just employees. Service accounts, API keys, certificates, and automation identities can all sit inside regulated service chains, yet they are frequently managed outside human IAM processes. That gap matters because the directive’s resilience model depends on control over the full access surface, not only user logins. Practitioners should extend governance scope to machine identities and their lifecycle controls.
Supplier access becomes a board-level risk when management accountability is explicit. NIS2 requires leadership oversight of cybersecurity measures, which means identity control failures can no longer be treated as a narrow technical issue. Access reviews, privilege reporting, and incident notification timelines now have governance consequences. Practitioners should align identity reporting with the artefacts management needs to approve and defend.
From our research:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.
- NIS2 makes that governance gap more material because access control, supplier assurance, and incident reporting all become auditable obligations.
What this signals
Standing privilege will increasingly fail compliance scrutiny in EU-regulated environments. NIS2 does not just ask whether access is protected. It asks whether access is proportionate, reviewable, and defensible across human, supplier, and machine identities. That means IAM and PAM teams should expect more pressure to replace persistent elevation with task-scoped controls and stronger evidence chains, especially where critical services depend on non-human identities.
Third-party identity governance is now part of operational resilience. When external credentials are left active, the organisation inherits both access risk and reporting risk. Teams that already use the Lifecycle Processes for Managing NHIs as a governance model are better placed to prove offboarding discipline, but they still need to validate supplier inventory against live access.
Access review cadences need to move closer to change events than annual comfort cycles. NIS2’s accountability model rewards evidence that access is reviewed when the business relationship, privilege scope, or incident context changes. The practical signal is simple: if you cannot show a recent decision trail for privileged access, the control is not mature enough for regulated services.
For practitioners
- Map regulated access paths end to end Identify every privileged, supplier, and machine identity that supports essential or important services, then link each one to a named owner and a documented business function.
- Tighten offboarding for third-party identities Add contract change, supplier termination, and access review triggers for vendor accounts, API keys, and delegated admin paths so external access cannot persist by default.
- Reduce standing privilege in critical workflows Move admin and operational access toward just-in-time provisioning with session recording and approval logging, especially where the access path supports regulated services.
- Build evidence for incident reporting and audits Make sure authentication logs, access decisions, and privileged session records can be retrieved quickly enough to support the 24-hour early warning and follow-on reporting duties.
Key takeaways
- NIS2 makes access control, supplier governance, and reporting readiness inseparable from cybersecurity compliance.
- Persistent privileged access and weak third-party offboarding are the identity patterns most likely to create audit and resilience problems.
- IAM, PAM, and NHI teams should shift from policy statements to evidence-backed governance that management can defend.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while NIS2 and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIS2 | The article is explicitly about NIS2 compliance obligations and access control. | |
| NIST CSF 2.0 | PR.AC-4 | NIS2 access control and accountability align with access permission management. |
| NIST SP 800-53 Rev 5 | AC-6 | Least-privilege access is central to the article’s PAM and JIT guidance. |
| CIS Controls v8 | CIS-5 , Account Management | The article stresses account discovery, offboarding, and privileged account control. |
| ISO/IEC 27001:2022 | A.5.15 | The article repeatedly centres access control and governance evidence. |
Map identity controls to NIS2 requirements for access, reporting, supplier assurance, and management oversight.
Key terms
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- JIT — Just-in-Time Access: A security approach that grants access permissions only for the duration needed to complete a specific task, then automatically revokes them. JIT access eliminates standing privileges for NHIs, dramatically reducing attack surface.
- Third-Party Access Governance: Third-party access governance is the control set that tracks, approves, reviews, and revokes access granted to external vendors and partners. It becomes an identity problem when suppliers operate through shared credentials, delegated workflows, or persistent machine access that outlives the business need.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
What's in the full article
Arcon's full article covers the operational detail this post intentionally leaves for the source:
- The article breaks down the specific NIS2 requirements for risk management, reporting, and management accountability.
- It lists practical PAM capabilities such as JIT access, session monitoring, anomaly detection, and account discovery.
- It outlines how EU organisations can align access control and audit reporting with compliance obligations.
- It provides a vendor-specific view of how privileged access tooling is positioned against NIS2 requirements.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 17, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org