Notifications
Clear all
Topic starter
06/06/2026 11:06 am
TL;DR: Attestation-based identity replaces pre-shared secrets with cryptographic proof of workload environment, reducing secret zero risk and enabling short-lived access across Kubernetes, cloud and CI/CD systems, according to Aembit. The core shift is that identity is verified from runtime evidence, not trusted because a token exists.
NHIMG editorial — based on content published by Aembit: Attestation-based workload identity and secret zero
Questions worth separating out
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.
Q: Why do static secrets fail in Kubernetes and multi-cloud workload identity?
A: Static secrets prove possession, not provenance.
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.
Practitioner guidance
- Classify bootstrap trust paths Inventory every workload that still needs a pre-shared secret to reach a secrets store, token broker or API.
- 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.
- Validate continuous re-attestation triggers Define what runtime changes invalidate trust, including image drift, revoked signing keys and unexpected environment claims.
What's in the full article
Aembit's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step attestation flow for Kubernetes, cloud-native metadata and CI/CD identities
- Platform-specific examples for AWS, Azure, GCP and SPIFFE/SPIRE federation
- Policy engine and credential broker patterns for short-lived access delivery
- Implementation notes on how to handle static-secret fallback where dynamic credentialing is not supported
👉 Read Aembit's analysis of attestation-based workload identity and secret zero →
Attestation-based workload identity: what it means for IAM teams?
Explore further
06/06/2026 11:42 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Attestation-based workload identity is replacing secret zero assumptions
