Identity-first zero trust for workloads: where network controls fail

At a glance

What this is: This guide explains why zero-trust architecture for workloads fails when identity is not preserved end to end, and it shows how request-level verification changes the control model.

Why it matters: IAM and NHI teams need identity-first controls because workload trust is no longer determined by network location, and static credentials do not scale to ephemeral execution.

👉 Read Aembit's analysis of zero-trust architecture for workloads

Context

Zero-trust architecture for workloads is the practice of verifying every machine-to-machine request instead of assuming trust because traffic came from an internal network. For IAM and NHI governance, the problem is that many environments still rely on VPNs, firewalls, and long-lived secrets even when services move across clouds and containers.

That gap becomes more visible as workloads multiply and AI agents call APIs on behalf of business processes. The article’s core point is that network controls can reduce exposure, but they do not establish durable identity for the workload itself, which is the real governance problem practitioners now have to solve.

Key questions

Q: How should security teams implement zero trust for workloads?

A: Start by binding identity to the workload, not to the network location. Then enforce per-request authorisation, preserve identity across proxies and service boundaries, and issue only short-lived credentials that are scoped to the task. If identity is lost at any hop, the design is still perimeter-based in practice.

Q: What is the difference between network zero trust and identity-first zero trust?

A: Network zero trust focuses on limiting where traffic can move, while identity-first zero trust focuses on proving what workload is making the request and whether it should act now. The first constrains pathways. The second controls the principal. For NHI governance, identity-first models are stronger because software principals do not behave like human users.

Q: Why do workload identities create risk for IAM programmes?

A: Workload identities are often created faster than they are reviewed, rotated, or retired, and they can be reused across services or environments. That creates hidden standing privilege even when user access looks well controlled. IAM programmes struggle when they track human lifecycle events but leave machine principals outside the same governance model.

Q: When do ephemeral credentials reduce risk, and when do they not?

A: They reduce risk when issuance is tied to verified workload identity, strict scope, and short validity. They do not help much if the wrong principal can obtain them, if the scope is too broad, or if downstream services still trust the session after the original check. Short duration is useful, but only with strong governance.

Technical breakdown

Why workload identity breaks at the proxy layer

In many deployments, a proxy or load balancer terminates the session before the application server receives the request. That means the original workload identity can be lost unless it is re-attested or cryptographically bound to the downstream hop. If the proxy only forwards network context, policy decisions revert to location-based trust. For NHI governance, this is the failure mode that turns a zero-trust design into a smaller perimeter with the same assumptions. Request signing, identity propagation headers, and revalidation at each hop are the usual remedies, but they only work if every boundary enforces them consistently.

Practical implication: preserve workload identity through every hop or the control plane will silently fall back to network trust.

How ephemeral credentials change the NHI attack surface

Ephemeral credentials reduce the life span of a secret, but they do not remove the need for strong identity verification. The article shows the distinction clearly: a short-lived token is safer than a static password, yet it still depends on the system knowing which workload is entitled to receive it. That is the NHI governance issue. If a token is issued after weak attestation, or if it remains valid long enough to be reused across contexts, the environment has merely repackaged standing privilege in different form. Identity-first zero trust makes issuance conditional on verified workload state and request context.

Practical implication: pair ephemeral credentials with attested workload identity, or you only shorten the abuse window instead of eliminating it.

Where policy must move from edge enforcement to per-request authorisation

Traditional zero-trust programmes often enforce policy at the perimeter, but workload communication requires decisions at every request. This shifts authorisation from a one-time gateway check to continuous evaluation of identity, posture, environment, and purpose. That model aligns more closely with NIST SP 800-207 than with older network segmentation designs. For NHI practitioners, the key issue is not whether access is allowed in general, but whether the specific workload should be allowed to perform the specific action now. Without per-request policy, overprivilege accumulates quietly inside service chains.

Practical implication: move authorisation checks closer to the request path and treat each service hop as a separate decision point.

Threat narrative

Attacker objective: The attacker wants to turn one compromised workload identity into broad internal API and data access.

1. Entry occurs when a workload or AI agent uses long-lived credentials that were accepted because the environment trusted the network location.
2. Escalation follows when the attacker reuses those credentials across service boundaries that do not preserve identity end to end.
3. Impact is lateral movement through internal APIs and data stores that were never meant to trust the compromised workload automatically.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity-first zero trust is the only workable model for workload governance at scale. Network-based trust can still reduce exposure, but it cannot answer the central question of NHI security: what exactly is making the request, right now? As cloud, container, and agentic environments expand, the security boundary increasingly becomes the workload identity itself. Practitioners should treat identity preservation as the primary design constraint, not an implementation detail.

Static credentials are becoming a governance debt problem, not just a hygiene problem. Long-lived secrets are still common because they are simple to issue and hard to retire, which makes them persistent liabilities in distributed systems. Once a secret can be copied, cached, or reused across services, blast radius becomes the real risk metric. The discipline now is to measure where standing privilege still exists and reduce it methodically.

Request-level authorisation must replace perimeter-level confidence for machine traffic. A service that is allowed once is not automatically safe to trust throughout the session, especially when proxies, multihop chains, and cross-cloud calls are involved. This is where Zero Trust Architecture either becomes meaningful or remains a slogan. Teams should assume each hop can fail independently and design for re-authentication and re-evaluation.

Ephemeral credentials create identity blast radius pressure if governance is weak. A short-lived token can still be overbroad, overly reusable, or issued to the wrong workload if attestation is weak. That means the policy problem shifts from rotation frequency to issuance quality and context validation. Practitioners should govern what gets minted, to whom, and under which runtime conditions.

Workload zero trust is now inseparable from NHI governance. The old split between network security and identity security no longer holds when software itself acts as the principal. IAM teams that do not map workload identities, lifecycle events, and policy enforcement points will keep finding the same gap in different forms. The practical conclusion is to build governance around the workload, not just the user.

From our research:

• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 62% of all secrets are duplicated and stored in multiple locations, causing unnecessary redundancy and increasing the risk of accidental exposure, according to NHI Mgmt Group research.
• To go further, review the Ultimate Guide to NHIs , Static vs Dynamic Secrets for the operational difference between long-lived and ephemeral credentials.

What this signals

Identity-first zero trust will increasingly become the default framing for machine access, but only if teams can prove identity continuity across the request path. The practical shift is away from gateway-based assurance and toward runtime verification of the principal making each call. For programmes that still depend on tunnel trust or static tokens, the gap is no longer theoretical, especially as automation and AI agents expand the number of non-human principals.

Ephemeral credentials will not fix governance debt unless lifecycle controls catch up. Offboarding, rotation, and reuse controls still matter because a short-lived secret can be issued to the wrong runtime or overbroadly inherited by downstream services. The real programme change is to treat credential issuance, not just credential storage, as a control point. See the Ultimate Guide to NHIs for the broader lifecycle model.

Workload identity programmes that ignore policy propagation will end up with fragmented enforcement. That is especially true in multihop service chains and proxy-heavy architectures where one weak link resets the trust model. Teams should align their internal standards with NIST SP 800-207 Zero Trust Architecture and use the OWASP Non-Human Identity Top 10 as a checklist for where trust assumptions typically fail.

For practitioners

• Map every workload identity path Document how each workload authenticates to peers, APIs, and data stores, including proxies, service meshes, and cloud-native identity federation. Identify where identity is lost at termination points and where static secrets are still used as fallback.
• Replace long-lived secrets with short-lived issuance Use ephemeral credentials only after strong attestation, and scope them to a single workload, task, or request window. Prioritise the systems that currently depend on hardcoded API keys, shared tokens, or persistent service passwords.
• Enforce policy at each request hop Treat gateway approval as insufficient and require downstream validation for multihop service chains. Re-sign or revalidate identity at each boundary so a compromised service cannot inherit trust across the entire path.
• Review proxy termination as a control failure point Test whether headers, tokens, or signed claims survive proxy and load balancer termination without spoofing risk. If they do not, redesign the flow before extending zero-trust assumptions to production traffic.

Key takeaways

• Workload zero trust fails when identity is verified only at the edge and not preserved through the request path.
• Ephemeral credentials lower exposure only when issuance, scope, and attestation are tightly governed.
• IAM teams should treat workload identity, not network location, as the primary control surface for machine access.

Key terms

• Workload Identity: A workload identity is the machine principal used by software to prove who or what it is before receiving access. In practice, it may be backed by tokens, certificates, or platform attestation. For NHI governance, the key issue is whether the identity can be verified continuously and scoped tightly enough to resist reuse.
• Ephemeral Credential: An ephemeral credential is a short-lived secret issued just in time for a specific task or request window. It reduces exposure compared with persistent secrets, but it still requires strong attestation, narrow scope, and reliable revocation. Without those controls, short duration alone does not prevent misuse.
• Identity Continuity: Identity continuity is the ability to preserve a workload’s verified identity across proxies, services, and other infrastructure boundaries. It matters because zero trust breaks down when a request loses its original proof of identity and falls back to network trust or header-based assumptions.

Deepen your knowledge

Zero-trust architecture for workloads is a core topic in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is moving from network controls to identity-first access, it is worth exploring.

This post draws on content published by Aembit: Zero-Trust Architecture: How to Move From Network Security to Identity-First Access. Read the original.