How should security teams apply zero trust to non-human identities?

Why This Matters for Security Teams

zero trust changes little if machine identities still behave like permanent back doors. Security teams often harden networks and user access while leaving service accounts, API keys, certificates, and tokens able to act for too long, in too many places, and without clear ownership. That gap is exactly where attackers look. NIST’s NIST SP 800-207 Zero Trust Architecture makes continuous verification central to the model, and NHIMG research shows why that matters: The State of Non-Human Identity Security reports that only 1.5 out of 10 organisations are highly confident in securing NHIs. That confidence gap usually reflects blind spots in ownership, rotation, and policy enforcement, not a lack of tools.

For NHI security, zero trust is not just about stronger authentication. It is about assuming every machine identity can be abused, then shrinking what it can reach, how long it can act, and under what conditions it remains valid. The practical target is not perfect trust, but controlled exposure with rapid invalidation when behavior changes.

In practice, many security teams discover machine identity overreach only after a token, certificate, or service account has already been used for lateral movement rather than through intentional control design.

How It Works in Practice

Applying zero trust to NHIs starts by treating each identity as a distinct workload with explicit ownership, purpose, and policy. The first step is inventory: identify every service account, API key, certificate, secret, and token, then bind it to a business service and a named owner. From there, replace standing access with short-lived, task-scoped authorisation. Current guidance suggests using least privilege plus continuous evaluation, rather than static allow lists that never change.

Implementation usually has four parts. First, issue credentials just in time and revoke them automatically after the task completes. Second, limit what the identity can call with role boundaries that are narrow by default and reviewed often. Third, monitor usage so the security team can detect drift, unusual call patterns, or new tool chains. Fourth, prefer cryptographic workload identity where possible. The Guide to SPIFFE and SPIRE is useful here because it shows how to prove what a workload is, not merely what secret it holds.

That approach fits the zero trust logic in NIST SP 800-207 Zero Trust Architecture: authenticate, authorise, and re-evaluate at request time, not once at deployment. It also aligns with NHIMG’s Ultimate Guide to NHIs — Standards, which emphasises lifecycle control, rotation, and offboarding as core security operations, not cleanup tasks. The 97% excessive-privilege finding in that research is a reminder that broad entitlements are usually the default failure state, so narrowing access is often the highest-value control.

These controls tend to break down when secrets are embedded in CI/CD pipelines or code repositories because the identity cannot be cleanly issued, revoked, or observed at the point of use.

Common Variations and Edge Cases

Tighter credential control often increases operational overhead, requiring organisations to balance security gains against deployment speed and service reliability. That tradeoff is real, especially for legacy systems, batch jobs, and vendor integrations where short-lived identity is harder to implement.

There is no universal standard for this yet, but current guidance suggests a few practical variations. Legacy workloads may need compensating controls such as PAM, segmented network paths, and aggressive rotation until they can support workload identity. Human-operated automation should not be confused with autonomous agents: if an AI agent can choose tools, chain actions, or adapt to new objectives, static RBAC is usually too coarse. In those cases, intent-based or context-aware authorisation is more appropriate, with runtime policy decisions based on what the agent is trying to do, the data it touches, and the risk of the requested action.

For platforms with strong orchestration, the best pattern is to combine JIT credential provisioning with ephemeral secrets, policy-as-code, and continuous logging. For vendor-managed integrations, the boundary must be explicit: scope the identity to the smallest possible API surface and verify that offboarding actually revokes access. If a team needs a concrete example of how fast this can fail, the JetBrains GitHub plugin token exposure case shows how a leaked machine token can create persistent access when rotation and detection lag behind exposure.

In practice, zero trust for NHIs works best when the identity is short-lived, the permission is narrow, and the policy is evaluated at the moment of action rather than assumed from prior approval.

Related resources from NHI Mgmt Group

• How should security teams apply zero trust authentication to non-human identities?
• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• How should security teams decide whether JIT access is safe for non-human identities?