Confidential VMs and containers, Kubernetes, workload identity
Attested cloud workloads
Confidential VMs are easy to start and hard to operate.
Confidential VMs and containers can prove what they run. The hard part is running it. Which verifier? Which reference values? What happens on every deploy? And how does a workload get its identity back after a crash, with nobody stepping in?
Who this is for
- Platform and infrastructure teams, running confidential VMs and containers
- Security architects, moving from network trust to workload identity
- Software vendors, shipping into customers' confidential environments
When trust has to be proved again
A deploy rolls outNew images mean new measurements; verifiers must know them before traffic arrives.
A node or agent loses its stateIt needs to re-attest to get its identity back. Today it often waits for someone to delete a stale record.
Short-lived credentials rotateEach rotation is a chance to check the workload again; most systems skip it.
What we deliver
- A design for attestation-backed workload identity (SPIFFE/SPIRE, Confidential Containers, cloud attestation services).
- Re-attestation and recovery paths that do not depend on trust on first use.
- Key release policies bound to measurements.
Questions worth answering
- Which of your nodes can re-attest, and which are trust on first use?
- Do your secrets depend on attestation or only on network location?
- Who updates reference values when you ship?
Across the life cycle
DesignBuildMake or deployOperateUpdateRetire
The stage that decides here: update. Deploys happen many times a day. Build and update have to hand measurements to the verifier without a person in between. See attestation in the product life cycle.
Rules and standards your buyers cite
DORANIS2ISO 27001 and SOC 2
Industries that use this
Blockchains and decentralised networks
Go deeper
- How the platforms attest: Intel TDX and SGX, AMD SEV-SNP, Arm CCA, Amazon Web Services, Microsoft Azure, Google Cloud, Oracle Cloud Infrastructure, Independent verifiers
- Terms explained: Reattestable, Re-attestation, Continuous attestation, Re-attestation vs continuous attestation, Trust on first use (TOFU), IETF RATS architecture, Trusted execution environment (TEE), Attested TLS, Workload identity (SPIFFE/SPIRE), Runtime integrity, TCB recovery, Quote, report, token: names for evidence, Local attestation, Attestation across vendors, Enclave, trust domain, realm: one idea, many names, Library operating systems for enclaves
- Read next: Evidence, reference values and appraisal, Attacks on trusted hardware, History of attestation
Who builds in this area
From our public landscape: Intel Trust Authority, Microsoft Azure Attestation, AWS Nitro Enclaves, Google Cloud Confidential Space, Google Cloud Confidential Computing, Edgeless Systems, Anjuna, Fortanix, enclaive, SCONTAIN (SCONE), IBM Confidential Computing Container Runtime, Arm Confidential Compute Architecture (CCA), AMD SEV, Intel TDX, Gramine, Occlum, Confidential Containers, Open Enclave SDK, Veraison, Project Oak, Confidential Computing Consortium, IETF RATS Working Group, SPIFFE / SPIRE, Defakto, Teleport, Smallstep, Istio, Cofide, Phala, iExec, Oasis, Automata, Marlin (Oyster), Secret Network, Turnkey, Lit Protocol.
Not quite your case? The build side of the same problem? Attested software supply chain. Blockchain nodes? Blockchains.
Working on Attested cloud workloads? A first call takes 30 minutes and commits you to nothing. Bring your product and the one question that worries you.
Next fixed date: EU Digital Identity Wallets are due in every member state on 24 December 2026, 42 days from now.
Concepts: Re-attestation · Continuous attestation · Remote attestation · IETF RATS architecture