8x H200: 8 GPUs and 4 NVSwitches Attested From the TDX Guest

In September we attested the eight GPUs of an 8x H100 node from inside its Intel TDX guest, but not the four NVSwitches that link them; our NVSwitch article keeps that history, corrections included. On 4 November 2026 we ran the same checks on an 8x H200 node, an h200-xlarge Confidential VM, with one more step for the switches, then the same evening on an 8x H100 node: on both, the four switches passed. Below: the commands that ran, the lines of output that carry the result, what changed for the switches since September, how to re-check the files on your own machine, and what the result does not prove.

Both nodes run NVIDIA’s multi-GPU Protected PCIe mode, which NVIDIA supports only on eight-GPU, four-NVSwitch HGX Hopper air-cooled systems. In this mode nvidia-smi reads CC State OFF next to Multi-GPU Mode Protected PCIe, which is the normal reading, and NVLink traffic between the GPUs is not encrypted. We come back to that last point below, because switch attestation does not change it.

How we ran it

Everything inside the VM ran over SSH, between 20:09 and 20:12 UTC. Beforehand, we drew every nonce and challenge on our own machine, outside the VM, with a cryptographically secure random generator, and passed each one in on the command line. The node was created for this capture and deleted right after it: 9.5 minutes passed between the creation request and the confirmed deletion. Five short scripts did the work. They are published as they ran, and their comments are in French.

1. Node state (p1-etat.sh): the confidential computing state of the GPUs, the GPU list and the Intel TDX guest. It only reads, except for one command shown below.
2. Tools (p2-outils.sh): pip, which the image does not have, then voltage-verify 0.2.3, which brings NVIDIA’s nv-attestation-sdk 2.7.3.
3. The eight GPUs (p3-nras.sh): NVIDIA’s Python SDK and NRAS, the method of our 10 September run on the 8x H100 node.
4. The TDX quote and the GPU tokens in one bundle (p4-tdx.sh): voltage-verify in its multi-GPU mode.
5. The four NVSwitches (p5-nvswitch.sh): first on the image as delivered, then after installing libnvidia-nscq.

The state of the node

CC State OFF is how Protected PCIe mode reports; the Multi-GPU Mode line is the one to read. The GPUs read Not Ready at boot, and the script set them Ready with sudo nvidia-smi conf-compute -srs 1:

=== nvidia-smi conf-compute -q ===

==============NVSMI CONF-COMPUTE LOG==============

    CC State                   : OFF
    Multi-GPU Mode             : Protected PCIe
    CPU CC Capabilities        : INTEL TDX
    GPU CC Capabilities        : CC Capable
    CC GPUs Ready State        : Not Ready

=== CC GPUs Ready State read Not Ready: sudo nvidia-smi conf-compute -srs 1 ===
=== nvidia-smi conf-compute -q, after -srs 1 ===

==============NVSMI CONF-COMPUTE LOG==============

    CC State                   : OFF
    Multi-GPU Mode             : Protected PCIe
    CPU CC Capabilities        : INTEL TDX
    GPU CC Capabilities        : CC Capable
    CC GPUs Ready State        : Ready

=== nvidia-smi conf-compute -gm ===
GPU 0: NVIDIA H200 (UUID: GPU-4cea7623-626a-2f0f-acd7-210d9a8a1cd3)
Protected memory size:   146115584 KiB
Unprotected memory size: 0 KiB

All eight H200s report 146,115,584 KiB of protected memory and 0 KiB unprotected; the excerpt shows GPU 0. The same file shows the Intel TDX guest: the /dev/tdx_guest device, the configfs TSM report directory and the kernel’s own messages.

kernel: 6.8.0-110-generic
systemd-detect-virt: kvm
crw------- 1 root root 10, 262 Nov  4 20:07 /dev/tdx_guest
/sys/kernel/config/tsm/report
[    0.000000] tdx: Guest detected
[   83.759009] process: using TDX aware idle routine
[   83.759009] Memory Encryption Features active: Intel TDX

The eight GPUs, through NVIDIA’s service

The SDK collects one piece of evidence per GPU inside the VM and sends it to NRAS at https://nras.attestation.nvidia.com/v3/attest/gpu. NVIDIA’s service checks each report’s signature and certificate chain, and compares the driver and VBIOS measurements with NVIDIA’s reference values. The nonce is set before any evidence is collected:

        client = cls()
        client.set_name("voltagegpu-8xh200-proof")
        client.set_nonce(nonce)
        client.set_claims_version("2.0")
        client.add_verifier(attestation.Devices.GPU, attestation.Environment.REMOTE, NRAS_GPU, "",
                            ocsp_url=OCSP, rim_url=RIM)
        evidence = client.get_evidence(options={"ppcie_mode": False})
        print(f"evidence items: {len(evidence)}", flush=True)
        ok = client.attest(evidence)
        print(f"attest(evidence) -> {ok}", flush=True)
        token = client.get_token()

=== NRAS ATTESTATION ppcie_mode=False (not standalone) (gpu) ===
Tenant nonce, drawn outside the VM: eed65ea59bfab77f38837eeaa3b1787724703d142712f91aa9dac37a50881fcb
/tmp/nras_8gpu.py:36: DeprecationWarning: nv-attestation-sdk is deprecated and will reach end of support on September 15, 2026. Please migrate to the C++ SDK: https://github.com/NVIDIA/attestation-sdk. Migration guide: https://docs.nvidia.com/attestation/attestation-client-tools-sdk/latest/migration_guide.html
  client = cls()
Nonce generated: eed65ea59bfab77f38837eeaa3b1787724703d142712f91aa9dac37a50881fcb
Number of GPUs available : 8
Fetching GPU 0 information from GPU driver.
Fetching GPU 1 information from GPU driver.
Fetching GPU 2 information from GPU driver.
Fetching GPU 3 information from GPU driver.
Fetching GPU 4 information from GPU driver.
Fetching GPU 5 information from GPU driver.
Fetching GPU 6 information from GPU driver.
Fetching GPU 7 information from GPU driver.
All GPU Evidences fetched successfully
evidence items: 8
**** Attestation Successful ****
attest(evidence) -> True
token bytes: 17522

Two lines need explaining. The SDK prints Nonce generated, but the value is the nonce we passed in. And it warns that nv-attestation-sdk “will reach end of support on September 15, 2026”, a date already past on the day of the run, and points to NVIDIA’s C++ SDK. We used the Python SDK because it is the method of the 10 September run that this one repeats; nothing on this page was produced with the C++ SDK.

The token file is 17,522 bytes. Its first element is an envelope the SDK makes locally (HS256, not signed by NVIDIA); the second holds NVIDIA’s summary token and one NVIDIA-signed token per GPU, issued by https://nras.attestation.nvidia.com. After the VM was deleted, our checker verified each ES384 signature against the keys NVIDIA publishes; the commands are in the re-check section below.

The TDX quote and the GPU tokens, bound to one manifest

The first round shows the GPUs to NVIDIA, but nothing in it ties them to a TDX quote. The second round does, with our open-source verifier, voltage-verify. It writes a manifest around the challenge, then asks the hardware to sign hashes of that manifest: the TDX quote carries its SHA-512 as report_data, and the NRAS tokens carry its SHA-256 as their nonce.

voltage-verify manifest --challenge "$CHALLENGE" \
  --statement "VoltageGPU h200-xlarge Confidential VM (8x H200, NVIDIA Protected PCIe mode), proof run of 2026-11-04" \
  --extra run=ppcie-8x-h200-2026-11-04 -o manifest.json 2>&1
echo "=== 2. attestation (TDX quote + NRAS), as root, --mode multi-gpu-ppcie ==="
sudo env PATH="$PATH" PYTHONPATH="$(python3 -c 'import site;print(site.getusersitepackages())')" \
  voltage-verify attest --manifest manifest.json --mode multi-gpu-ppcie -o bundle.json 2>&1

The manifest names no container image and no file: it holds the challenge, a statement and a run name. The bundle therefore binds the quote and the GPU tokens to our challenge, not to a workload. After the VM was deleted, we checked the bundle on our own machine, with Intel’s collateral fetched live:

[PASS] manifest.format       manifest is well formed
[PASS] manifest.commitments  bundle commitments match the manifest
[PASS] manifest.challenge    challenge is the one this verifier issued
[PASS] tdx.structure         TDX quote v4, TEE 0x81, 4936 bytes
[PASS] tdx.debug             TD attributes 0000001000000000 (0x10000000), DEBUG (bit 0) off: not a debug TD
[PASS] tdx.report_data       quote report_data equals SHA-512 of the manifest
[PASS] tdx.signatures        attestation key, QE binding, QE report and PCK chain verify up to the pinned Intel SGX Root CA
[PASS] tdx.collateral        TCB info and QE identity signed by Intel (Intel PCS, fetched now)
[PASS] tdx.tcb               platform TCB UpToDate, QE UpToDate, TDX_01 UpToDate
[PASS] tdx.revocation        PCK certificate not revoked (57 entries in CRL)
[PASS] tdx.revocation        PCK CA certificate not revoked (0 entries in CRL)
[PASS] nvidia.signatures     9 NVIDIA-signed tokens verify, keys from the bundle chained to a pinned NRAS intermediate (NVIDIA's live JWKS fetched for its intermediates)
[PASS] nvidia.nonce          NRAS eat_nonce equals SHA-256 of the manifest
[PASS] nvidia.policy         overall result true, every GPU: measurements ok, secure boot on, debug off, nonce matched, report signature and chain validated
[PASS] nvidia.freshness      token issued 2s from bundle creation

TDX: MRTD eea8b6a814569a52bd1e12f6b869bb2d...  TCB UpToDate  QE UpToDate
GPU: GPU-0 GH100 driver 595.71.05 vbios 96.00.CF.00.02 measurements success
GPU: GPU-1 GH100 driver 595.71.05 vbios 96.00.CF.00.02 measurements success
GPU: GPU-2 GH100 driver 595.71.05 vbios 96.00.CF.00.02 measurements success
GPU: GPU-3 GH100 driver 595.71.05 vbios 96.00.CF.00.02 measurements success
GPU: GPU-4 GH100 driver 595.71.05 vbios 96.00.CF.00.02 measurements success
GPU: GPU-5 GH100 driver 595.71.05 vbios 96.00.CF.00.02 measurements success
GPU: GPU-6 GH100 driver 595.71.05 vbios 96.00.CF.00.02 measurements success
GPU: GPU-7 GH100 driver 595.71.05 vbios 96.00.CF.00.02 measurements success

RESULT: VERIFIED

Fifteen checks pass. Offline, with the collateral stored in the bundle, the result is the same; only the two lines that name the source of Intel’s collateral and of NVIDIA’s keys change (verify-offline.txt). Under an all-zero challenge the same bundle is refused, with challenge differs from the one this verifier issued (replay or foreign bundle) and RESULT: NOT VERIFIED (manifest.challenge) (verify-wrong-challenge.txt). The selftest rejected nine kinds of tampering with the bundle (verify-selftest.txt).

The NVSwitches: what changed since September

The node has four NVSwitches, which carry the NVLink traffic between the eight GPUs. They are on the guest’s PCI bus, where lspci lists them as GH100 [H100 NVSwitch]; NVIDIA’s claims identify them as LS_10.

=== lspci -nn | grep -i nvswitch ===
09:00.0 Bridge [0680]: NVIDIA Corporation GH100 [H100 NVSwitch] [10de:22a3] (rev a1)
0a:00.0 Bridge [0680]: NVIDIA Corporation GH100 [H100 NVSwitch] [10de:22a3] (rev a1)
0b:00.0 Bridge [0680]: NVIDIA Corporation GH100 [H100 NVSwitch] [10de:22a3] (rev a1)
0c:00.0 Bridge [0680]: NVIDIA Corporation GH100 [H100 NVSwitch] [10de:22a3] (rev a1)

Both attempts below ran the same Python code, with NVIDIA’s SDK in remote mode: collect the switch evidence in the guest, then send it to NRAS at https://nras.attestation.nvidia.com/v3/attest/switch, each time on a new nonce of ours.

def main():
    nonce, out = sys.argv[1], sys.argv[2]
    try:
        from nv_attestation_sdk import attestation  # noqa: F401  (configures the SDK logging)
        from nv_attestation_sdk.nvswitch import attest_nvswitch_remote
    except Exception:
        traceback.print_exc()
        return 3
    print(f"Tenant nonce, drawn outside the VM: {nonce}", flush=True)
    options = {"ppcie_mode": False, "no_gpu_mode": False}
    try:
        evidence = attest_nvswitch_remote.get_evidence(nonce, options) or []
    except Exception:
        traceback.print_exc()
        evidence = []
    print(f"switch evidence items: {len(evidence)}", flush=True)
    ok, token = attest_nvswitch_remote.attest(nonce, evidence, {"verifier_url": NRAS_SWITCH, "claims_version": "2.0"})
    print(f"NRAS switch attestation -> {ok}", flush=True)

Attempt A: the image as delivered

The image ships no NSCQ library, which the SDK needs to read evidence from the switches. The result is the one we got on 10 September on the 8x H100 node:

=== NSCQ library on the stock image ===
no nscq package installed
ls: cannot access '/usr/lib/x86_64-linux-gnu/libnvidia-nscq*': No such file or directory

=== A. method of 10 September: switch evidence and NRAS, ppcie_mode False, stock image ===
Tenant nonce, drawn outside the VM: 77f046c9397afbb1877043e8827be289adaba48d0a71c271ffcd02a0d4835ab5
python3: undefined symbol: nscq_session_create
switch evidence items: 0
**** Attestation Failed ****
Error in Nvswitch Attestation using NRAS due to: {'status': 'BAD_REQUEST', 'errorCode': 4005, 'message': 'INVALID_EVIDENCE', 'debugMessage': 'Invalid Evidence, please provide valid evidence', 'fieldName': 'evidences', 'timestamp': '2026-11-04 08:11:35'}
NRAS Response Code: 400
NRAS switch attestation -> False
exit code: 1

No library, no switch evidence, and NRAS answers INVALID_EVIDENCE, error code 4005. A tenant who stops here gets no switch attestation.

Attempt B: libnvidia-nscq at the driver’s version

As NVIDIA advised on nvtrust issue 153, the package to use is libnvidia-nscq without a branch suffix, from NVIDIA’s own repository, at the version of the driver. The script reads the driver version, adds NVIDIA’s network repository and installs that exact version. PILOTE is French for driver.

. /etc/os-release
DIST=$(echo "$VERSION_ID" | tr -d .)
PILOTE=$(nvidia-smi --query-gpu=driver_version --format=csv,noheader | head -1)
echo "driver ${PILOTE}, target package libnvidia-nscq=${PILOTE}-1ubuntu1, repository ubuntu${DIST}"
wget -q "https://developer.download.nvidia.com/compute/cuda/repos/ubuntu${DIST}/x86_64/cuda-keyring_1.1-1_all.deb" -O /tmp/cuda-keyring.deb \
  && sudo dpkg -i /tmp/cuda-keyring.deb 2>&1 | tail -2
sudo apt-get -o DPkg::Lock::Timeout=90 update -qq 2>&1 | tail -3
apt-cache policy libnvidia-nscq 2>/dev/null | head -8
sudo DEBIAN_FRONTEND=noninteractive apt-get -o DPkg::Lock::Timeout=90 install -y -q "libnvidia-nscq=${PILOTE}-1ubuntu1" 2>&1 | tail -4
dpkg -l 2>/dev/null | grep -i nscq || echo "libnvidia-nscq NOT installed"
ls -l /usr/lib/x86_64-linux-gnu/libnvidia-nscq* 2>&1 | head -5

=== B. same call after installing libnvidia-nscq pinned to the driver (NVIDIA network repository, method of 19 September) ===
driver 595.71.05, target package libnvidia-nscq=595.71.05-1ubuntu1, repository ubuntu2404
Unpacking cuda-keyring (1.1-1) over (1.1-1) ...
Setting up cuda-keyring (1.1-1) ...
libnvidia-nscq:
  Installed: (none)
  Candidate: 620.70.06-1ubuntu1
  Version table:
     620.70.06-1ubuntu1 600
        600 https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64  Packages
     615.71.10-1ubuntu1 600
        600 https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64  Packages

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.
ii  libnvidia-nscq                        595.71.05-1ubuntu1                      amd64        NVSwitch Configuration and Query library
lrwxrwxrwx 1 root root      19 Apr 24  2026 /usr/lib/x86_64-linux-gnu/libnvidia-nscq.so -> libnvidia-nscq.so.2
lrwxrwxrwx 1 root root      21 Apr 24  2026 /usr/lib/x86_64-linux-gnu/libnvidia-nscq.so.2 -> libnvidia-nscq.so.2.0
lrwxrwxrwx 1 root root      27 Apr 24  2026 /usr/lib/x86_64-linux-gnu/libnvidia-nscq.so.2.0 -> libnvidia-nscq.so.595.71.05
-rw-r--r-- 1 root root 1586224 Apr 24  2026 /usr/lib/x86_64-linux-gnu/libnvidia-nscq.so.595.71.05

The pin matters. In NVIDIA’s repository, apt’s candidate was 620.70.06-1ubuntu1, which does not match the 595.71.05 driver; the script asked for 595.71.05-1ubuntu1, and that is the version dpkg lists as installed. Then the same Python code as in attempt A, on a new nonce:

Tenant nonce, drawn outside the VM: 000ce30c44d14be0b5e7e736d0801b50315c534eadcdeef241e5ac5c73217498
Getting evidence details for SWX-E7DAEE16-A0CE-2AF1-D01A-19731D106532
Getting evidence details for SWX-CB70CE3A-0AB8-D30F-832C-EF9631BAE408
Getting evidence details for SWX-BD08A864-EC9F-B67F-0B30-8BE843723507
Getting evidence details for SWX-16193CCB-D5C4-A9B9-83D4-DCE9B660955D
All nvSwitch Evidences fetched successfully
switch evidence items: 4
**** Attestation Successful ****
NRAS switch attestation -> True
switch token bytes: 7410

Evidence from the four switches, and Attestation Successful from NRAS. After the VM was deleted, our checker verified the switch tokens against the keys NVIDIA publishes and printed the claims of each switch:

[NVSwitch] summary: ES384 signature OK (kid nv-eat-kid-prod-20261104190947098-fb174330-770b-431a-b511-b606be9b6e75), iss https://nras.attestation.nvidia.com, overall True, eat_nonce matches: True
[NVSwitch] SWITCH-0: ES384 signature OK, eat_nonce matches: True, {"dbgstat": "disabled", "hwmodel": "LS_10", "measres": "success", "secboot": true, "switch-attestation-report-cert-chain-validated": true, "switch-attestation-report-nonce-match": true, "switch-attestation-report-signature-verified": true, "switch-bios-version": "96.10.6D.00.01"}
[NVSwitch] SWITCH-1: ES384 signature OK, eat_nonce matches: True, {"dbgstat": "disabled", "hwmodel": "LS_10", "measres": "success", "secboot": true, "switch-attestation-report-cert-chain-validated": true, "switch-attestation-report-nonce-match": true, "switch-attestation-report-signature-verified": true, "switch-bios-version": "96.10.6D.00.01"}
[NVSwitch] SWITCH-2: ES384 signature OK, eat_nonce matches: True, {"dbgstat": "disabled", "hwmodel": "LS_10", "measres": "success", "secboot": true, "switch-attestation-report-cert-chain-validated": true, "switch-attestation-report-nonce-match": true, "switch-attestation-report-signature-verified": true, "switch-bios-version": "96.10.6D.00.01"}
[NVSwitch] SWITCH-3: ES384 signature OK, eat_nonce matches: True, {"dbgstat": "disabled", "hwmodel": "LS_10", "measres": "success", "secboot": true, "switch-attestation-report-cert-chain-validated": true, "switch-attestation-report-nonce-match": true, "switch-attestation-report-signature-verified": true, "switch-bios-version": "96.10.6D.00.01"}
[NVSwitch] RESULT: ALL CHECKS PASS

For each switch, the report carries our nonce, its signature and certificate chain are valid, the measurement result is success, secure boot is on and debug is disabled. All four run BIOS 96.10.6D.00.01. The full claims, including the five on the BIOS reference measurements (fetched, signature verified, schema validated, certificate validated, measurements available), are in nvswitch-diag.txt.

Why it passed here and failed on 19 September

On 19 September, on an 8x H100 node, the same driver-matched library let NVIDIA’s nvattest tool open the NSCQ session and collect switch evidence. What failed was the local verification that nvattest runs inside the guest: it checks certificate revocation with NVIDIA’s OCSP responder, ocsp.ndis.nvidia.com, and the guest could not reach it over TLS. On 27 October, capturing the traffic on a single-GPU H100 VM, we traced that kind of failure to the network path: TCP connections from the guest to NVIDIA’s OCSP and RIM servers are cut intermittently, and a plain curl fails almost as often as the tool (public capture).

On 4 November the evidence went to NRAS instead, and NRAS ran the certificate and revocation checks on NVIDIA’s side. The node type and the verification path both differ from 19 September, so the 8x H200 run alone could not tell which of the two made the difference. The 8x H100 run below answers it: on the node type of 19 September, whose guest still failed 7 of 20 TLS attempts to the OCSP responder that evening, the switches passed through NRAS too. That rules out the node type and points to the verification path (local checks in the guest on 19 September, NVIDIA’s side on 4 November).

The 8x H100 node

At 22:28 UTC the same evening we ran the same phases on an 8x H100 node, an h100-xlarge Confidential VM (NVIDIA H100 SXM5 80GB, driver 595.71.05, VBIOS 96.00.CF.00.01), on new challenges drawn on our own machine. The node was deleted 9.8 minutes after the creation request.

• NVIDIA’s remote attestation service returned Attestation Successful for all eight GPUs: measurements success, secure boot on, debug disabled, nonce matched.
• The voltage-verify bundle, with the Intel TDX quote (4,936 bytes, TCB UpToDate) and the eight GPU tokens bound to one manifest, verified outside the VM online and offline; a wrong challenge was rejected, and the selftest rejected nine kinds of tampering.
• The switches behaved as on the 8x H200. On the image as delivered: undefined symbol: nscq_session_create, then INVALID_EVIDENCE. With libnvidia-nscq 595.71.05 installed in the guest: Attestation Successful for all four (LS_10, BIOS 96.10.6D.00.01). These are the first switch tokens we have for an 8x H100 node.
• From the same guest we repeated the TLS test to NVIDIA’s OCSP responder: 13 of 20 handshakes completed, 4 connections were reset and 3 timed out, with the TCP connection established every time. The network-path issue of 27 October is still there; the NRAS path does not depend on it.

Files, checksums and the replay commands: ppcie-8x-h100-2026-11-04, also in the public evidence repository. The same limits apply as for the 8x H200: one run, a package the image does not ship, a separate call not bound to the TDX quote, and nothing about NVLink encryption.

Re-check it yourself

You need the files and Python 3 with pip; no account and no GPU. Download bundle.json, nras_token.json, nras_switch_token.json and check_raw_tokens.py into one directory, then run the commands of the folder’s README.

pip install "voltage-verify>=0.2.3"
voltage-verify verify bundle.json --offline --hwmodel GH100 --gpus 8 \
  --challenge 5fe630be5d8455ca3bca9f9bee88d66915c91df39f2136186fbcb2530ef6a206
voltage-verify selftest bundle.json
pip install "PyJWT[crypto]>=2.7"
python check_raw_tokens.py \
  nras_token.json eed65ea59bfab77f38837eeaa3b1787724703d142712f91aa9dac37a50881fcb \
  nras_switch_token.json 000ce30c44d14be0b5e7e736d0801b50315c534eadcdeef241e5ac5c73217498

voltage-verify checks the TDX quote up to the Intel SGX Root CA pinned in the tool and the NVIDIA tokens up to a pinned NRAS intermediate, using the collateral stored in the bundle. Expect the fifteen [PASS] lines of verify-offline.txt and RESULT: VERIFIED. The challenge must be the one in the manifest: pass any other value and the bundle is refused. The selftest makes tampered copies of the bundle and expects each one to be rejected.

check_raw_tokens.py fetches the keys NVIDIA publishes, so it needs a connection. It checks every ES384 signature, the issuer, the overall result and the nonce, and for each device a measurement result of success, secure boot on and debug disabled. Expect the output in raw-tokens-check.txt, ending with [GPU] RESULT: ALL CHECKS PASS and [NVSwitch] RESULT: ALL CHECKS PASS.

These commands check files we captured. The proof that counts for you is a fresh run on your own VM, on your own nonce: the five scripts are linked under How we ran it, and the method is in our Confidential VM guide.

What this proves, and what it does not

What it proves:

• The VM ran as an Intel TDX trust domain, not in debug mode, on a platform whose TCB Intel rated UpToDate at the time, and the quote was produced after our challenge existed.
• Each of the eight GPUs answered our nonce with a report signed under NVIDIA’s certificate chain, and NVIDIA’s service matched its driver and VBIOS measurements with NVIDIA’s reference values, with secure boot on and debug disabled.
• With libnvidia-nscq installed, each of the four NVSwitches answered another nonce of ours with a report that NVIDIA’s service validated: signature, certificate chain, BIOS measurements, secure boot on, debug disabled.
• All of it can be checked outside the VM against Intel’s and NVIDIA’s keys: the TDX chain ends at the Intel root pinned in the verifier, and the NVIDIA tokens at keys NVIDIA publishes.

What it does not prove:

• The switch result is not bound to the TDX quote. It came from a separate call, on its own nonce. Its token is not in the voltage-verify bundle, and nothing in the quote refers to it.
• It is one run on this node. The switch result in these files comes from a single attempt, on one day.
• It needed a package the image does not ship. On the image as delivered, switch attestation fails. To get it, a tenant has to install libnvidia-nscq at the driver’s version from NVIDIA’s network repository, as above.
• NVLink traffic between the GPUs is not encrypted in this mode, and the switch tokens do not change that. NVIDIA’s white paper (WP-12554-001 v1.3, page 13) describes Protected PCIe mode this way: data between the CPU and the GPUs is encrypted through bounce buffers, “while data traffic between GPUs over NVLINK remains unencrypted”. The switch tokens say the switches run firmware matching NVIDIA’s reference measurements, with secure boot on; they leave the NVLink traffic as it is. NVIDIA’s threat model adds that, for this mode, the assessment “must also account for protection of the fabric, including NVSwitch and physical access.”
• Nothing about the software in the VM. The manifest carries a challenge, not an image digest. The quote and the tokens describe the hardware, the firmware and the trust domain at the moment of the challenge, not what ran afterwards, and not any other VM.
• Nothing about the bare metal offer. This is the Confidential VM tier (h200-xlarge). The same hardware sold as bare metal has no TDX trust domain and no attestation.
• The H200 files say nothing about the 8x H100 node. That node has its own section above.

In short: The 8x H200 node was attested on 4 November 2026 (Intel TDX quote and NVIDIA attestation of all 8 GPUs, Protected PCIe mode). On the 8x H200 and 8x H100 nodes, the 4 NVSwitches of each node passed NVIDIA attestation on 4 November 2026 once libnvidia-nscq matching the driver version was installed in the guest; on the image as delivered, switch attestation fails.

Files and links

• The evidence folder on this site, README first: /blog/two-proofs/evidence/ppcie-8x-h200-2026-11-04/.
• The same files in our public evidence repository, under CC BY 4.0: confidential-gpu-attestation-evidence, folder ppcie-8x-h200-2026-11-04.
• What is and is not attested, per SKU, as JSON: /api/attestation/evidence. The proofs we publish are listed on /proofs.
• Our thread with NVIDIA about NVSwitch attestation from a TDX guest: nvtrust issue 153.
• The verifier: voltage-verify on GitHub (MIT, also on PyPI).
• The switch question on the 8x H100 node, with its corrections: our NVSwitch article. The two proofs on a single-GPU H200 VM: Two Proofs, Zero Trust.

Captured on 4 November 2026, 20:09 to 20:12 UTC, inside a VoltageGPU h200-xlarge Confidential VM (8x H200), deleted after the capture, and verified outside the VM the same day.