They often treat zero trust as an architecture label instead of an access governance model. Under NIS2, the practical test is whether least privilege, approval discipline, and access review are actually enforced. If those controls are missing, zero trust claims do not withstand audit or incident scrutiny.
Why This Matters for Security Teams
zero trust is often presented as a modern security posture, but NIS2 looks at outcomes: whether access is actually constrained, reviewed, and justified in operation. That distinction matters because many organisations equate network segmentation or an IAM roadmap with compliance, while leaving service accounts, API keys, and machine-to-machine access effectively unmanaged. NIST defines zero trust as a strategy built around continuous verification, not a product label, in NIST SP 800-207 Zero Trust Architecture. NHIMG’s Ultimate Guide to NHIs — Regulatory and Audit Perspectives frames the same issue through audit evidence: if least privilege and review discipline are not demonstrable, zero trust claims do not hold up under scrutiny.
The practical problem is that NIS2 places pressure on governance, not branding. Security teams are expected to prove that access is necessary, time-bound, and recoverable after misuse. NHIs make this harder because they are numerous, often overprivileged, and frequently left out of periodic review. NHI Mgmt Group notes that 97% of NHIs carry excessive privileges in modern enterprises, which turns a vague access model into a concrete operational risk. In practice, many security teams encounter zero trust failures only after an incident or an audit request exposes how much machine access was assumed rather than controlled.
How It Works in Practice
For NIS2, the working question is not whether an organisation “has zero trust,” but whether access decisions are enforced at the point of use. That means least privilege, approval workflows, and access reviews must cover humans and NHIs alike. The most useful interpretation of zero trust is therefore an access governance model aligned to NIS2 Directive — official EU legal text, not a perimeter redesign.
In operational terms, teams should be able to answer four questions quickly:
- What identity is making the request, including service accounts, workloads, and API clients?
- Why does that identity need this permission right now?
- How long will that access remain valid?
- Who reviews and revokes it when the task or risk changes?
That is where NHI governance becomes measurable. NHIMG’s Ultimate Guide to NHIs is useful because it ties zero trust to lifecycle controls such as rotation, offboarding, and visibility. If a secret is embedded in code, shared across pipelines, or never rotated, the organisation may still be calling its design “zero trust” while operating with standing privilege. Current guidance suggests pairing policy-as-code with periodic entitlement review so access can be proven, not assumed. Where possible, organisations should align this with the control discipline described in Ultimate Guide to NHIs — Standards and make revocation events auditable end to end.
These controls tend to break down in CI/CD-heavy environments because machine identities are created faster than governance processes can review and revoke them.
Common Variations and Edge Cases
Tighter access control often increases operational overhead, requiring organisations to balance auditability against delivery speed. That tradeoff becomes visible when teams try to apply zero trust uniformly across cloud workloads, legacy systems, and third-party integrations. There is no universal standard for this yet, but current guidance favours context-aware control over static allow lists.
One common edge case is vendor and third-party access. NIS2 does not let organisations outsource accountability, so external integrations still need scoped permissions, logging, and review. Another is privileged automation: if an agent or pipeline needs elevated access for a short task, standing privilege is hard to justify. Just-in-time approval and ephemeral credentials are better aligned to zero trust, but only if revocation is automatic and verified.
A second variation is the difference between architecture and governance evidence. Teams often deploy ZTA tooling, then assume the compliance problem is solved. In practice, auditors and incident responders look for access history, approval records, and revocation timing. If those records are incomplete, the label matters less than the control failure. For a practical NHI lens, NHIMG’s research on the lifecycle of NHIs is often the better test than a diagram. The same is true for the official EU NIS2 Directive: it evaluates whether governance is effective, not whether terminology sounds modern.
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 surface, NIST Zero Trust (SP 800-207) set the technical controls, and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | Defines zero trust as continuous verification, not an architecture label. | |
| NIS2 | NIS2 requires demonstrable access governance and review discipline. | |
| OWASP Non-Human Identity Top 10 | NHI-03 | NHI lifecycle and rotation failures commonly undermine zero trust claims. |
Treat zero trust as runtime access decisions with continuous verification and explicit trust reduction.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
