GPU Attestation with NVIDIA OCSP and NVIDIA RIM Service

Confidential computing on a GPU means a hardware-based trusted execution environment isolates whatever's running on the chip from the operating system, the hypervisor, and even the person who physically owns the machine. NVIDIA's H100, and the architectures that came after it, carry this idea from the CPU into the GPU itself, which matters for AI workloads because model weights and training data are often the single most valuable thing a company owns. GPU attestation is the mechanism that proves, cryptographically, that the hardware and firmware running that workload are genuine and untampered with before any sensitive data touches the chip. Two NVIDIA services do the actual verification work behind that proof: OCSP, which checks certificate validity, and RIM, which checks firmware integrity. This piece walks through how each one operates, why they're separate but inseparable, and what an implementer has to plan for once the happy path stops holding.

Sending proprietary model weights or a customer's private inference data into a GPU that hasn't proven its own integrity is a bet no security-conscious shop should make. NVIDIA extended trusted execution environment technology to GPUs starting in 2023, and by the 2025 to 2026 window, that coverage spans H100, H200, B200, and the Vera Rubin Platform, across Hopper, Blackwell, and beyond, on premises and in the cloud. Attestation is what turns "this GPU says it's secure" into something a relying party can actually check, rather than something they take on faith.

How the H100 establishes a hardware root of trust before any attestation can happen

Attestation has to start somewhere that can't be faked, and on the H100 that starting point is silicon, not software. The chip carries an on-die hardware Root of Trust that verifies its own firmware integrity at boot, before it accepts any workload at all. If firmware doesn't check out against what's expected, the chip doesn't get to fake it later, because the check happens too early in the boot sequence for anything downstream to cover for it.

Turning on confidential mode, called CC-On, triggers a set of hardware protections that lock down the confidentiality and integrity of code and data running on the GPU. Secure and measured boot builds the actual chain of trust through that sequence, step by step. The H100 supports three modes, and they are not interchangeable. CC-Off is standard operation with no attestation guarantees at all. CC-On activates the full security feature set but disables performance counters as a tradeoff. CC-DevTools flips that around: profiling for debugging turns on, security protections turn off. That's fine for development work. It's the wrong mode for anything touching a production confidential workload, and treating it as equivalent to CC-On is a mistake worth naming plainly, since it looks identical in every way that doesn't matter until it does.

Once the GPU is up, its driver opens an SPDM session (Security Protocol and Data Model) to authenticate the device, gather attestation evidence, and negotiate a key exchange, which together establish a secure channel between the CPU's trusted execution environment and the GPU. That session produces the attestation report: a cryptographically signed set of measurements generated after the secure channel is live. The isolation guarantees aren't a policy setting sitting somewhere in firmware, either. A PCIe firewall physically blocks the CPU from reaching most GPU registers and the GPU's compute protected region memory, and an NVLink firewall does the same for peer GPUs trying to reach across. That enforcement lives in silicon, which is a meaningfully different guarantee than a software flag a sufficiently privileged attacker could flip.

The per-device certificate chain that ties a physical GPU to NVIDIA's root CA

Every H100 leaves the factory with a unique hardware-fused Device Identity Key and a matching Device Identity Certificate burned in at manufacture. From that key, the GPU derives an Attestation Key pair by mixing the fused secret with specific firmware measurements taken at boot. The private half of that Attestation Key signs the attestation report, and the resulting Attestation Certificate is itself signed by the private Device Identity Key, linking the two.

The full chain a verifier walks contains exactly five certificates. Two come straight off the GPU: the Attestation Certificate and the Device Identity Certificate. Three come from the NVIDIA kernel-mode driver: the Provisioner Certificate, the Model Certificate, and the Root Certificate, with that last one anchoring all the way back to NVIDIA's Root CA. A verifier has to walk this entire chain, link by link, to confirm the GPU's claimed identity actually matches a real device NVIDIA provisioned, before it trusts a single measurement in the attestation report.

This chain isn't an identity check that happens once and gets forgotten. It's also the exact object OCSP validation operates on, which is why certificate chain integrity gets checked before anyone bothers comparing firmware measurements against golden values. Measuring firmware against a reference is pointless if the certificate proving the GPU's identity has already been revoked. Get the order backwards and a verifier could spend cycles validating firmware on a device that should have been thrown out at step one.

What the NVIDIA OCSP service checks and why certificate validity is a separate question from firmware correctness

OCSP has one job, and it's narrower than people sometimes assume: it determines whether a certificate is currently valid or has been revoked. It says nothing about whether the firmware behind that certificate is correct. NVIDIA runs this service at ocsp.ndis.nvidia.com, and the protocol underneath is the standard OCSP handshake. A client sends a request carrying the certificate's serial number, NVIDIA's responder checks its database, and it comes back with one of three answers: good, revoked, or unknown.

During a successful attestation run, the JWT token that comes back includes per-chain OCSP status fields, covering the VBIOS RIM certificate chain and the attestation report certificate chain separately, and every certificate in each chain has to come back "good," not just the leaf certificate sitting at the end of it.

What does a revoked response actually mean in practice? If the GPU's own certificate chain comes back fully revoked, that's a signal the physical device or its firmware signing key has been compromised, and the recommended response is blunt: stop using that device and get it replaced. There's also a "hold" status, which NVIDIA uses to flag RIMs tied to pre-release driver drops. Attestation used to pass through a hold status without complaint. As of NRAS version 3.3, released December 5, 2024, that changed. Opting into pre-release driver drops now requires explicitly passing the header X-NVIDIA-OCSP-ALLOW-CERT-HOLD: true, a breaking change for anyone quietly relying on the old, more permissive behavior.

None of this touches firmware correctness, and that's the whole point of keeping the two services separate. A certificate can be entirely valid, unrevoked, sitting on good status, while the firmware attached to it has drifted from the known-good state NVIDIA originally shipped. That gap, valid certificate paired with wrong firmware, is exactly what the RIM service exists to close.

What the NVIDIA RIM service checks and what counts as a valid firmware measurement

A Reference Integrity Manifest, or RIM, is a set of golden measurements: known-good values NVIDIA generates offline and publishes alongside every driver and VBIOS release. The public endpoint sits at rim.attestation.nvidia.com. VBIOS and GPU drivers each get their own RIM, and a verifier needs both to finish a verification pass. Checking just one leaves half the firmware stack unaccounted for, and a verifier that skips the VBIOS RIM because the driver RIM already passed is checking half the surface and calling it done.

What does a RIM actually cover? For GPU inband attestation, it measures and validates static hardware configurations, firmware and VBIOS versions, hardware initialization states captured during boot, runtime and dynamic states, the driver microcode components (ucodes) the GPU loads and executes, and signed opaque data structures carrying NVIDIA's own proprietary information. The file format is TCG SWID, an XML-based standard used across all Hopper and Blackwell driver and VBIOS RIMs, and the service also exposes a REST API, documented under an OpenAPI 3 spec, that returns either signed SWID or CoRIM depending on what the caller needs.

Each RIM identifier follows a naming pattern that tells a verifier exactly what it's looking at. Driver RIMs follow NV_GPU_DRIVER_{PRODUCT}_{DRIVER_VERSION}. VBIOS RIMs follow NV_GPU_VBIOS_{BOARD_NUMBER}{SKU}{BOARD_ID}. Equivalent naming schemes exist for NVSwitch RIMs and NIC firmware RIMs. Every one of these bundles is cryptographically signed by NVIDIA, and that signature gets validated through OCSP, which is precisely why RIM and OCSP can't really be discussed as fully separate systems. They're coupled by design, not by accident of implementation.

RIM bundles live outside customer infrastructure on purpose, so that even if a customer's own environment is fully compromised, the reference values used to judge that environment stay untouched. The verifier always reaches out to NVIDIA's controlled endpoint rather than trusting a local copy an attacker could have swapped out. There's a privacy tradeoff worth naming here too: querying the RIM service means NVIDIA collects the requester's IP address, the GPU's device identity, and its device certificates, used for security, debugging, and troubleshooting.

How OCSP and RIM work together inside a single attestation verification pass

Treating OCSP and RIM as two steps a verifier picks between misreads how a real attestation run works. Both services get called within the same pass, in an order that isn't arbitrary.

First, the verifier pulls the five-certificate chain off the GPU and the driver. Then OCSP gets called to confirm every certificate in the attestation report chain is currently valid. Next, the verifier fetches the matching RIM bundles, the driver RIM and the VBIOS RIM, from the RIM service. OCSP gets called a second time here, this time to validate the RIM certificate chain itself, confirming NVIDIA's own signing key for that RIM hasn't been revoked either. Only then does the verifier compare the measurements inside the attestation report against the RIM's golden values, and if everything lines up, it produces an attestation result.

Why does the order matter so much? Comparing measurements against a RIM whose own signing certificate has been revoked would be meaningless, because there'd be no assurance the reference values themselves are trustworthy. Checking OCSP against the RIM chain specifically guards against the scenario where NVIDIA's signing infrastructure itself was somehow compromised, a lower-probability event but not a zero-probability one, and exactly the kind of edge case attestation systems exist to catch.

The two ways this can fail point to genuinely different problems, and mixing them up leads to the wrong fix. An OCSP failure on the GPU's own chain means the device or its key is compromised, and the answer is replacing hardware or pulling it from service. A RIM mismatch means the firmware currently running doesn't match the known-good state, which calls for checking whether something changed without authorization or whether the firmware is just stale and needs updating. Same failing attestation result on paper. Entirely different root cause underneath it, and treating the two as interchangeable failure modes is how teams end up replacing hardware that just needed a driver update.

NRAS as the orchestration layer that operationalizes both services

Running all of that by hand, chain retrieval, two separate OCSP calls, RIM bundle fetches, measurement comparison, for every attestation request would be a lot to wire up correctly and keep correct over time. NVIDIA's Remote Attestation Service, NRAS, hosted at nras.attestation.nvidia.com, exists to do that orchestration centrally.

When NRAS receives a GPU's attestation report as evidence, it calls the RIM service to fetch bundles matching the reported firmware, calls the OCSP service to validate both the evidence signature and the RIM signature, compares the measurements in the evidence against the golden reference values in the RIM bundle, and returns a signed attestation result token. NRAS itself runs inside a secure, attested enclave in the cloud, so the verification service is a trusted execution environment in its own right, not just a plain API sitting on some server.

A single NRAS request can cover up to eight NVIDIA confidential-computing GPUs at once, which matters for anyone running multi-GPU nodes rather than single-card setups. The response for a batch request covers all included devices within a single attestation result. That multi-device coverage is what makes confidential computing across a full node trustworthy, rather than a collection of individually-attested chips with no coordinated verification.

General availability currently covers H100, with the underlying architecture built to extend across Hopper, Blackwell (B200), and the Vera Rubin platform as those roll out. Verifiers and relying parties reach NRAS either through the NVIDIA Attestation SDK or by calling the REST API directly, depending on how much control the integration needs.

Choosing between local and remote verification, and what each mode requires

Not every deployment can or should call out to NRAS over the network, so NVIDIA supports a local verification path too. The choice between the two isn't cosmetic. It changes where the trust actually sits, and for most production fleets, the remote path is the right default.

The local verifier is a Python-based tool that checks GPU measurements by comparing an authenticated attestation report against authenticated golden measurements, entirely on the machine doing the verifying. That sounds self-contained, and it is, but it comes with a catch worth sitting with: the confidential VM now has to implicitly trust the local verifier itself. The trust assumption hasn't gone away, it's just moved inward, onto a piece of software the operator controls directly. As the number of GPU architectures supporting confidential computing grows, keeping local reference values current across a fleet gets expensive fast. Someone has to make sure every node's local copy of the golden measurements actually matches what NVIDIA currently publishes, and that someone is now a permanent line item in operations, not a one-time setup task.

Remote verification through NRAS offloads all of that, the RIM fetching, the OCSP calls, the measurement comparison, onto NVIDIA's centrally managed service, and it scales more naturally as new architectures come online since RIM and OCSP update centrally rather than requiring every client to sync a local cache. The tradeoff is a network dependency and the latency that comes with it, so client applications calling NRAS need retry logic built in, particularly for composite attestation flows where a single NRAS timeout can fail the entire attestation, since the signed result token won't be returned.

Composite attestation comes up when both a CPU trusted execution environment (Intel TDX, for instance) and an NVIDIA GPU are both in scope for a given workload. Evidence gets collected separately from each TEE: the GPU evidence goes to NRAS, the CPU quote gets verified independently, and the final result folds claims from both into a single JWT. GPU-only attestation is valid on its own terms for environments where the GPU TEE is the relevant trust boundary, though per Intel Trust Authority's own documentation, it doesn't add up to a complete confidential computing solution without a CPU TEE alongside it.

So which mode actually makes sense? For production fleets running at any real scale, remote verification through NRAS is the more sustainable path, since it sidesteps the fleet-wide reference-value maintenance burden local verification carries. Local verification earns its place in isolated or air-gapped environments where reaching NVIDIA's endpoints isn't an option, a real constraint in some deployments, just not the common one, and building a fleet-wide strategy around it when NRAS was available would be the wrong call for most teams.

What implementers need to account for beyond the happy path

Everything above describes attestation working the way it's supposed to. Production systems need policy for what happens when it doesn't work quite that cleanly.

An OCSP "unknown" response is one of those cases. The responder returns unknown when it can't determine status conclusively, and that's a real, defined outcome, not a network hiccup to retry past. Attestation policy needs to state explicitly whether unknown counts as a pass or a fail, rather than letting whatever the SDK defaults to decide that silently on the implementer's behalf. Defaulting to "pass" here because a retry didn't come back cleaner is a quiet way of turning an unresolved question into an approved GPU.

The header change from NRAS 3.3 is worth flagging again because it's the kind of thing that breaks a working pipeline without warning if nobody updates their integration. Pre-release driver RIMs now carry certificate hold status and fail attestation by default as of that release, so any team working with pre-release drivers has to explicitly pass X-NVIDIA-OCSP-ALLOW-CERT-HOLD: true or their attestation calls start failing where they didn't before. It's a small header, easy to miss in a changelog and expensive to debug in production once it bites.

OCSP and RIM aren't redundant checks stacked on top of each other for the sake of thoroughness. They answer two genuinely different questions: is this certificate still good, and does this firmware match what NVIDIA actually shipped. NRAS exists specifically because running both checks correctly, in the right order, across a fleet of GPUs, is a coordination problem that benefits from centralization rather than reinvention at every deployment.