Platform guide

Attestation on every platform

Sixteen platforms, four questions each. What it proves, how, who checks, and when to check again.

Processors, GPUs, phones, industrial controllers and clouds all attest differently. The names change. The questions a buyer should ask do not.

Intel TDX and SGX AMD SEV-SNP Arm CCA Arm TrustZone and PSA TPM DICE NVIDIA GPUs Android Apple devices Controllers and industrial devices Amazon Web Services Microsoft Azure Google Cloud Oracle Cloud Infrastructure Independent verifiers Transparency services

Processors and TEEs

Intel TDX and SGX

What it proves: That a trust domain (a whole virtual machine) or an enclave (part of a program) runs on genuine Intel hardware at a known security version, with a known initial state.
The evidence: A quote: a report from the processor, signed by a quoting enclave whose key chains back to Intel.
Who verifies: Your own verifier with Intel's certificates, or a service such as Intel Trust Authority.
When to prove it again: After a microcode or module update, after a TCB recovery, and whenever the virtual machine is started again.
Source: Intel TDX Demystified

AMD SEV-SNP

What it proves: That a virtual machine is isolated from its host on a genuine AMD processor, with a measured launch state and stated firmware versions.
The evidence: An attestation report signed by a key held in the AMD secure processor. The key depends on the firmware version.
Who verifies: Your own verifier, using certificates from AMD's key distribution service.
When to prove it again: After a firmware update, because the signing key changes with it, and at every launch.
Source: Attestation Mechanisms for TEEs Demystified

Arm CCA

What it proves: That a realm (a protected virtual machine) runs on a genuine Arm platform, with a known platform state and a known initial realm state.
The evidence: A token in two parts: a platform token for hardware and firmware, and a realm token for the realm's initial memory and boot state.
Who verifies: A verifier such as Veraison. Linaro hosts one for early platforms.
When to prove it again: After firmware changes on the platform and whenever a realm is created.
Source: Arm: CCA attestation and Veraison

Arm TrustZone and PSA

What it proves: That a device has a genuine root of trust and that its secure world runs known software.
The evidence: A PSA attestation token, signed by a key in the device's root of trust.
Who verifies: The device maker's or operator's verifier.
When to prove it again: After every firmware update and at each change of owner.
Source: PSA Certified

TPM

What it proves: What a machine booted: firmware, bootloader, kernel and whatever else was measured.
The evidence: A quote: the measurement registers, signed by a key that never leaves the chip.
Who verifies: A verifier with reference values, for example Keylime.
When to prove it again: After every update of anything that is measured, and on a schedule while the system runs.
Source: TCG: TPM 2.0 Library

DICE

What it proves: The identity of each boot layer of a small device, derived from the code of the next layer.
The evidence: A chain of certificates, one per layer.
Who verifies: The device maker's or operator's verifier.
When to prove it again: Automatically: changed firmware produces a changed identity.
Source: TCG: DICE Attestation Architecture

GPUs

NVIDIA GPUs

What it proves: That a GPU is genuine, runs approved firmware and is in confidential computing mode.
The evidence: Each GPU has its own key and certificate. The driver opens a secure session with the GPU and collects signed measurements, which are compared with NVIDIA's reference manifest.
Who verifies: NVIDIA's remote attestation service, which returns a signed token, or a local verifier. The local verifier still fetches reference manifests and certificate status from NVIDIA.
When to prove it again: After a driver or firmware update, when a GPU is added or replaced, and before each new workload receives keys. The GPU's protection also rests on the CPU's TEE, so both are checked.
Source: NVIDIA Attestation documentation

Phones and personal devices

Android

What it proves: That a device booted an unmodified system, that a key lives in secure hardware on that device, and that an app is genuine.
The evidence: Verified Boot checks the system at start and records its state. Key and ID attestation gives a certificate chain for a key held in the Trusty TEE or a StrongBox chip, and that chain carries the boot state. Since Android 13 the certificates come through Remote Key Provisioning and are short-lived. Play Integrity adds Google's verdict on the app and device. The Android Virtualization Framework adds protected virtual machines that are isolated from Android itself.
Who verifies: Your server, checking the chain against Google's roots, or Google for Play Integrity.
When to prove it again: Whenever certificates expire, after operating system updates, and before sensitive actions.
Source: Android: Key and ID attestation

Apple devices

What it proves: That a request comes from a genuine instance of your app, or that a managed device is the device it claims to be.
The evidence: App Attest creates a key in the Secure Enclave and has Apple certify it for your app. Managed Device Attestation proves the identity and properties of devices under management.
Who verifies: Your server, checking Apple's signature. Apple is the root of trust in both cases.
When to prove it again: At each new installation, and when device management asks for fresh attestation.
Source: Apple: Managed Device Attestation

OT, industrial and small devices

Controllers and industrial devices

What it proves: That a controller, drive or gateway is the device the maker shipped, and increasingly what firmware it runs.
The evidence: A manufacturer identity certificate installed at the factory. Onboarding protocols such as BRSKI and FIDO Device Onboard use it to hand the device to its owner.
Who verifies: The plant's onboarding service and, where the device supports it, a verifier for its measurements.
When to prove it again: After a firmware update, a repair, a move to another zone or a change of owner. Attestation of running controllers is still young. Identity at onboarding is common; proof of state afterwards is the gap.
Source: RFC 8995 (BRSKI)

Clouds

Amazon Web Services

What it proves: What code runs in a Nitro Enclave, and what an EC2 instance booted.
The evidence: A signed attestation document with measurements. It can be used as a condition for releasing keys. Instances with NitroTPM can be checked against images built to have known measurements.
Who verifies: AWS key management, or your own verifier.
When to prove it again: After every new enclave image or machine image.
Source: AWS: Nitro Enclaves attestation

Microsoft Azure

What it proves: That an enclave, a confidential virtual machine or a TPM-backed machine is in a trustworthy state.
The evidence: Platform evidence from Intel, AMD or a TPM, sent to Microsoft Azure Attestation, which returns a signed token.
Who verifies: Microsoft Azure Attestation, under a policy you define.
When to prove it again: At each start, and whenever policy or platform versions change.
Source: Microsoft: Azure Attestation

Google Cloud

What it proves: That a confidential virtual machine runs on AMD or Intel protection, and what it booted.
The evidence: Evidence from the virtual TPM and from the processor, turned into a signed token.
Who verifies: Google Cloud Attestation, or your own verifier.
When to prove it again: At each start and after image updates.
Source: Google Cloud: Confidential VM attestation

Oracle Cloud Infrastructure

What it proves: That a virtual machine runs with AMD memory encryption and, on newer shapes, with integrity protection.
The evidence: An AMD attestation report requested from inside the virtual machine.
Who verifies: A verifier you run yourself. Oracle describes this as bringing your own attestation service.
When to prove it again: At each launch and after firmware changes.
Source: Oracle: Confidential Computing

Verifiers and transparency

Independent verifiers

What it proves: Nothing by themselves. They check other platforms' evidence against reference values and policy, and issue a result you can pass on.
The evidence: They accept quotes, reports and tokens from several vendors.
Who verifies: Intel Trust Authority, Veraison, Keylime and the Trustee project are examples. Running your own keeps the verdict out of the hands of the party being checked.
When to prove it again: Whenever reference values or policy change. A verifier with old reference values approves old software.
Source: RFC 9334 (RATS architecture)

Transparency services

What it proves: That a statement about software, such as a release or a set of reference values, was published in a log that cannot be quietly rewritten.
The evidence: A receipt from an append-only log.
Who verifies: Anyone. That is the point: auditors and customers can see what was ever accepted.
When to prove it again: Each release adds an entry. A verifier can refuse anything that is not in the log.
Source: SCITT architecture

What a verifier does with this evidence is explained in evidence, reference values and appraisal.

The standards behind these platforms are on the reading list. What has broken is in the vulnerability tracker. Who builds on each platform is in the landscape.

Summaries of public documentation, checked 12 November 2026. Products change; read the source before you build on a detail.

Working on attestation on your platform? 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.

Book a 30-minute call Get expert help

NextCheck your product's TCB →Quote, report, token →Reading list →