How should organisations apply NIS2 to human, machine, and third-party identities?

Why This Matters for Security Teams

NIS2 is not just a human access policy. Its operational impact reaches service accounts, vendor access, API keys, and automation pathways that can touch essential or important entities. That matters because regulated environments rarely fail through a single login failure; they fail when standing access, weak revocation, or poor visibility lets an identity keep working long after its purpose has changed. The NIS2 Directive — official EU legal text sets the legal expectation, while NHI Management Group’s research shows why identity sprawl is a real exposure: NHIs outnumber human identities by 25x to 50x in modern enterprises, and the Ultimate Guide to Non-Human Identities highlights that only 5.7% of organisations have full visibility into their service accounts.

For NIS2, the practical question is whether each identity has a defined owner, narrow scope, and a dependable revocation path. That applies equally to internal admins, outsourced support users, machine-to-machine credentials, and cloud-native workload identities. Security teams often discover the real problem when a vendor session, CI/CD token, or dormant service account remains valid during an incident and becomes the easiest path into a regulated system.

How It Works in Practice

A useful NIS2 implementation starts by classifying identities by function rather than by employment status. Human identities need strong authentication, role scoping, session logging, and joiner-mover-leaver controls. Machine identities need short-lived credentials, workload-bound trust, and rotation or revocation that is automated instead of ticket-driven. Third-party identities need contract-backed approval, time limits, and proof that access can be withdrawn without waiting for the next audit cycle.

Practitioners should map these controls back to the technical realities of access. For humans, privileged access management and just-in-time elevation reduce standing access. For machines, secrets should be ephemeral where possible, and service accounts should be tied to workload identity rather than embedded passwords. For vendors, access should be brokered, monitored, and constrained to specific systems and time windows. The OWASP Non-Human Identity Top 10 is useful here because it frames the recurring failure modes around over-privilege, secret exposure, and weak lifecycle controls.

NHI Management Group’s 52 NHI breaches Analysis is a reminder that exposure is rarely theoretical, and supply-chain access is especially sensitive: the Klue OAuth Supply Chain Breach and the Reviewdog GitHub Action supply chain attack show how third-party tooling can widen the blast radius fast.

• Give every identity an owner who can approve, review, and revoke it.
• Prefer short-lived tokens and workload identity over long-lived shared secrets.
• Log privileged actions and vendor sessions at the point of use, not only at the gateway.
• Review access after role changes, incidents, and supplier changes, not just at quarterly attestation.

These controls tend to break down when legacy applications require static credentials or when third-party access is embedded in business-critical workflows that cannot tolerate rapid token expiry.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance resilience against friction for administrators, developers, and suppliers. That tradeoff is real, especially where regulated services depend on older systems, outsourced operations, or shared platform accounts.

Current guidance suggests that human, machine, and third-party identities should not be treated as equal only in policy language. They differ in how they authenticate, how they are monitored, and how fast they can be revoked. For example, a human admin can usually be challenged interactively, while a workload identity may need automated re-issuance every few minutes. A supplier may need access for a single maintenance window, while a CI pipeline may need repeated access across many deployments. The control objective stays the same: reduce standing access and prove that every path is justified.

There is no universal standard for this yet, but best practice is evolving toward identity inventory, owner assignment, and revocation testing across all identity classes. The Ultimate Guide to Non-Human Identities is especially relevant when organisations need to justify why NIS2 cannot be met through human IAM alone. For implementation detail, the NIST SP 800-53 Rev 5 Security and Privacy Controls helps translate policy into auditable access, logging, and account-management controls.

Edge cases include emergency access, service desks that impersonate users, and vendor-managed platforms where the customer never directly sees the underlying service account. In those cases, the safest pattern is to require compensating controls such as enhanced logging, tighter approval workflows, and explicit time-bounded access.

Related resources from NHI Mgmt Group

• How do organisations reduce risk from third-party machine identities?
• What breaks when organisations apply human IAM models to machine identities?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?