Because NIS2 covers supply chain security, incident response, and operational resilience, and NHIs are often the access path to critical systems. If service accounts, tokens, and API keys are not governed with the same discipline as human access, organisations can lose control of third-party exposure and fail to produce reliable evidence during an incident.
Why This Matters for Security Teams
NIS2 is not only about network controls and incident reporting. It also raises the bar for supply chain security, access governance, and operational resilience, all of which depend on how service accounts, API keys, certificates, and tokens are managed. When those non-human identities are over-privileged, left unrotated, or shared across vendors, they become the easiest path into critical services and the hardest evidence source to reconstruct during an incident.
The NIS2 Directive - official EU legal text expects organisations to reduce operational risk, not merely document it after the fact. NHIMG’s Ultimate Guide to NHIs reports that 92% of organisations expose NHIs to third parties, which illustrates why supplier access and machine-to-machine trust are now compliance issues as much as security issues. The practical challenge is that many teams still govern NHIs as technical clutter instead of regulated access paths tied to business services.
In practice, many security teams encounter NIS2 exposure only after a vendor token or service account has already been used in an incident, rather than through intentional lifecycle control.
How It Works in Practice
Under NIS2, the most defensible approach is to treat NHIs as production access subjects with an owner, purpose, lifecycle, and audit trail. That means inventorying every service account, API key, certificate, automation token, and workload credential; mapping each one to a business service; and proving who can issue, use, rotate, and revoke it. Current guidance suggests that this should be joined to incident response and supplier governance, because the same credential often crosses application, cloud, and third-party boundaries.
In practice, security teams should combine identity hygiene with evidence collection:
- Assign each NHI a named business owner and technical custodian.
- Classify credentials by privilege, exposure, and third-party dependency.
- Rotate secrets on a fixed schedule and revoke unused credentials quickly.
- Log issuance, authentication, privilege changes, and failed use attempts.
- Link supplier access to contract terms and offboarding triggers.
This aligns with the NIS2 emphasis on resilience, because it creates demonstrable control over who or what can reach critical systems. It also matches NHIMG’s Ultimate Guide to NHIs - Regulatory and Audit Perspectives, which frames NHI governance as a repeatable evidence problem, not a one-time cleanup task. For implementation patterns, teams can borrow from CISA guidance on identity hardening and from the EU NIS2 Directive itself, which places clear emphasis on risk management measures and supply chain security.
These controls tend to break down in distributed environments with unmanaged secrets in CI/CD pipelines and ad hoc vendor integrations because ownership, rotation, and revocation are difficult to enforce consistently.
Common Variations and Edge Cases
Tighter NHI governance often increases operational overhead, requiring organisations to balance compliance evidence against developer velocity and vendor agility. That tradeoff is especially visible when the same credential must support both production automation and regulated third-party access.
There is no universal standard for every NIS2 implementation detail, but current guidance suggests a few edge cases deserve extra attention. Long-lived machine credentials used by legacy systems may need compensating controls such as network segmentation, stronger logging, and more frequent review when immediate rotation is not possible. Shared service accounts are another weak point because they obscure accountability, making incident reconstruction and supplier attribution difficult. Short-lived tokens reduce exposure, but only if revocation is automated and logs are retained long enough to support forensic review.
NHIMG’s research on JetBrains GitHub plugin token exposure is a useful reminder that tooling and integrations can leak machine credentials outside the primary control plane. The operational lesson under NIS2 is straightforward: if a credential can touch regulated systems, it should be governed like a first-class access path, even when it is not used by a person. Organisations that only review human accounts often miss the machine-to-machine paths that actually carry the highest incident and supply chain risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | NHI inventory is essential for proving control over machine access under NIS2. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access governance map directly to NIS2 resilience expectations. |
| NIST AI RMF | Governance and accountability are needed where automated access affects resilience outcomes. |
Inventory every service account, token, and key, then assign ownership and lifecycle controls.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
