NIS2 compliance in the public sector: identity and process gaps

At a glance

What this is: This is an Efecte analysis of NIS2 compliance for public-sector organisations, showing that workflow automation, incident handling, and access controls are central to meeting the directive’s demands.

Why it matters: It matters because public-sector IAM, IGA, and service-management teams must show that access, reporting, and supplier oversight are operationally controlled, not just documented.

By the numbers:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
• Only 5.7% of organisations have full visibility into their service accounts.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Efecte's analysis of NIS2 compliance for public-sector organisations

Context

NIS2 compliance in the public sector is less about a single control and more about whether organisations can prove that risk management, incident reporting, resilience, and supplier oversight work under pressure. For public authorities, the gap is often not intent but operating model: legacy systems, limited budgets, and thin security teams make evidence-driven governance difficult.

The identity dimension is easy to miss. If access rights, service accounts, third-party connections, and workflow permissions are not centrally governed, the organisation may satisfy policy language while still failing operational control. That is why NHI governance, IAM, and service management need to be treated as one compliance chain rather than separate programmes.

Key questions

Q: How should public-sector teams align NIS2 compliance with IAM and service management?

A: Public-sector teams should treat NIS2 as an evidence problem, not just a policy problem. That means binding incident reporting, supplier oversight, and privileged access to governed workflows with clear ownership, timestamps, and offboarding triggers. If access paths and service tickets are disconnected, the organisation will struggle to prove control when it matters.

Q: Why do third-party accounts create NIS2 compliance risk?

A: Third-party accounts create risk because supplier access often outlives the contract, the project, or the operational need. Under NIS2, that is a governance failure, not a minor administration issue. Teams need lifecycle controls for delegation, review, and revocation so external access does not become permanent by accident.

Q: What breaks when incident workflows are not identity-aware?

A: When incident workflows are not identity-aware, organisations lose the ability to prove who approved access, who changed a record, and who escalated the event. That weakens both response quality and compliance evidence. The result is slower containment, incomplete documentation, and a higher chance of audit findings.

Q: Who is accountable when a NIS2 supplier or access failure occurs?

A: Accountability should sit with the service owner and the control owner, not just the help desk or security team. NIS2 compliance fails when responsibility is spread across teams but no one owns access revocation, supplier review, or incident evidence. Clear ownership is what turns process into control.

Technical breakdown

Why NIS2 compliance depends on identity and workflow governance

NIS2 is not just a reporting obligation. It requires organisations to show that risk management, incident handling, and supplier control are operationally effective, which means the identity layer matters as much as the security tooling layer. In public-sector environments, access paths often span human accounts, service accounts, and vendor-integrated workflows, so a weakness in one layer can undermine the whole control chain. Role-based access control helps, but only if roles are reviewed, exceptions are tracked, and privileged access is time-bounded.

Practical implication: map NIS2 control evidence to the identities and workflows that actually execute critical services.

How service-management automation supports incident reporting and resilience

ITSM and ESM platforms can reduce manual friction by routing incidents, capturing timestamps, preserving case history, and enforcing approval steps. That matters because NIS2 expects timely notification and traceable handling, not informal email chains. The technical value comes from standardised workflow state, not from the platform name itself. If a ticketing process cannot show who saw what, when, and under which authority, it weakens both response quality and auditability.

Practical implication: make incident workflows produce evidence automatically, including timestamps, ownership, and escalation history.

Why third-party access becomes a compliance problem under NIS2

NIS2 explicitly raises the bar on supply-chain security, which means third-party access can no longer sit outside core governance. Vendor integrations, contractor accounts, and delegated service access all create control obligations around offboarding, certification, and least privilege. In practice, the risk grows when access is persistent, undocumented, or disconnected from contract lifecycle events. That is a classic identity governance failure, not just a procurement issue.

Practical implication: tie third-party access reviews to contract renewal, offboarding, and service-owner accountability.

Threat narrative

Attacker objective: The attacker or negligent insider seeks to exploit governance gaps that let access persist without effective oversight, increasing the chance of data exposure or disruptive service failure.

1. Entry occurs through weakly governed third-party access or legacy administrative paths that remain active longer than the business relationship requires.
2. Escalation follows when standing privileges, undocumented exceptions, or over-broad workflow rights allow access to sensitive systems or incident records.
3. Impact is delayed detection, incomplete reporting, and weaker resilience because the organisation cannot prove who accessed what or when.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

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 compliance is an identity governance problem as much as a cyber compliance problem. The article frames NIS2 through process optimisation, but the underlying issue is whether public-sector organisations can control who and what is allowed to act on critical systems. That includes human users, service accounts, and third-party access chains. If those identities are not governed coherently, compliance becomes a reporting exercise rather than an operational state.

Public-sector resilience fails when access and incident workflows are treated as separate systems. NIS2 demands timely notification, traceability, and risk management, but those outcomes depend on identity-linked workflow evidence. If incident handling, approvals, and access rights live in disconnected tools, the organisation can lose the audit trail before it loses the incident. Practitioners should treat this as a governance design flaw, not a tooling gap.

Third-party access without lifecycle offboarding: NIS2 elevates supplier oversight, yet many public organisations still leave delegated access in place after a vendor relationship changes. That assumption was designed for stable, predictable service relationships. It fails when external access outlives the contract, the ticket, or the operational need, and the implication is that accountability no longer matches access.

Standing privilege remains the silent NIS2 compliance risk in public services. When roles and admin rights are persistent, the organisation may pass policy checks while still accumulating hidden exposure. This is especially problematic in shared municipal, healthcare, and education environments where staffing constraints encourage exceptions. The practical conclusion is that compliance evidence must include privilege scope, not just policy existence.

Service-management platforms only help when they encode governance, not just workflow speed. Automation can shorten response time, but it does not correct weak access design, poor offboarding discipline, or missing supplier attestations. NIS2 programmes that stop at workflow acceleration will still struggle to prove resilience under audit. The field needs more attention on identity-backed evidence than on process volume.

From our research:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs , Key Challenges and Risks.
• 68% of organisations do not know how to fully address NHI risks, according to the Ultimate Guide to NHIs , Key Challenges and Risks.
• For the lifecycle angle, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the next resource because NIS2 compliance depends on provisioning, review, and offboarding discipline.

What this signals

Third-party access is the hidden compliance multiplier in public-sector NIS2 programmes. With 92% of organisations exposing NHIs to third parties, the governance problem is not isolated to vendors or contractors. It becomes a control-chain issue across procurement, identity review, and incident response, so programmes need a single view of access ownership and revocation.

NIS2 pushes public-sector teams toward evidence-first identity governance. The practical shift is to make every access grant, exception, and incident action produce a usable audit trail. Where the organisation still relies on manual coordination, the control may exist on paper but not in a form that can survive inspection or crisis.

Public-sector teams should expect supplier oversight, access certification, and incident documentation to converge into one operating model. That is where identity and service management stop being separate disciplines and become the same compliance mechanism.

For practitioners

• Map NIS2 obligations to identity-controlled workflows Link incident reporting, supplier oversight, and access governance to the systems that actually execute those controls. Include human administrators, service accounts, and third-party delegated access in the same evidence chain.
• Review third-party access against contract lifecycle events Align vendor access reviews, offboarding, and privilege revocation with contract changes, service closure, and renewal points. Do not let supplier access persist because the ticketing process is incomplete.
• Prove incident traceability through workflow records Require every incident path to capture timestamps, approvals, ownership, and escalation state so you can demonstrate who acted and when during audit or investigation.
• Reduce standing privilege in public-sector operations Minimise persistent administrator rights across service desks, infrastructure teams, and external support channels. Revalidate exceptions regularly and separate routine service actions from high-risk access.

Key takeaways

• NIS2 compliance in the public sector depends on governed identity and workflow evidence, not just policy language.
• Third-party access, standing privilege, and disconnected incident handling are the control gaps most likely to undermine auditability.
• Teams that tie access review, offboarding, and reporting to operational workflows will find NIS2 easier to prove and sustain.

Key terms

• NIS2 Compliance Evidence: NIS2 compliance evidence is the operational record that proves controls are working, not just written down. It usually includes access logs, incident timestamps, approval history, supplier reviews, and revocation records that show governance was executed consistently across the organisation.
• Third-Party Access Lifecycle: Third-party access lifecycle is the end-to-end control of external user or service access from approval through review to removal. In public-sector environments, it is critical because supplier relationships change, but their access often lingers unless lifecycle events are tied to contracts and service ownership.
• Standing Privilege: Standing privilege is persistent elevated access that remains available without just-in-time approval. It increases risk because it broadens the window for misuse and makes compliance evidence weaker unless organisations can prove why the privilege exists, who owns it, and when it will be removed.

What's in the full article

Efecte's full article covers the operational detail this post intentionally leaves for the source:

• How Matrix42 is positioned for public-sector ITSM and ESM workflows in NIS2 programmes
• Examples of automated incident categorisation and reporting workflows for regulated environments
• The article's public-sector use cases for municipal services, healthcare, and supplier management
• The specific efficiency claims Efecte uses to describe process optimisation in compliance operations

👉 Efecte's full article covers the workflow, incident, and supplier-management examples behind the compliance argument.

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.