NIS2 makes access governance a board-level accountability issue

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Wallix's blog post: NIS2 pushes access governance from an operational control into a board-accountable resilience issue, especially where excessive privileges and shared accounts persist.

Why it matters: IAM and PAM teams need to treat access governance as evidence of oversight, traceability, and resilience, not just as a compliance activity.

Context

NIS2 changes the governance problem, not just the control set. The interview frames cybersecurity as a business risk that senior management and boards must actively oversee, which means access governance now carries accountability weight well beyond the IAM team.

In practical terms, the issue is not whether organisations have identity tooling. The issue is whether they can prove who had access, under what conditions, and whether that access matched responsibility, especially in fragmented environments with legacy systems and shared administrative accounts.

Key questions

Q: What breaks when shared admin accounts are still used under NIS2?

A: Shared admin accounts break accountability because multiple people can act through the same credential, making it difficult to prove who did what. Under NIS2, that weakens both governance oversight and incident investigation. PAM and auditable access paths can restore traceability, but the underlying issue is a lack of named ownership.

Q: Why does NIS2 make third-party access a governance issue?

A: Because NIS2 expects organisations to control risk across their supply chain, not just inside the enterprise boundary. If vendors, MSPs, or cloud partners retain unnecessary access, the organisation still owns the accountability. Third-party lifecycle management, entitlement scope, and revocation discipline become part of compliance.

Q: How can organisations improve traceability when legacy systems do not support modern access models?

A: They can place those systems behind privileged access management, stronger authentication, and auditable access paths. That does not modernise the application, but it does create a defensible trail for oversight and investigation. The goal is to reduce ambiguity even when the underlying system cannot be redesigned immediately.

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.

Technical breakdown

Why access governance becomes the control plane under NIS2

Access governance is the layer that determines who can reach which systems, under what conditions, and with what accountability. In the interview’s framing, that matters because privileged access is where business risk becomes operationally visible: excessive rights, generic admin access, and unmanaged third-party access erode both prevention and traceability. For regulated organisations, the control is no longer just an IAM hygiene issue. It becomes the mechanism that connects executive oversight, operational enforcement, and post-incident evidence.

Practical implication: map access governance to board-reportable risk indicators, not just technical administration tasks.

Shared accounts and legacy systems keep accountability incomplete

Shared administrative accounts often persist because older applications do not support modern role-based access control or named identities. That is a governance failure as much as a technical one, because accountability becomes ambiguous when multiple people use the same credential. The interview notes that where redesign is not possible, privileged access management and stronger authentication can at least restore traceability around who used the access and when. In NIS2 terms, visibility is not optional metadata; it is part of resilience.

Practical implication: isolate legacy shared access behind audited privileged access workflows until application redesign is possible.

Traceability is the bridge between prevention and investigation

NIS2 pressure is not limited to stopping access misuse. Organisations also need durable evidence after an incident, including who accessed which systems, when access occurred, and what actions were taken. That means logging, auditability, and access path clarity are governance controls, not afterthoughts. Without that evidence chain, organisations cannot answer the board-level question NIS2 creates: not only whether a control existed, but whether it actually supported accountability and incident reconstruction.

Practical implication: retain auditable access records that support both operational review and post-incident analysis.

Threat narrative

Attacker objective: The objective is to exploit governance gaps in access control to move with too much privilege and leave too little traceability behind.

1. Entry occurs through excessive privileges, shared accounts, or poorly governed third-party access that gives more reach than responsibility warrants.
2. Escalation follows when the same access is reused across systems without clear ownership, making it difficult to contain or attribute actions.
3. Impact is not only misuse of systems but also weak investigation, because organisations cannot reliably reconstruct who accessed what and under which authority.

Breaches seen in the wild

• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

NIS2 turns access governance into a board accountability problem, not an IAM housekeeping task. The interview is clear that cybersecurity is now treated as business risk, which means the board must understand access posture as part of resilience oversight. That shift changes the status of privilege management, traceability, and third-party access from operational concerns to governance evidence. Practitioners should expect access decisions to be reviewed through accountability, not just technical correctness.

Shared administrative access is a symptom of governance debt, not just legacy technology. When older systems cannot support named accounts or modern role models, organisations drift into shared credentials and excessive privilege because operations are easier that way. The governance problem is that convenience substitutes for attribution. The implication is that PAM becomes a compensating accountability layer where identity redesign is not immediately possible.

Visibility after the incident is part of the control, not a separate forensic activity. NIS2 makes it necessary to prove who accessed which systems, when, and what actions were performed. That requirement elevates auditability from logging mechanics to resilience assurance. Organisations that cannot reconstruct access paths will struggle to demonstrate that access governance is working as intended.

Third-party access now sits in the same accountability frame as internal privileged access. The interview treats unmanaged vendor access, standing external privileges, and generic remote accounts as unacceptable because they obscure responsibility and raise residual risk. That is a useful signal for the market: NIS2 is narrowing the tolerance for access arrangements that cannot be clearly owned, time-bound, and traced.

What this signals

Accountability now reaches into access design itself. NIS2 effectively forces organisations to ask whether their access model can survive board scrutiny, incident review, and regulator questioning at the same time. That is a stronger test than compliance checklists, because it measures whether privilege assignments, ownership, and audit trails line up in practice.

Legacy convenience is no longer a neutral design choice. Shared accounts, inherited permissions, and unmanaged external access create governance debt that becomes visible only when something goes wrong. Practitioners should expect greater pressure to document exceptions, justify compensating controls, and retire access patterns that cannot support attribution.

For practitioners

• Treat access governance as a board risk metric Build reporting that shows privilege concentration, shared account usage, third-party access scope, and traceability gaps in language leadership can act on.
• Replace shared admin credentials with named accountability Move older systems toward named individual accounts wherever the application allows it, and document exceptions where it does not.
• Wrap legacy access in PAM controls Use privileged access management to add approval, session oversight, and audit trails around unavoidable shared or elevated access paths.
• Make third-party access time-bound and traceable Remove standing vendor privileges, avoid generic remote accounts, and require monitored access paths that preserve attribution for every session.

Key takeaways

• NIS2 pushes access governance into the centre of resilience because boards are now accountable for how privilege is granted, used, and reviewed.
• Shared accounts and excessive privileges are not only technical weaknesses, they are governance gaps that make accountability difficult to prove.
• The control outcome that matters most is traceability, because organisations must be able to reconstruct who accessed what and under what authority.

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.
• Privilege Access Management: Privilege Access Management is the discipline of controlling and monitoring elevated access to critical systems and data. It governs how privileged accounts, credentials, sessions, and commands are issued, used, recorded, and revoked, so administrative power is limited, traceable, and aligned to policy, risk, and operational need.
• Identity Traceability: Identity traceability is the ability to link each action back to a specific identity, authorisation path, and time window. It is essential when humans, service accounts, and AI agents all operate in the same environment and auditors need a defensible record.
• Shared Admin Account: A shared admin account is a privileged database identity used by more than one person or system, usually for convenience. It breaks attribution, complicates audits, and creates a standing access path that is difficult to govern cleanly. In practice, it turns accountability into a guess rather than a record.

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.