So your GPU passed attestation. Now what?

A confidential workload that spans a CPU enclave and a GPU produces attestation evidence at every hop, and deployment guides call the result "attested." But if you decompose what the reports contain you're left with grey areas: what was measured versus what executes, when the evidence held versus when you rely on it, and what one device proves versus what a boundary of devices proves.

You'll find a relying party standing there at the end of every confidential computing diagram. And somewhere upstream, a confidential virtual machine has proven its launch state, a GPU has produced a signed report, a verification service has returned a token, and the deployment is now proclaimed "attested."

But what exactly is the party relying on it entitled to conclude?

In July, a research group studying large-model serving on NVIDIA's Blackwell B300 platform published a plain accounting of the boundary, itemizing what a confidential tenant on a multi-GPU system can verify, its CVM's evidence, the GPU's confidential mode and attestation reports, the fabric topology it can see, and what it cannot, which is the host-operated control plane that programs which GPUs its traffic can reach.

Their summary of the current state: "The fabric works as a confidential resource before it is an attestable one." That describes one hop of a chain that deserves the same accounting at every link.

The attestation architecture NVIDIA built for its Hopper and Blackwell GPUs solves for a specific set of constraints. But the engineering term "attested" crosses into general usage, and as it does so, it gathers associations that need to be trimmed back.

What does the evidence actually contain?

Every Hopper-class GPU leaves the factory with a device-unique identity key burned into fuses, with NVIDIA destroying all copies of the private key during manufacturing and anchoring the public half to its certificate authority. At boot, ROM code begins a measured chain, with firmware verified against NVIDIA's signatures before it executes. The device derives an attestation key by mixing its fused secret with the measurements of the firmware it loaded. When a confidential VM initiates a session with the GPU, the driver establishes an encrypted channel and retrieves a signed report containing, per the first independent examination of the architecture, the device identity, VBIOS and firmware measurements, and the current security settings.

Verification then compares those measurements against golden values. A relying party can do this through the NVIDIA Remote Attestation Service, which per the H100 confidential computing whitepaper checks the evidence signature against the device certificate chain, checks revocation status, fetches the reference measurements matching the driver version and GPU model, applies an appraisal policy, and returns a signed token with an expiry. Airgapped deployments can verify locally instead, although these local verifiers can hold stale revocation data. But, anyway, the token is not the end of the chain. The whitepaper's flow ends with the relying party applying its own appraisal policy to decide whether the device is in a good state. The architecture, in other words, formally expects the relying party to exercise judgment.

So that asserts that this is a genuine NVIDIA device of a known model, it booted firmware NVIDIA signed at versions matching published reference values, its confidential mode and security settings are configured as claimed, and it has one end of the encrypted session your VM established.

What was measured, versus what executes?

The most common over-reading of this would conclude that the workload was attested.

The team that built the system, writing in ACM Queue, describes the goal that shaped the software stack: CUDA applications should run unchanged in confidential mode. Once the CPU TEE's trust has been extended to the GPU, running compute applications is identical to a regular GPU. That is why two years of AI deployments could adopt confidential mode without rewriting their inference stacks. And it has a corollary, which is that the kernels a tenant launches after attestation are not measured, not signed, and not represented in any report. The attestation covers the platform that will run the workload, the firmware, the microcode, the configuration. It does not cover the workload.

This is the same division of labor the CPU side settled on years ago. A confidential VM's launch measurement covers its initial memory contents and boot chain. Anyone who wants workload identity in the evidence has to put it there themselves by measuring their own stack into the boot chain, pinning container digests, or running an attested runtime that extends measurements upward.

When do you rely on it?

An attestation report is evidence about the state of the device at the moment of measurement. The relying party consumes it later, sometimes much later, and this requires things like nonces to guarantee freshness of the challenge, tokens that carry expiries, attestation keys that regenerate on every full chip reset, revocation checks against certificate lists that themselves go stale. NVIDIA's developer material discusses what one of its architects calls the time domain problem of attestation evidence, and the company's attestation suite documentation suggests that appraisal cadence should be seen as a lifecycle question.

How long is a passing result good for? What happens to a running session when a certificate in the chain is revoked mid-run, when reference measurements are superseded, when a driver advisory lands?

The published flow defines the mechanisms, expiring tokens, refreshed revocation lists, re-attestation on demand, but defines no mandatory cadence. That's fine, because the right cadence is a function of the deployment's threat model. A hardware vendor cannot necessarily know this.

The silicon threat models on the CPU side scope out sophisticated physical attacks, and the GPU whitepaper's threat table does the same. Proof Street's May article traced what followed when researchers with interposer hardware extracted signing keys, forged CPU-side quotes, and, in the finding most relevant here, a demonstration that GPU attestation reports were not bound to the identity of the specific CVM that requested them, so a forged CPU attestation could be paired with a genuine GPU report borrowed from other hardware. The lesson for the relying party is about composition.

What does one device prove, versus what does the boundary prove?

A workload that spans a CPU enclave and a GPU never rests on one attestation. Intel's attestation service documentation states that the GPU TEE relies on the CPU TEE to establish trust in the GPU and to manage the secure channel between them. Composite attestation, in that flow, means independent evidence collected from each side and appraised together. What the relying party must supply is whether these two reports are about the same boundary, at the same time, bound to the same session, or merely two true statements about two devices somewhere?

The multi-GPU generation raises the same question at rack scale. On Hopper, the multi-GPU answer was to hand a whole connected GPU complex to one tenant and treat the fabric as private because nothing else shares it. Blackwell adds a mode where the NVSwitch fabric stays shared and the host partitions it into confidential tenant sets, with NVLink traffic encrypted between the devices. The paper's accounting shows the tenant verifying its CVM evidence, each GPU's mode and reports, and the fabric health it can observe, while the Fabric Manager binary and the NVSwitch routing tables that decide where its traffic can travel remain host-trusted and outside the evidence. The authors also name the plausible path to closing the gap, an attestable service VM for the fabric control plane, signed routing state, and device-interface attestation in the TDISP mold as the PCIe standards mature. NVIDIA's attestation roadmap material presents NVLink encryption and TDISP-capable hosts as complementary layers of the same architecture. A claim about a multi-GPU boundary contains a component the evidence does not cover.

What does a careful deployer do?

Phala, which operates GPU TEEs as a cloud platform and reports verifying thousands of attestations daily, builds its dstack stack to extend measurement upward from the substrate, publishing verification flows that pin what runs inside the boundary rather than resting on device evidence alone, and it was among the deployments named in last year's physical-attack research, which is to say among the first to engineer against the binding gap the researchers demonstrated.

What this means

"Attested" means specific evidence about specific measurements at a specific time for a specific boundary, appraised under a policy the relying party owns.

The word gets over-read. Note that the workload is not in the measurements, the time of measurement is not the time of reliance, and the boundary in the evidence is not always the boundary in the deployment diagram.

It remains open what the right re-appraisal cadence is for any given deployment. And the past two years of physical attack research suggest that relying parties should price evidence whose threat model excludes the adversary some of them actually face. Those are questions for the deployers, the standards bodies, and the next generation of hardware.

The next time a diagram says attested, ask which of the three the word aligns with.