Zero trust for the cloud is really NHI governance in disguise

At a glance

What this is: This is StrongDM’s analysis of zero trust for cloud security, with the key finding that NHI governance is the deciding factor when cloud controls must cover service accounts, tokens, and automation paths.

Why it matters: It matters because IAM teams cannot claim zero trust coverage if human access is controlled but machine and workload identities still hold standing access or bypass review and monitoring.

Context

Zero trust for the cloud is not just a perimeter strategy. In practice, it is an identity governance problem because the cloud introduces users, workloads, automation, and service identities that all need explicit authorization and continuous scrutiny.

The model fails when teams apply strong controls to people but leave service accounts, tokens, API keys, and automation paths outside the same policy and review model. That gap is where cloud sprawl turns into access sprawl.

StrongDM frames the issue through cloud access, but the operational question for security teams is broader: can your zero trust program actually govern non-human identities at the same standard as human access?

Key questions

Q: What breaks when service accounts are not included in zero-trust verification?

A: The control only covers people while the attacker uses machine access. Service accounts, APIs, and application identities often carry the privileges that matter most during lateral movement, so excluding them leaves a blind spot in the exact place where attackers try to expand reach.

Q: Why do service account secrets create so much risk in zero trust architecture?

A: Service account secrets create risk because they often provide standing, non-interactive access to multiple systems. If one secret is leaked, reused, or over-scoped, attackers can move beyond the original application boundary without needing to defeat interactive authentication. In zero trust terms, the secret itself becomes the hidden trust anchor.

Q: How can security teams tell whether zero trust is actually working in AWS?

A: Look for evidence that access is issued for a narrow purpose, expires automatically, and is auditable across accounts and resource types. If teams still rely on long-lived credentials, broad roles, or manual revocation to control AWS access, zero trust is only partially implemented.

Q: What is the difference between access review and true NHI governance?

A: Access review checks whether an identity still exists and whether its permissions look acceptable at a point in time. True NHI governance also tracks ownership, behavior, lifecycle, dependency chains, and revocation readiness. In other words, governance asks whether the identity still belongs in the environment and whether it can be safely used right now.

Technical breakdown

Identity verification for cloud access

Zero trust depends on making every access request prove identity and context before granting resource access. In cloud environments, that means authentication is not a one-time gate at login. It must account for session context, device posture, role, and workload identity. The technical point is that cloud access is often mediated by tokens, service credentials, and short-lived sessions, so identity verification has to apply to both human and non-human actors. If the policy engine only understands users, it will miss the identities that actually move data and call services inside the environment.

Practical implication: extend verification logic to workload and service identities, not just user sign-in flows.

Least privilege for service accounts and workloads

Least privilege in the cloud means access should be scoped to the minimum set of actions a user or workload needs, and nothing more. In NHI terms, that includes service accounts, automation scripts, and cloud integrations that often accumulate broad permissions over time. The risk is privilege drift: access granted for deployment, maintenance, or orchestration remains in place long after the original need has changed. That turns machine identities into durable access pathways rather than task-specific actors. Zero trust only works when privilege is continuously reduced to the actual execution need.

Practical implication: review and trim service-account permissions with the same discipline used for privileged human roles.

Continuous monitoring of cloud activity and automation

Continuous monitoring is the mechanism that makes zero trust operational after access is granted. In cloud settings, this means observing user behavior, access patterns, device health, and workload actions in real time so anomalies can be detected before they become breaches. For NHIs, the important difference is that activity may be generated by scripts, orchestrators, or applications rather than humans, so the telemetry must preserve actor identity and intent. Without that visibility, it is difficult to distinguish normal automation from lateral movement or compromised credentials masquerading as routine service traffic.

Practical implication: make machine and automation telemetry first-class in your monitoring and detection workflows.

NHI Mgmt Group analysis

Zero trust in the cloud is really NHI governance because cloud control surfaces are dominated by machine identities. Human sign-in controls matter, but cloud operations run on service accounts, tokens, automation, and workload identities. If those identities are not inventoried, authorized, and reviewed, the programme only looks like zero trust at the perimeter.

Continuous authorization only works when the subject of authorization is known. The cloud often grants access through short-lived sessions and delegated credentials that blur ownership and intent. That makes identity governance the control plane, not a supporting function, because the wrong identity model leads to the wrong policy decision.

Least privilege collapses when privilege is defined once and reused everywhere. Cloud teams frequently provision machine access for deployment convenience and then let it persist across environments. That creates standing access for NHIs, which turns zero trust into a document rather than a control model.

What looks like cloud security is often lifecycle failure. The core problem is not only who can authenticate, but whether service accounts, tokens, and automation paths are created, scoped, monitored, and retired with governance discipline. Practitioners should treat NHI lifecycle control as a prerequisite for zero trust credibility.

Ephemeral access debt: Cloud teams that rely on temporary sessions while leaving long-lived machine credentials untouched create a hidden mismatch between human-centric zero trust and machine-centric reality. The programme appears modern, but the underlying access model still depends on credentials that outlive the task they were meant to support.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs

What this signals

Zero trust becomes brittle when machine identity is treated as an implementation detail. Cloud programs often start with strong user-centric controls, then discover that the real risk sits in service accounts, tokens, and automation flows that bypass the human access layer. Practitioners should assume the control gap will appear wherever identity is delegated but not lifecycle-managed.

Ephemeral sessions do not solve the governance problem if the underlying non-human credential remains stable. A cloud environment can look well-contained on the surface while long-lived machine access continues to accumulate behind the scenes. The practical test is whether your programme can answer who owns each NHI, where it is used, and when it is retired.

For practitioners

• Map cloud zero trust coverage to NHI control points Inventory service accounts, tokens, API keys, certificates, and automation identities, then confirm which ones are governed by the same authorization and monitoring policies as human users.
• Reduce standing privilege in cloud automation Identify workloads and scripts that keep broad access after deployment or maintenance tasks end, and re-scope them to task-specific permissions.
• Make workload telemetry identity-aware Correlate cloud logs so machine actions can be traced to the underlying non-human identity, not just the source IP or application name.
• Test zero trust against machine access paths Validate whether access reviews, conditional access, and monitoring rules still work when the actor is a service account or automation pipeline rather than a person.

Key takeaways

• Zero trust for cloud security fails when machine identities are excluded from the same authorization model used for people.
• Service accounts, tokens, and automation paths create the most common mismatch between policy language and actual cloud access.
• The most useful control change is to treat NHI lifecycle governance as part of zero trust design, not as an adjacent hygiene task.

Key terms

• Zero Trust: A security model that assumes no identity, human or non-human, should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
• Continuous authorization: Continuous authorization is the practice of rechecking access as a session unfolds instead of trusting a single login decision. It matters for AI workflows because the request, context, retrieved data, and downstream action can all change between prompt and execution, making static approval too blunt.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.