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.

Nine attestation roots, in two kinds. 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. Six attest a machine. Three attest a single component and name no machine at all, which is why they are never accepted alone.

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.

Each entry here is an attestation root: a kind of evidence, with its own verifier. That is a different thing from a vendor root certificate — the certificate at the top of one manufacturer’s chain — and several of those can sit inside a single attestation root. The certificates we pin, with their fingerprints, are published there.

Built is not the same as switched on

Nine attestation roots are implemented, tested, and documented on this page. The live service accepts six of them today: Android Key Attestation, AWS Nitro Enclaves, Apple App Attest, TPM 2.0, Intel TDX and the GPU-node composite. Everything else is refused at the door, with a message naming the root rather than a vague failure.

AWS Nitro Enclaves was switched on 10 October 2026. The pinned root is the published AWS Nitro Enclaves root, and the verifier has been exercised against a document produced by a real enclave. No Nitro enclave has attested to the live service.

Intel TDX and the GPU-node composite were switched on together on 1 October 2026. TDX is on with its firmware level appraised against Intel’s signed TCB information, the Quoting Enclave compared against the one Intel publishes, and certificate revocation checked — a quote that fails any of those is refused rather than noted. The GPU-node composite had been held back over a firmware comparison that disagreed with the hardware; the disagreement turned out to be an off-by-one of ours between how SPDM numbers measurement blocks and how a reference manifest numbers its measurements. The hardware had been right the whole time. It is fixed, and the mapping is now pinned by a test against NVIDIA’s own published artifacts.

That is a deployment decision, not a gap in the work. A verifier is switched on when its evidence has been appraised first-hand and there is a reason for the public service to take it — and when the vendor root it anchors to has been confirmed from a source independent of the certificates it validates. AMD firmware TPMs fail that last test today: the root is pinned, its fingerprint has one source, and production declines it for that reason alone.

Read every entry below as what the verifier does when it runs, not as an invitation to send it something. What we cannot do keeps the running tally.

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 Verified first-hand	A CBOR attestation object — fmt, an attStmt carrying an X.509 chain, and WebAuthn authenticator data	Apple App Attestation Root CA, pinned from a PEM file the coordinator loads at startup and refuses to run without once Apple is switched on	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 Verified first-hand	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 Verifier built, no first-hand hardware	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
GPU node Verified first-hand	One confidential-VM CPU proof — an AMD SEV-SNP report or an Intel TDX quote — plus one NVIDIA attestation report per GPU that VM can see, submitted together	Both anchors at once: AMD’s or Intel’s root for the CPU proof, and NVIDIA’s Device Identity CA for each GPU report	that these specific GPUs are genuine AND that they are attached to this specific confidential VM — one fact, not two	that the VM image which collected the GPU reports is itself honest; which GPU a job actually runs on; anything a single unbound report could not prove either
Device roots — never accepted on their own
NVIDIA CC Verified first-hand	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
SPDM Verifier built — no collector	The full SPDM exchange transcript — version, capabilities and algorithm negotiation plus every measurement exchange — signed by the device’s own security processor	The device vendor’s pinned root certificate	that a PCIe device is genuine silicon from its vendor, and what firmware it is running	which machine the device is installed in — an SPDM report names no host at all

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.

Node roots

Roots that attest a machine

Each of these appraises a host a workload could run on. The evidence describes the machine, so it can stand on its own.

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.
On some devices, that the certificate encoding itself is correct. Measured on a OnePlus 15R on 12 October 2026: the chain encodes an extension flag in a form the strict standard forbids, and we read it leniently rather than refuse genuine hardware. Every signature is still checked against the original bytes and no other check is relaxed, but an appraisal from such a device says so, because an out-of-spec encoding should not read as identical to a correct one.
On a device made before 2021, that its certificates were still inside their validity window when we read them. Those certificates are written at the factory and cannot be renewed, so such a device can never present unexpired ones; Google documents that a chain reaching the pre-2021 root stays trustworthy, and we accept it only when the operator has switched that on. The chain still has to reach a root we pin, every signature is still checked and revocation is still consulted. An appraisal read that way says so, because a certificate we accepted past its expiry is something a reader is entitled to know about.

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

Verified first-hand

Appraised first-hand. An iPhone 14 Pro on 2 October 2026, then seven attestations across six devices on 13 October — five iPhone models spanning iOS 17 to iOS 27, and one iPad — each installed from TestFlight onto a physically distinct device and accepted by the live coordinator. What the evidence proves is narrow by Apple’s design, not by ours: four claims, and eleven statements of what it cannot show, counted on a handset on 24 October 2026.

Evidence: A CBOR attestation object — fmt, an attStmt carrying an X.509 chain, and WebAuthn authenticator data
Anchor: Apple App Attestation Root CA, pinned from a PEM file the coordinator loads at startup and refuses to run without once Apple is switched on
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.
Whether the device is running in a secured mode. Where Apple attaches an access control policy to the key we read it, and exactly one published value proves anything: System Integrity Protection and full security mode both enabled, which describes a Mac and not a phone. An iPhone attaches no such constraint, so there is nothing to validate and nothing is claimed — the absence is written into the appraisal rather than left to be read as satisfied. A policy that does assert a mode we cannot check is refused outright rather than trusted.

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

Verified first-hand

Appraised first-hand. Two real TD quotes from running trust domains, 25 and 30 September 2026, alongside a production Sapphire Rapids quote from hardware neither we nor Intel controls — so the verifier is not tested only against evidence we produced ourselves.

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

Verifier built, no first-hand hardware

Verifier implemented, tested and committed against a real production report and its VCEK, taken from AMD hardware and published by Google. No AMD SEV-SNP machine of ours has produced evidence, because we do not have one to run it on.

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

GPU-node composite

Verified first-hand

Appraised first-hand, end to end. One Blackwell GPU on 25 September 2026, then an eight-GPU H100 node on 30 September 2026, each binding every GPU report to a single TD quote from the same machine. Reordering two GPUs broke the binding, and so did removing one.

Evidence: One confidential-VM CPU proof — an AMD SEV-SNP report or an Intel TDX quote — plus one NVIDIA attestation report per GPU that VM can see, submitted together
Anchor: Both anchors at once: AMD’s or Intel’s root for the CPU proof, and NVIDIA’s Device Identity CA for each GPU report
Freshness: One challenge, used twice. Each GPU report carries SHA-256 of the challenge as its SPDM nonce, and the CPU proof’s REPORT_DATA carries a digest over the challenge and every GPU report together.

Proves

Every claim the underlying CPU root proves about the confidential VM — launch measurement, firmware level, debug state — carried through in full on the CPU sub-result.
Every claim each NVIDIA report proves about its own GPU: genuine silicon, confidential-computing mode, and firmware matching NVIDIA’s signed reference manifests.
THE BINDING, which is the whole reason this root exists. The confidential VM itself states, under AMD’s or Intel’s signature, exactly which GPU evidence it collected. Swapping in a genuine GPU report from a different machine breaks the digest and the appraisal fails.
How many GPUs were bound, as a hardware-sourced claim — not the count the submitter asserted.
Which CPU technology vouched for the GPUs, published as the cpu.root claim. A policy that cares about the vendor asks this claim.

Cannot prove

That the VM image which collected the GPU reports is honest. The binding proves the reports came from this VM; it does not prove the VM is trustworthy. That is what the launch measurement is for, and a policy should pin it.
Anything the CPU proof alone could not prove about the host, or the GPU report alone could not prove about the GPU. A composite inherits both sets of limits; it does not cancel either.
That the GPUs stay attached. The evidence describes the moment the challenge was answered.
Which GPU any particular job runs on, or that a job is given a GPU at all. This names the GPUs the node attested and reported; scheduling is a separate matter and nothing in this evidence is a statement about it.
Which physical machine this is, or where it sits, or who owns it. Binding proves two proofs came from the same place, not what that place is.

Easy to get wrong A GPU report and a CPU report presented side by side are not a bound pair, and nothing about the two documents themselves says so. Two genuine, individually valid proofs from two different machines look exactly like one attested GPU node unless the verifier checks that the CPU proof’s signed data actually covers the GPU reports. That check is the product; the pairing is not.

NVIDIA — Confidential Computing deployment guide (attestation)

Device roots

Roots that attest one component, and never stand alone

These appraise a single piece of hardware — a GPU, a card, a drive. Each proves the part is genuine and says what firmware it runs. Neither names the machine it is installed in.

That omission is the whole point of this section. A genuine report from one machine, presented beside unrelated evidence from another, looks exactly like an attested component in a trusted host — unless the two proofs are cryptographically bound together. So we accept neither of these on its own. A device proof counts only inside a composite that binds it to the host’s own proof, which is what the GPU-node composite above does.

NVIDIA Confidential Computing

Verified first-hand

Appraised first-hand. Nine GPUs across two rented confidential machines — one Blackwell, eight H100 — every attestation report verified against the pinned NVIDIA device root, and firmware measurements matched against NVIDIA’s signed reference manifests.

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.

The trap. 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

SPDM device attestation

Verifier built — no collector

A verifier exists and is tested. Nothing yet collects a measurement from a real device, so this root has never appraised live hardware.

Evidence: The full SPDM exchange transcript — version, capabilities and algorithm negotiation plus every measurement exchange — signed by the device’s own security processor
Anchor: The device vendor’s pinned root certificate
Freshness: A caller-supplied nonce carried in the signed exchange.

Proves

The device is genuine silicon, chained to the vendor’s pinned root.
What firmware the device has loaded, as measurements the device’s own security processor signed.
That the firmware was signed by the vendor, where the device reports a secure-boot state.

Cannot prove

Which machine it is installed in. This is the important one. Nothing in an SPDM measurement report names the host, the VM it is assigned to, or the tenant using it — so a genuine report from one machine can be presented alongside evidence from another unless the caller binds the two together. That is why this root is never accepted on its own.
Anything about a workload. An SPDM report describes the device’s own firmware and configuration. The device does not execute customer code in a trust boundary.
That the device is still in the state it reported. Measurements describe firmware as loaded; a device compromised afterwards attests identically to a clean one until it is measured again.
That the firmware is sound. A vendor signature proves the firmware was signed, not that it is free of vulnerabilities or has not since been revoked.
That traffic between the device and the host is protected. Unless PCIe IDE or an equivalent is separately established and attested, that link is not encrypted.
That the operator holding the silicon is honest. A valid report proves the part is genuine. Interposer attacks on the host’s memory bus sit outside every vendor’s threat model.

The trap. The obvious use — “prove this server’s network card is genuine” — is exactly the use SPDM cannot serve alone, because the report does not say which server. Presented by itself it invites the reader to supply the host from context, which is the assumption an attacker wants them to make.

DMTF — Security Protocol and Data Model (SPDM) specification

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.