Attestation-based workload identity is replacing secret zero assumptions

At a glance

What this is: This is a view of attestation-based workload identity, where runtime evidence rather than pre-shared secrets proves a workload is running in an approved environment.

Why it matters: It matters because IAM teams must replace secret-zero assumptions with controls that verify workload state at issuance time across clouds, Kubernetes, and CI/CD.

Context

Attestation-based workload identity is a control pattern for proving a workload is running where and how it should before granting access. The article argues that traditional workload authentication still trusts a token issuer or stored secret, which breaks down when the issuer, runtime, or build pipeline is compromised.

For IAM and NHI programmes, the governance problem is not just credential theft but trust in the issuing environment itself. If the environment can mint valid tokens for the wrong workload, the access model has already failed before the first API call is made.

The article frames secret zero as the original weakness: a system that still needs an initial secret to bootstrap access cannot fully escape secret dependency unless identity is derived from verifiable runtime evidence.

Key questions

Q: What breaks when workload identity is still managed with long-lived tokens and shared secrets?

A: Long-lived tokens and shared secrets break least privilege, make offboarding harder, and weaken auditability. They also create blind spots when workloads move across clusters, clouds, and service boundaries. In practice, teams lose the ability to prove which machine acted, what it was allowed to do, and whether access should have expired earlier.

Q: Why does attestation reduce risk in cloud and Kubernetes access paths?

A: Because it replaces possession of a credential with proof of runtime state. Instead of assuming a token belongs to the right workload, the verifier checks where the workload is running, what code it is executing, and whether the environment matches policy. That makes cloud and Kubernetes access decisions conditional on evidence, not just identity claims.

Q: How do teams know attestation-based identity is actually working?

A: Look for access decisions that depend on verified runtime evidence, not just token validity. You should also see sensitive credentials invalidated when image hashes, node state or signing trust changes. If drift does not change access, the attestation control is only decorative.

Q: What should teams do when one cloud workload needs access to another cloud service?

A: They should use a federation rule that allows the destination service to validate the source workload’s attestation evidence, then issue only a short-lived, scoped credential. The key decision is whether the trust relationship is explicit and policy-driven, not whether the two environments can exchange credentials.

Technical breakdown

Why secret-based workload identity fails

Secret-based workload identity assumes the credential holder is the right workload and that the issuer of the credential is trustworthy. That model breaks when attackers steal tokens, compromise the token issuer, or move laterally into the environment that mints access. In multi-cloud and Kubernetes estates, the credential becomes a bearer of trust rather than a proof of state, so the security decision is outsourced to something that may already be compromised. Attestation changes the trust anchor from possession to proof.

Practical implication: treat any credential model that depends on a bootstrap secret as a residual risk, not as a complete workload trust design.

How attestation turns environment state into identity

Attestation-based identity binds a workload token to verifiable evidence about its runtime context. That evidence can include cloud-signed metadata, TPM measurements, container image signatures, boot records, or namespace and runner identity. A verifier checks those claims against policy and a known-good baseline before any credential is issued. The important shift is that identity is no longer asserted by a token alone. It is proven by the environment in which the workload is executing, which makes replay, drift, and misplacement visible at verification time.

Practical implication: build policy around acceptable runtime evidence, not around the mere existence of a signed token.

Why continuous re-attestation matters in distributed environments

Attestation is not a one-time check. Modern workloads move, rebuild, and redeploy frequently, so the trust decision has to be revisited as the environment changes. Continuous re-attestation catches changes in image hashes, expired tokens, revoked signing keys, or a workload that no longer matches its approved configuration. This is what makes the model useful in Kubernetes, CI/CD, and cross-cloud access paths. Without ongoing verification, attestation would just become another static trust artifact with a shorter name.

Practical implication: design attestation as an ongoing authorization control, not as a one-off onboarding step.

Threat narrative

Attacker objective: The attacker aims to convert a stolen or fraudulently issued workload credential into trusted access to cloud and service infrastructure.

1. Entry occurs when an attacker steals a workload token or compromises the system that issues it, allowing access to appear legitimate to downstream services.
2. Escalation follows when the compromised issuer mints valid credentials for an unauthorized workload, extending trust beyond the intended runtime boundary.
3. Impact is unauthorized access to infrastructure and services that were supposed to be protected by workload identity, including cloud resources and CI/CD-connected systems.

Breaches seen in the wild

• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.
• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.

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

NHI Mgmt Group analysis

Secret zero is a governance assumption, not just a bootstrap problem: traditional workload identity assumes an initial secret can safely exist long enough to start trust. That assumption collapses when the environment itself can be compromised, because the issuer of truth becomes part of the attack surface. The implication is that workload governance must move from secret custody to verifiable runtime proof.

Attestation is a root-of-trust shift for NHI governance: the meaningful control is no longer who holds a credential, but whether the workload can prove where it is running and what code it is executing. That aligns better with OWASP-NHI and ZT-NIST-207 thinking because trust is conditional, contextual, and revalidated. Practitioners should treat runtime evidence as the object being governed.

Continuous re-attestation closes the drift gap that static secrets cannot see: short-lived credentials reduce exposure, but they do not by themselves prove the workload stayed in policy after issuance. Re-attestation makes environment drift, revoked signing keys, and image changes actionable events rather than silent deviations. The practical conclusion is that access governance has to follow the workload lifecycle, not the secret lifecycle.

Platform diversity does not excuse trust fragmentation: the article’s strongest point is that cloud metadata, Kubernetes tokens, TPMs, and image signatures can all feed the same identity decision. That matters because fragmented identity systems create gaps between cloud, CI/CD, and orchestration layers. Teams need one policy model for evidence quality, not separate trust logic for every platform.

Attestation exposes the limit of credential-centric security: when a service can only be trusted after its environment is verified, the presence of a valid secret is no longer sufficient evidence of legitimacy. That is the right failure mode to name for modern workload IAM. The implication for practitioners is to govern proof, not just possession.

What this signals

Runtime proof is becoming the more durable trust primitive for machine access: workloads that can prove their environment at request time are easier to govern than workloads that only present a reusable secret. That changes the control point from secret storage to evidence validation, which is where identity teams should be investing.

Attestation also narrows the gap between cloud, Kubernetes, and CI/CD governance. A single evidence policy can cover different execution surfaces, which reduces the need for bespoke trust exceptions and makes drift visible before access is granted.

For practitioners

• Map your bootstrap secrets Identify every workload path that still needs a pre-shared secret to obtain its first credential, including Kubernetes, CI/CD, and cross-cloud calls.
• Define acceptable evidence sources Specify which attestation inputs are authoritative for each workload class, such as cloud-signed metadata, TPM measurements, or signed image hashes.
• Tie policy to runtime baseline Require the verifier to compare attestation claims against an approved baseline for namespace, image digest, hardware state, or runner identity.
• Use short-lived credentials only after proof Issue scoped credentials only after attestation succeeds, and invalidate them when the underlying evidence changes or expires.
• Review cross-cloud trust paths Check where one environment accepts identity proof from another, and document the federation rule that makes that trust explicit.

Key takeaways

• Traditional workload authentication still leaves IAM dependent on secrets and trust in the issuer, which is where the biggest exposure begins.
• Attestation-based identity shifts the decision to runtime evidence, making environment state part of the identity check instead of an assumption.
• For practitioners, the practical change is to govern proof, issue only short-lived access after verification, and re-check when the workload changes.

Key terms

• Attestation-based identity: An identity model that proves a workload’s runtime state with cryptographic evidence before access is granted. Instead of trusting a stored secret alone, the system validates where the workload is running, how it was built and whether it matches policy.
• Secret Zero: Secret zero is the first credential needed to reach a secrets store, identity broker, or protected system. It is the root trust dependency that often survives even when everything else is rotated. If that initial credential is exposed, the rest of the secret model can collapse very quickly.
• Runtime evidence: Cryptographic proof collected from the environment a workload is using, such as image hashes, cloud-signed metadata, boot measurements or code signatures. It is the material a verifier checks to decide whether an identity should be trusted.
• Continuous re-attestation: A repeated validation process that re-checks a workload’s trust state after access has been issued. For autonomous or mutable environments, this matters because identity can drift after the first approval, and the control must detect that change quickly.

Deepen your knowledge

NHI governance, workload identity security, and secrets management 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.