NIS2

The European Union’s updated cybersecurity directive for essential and important entities. It requires organisations to demonstrate stronger cyber resilience through risk management, incident reporting, supply chain oversight, and access control, with identity governance playing a central role in how those obligations are proven.

Expanded Definition

NIS2 is the European Union’s updated cybersecurity directive for essential and important entities, but in practice it is more than a legal update to NIS1. It formalises expectations for risk management, governance accountability, supply chain security, incident reporting, and access control. For NHI and IAM teams, the directive matters because service accounts, API keys, certificates, and automation credentials are often the mechanisms through which an organisation proves control over systems that regulators will scrutinise. The directive’s language is broad, so implementation details vary across sectors and member states, but the operational direction is clear: organisations must be able to evidence control, not just state policy intent. The NIS2 Directive – official EU legal text is the primary source for legal obligations, while Ultimate Guide to NHIs – Regulatory and Audit Perspectives shows how identity governance supports auditability. The most common misapplication is treating NIS2 as a compliance-only project, which occurs when teams focus on policy documents while leaving machine identities, privilege paths, and revocation processes ungoverned.

Examples and Use Cases

Implementing NIS2 rigorously often introduces reporting and control-evidence overhead, requiring organisations to weigh faster operational change against stronger provable governance.

• A healthcare provider maps system-to-system access so every service account has an owner, a business purpose, and a documented review cycle aligned to NHI regulatory and audit guidance.
• A financial entity uses EU NIS2 Directive obligations to drive incident reporting playbooks that include token rotation, key revocation, and forensic retention for automation identities.
• A manufacturing company inventories API keys in CI/CD pipelines and moves them into controlled secrets storage after ENISA threat reporting highlights machine-identity exposure as a recurring risk pattern.
• A managed service provider adds supplier access attestations so third-party tools cannot retain standing credentials after contract termination or scope changes.
• A public sector operator aligns access control evidence with asset criticality, showing that privileged machine access is reviewed on the same cadence as human administrative access.

Why It Matters in NHI Security

NIS2 matters because identity failures are often the hidden path by which regulatory, operational, and supply-chain risk becomes real. NHI Management Group research shows that only 5.7% of organisations have full visibility into their service accounts, and that visibility gap makes it difficult to prove control during an audit or incident review. When secrets are scattered across code, config files, and CI/CD tools, incident reporting and containment become slower and less defensible. NIS2 raises the bar by making governance, not just tooling, the measure of maturity, and that is especially important in environments where machines act with authority but no human prompts at execution time. The directive also reinforces the need to understand third-party exposure, because supplier relationships often extend machine access beyond what teams can easily monitor. Practitioners should read the broader context in the Ultimate Guide to NHIs – Regulatory and Audit Perspectives and compare threat trends with the ENISA Threat Landscape. Organisations typically encounter the full weight of NIS2 only after a breach, outage, or supplier compromise exposes weak identity governance, at which point machine access control becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• How should security teams prepare identity controls for NIS2 audit scrutiny?
• Why do privileged accounts create extra risk under NIS2?
• Who is accountable when identity controls fail under NIS2?
• How do Zero Trust and NIS2 fit together for OT resilience?