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

At a glance

What this is: Aembit’s analysis argues that workload zero trust fails when identity dies at the network boundary, leaving machine-to-machine access governed by location rather than verified workload identity.

Why it matters: IAM, PAM and NHI teams need this distinction because workloads now authenticate across clouds, containers and APIs, so perimeter-style controls no longer give reliable assurance about who or what is requesting access.

Context

Workload zero trust is a governance problem as much as a technical one. If access decisions still rely on where traffic comes from, the programme is assuming that network location is a safe proxy for identity. That assumption no longer holds when workloads move across clouds, containers and API-driven automation.

In identity-first access, the question changes from whether a connection is inside the perimeter to whether the requesting workload can be verified at each request. That matters for NHI governance because service accounts, tokens and other machine credentials now carry the trust burden that the network used to absorb.

Aembit’s article is not about abandoning zero trust. It is about where the model breaks when workloads, not users, are the primary actors and when credential handling, proxy termination and policy enforcement all need to preserve identity end to end.

Key questions

Q: What breaks when healthcare zero trust is applied only at the network layer?

A: It leaves the actual identity and session risks untouched. Shared devices, mobile work, privilege drift, and stale credentials can still create exposure even when the network is segmented. Healthcare needs identity-aware zero trust that continuously validates who is accessing what, from where, and in what context.

Q: Why do long-lived workload credentials weaken zero-trust architecture?

A: Long-lived credentials create a reusable trust object that can outlive the request it was meant to support. Once an API key, password or persistent token is exposed, the attacker does not need to re-establish identity for each action. Zero trust loses force unless access is issued just in time and tied to verified workload identity.

Q: How can security teams tell if workload identity is actually being preserved?

A: Look for identity continuity across every hop, not just at launch. If a request is authenticated at the edge but then forwarded through proxies or meshes without re-validation, the programme has lost the very signal it relies on. Effective designs preserve cryptographic binding and re-authorize at each boundary.

Q: When should teams choose identity-first access over network segmentation for workloads?

A: Choose identity-first access when workloads cross clouds, containers or external APIs and network boundaries no longer represent a meaningful trust zone. Segmentation can still reduce exposure, but it cannot prove which workload is making the request. Identity-first controls are the better fit when access decisions must follow the request itself.

Technical breakdown

Why network controls lose identity at the proxy layer

Network-centric zero trust often validates the path, not the actor. Firewalls, VPNs and many proxy-based designs decide whether traffic may pass based on source location or tunnel membership, but the workload identity often disappears when TLS is terminated or when a service mesh hands traffic to the next hop. That creates a smaller perimeter, not a true identity model. In practice, the control boundary shifts from request-level verification to infrastructure trust, which weakens assurance for service-to-service communication.

Practical implication: treat proxy termination as an identity loss point and require request-level verification beyond the network edge.

How cryptographic workload identity preserves trust end to end

Identity-first access binds the workload to the request using cryptographic proof rather than network position. Cloud instance metadata, Kubernetes service account tokens and OIDC-based federation can attest that a workload is what it claims to be, and policy engines can then evaluate that identity at each access decision. The point is not simply authentication at startup. The point is continuity of identity across proxies, load balancers and service boundaries so that trust survives the full request lifecycle.

Practical implication: verify that workload identity remains intact after each hop, not just at launch.

Why long-lived credentials undermine zero trust for workloads

Long-lived API keys, passwords and persistent tokens create a standing attack surface that contradicts the logic of zero trust. If a credential can be reused indefinitely, then a single exposure can outlast the request that justified it. Ephemeral credentials issued just in time reduce that window, but they only work when issuance is tied to verified identity and current context. Without that linkage, short-lived secrets become static credentials in different packaging.

Practical implication: replace standing credentials with task-scoped issuance tied to verified workload identity and context.

NHI Mgmt Group analysis

Identity-first zero trust is the correct model for workloads because network trust cannot prove actor identity. Zero trust was designed to remove implicit trust from the perimeter, but many implementations still stop at the transport layer. Once identity is lost at proxy termination or tunnel exit, the programme has preserved encryption without preserving governance. Practitioners should treat end-to-end workload identity as the control objective, not a nice-to-have overlay.

Long-lived credentials are the hidden failure mode in most workload access designs. A static secret used by a service account, API client or automation flow turns each access path into a reusable attack surface. That is a governance problem before it is a technical one, because the access decision has already been made at provisioning time. Practitioners need to recognise that credential lifetime now defines blast radius in machine-to-machine environments.

Proxy-based zero trust can create a false sense of control when the trust boundary simply moves. If traffic is routed through a vendor appliance, a service mesh or a gateway that terminates identity, the architecture has not eliminated trust assumptions. It has outsourced them or pushed them downstream. The practitioner conclusion is that identity continuity, not inspection depth, is what determines whether zero trust actually holds.

Workload identity governance now has to span clouds, containers and external APIs as one access plane. The article’s core message is that workloads are no longer confined to a single hosting layer or administrative domain. That means policy, credential issuance and verification must be designed for distributed execution paths. The practical conclusion is that NHI governance needs request-scoped trust, not just inventory and rotation discipline.

Runtime identity becomes the decisive control variable when workloads act across organizational boundaries. The old perimeter model assumed stable network adjacency and predictable trust zones. That assumption breaks when services call external APIs, shift between clouds or execute through automation chains. The practitioner implication is to re-centre architecture on attested identity and contextual authorization at every request.

From our research library:

• 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
• 30.9% of organisations store long-term credentials directly in code, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity continuity is now the control objective for workload zero trust. Teams should expect more environments where the same service identity must survive proxies, meshes and external API calls without losing verifiability. If that continuity fails, the architecture is still perimeter-driven even if the tooling is modern.

Long-lived credentials are still the easiest way to defeat a zero-trust posture for workloads. Once a service account or API client can reuse the same secret across many requests, the trust decision has effectively been made once and reused many times. That is why short-lived issuance and request-scoped authorization matter more than tunnel design.

Workload identity governance is becoming a cross-domain discipline. IAM, NHI and cloud teams now need to evaluate the same access path from credential issuance to proxy termination to downstream authorization. The practical signal is simple: if your policy cannot follow the request end to end, your zero-trust model is incomplete.

For practitioners

• Audit identity loss points in your access path Map where workload identity disappears at proxies, load balancers, service mesh exits and gateway hops. Prioritise the paths where network location still determines access after identity has been stripped away.
• Replace standing secrets with task-scoped issuance Move service accounts and automation flows off long-lived API keys, passwords and persistent tokens. Issue short-lived credentials only after verifying workload identity and current context.
• Enforce request-level authorization at every hop Require each service boundary to re-evaluate the workload identity and the requested action instead of trusting an upstream network decision. Preserve cryptographic binding across the full request chain.
• Inventory cross-cloud and external API dependencies Identify which workloads cross cloud boundaries or depend on outside APIs, then apply the strongest identity verification and policy enforcement to those communication paths first.
• Test whether your zero-trust model survives proxy termination Validate that identity still exists after TLS termination, header forwarding and backend handoff. If the answer is no, the control plane is relying on a smaller perimeter rather than true identity-first access.

Key takeaways

• Workload zero trust fails when identity is validated only at the network edge and then lost at proxies, tunnels or service boundaries.
• Long-lived credentials turn machine access into a standing attack surface, especially where services reuse the same secret across many requests.
• Identity-first access shifts the control point to request-time verification, short-lived credentials and re-authorization at every hop.

Key terms

• Identity-first security: Identity-first security is an approach that treats identity as the primary control plane for managing risk. Instead of relying mainly on network or endpoint boundaries, it uses identity context to decide what can happen, when it can happen, and under what conditions. That model is especially relevant where privileges move across human, non-human, and agentic actors.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• 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.
• Short-Lived Attested Credential: A short-lived attested credential is a token or certificate issued for a specific run or workload after the platform verifies who or what is asking. It reduces replay risk because the credential is only useful within a narrow window and is tied to claims that can be checked at runtime.

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.