NIS2 makes access governance a board-level accountability issue

At a glance

What this is: This interview argues that NIS2 turns access governance into a board-level resilience control, with accountability, traceability, and privileged access now central to compliance.

Why it matters: It matters because IAM, PAM, and NHI programmes will be judged on whether they can prove who accessed what, when, and under whose authority across internal and third-party access.

👉 Read Wallix's interview on NIS2 and the new accountability model for access governance

Context

NIS2 changes access governance from an operational control into an accountability model. The article’s core point is that cybersecurity is now treated as a business risk issue, which means senior leadership, boards, and CISOs all need visibility into who has access, under what conditions, and how that access is governed.

That matters for IAM, PAM, and NHI programmes because the same governance failures keep recurring across human users, shared administrative accounts, and third-party access. Where modern role models cannot be applied, the control gap is usually traced back to legacy systems, shared credentials, or weak auditability rather than a lack of policy language.

Key questions

Q: How should organisations govern privileged access under NIS2?

A: They should treat privileged access as a resilience and accountability control, not just a technical permission set. That means naming owners, enforcing approvals, time-bounding access, and preserving logs that let investigators reconstruct who did what, when, and under whose authority. If those elements are missing, compliance evidence will be weak and incident response will be slow.

Q: Why do shared administrative accounts create NIS2 risk?

A: Shared accounts weaken attribution, which makes it hard to prove accountability or investigate misuse. They often exist because legacy applications cannot support named identities, but that operational convenience becomes a governance failure when access decisions cannot be traced to an individual. PAM can reduce the exposure, but not erase the accountability gap.

Q: What breaks when third-party access is not time-bound and traceable?

A: The organisation loses control over offboarding, incident reconstruction, and privilege review. Vendors can retain standing access longer than the business need, and security teams may not be able to prove who accessed what or when. That undermines both NIS2 resilience expectations and practical forensic response.

Q: Who is accountable for NIS2 access decisions and incident reporting?

A: Top-level management remains accountable for risk governance, but identity, data, and security teams must supply the evidence and control operations that make accountability real. Practically, that means clear ownership for access policy, review outcomes, incident scope, and reporting artefacts. Without named stewardship, the organisation cannot demonstrate control.

Technical breakdown

Why NIS2 turns access governance into accountability

NIS2 does not change the mechanics of identity control so much as it changes who must answer for failures. Access governance becomes the evidence layer for resilience because leadership must be able to explain privilege decisions, review exceptions, and demonstrate oversight. In practice, that pulls IAM, PAM, and audit logging into the same control conversation, especially where business operations depend on legacy systems or shared accounts.

Practical implication: boards should demand access reporting that links privilege, approvals, and traceability to named accountability owners.

Shared administrative accounts and legacy access models

Shared administrative accounts persist when older applications cannot support named identities, role-based access control, or modern authentication patterns. That creates an accountability gap because the system can record activity, but not always the individual behind it. PAM can partially restore traceability by brokering access, recording sessions, and time-bounding privileged use, but it does not remove the underlying legacy constraint.

Practical implication: teams should map where shared access is a system limitation versus a governance choice, then prioritise the highest-risk exceptions.

Third-party access as a privileged access problem

Under NIS2, third-party access should be treated with the same discipline as internal privileged access because suppliers often create the same blast radius with less visibility. The important technical point is not whether the user is internal or external, but whether access is time-bound, monitored, and attributable. Unmanaged remote accounts and standing vendor privileges defeat that model by making investigation and recertification much harder.

Practical implication: security teams need the same controls for external access as for privileged internal access, including session logging and expiry.

Threat narrative

Attacker objective: The objective is to use privileged or poorly governed access to expand control while avoiding reliable attribution and oversight.

1. Entry occurs through legacy systems, shared accounts, or third-party access paths that bypass modern identity controls and make attribution difficult.
2. Escalation follows when excessive privileges or unmanaged administrative access allow operators or vendors to reach systems beyond their responsibility.
3. Impact appears in weakened resilience, poor post-incident traceability, and higher likelihood that an attack or misuse cannot be conclusively investigated.

Breaches seen in the wild

• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

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

NHI Mgmt Group analysis

Access governance becomes a resilience control, not just an IAM hygiene task. NIS2 pushes accountability up the organisation, so privilege decisions now need to survive executive scrutiny and audit review. That changes the measure of maturity from policy existence to proof of oversight, traceability, and exception handling. The practitioner conclusion is simple: if you cannot evidence access decisions, you do not control them.

Shared accounts are an accountability failure, not merely an operational compromise. They persist because legacy systems block named identity models, but the security consequence is the same: activity cannot be cleanly tied back to a person or delegated authority. PAM can contain the problem, yet the underlying governance gap remains visible whenever recertification and incident response depend on attribution. The practitioner conclusion is to treat shared access as a controlled exception, not a stable operating model.

Third-party access should be governed as privileged access with external blast radius. NIS2 does not distinguish between internal and external risk when a vendor can reach critical systems. Standing vendor privileges, generic remote accounts, and unmanaged offboarding create an audit and resilience problem at the same time. The practitioner conclusion is to align supplier access with the same lifecycle discipline used for internal privileged users.

Identity accountability is the new audit language for operational resilience. Boards do not need more technical detail, they need evidence that access can be explained, bounded, and reversed. That is where access governance, PAM, and lifecycle review intersect across human, third-party, and non-human accounts. The practitioner conclusion is that resilience programmes now depend on identity evidence, not just security policy.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• That confidence gap matters because unmanaged access often persists longer in machine and service identities than in human workflows, which expands audit and incident-response risk.
• For a broader baseline on lifecycle and governance failure modes, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

NIS2-style accountability will push more organisations to prove, not merely state, that access is governed. The programme risk is that IAM reporting built for admin convenience will not satisfy board-level scrutiny once exceptions, shared accounts, and third-party access are audited against resilience expectations.

Identity accountability gap: this is the pattern where access exists without a clean answer to who approved it, who used it, and who is responsible for revoking it. That gap will force security leaders to align PAM, supplier access, and access review evidence with the same operational discipline, and the pressure will extend beyond human users to service and vendor identities.

The broader signal is that access governance is becoming the common language for human IAM, NHI controls, and third-party risk. Teams that can already trace entitlement, session, and offboarding evidence will have a much easier path to demonstrating resilience under NIS2 and similar regimes.

For practitioners

• Map accountability to every privileged access path Create an inventory of who can reach critical systems, how access is granted, and which approvals or logs prove that access was legitimate. Include shared accounts, vendor connections, and break-glass access in the same register.
• Convert shared administrative access into named or brokered access Replace shared credentials where systems allow it, and where they do not, place privileged access behind session brokering, recording, and time limits so activity can be attributed during review or incident response.
• Apply the same controls to third-party access as to internal privilege Require time-bound access, auditable sessions, and offboarding checks for suppliers and integrators. Do not allow unmanaged remote accounts or standing vendor privileges to persist beyond the business need.
• Test whether leadership can explain access decisions under scrutiny Run board-facing exercises that ask which teams approved access, why exceptions existed, and how investigators would reconstruct actions after an incident. If the answer depends on informal knowledge, the governance model is too weak.

Key takeaways

• NIS2 recasts access governance as a board-accountable resilience control, not a narrow IAM task.
• Shared accounts and unmanaged third-party access weaken attribution, which is the core failure mode this article exposes.
• The control that changes the outcome is auditable, time-bound, named access with clear ownership and offboarding evidence.

Key terms

• Access Governance: Access governance is the policy and workflow layer that manages how access is requested, approved, certified, and revoked. In SaaS environments it helps standardise control across many applications, reducing inconsistency between teams. It is most effective when it covers both human accounts and non-human identities.
• PAM — Privileged Access Management: Solutions that control, monitor, and audit privileged access for both human and non-human identities. Traditional PAM tools are being extended to cover machine identities, service accounts, and agentic AI workloads.
• Third-Party Access: Third-party access is access granted to vendors, contractors, or support partners who are not direct employees of the organisation. It is higher risk than internal access because accountability, device assurance, and access duration are harder to control, so it usually requires tighter time limits and stronger auditability.
• 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

Wallix's full interview covers the operational detail this post intentionally leaves for the source:

• How access governance maps to NIS2 accountability expectations for leadership and boards
• The practical limits of legacy applications that force shared accounts and excessive privileges
• Where PAM, stronger authentication, and audit trails fit when systems cannot be redesigned
• How third-party access should be controlled, monitored, and traced under resilience-focused governance

👉 The full Wallix interview covers leadership accountability, shared accounts, and third-party access control under NIS2.

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 building or maturing an IAM programme, it is worth exploring.