Attestation-based workload identity is replacing secret zero assumptions

At a glance

What this is: This is an analysis of attestation-based workload identity and its key finding that cryptographic environment proof can replace secret-based bootstrap trust.

Why it matters: It matters because IAM, PAM and NHI teams need a control model that handles distributed workloads without relying on long-lived secrets or fixed infrastructure assumptions.

👉 Read Aembit's analysis of attestation-based workload identity and secret zero

Context

Attestation-based identity is a workload authentication model that proves where a workload is running and how it is configured before access is granted. In the primary keyword of this post, the issue is not token format but trust: traditional workload IAM assumes the issuer and runtime are already safe, which breaks down in multi-cloud, Kubernetes and CI/CD environments.

That matters for NHI governance because service accounts, projected tokens, SPIFFE identities and API credentials all depend on the same decision: can the environment be trusted enough to mint access? Attestation shifts the control point from static credential possession to verifiable runtime evidence, which changes how practitioners think about bootstrap, federation and drift.

Key questions

Q: How should security teams replace secret zero with attestation-based workload identity?

A: Start by identifying every workload that still needs an initial secret to bootstrap access, then move those trust decisions to a verifier that checks runtime evidence before a credential is issued. The goal is to remove possession-based trust from the bootstrap path and replace it with proof of environment integrity.

Q: Why do static secrets fail in Kubernetes and multi-cloud workload identity?

A: Static secrets prove possession, not provenance. In Kubernetes and multi-cloud estates, that means a stolen token can still look legitimate even if the runtime was compromised, relocated or tampered with. Attestation reduces that weakness by tying access to the workload’s verified environment rather than to a reusable secret.

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 is the difference between attestation-based identity and secret-based identity?

A: Secret-based identity trusts a credential holder, while attestation-based identity trusts evidence about the workload’s environment. That distinction matters because a credential can be copied, but a trusted runtime state must be proven against policy. In practice, attestation adds provenance to the access decision.

Technical breakdown

How attestation-based workload identity changes the root of trust

Attestation-based identity moves the root of trust away from a pre-shared secret and toward cryptographic proof of runtime state. Evidence can include cloud-signed metadata, TPM measurements, container image hashes, boot measurements or code signatures. A verifier checks that evidence against policy, then a credential issuer can mint a short-lived credential only after the workload matches the expected environment. This is distinct from simple token authentication because the token is not trusted on its own. The identity decision depends on an external proof of environment integrity that can be re-evaluated as conditions change.

Practical implication: map every workload trust decision to a verifier and policy engine, not to a static secret alone.

Secret zero and continuous re-attestation in cloud workloads

Secret zero is the bootstrap problem created when a workload needs an initial credential before it can obtain any other credential. Attestation reduces that dependency by using the runtime environment itself as the proof source, so the workload can prove identity without storing a long-lived password, key or certificate. Continuous re-attestation then extends the model by checking whether the workload remains in the approved state. If the image hash, signing key or environment claim changes, the previously issued credential can be invalidated. That makes drift a live control signal, not an after-the-fact audit finding.

Practical implication: treat changed image hashes, revoked signing keys and expired proofs as immediate access invalidation events.

Attestation in Kubernetes, SPIFFE and cross-cloud federation

In Kubernetes and federated cloud environments, attestation often sits alongside projected service account tokens, SPIFFE/SPIRE issued SVIDs and signed instance identity documents. The common pattern is the same: the workload proves its runtime context, a policy layer evaluates that proof, and access is granted only for the approved scope. Federation matters because each cloud provider exposes identity differently, but attestation creates a portable verification layer above those differences. That portability is useful only if the destination can trust the evidence format or federation relationship. Without that, organisations simply replace one credential dependency with another.

Practical implication: standardise the evidence format and federation path before you try to eliminate static secrets across platforms.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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 not a provisioning nuisance. It is a trust assumption that breaks once workloads can prove identity from runtime evidence instead of pre-shared credentials. Traditional workload IAM assumes an initial secret exists somewhere and can be protected long enough to bootstrap access. Attestation removes that premise by using environment proof as the starting point. Practitioners should recognise this as a structural shift in how machine trust is established.

Attestation closes a real NHI governance gap because a valid credential no longer proves that the runtime is trustworthy. In multi-cloud and Kubernetes estates, token possession alone says nothing about image integrity, node state or build provenance. OWASP-NHI and NIST CSF both point to the need for identity assurance and continuous verification, and attestation operationalises that for workloads. The practical conclusion is that access policy must evaluate evidence, not just identity claims.

Continuous re-attestation turns drift into an access decision instead of a monitoring event. A workload that changes image hash, boot state or signing trust can be invalidated without waiting for human review. That is especially relevant where short-lived credentials are already the norm, because the control now depends on re-verification rather than revocation cleanup. Teams should treat runtime drift as a first-class governance signal.

Attestation-based identity exposes the limitation of secret-centric zero trust programmes. Zero Trust for workloads cannot be built on the assumption that a secret is enough to define trust, because the secret proves possession, not provenance. Attestation adds provenance, which is the missing layer when supply-chain compromise and environment tampering are the dominant concerns. Practitioners should re-evaluate where their current workload identity stack still relies on static credential confidence.

Named concept: identity provenance gap. This is the gap between proving that an identity exists and proving that it is executing in the approved state. The article’s central insight is that modern workload governance needs both, especially when credentials are ephemeral and infrastructure is mutable. The implication is that identity programmes must distinguish possession from provenance when they assess workload access risk.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage.
• For the broader credential-removal problem, see Guide to the Secret Sprawl Challenge for how teams reduce exposure paths from code, config and CI/CD.

What this signals

Identity provenance gap: organisations should expect workload governance to shift from credential possession checks to evidence validation as cloud estates become more dynamic. The practical consequence is that access reviews, rotation schedules and federation controls will matter less unless they are anchored to runtime proof and not just secret lifecycle. For teams mapping this to standards, the NIST Cybersecurity Framework 2.0 remains the clearest control vocabulary for govern, protect and detect functions.

With 91.6% of secrets still valid five days after notification in our research, the problem is not only issuance but slow trust decay across the environment. That means static credential retirement is too slow for distributed workloads that can change state between one request and the next. Practitioners should plan for evidence expiry and access invalidation as operational controls, not exceptional events.

The next governance step is to treat attestation as part of workload identity architecture, not as a bolt-on control. Where teams already use SPIFFE-style identity, the SPIFFE workload identity specification is a useful reference point for portable trust and federation across systems.

For practitioners

• Classify bootstrap trust paths Inventory every workload that still needs a pre-shared secret to reach a secrets store, token broker or API. Mark those paths as secret zero dependencies and prioritise them where the bootstrap credential is long-lived or widely reused.
• Require evidence-based policy evaluation Route workload access decisions through a verifier that checks image hashes, signed metadata or attestation claims before a credential is issued. Keep the policy separate from the issuer so trust can be evaluated independently of token minting.
• Validate continuous re-attestation triggers Define what runtime changes invalidate trust, including image drift, revoked signing keys and unexpected environment claims. Make those events revoke or quarantine the credential before the workload completes its next sensitive call.
• Standardise federation for cross-cloud workloads Document which attestation signals are accepted across AWS, Azure, GCP, Kubernetes and CI/CD identities. Align the evidence format and federation relationship before you try to remove static secrets from the access path.

Key takeaways

• Attestation-based identity changes workload security by proving runtime trust instead of relying on long-lived secrets.
• The real scale problem is credential persistence, not just credential issuance, because stale secrets remain active long after risk is known.
• Practitioners should align workload IAM, federation and drift handling around evidence validation so access can fail closed when runtime state 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: The bootstrap dependency where a workload needs an initial credential before it can obtain any other credential. In practice, this is the point where static secrets create the earliest and often weakest trust assumption in workload identity design.
• 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

Attestation-based workload identity and secret zero reduction are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing static bootstrap secrets with runtime proof, it is worth exploring.

This post draws on content published by Aembit: Attestation-based workload identity and secret zero. Read the original.