Attestation matrix · Reference

What each attestation root proves, and what it does not.

This is a technology reference, not a list of hardware currently supported by SEVEN KG. GPU and broader platform support remain in research.

Five attestation technologies in common use. Each produces evidence in its own format, signed against its own trust anchor, answering its own question. None of them answers the others’ question, and the industry language around them is loose enough that the difference is easy to lose.

This page states, for each root, the evidence it produces, what that evidence establishes, and what it does not. The second list is the reason the page exists. Vendor documentation describes the inside of each boundary thoroughly and the outside of it rarely.

Terms follow RFC 9334: Attester, Verifier, Relying Party, Evidence, Attestation Results, Appraisal Policy. Every claim below is drawn from the primary source cited under the root it belongs to.

Summary

The short form. Each row expands into a section below it.

Attestation roots compared by evidence format, trust anchor, what they prove, and what they cannot prove.
Root	Evidence format	Trust anchor	Proves	Cannot prove
Android Verified first-hand	X.509 chain; the leaf carries the KeyDescription extension, OID 1.3.6.1.4.1.11129.2.1.17	Google attestation roots — the legacy RSA root, the re-signed RSA root, and the ECDSA RKP root	key custody in secure hardware, verified boot state, bootloader lock, OS patch level	workload memory isolation, code measurement, that any third-party code ran in a TEE, device state after the moment of attestation
Nitro Verified first-hand	COSE_Sign1 (CBOR tag 18), ECDSA P-384, over a CBOR attestation document	AWS Nitro attestation PKI, supplied in the document’s cabundle; the document is signed by the Nitro Hypervisor	measurement of the loaded image, parent instance identity and IAM role	enclave logic correctness, anything outside a PCR, AWS’s own position inside the trust boundary, state after the document was signed
TPM 2.0 Verified first-hand	X.509 endorsement key certificate following the TCG EK Credential Profile. Attestation proper is a TPMS_ATTEST quote signed by a separate attestation key.	The chip manufacturer’s root, pinned by digest in our build — Nuvoton TPM Root CA 2111 for the discrete part, AMD’s AMDTPM root for the firmware part	a genuine TPM of a known vendor and class exists, and its endorsement key was certified at manufacture	freshness, possession, or any platform state — an endorsement certificate establishes none of the three
App Attest Verifier built, no device evidence	A CBOR attestation object — fmt, an attStmt carrying an X.509 chain, and WebAuthn authenticator data	Apple App Attestation Root CA, pinned in our build	a key in the Secure Enclave of genuine Apple hardware, bound to one named application	any operating system property at all — no version, no patch level, no boot state
Intel TDX Documentation only	TD Quote — a TDREPORT signed by the TD Quoting Enclave	An Intel certificate authority, verified with collateral: TCBInfo, Quoting Enclave identity, and CRLs	memory-encrypted VM, launch and runtime measurements, platform TCB level	accelerator state, the guest’s own software stack
SEV-SNP Documentation only	Attestation report signed by the AMD Secure Processor with a VCEK or VLEK	AMD root and signing keys (ARK / ASK), distributed through AMD’s Key Distribution Service	memory-encrypted VM with integrity protection, launch measurement, firmware TCB	accelerator state, runtime state after launch, side channels
NVIDIA CC Documentation only	GPU attestation report from the GPU security processor, with a device identity certificate	NVIDIA device root; measurements compared against NVIDIA-published reference values	genuine GPU in CC mode, signed firmware, VRAM and link encryption	exist on any consumer GPU; anything without a CPU TEE to anchor it; which workload ran

Read the two right-hand columns together. A root is not better or worse than another; it answers a different question, and the failure that matters is presenting one root’s answer as evidence for another root’s question.

Android Key Attestation

Verified first-hand

Appraised first-hand. Five physical devices tested; four accepted, one rejected.

Evidence: X.509 chain; the leaf carries the KeyDescription extension, OID 1.3.6.1.4.1.11129.2.1.17
Anchor: Google attestation roots — the legacy RSA root, the re-signed RSA root, and the ECDSA RKP root
Freshness: attestationChallenge — a caller-supplied nonce baked into the key at creation time. The key must be regenerated to bind a new challenge.

Proves

attestationSecurityLevel names where the attested key lives: Software, TrustedEnvironment, or StrongBox.
The attested private key was generated inside that environment and cannot be exported from it.
RootOfTrust reports verifiedBootState, deviceLocked, verifiedBootKey and verifiedBootHash — the device booted an image signed by a key the bootloader trusts, with the bootloader locked.
OS version and patch level, when they appear in the hardwareEnforced list.
The caller-supplied challenge, bound at key creation, so a chain cannot be replayed against a different request.

Cannot prove

Anything about a workload’s memory. Third parties cannot deploy code into TrustZone on stock Android, so integrity is inferred from verified boot rather than enforced by memory isolation. A device that passes attestation is a device whose owner is still on the other side of the boundary.
A measurement of the application’s code. There is no equivalent of a launch measurement here.
Anything in the softwareEnforced list, which the Android OS asserts rather than the secure hardware. attestationApplicationId is in that list.
Uniform device identity across vendors. Manufacturers attest different fields — Samsung includes attestationIdModel, Motorola does not — so a policy keyed on device model silently excludes vendors that omit it.
Anything after the moment the challenge was answered. The evidence describes the device as it was, not as it is. It could be unlocked, rooted or rebooted a second later and nothing in the chain would say so. A monthly verification is a sequence of snapshots, not a continuous guarantee, and we will not describe it as one.
Who physically holds the device. Custody of a key in secure hardware is not custody of the hardware.
Anything about a GPU or NPU on the device. Those accelerators sit outside the attested boundary entirely.

Easy to get wrong attestationSecurityLevel and keyMintSecurityLevel are different fields, and a device can report a software attestation level with a TEE-level key. A verifier that checks only the key’s level will accept a device whose attestation chain anyone can forge, because the AOSP software attestation key is published in the Android source.

AOSP — Verifying hardware-backed key pairs with key attestation

AWS Nitro Enclaves

Verified first-hand

Appraised first-hand. Two real attestation documents from a running enclave.

Evidence: COSE_Sign1 (CBOR tag 18), ECDSA P-384, over a CBOR attestation document
Anchor: AWS Nitro attestation PKI, supplied in the document’s cabundle; the document is signed by the Nitro Hypervisor
Freshness: An optional nonce field, supplied by the relying party and echoed into the signed document, alongside a hypervisor timestamp.

Proves

The document carries module_id, timestamp, digest, pcrs, certificate and cabundle, plus optional public_key, user_data and nonce.
PCR0 measures the enclave image file, PCR1 the Linux kernel and bootstrap, PCR2 the application.
PCR3 measures the IAM role assigned to the parent instance and PCR4 the parent instance ID, so a document can be tied to a specific caller.
PCR8 measures the enclave image file signing certificate, so an operator can require that the enclave booted from an image they signed.

Cannot prove

That the enclave’s logic is correct. A measurement fixes what was loaded, never what it does.
Anything not measured into a PCR. PCR0 is a contiguous measure of the image file contents *without the section data*, so image metadata is outside the measurement.
Isolation from the parent instance as a cryptographic fact. Isolation is a property AWS designs and asserts about the platform; the PCRs do not measure it.
Anything about AWS. The chain roots in AWS’s own PKI and the document is signed by AWS’s hypervisor, so AWS sits inside the trust boundary by construction.
Who controls the AWS account the enclave runs in. PCR3 measures the IAM role and PCR4 the parent instance; neither says whose account it is.
Anything after the moment the document was signed. It describes state at attestation time only.
Anything about a GPU attached to the parent instance.

Easy to get wrong This root is structurally alien to the X.509 world: no certificate extension to parse, no chain of attestation certificates, a CBOR document signed once. A verifier abstraction that assumes X.509 will not absorb it without changing shape.

AWS — Nitro Enclaves attestation, PCR table

TPM 2.0

Verified first-hand

Appraised first-hand. Two machines — one discrete chip, one firmware TPM — with both certificate chains verified against pinned vendor roots.

Evidence: X.509 endorsement key certificate following the TCG EK Credential Profile. Attestation proper is a TPMS_ATTEST quote signed by a separate attestation key.
Anchor: The chip manufacturer’s root, pinned by digest in our build — Nuvoton TPM Root CA 2111 for the discrete part, AMD’s AMDTPM root for the firmware part
Freshness: None at this layer. An endorsement certificate carries no nonce and cannot carry one. Freshness arrives only with a quote, whose extraData carries relying-party bytes.

Proves

The endorsement key certificate chains to a manufacturer root pinned in our build, so a genuine chip from that vendor exists.
Whether the part is a discrete TPM — a separate package on the board — or a firmware TPM executing inside the main processor. That is decided by which pinned root the chain terminates at, never by the manufacturer string the chip reports about itself. The two are cross-checked and a disagreement is refused rather than resolved.
The TPM specification family and revision the part implements, and the chip family, as asserted by the manufacturer at production time.
Where a vendor populates it, how the endorsement key came into existence. On the AMD part we tested, the certificate asserts ekGenerationType internal — the key was generated inside the chip and never existed outside it. The Nuvoton part asserts nothing here at all, which is not the same as asserting otherwise.

Cannot prove

Freshness of any kind. An endorsement certificate is a static file written at manufacture. It is replayable forever, and no amount of chain validation changes that.
That whoever presented it holds the chip. Anyone with a copy of the certificate can present a copy. Possession is a separate proof, by credential activation.
Any platform state. No PCR values, no boot measurement, no bootloader claim, no operating system, no firmware hash.
What firmware is running now. On the firmware TPM we tested, the certificate names version 3.1 while the chip reports 3.84.0.5; the certificate is written once and never reissued. On the discrete part the two agree. That difference is measured, not assumed — and it is why the two classes stay separate in policy.

Easy to get wrong The endorsement key cannot sign. On both vendors we tested, its KeyUsage is keyEncipherment only, and marked critical — so possession must be proved by decrypting a secret encrypted to the key, not by answering a challenge with a signature. An implementation that expects a signature here has misread the primitive. The second trap arrives with the quote: TPMS_ATTEST must be checked for its TPM_GENERATED magic value, because without that check the same key can be made to sign arbitrary bytes with an ordinary sign command, and the result verifies perfectly while not being a quote at all.

TCG — TPM 2.0 Library Specification

Apple App Attest

Verifier built, no device evidence

Verifier implemented, tested and committed; the pinned root is verified. No Apple device has produced evidence for us, which requires a paid developer membership we have not bought.

Evidence: A CBOR attestation object — fmt, an attStmt carrying an X.509 chain, and WebAuthn authenticator data
Anchor: Apple App Attestation Root CA, pinned in our build
Freshness: A nonce Apple binds into the credential certificate as an extension, computed over the authenticator data and our challenge.

Proves

A private key exists in the Secure Enclave of genuine Apple hardware, certified by Apple’s own CA and chaining to the pinned App Attestation root.
The key belongs to one named application. The RP ID hash is a digest of our App ID, so a key attested for somebody else’s app — correctly signed by Apple, chaining perfectly — fails here.
The holder answered a fresh, server-issued challenge.
The counter was zero, so this is an enrolment rather than a replayed assertion.

Cannot prove

Any property of the operating system. This is the correction that matters most, because Apple’s reputation runs the other way. Android Key Attestation reports verified boot state, bootloader lock, OS version and both OS and vendor patch levels. App Attest reports none of them. A jailbroken device is not distinguished from a clean one, and a device three releases behind is not distinguished from a current one.
Anything about workload isolation. The app runs in ordinary iOS userspace. The Secure Enclave holds the key; it does not execute the code.
Device identity. No model, no serial number, no hardware identifier — so a device matrix cannot be built from Apple evidence the way one can from Android evidence. That is Apple’s privacy design working as intended, and it is a real constraint rather than a complaint.

Easy to get wrong Apple’s servers participate in issuing an attestation, and the attestation object carries a receipt that can be exchanged with Apple server-to-server for a fraud metric. Doing so would tell Apple which devices attested and when, and would place a third party inside the evidence path. We parse the receipt and deliberately ignore it. Verification is entirely local against the pinned root; the issuance dependency fails closed, because no attestation means no registration.

Apple — Validating apps that connect to your server

Intel TDX

Documentation only

Documented from primary sources. No verifier implemented, and no Intel TDX evidence has ever been checked by us.

Evidence: TD Quote — a TDREPORT signed by the TD Quoting Enclave
Anchor: An Intel certificate authority, verified with collateral: TCBInfo, Quoting Enclave identity, and CRLs
Freshness: REPORTDATA carries relying-party bytes into the signed quote. Verification collateral expires separately — Intel currently sets it at 30 days.

Proves

The Trust Domain’s memory is encrypted with a key the host does not hold.
MRTD records the TD’s launch measurement; RTMR0–3 record measurements extended at runtime by the guest.
The platform TCB level, including microcode and TDX module versions, so a stale platform can be rejected on evidence rather than on policy about hostnames.
That the quote was produced on genuine Intel silicon with TDX enabled — the TD Quoting Enclave signs with a key whose trust roots in Intel.

Cannot prove

Anything about an accelerator. A GPU is attested separately, by its own root, and the two pieces of evidence must be bound together by something outside either one.
The guest operating system and everything above it. Those stay inside the TD’s own trust boundary; beyond MRTD at launch, the quote knows only what the guest chose to extend into an RTMR.
That the verifier’s collateral is current. Verification depends on Intel-published TCB data that expires, and a verifier holding stale collateral is a real failure mode rather than a theoretical one.

Easy to get wrong A quote proves the platform, not the workload. "Verified on TDX" with no MRTD or RTMR comparison against an expected value is a statement that the hardware exists, not that the right code ran on it.

Intel — TDX Enabling Guide, attestation and infrastructure setup

AMD SEV-SNP

Documentation only

Documented from primary sources. No verifier implemented, and no AMD SEV-SNP evidence has ever been checked by us.

Evidence: Attestation report signed by the AMD Secure Processor with a VCEK or VLEK
Anchor: AMD root and signing keys (ARK / ASK), distributed through AMD’s Key Distribution Service
Freshness: REPORT_DATA carries 64 relying-party bytes into the signed report.

Proves

The guest’s memory is encrypted with a per-VM key.
SNP’s integrity protection: the host cannot remap, alias, or replay guest pages without detection. This is the property plain SEV lacked.
MEASUREMENT records the launch measurement of the guest’s initial memory image.
The guest policy in force, and the firmware and microcode TCB versions of the platform.

Cannot prove

Anything about an accelerator, for the same reason as TDX.
Anything after launch. The launch measurement describes the image the VM started from; it does not describe what the VM became.
The guest OS and workload, which remain in the guest owner’s own trust boundary rather than AMD’s.
Resistance to side channels or to physical attacks on the memory interface. The report is silent on both, and they sit outside what the design sets out to defend.

Easy to get wrong The report is chained through a VCEK derived per chip and per TCB version. Rotate the platform TCB and the certificate changes, so a relying party that pinned a certificate rather than a policy will fail closed on a routine firmware update.

AMD — SEV-SNP: Strengthening VM Isolation with Integrity Protection and More

NVIDIA Confidential Computing

Documentation only

Documented from primary sources. No verifier implemented, and no NVIDIA Confidential Computing evidence has ever been checked by us.

Evidence: GPU attestation report from the GPU security processor, with a device identity certificate
Anchor: NVIDIA device root; measurements compared against NVIDIA-published reference values
Freshness: A relying-party nonce in the report request. Verification can run locally against reference values or through NVIDIA’s remote attestation service.

Proves

The GPU is genuine NVIDIA silicon, identified by a device identity certificate signed with a device-unique ECC-384 key pair.
Secure Boot verified that the running GPU firmware was signed by NVIDIA, and the report carries firmware measurements to compare against NVIDIA’s reference values.
Confidential Computing mode is engaged: VRAM is encrypted, and PCIe and NVLink traffic is protected with 256-bit AES-GCM using rolling initialization vectors.

Cannot prove

Exist on consumer hardware at all. NVIDIA implements Confidential Computing only on datacenter parts — H100, H200, B200, HGX B300 and the RTX PRO 6000 Blackwell Server Edition. No GeForce or consumer RTX GPU has the mode, the device identity certificate, or the security processor that signs the report.
Stand alone. NVIDIA’s design requires a CPU TEE — Intel TDX, AMD SEV-SNP, or Arm CCA — to host the confidential VM, and the GPU report is only meaningful once it is bound to that VM’s own attestation.
Which process or workload ran on the GPU. The report describes the device and its firmware, not the tenant’s code.
Protection against sophisticated physical attacks or denial of service. NVIDIA places both outside the threat model.

Easy to get wrong A GPU report and a CPU quote are two separate documents from two unrelated roots. Presenting the pair as one result, with nothing cryptographically binding them, is the most common way a compliance package looks complete while proving less than it appears to.

NVIDIA — Confidential Compute on Hopper H100, WP-11459-001

Every root above can be replayed if freshness is not enforced.

All five carry a field for relying-party bytes: attestationChallenge, nonce, REPORTDATA, REPORT_DATA. All five are worthless if the verifier supplies the value from the evidence itself rather than choosing it, recording it, and refusing it on second use. Evidence that satisfies a challenge the evidence chose proves nothing.

Freshness also has a shelf life that is shorter than people expect. Working with real Android hardware, we have observed attestation leaf certificates valid for roughly half an hour — one expired four minutes before a verification attempt on evidence that had only just been collected.

That has a consequence for anyone assembling a compliance package: by the time an auditor opens the evidence, its certificates will not verify. The verification result and the time it was reached have to be recorded as part of the artifact, not left to be recomputed later.

Method, and corrections

Every statement above is taken from the primary source cited under its root, or from evidence produced by hardware we have run ourselves. We sell no hardware and represent no vendor, so nothing here is improved by making any root look broader than it is.

This page is a claim about other people’s systems, which means it can be wrong. If something is inaccurate, or a vendor has changed what its evidence carries, this reference will need to be updated.

Contact details for corrections will be published when our communication channels are ready.

Reviewed against sources on 13 September 2026. Vocabulary follows RFC 9334.