The root of trust
Hardware attestation for self-hosted AI in regulated firms. Everything above it is contingent.
What the previous three pieces assumed
The first piece in this series made the case for self-hosting. The second established the model supply chain discipline: hash the weights on arrival, hold the keys under firm-controlled custody, pin the model version with named authority. The third went one layer down, into the data: corpus provenance, retrieval integrity, prompt injection surface.
Every control in those three pieces is software. Software running on hardware. Hardware that the firm purchased from a vendor, assembled in a rack, and connected to a network.
The hardware layer has its own supply chain. Its own integrity problem. Its own governance gap. And unlike the software layers above it, a compromise at the hardware layer is not recoverable by any control the firm operates above it.
The four layers of the hardware trust chain
The GPU that runs your inference workload began as a photolithographic process at TSMC's fabs in Taiwan. It moved through NVIDIA's (or AMD's) packaging facilities, through an OEM's system integration, through a distributor's logistics chain, and arrived in your data centre. At each transition, the firmware image burned into the device's non-volatile memory could have been altered. The silicon itself carries a device identity certificate, signed by the manufacturer, that establishes its provenance. Few firms verify it.
The firm cannot verify silicon-layer integrity in any meaningful operational sense. The fab process, the die composition, the embedded fuses that set security configurations at manufacture: these are outside the firm's control and outside any audit scope the firm can practically operate. What the firm can verify is narrower and more important: that the hardware was purchased through authorised channels (not grey market, not secondary resale for production workloads), that the hardware vendor publishes transparency reports on its security posture, and that the firmware baseline shipped with the device is the manufacturer's unmodified release.
The procurement floor is the governance primitive for Layer 1. It does not solve the silicon integrity problem. It establishes the earliest verifiable point in the chain. For regulated firms subject to DORA Article 28 third-party risk requirements, the hardware manufacturer is a third-party ICT provider. The DORA third-party risk register should include the GPU vendor and the server OEM. Few firms' registers currently do.
Below the operating system sits a stack of firmware components that most security programmes treat as infrastructure, not attack surface. UEFI manages the boot sequence and hardware initialisation. The BMC provides out-of-band management: remote power cycling, console access, hardware monitoring. The Intel Management Engine (ME) or AMD Platform Security Processor (PSP) provides additional system services running in a separate execution environment below the OS. Each is a software component. Each has its own vulnerability surface. Each is updated on a cadence entirely separate from the OS and application patching cycle the firm's vulnerability management programme tracks.
The BMC deserves specific attention. It runs a full operating system (typically a Linux variant) on a dedicated processor, has access to the system bus, can read and write system memory, and maintains network connectivity independent of the host OS state. A BMC running unpatched firmware from 2023 on a server that the OS team patched to current in 2026 is a common and largely invisible risk posture. BMC firmware is absent from most hardware asset registers in current practice. Penetration testing scopes routinely exclude it. DORA and SS2/21 infrastructure reviews tend to focus on the OS layer and above.
The minimum defensible posture for the firmware layer is measured secure boot: UEFI Secure Boot enabled, with a TPM (Trusted Platform Module) recording measurements of each component in the boot chain (PCR values). The TPM's PCR chain gives the firm a cryptographic record of the boot state: every component that loaded, in sequence, as measured at boot time. If any component in the chain has been altered, the PCR values change. Remote attestation can then verify that the boot state matches an expected baseline.
Three specific controls for the firmware governance gap: include BMC firmware in the hardware asset register alongside OS versions; add BMC/UEFI firmware to the vulnerability scanning scope (Dell, HPE, and Lenovo all publish BMC CVE feeds); and define a firmware patching cadence separate from, and faster than, the OS patching cycle for production AI infrastructure.
The regulatory hook is direct. DORA Article 9 requires that ICT systems maintain integrity throughout their lifecycle. Firmware is part of that lifecycle. UEFI vendors (AMI, Phoenix, Insyde) and BMC implementation vendors are third-party ICT providers under DORA Article 3(21). They belong in the DORA third-party ICT risk register. The supply chain risk is not hypothetical: Eclypsium has documented active exploitation of BMC vulnerabilities in enterprise environments including financial services infrastructure.
The GPU is no longer a peripheral. For AI inference workloads, it is the primary compute surface: the component that processes every token, executes every model layer, holds the model weights in memory during inference. It has its own firmware (VBIOS), its own execution environment, its own attestation architecture.
NVIDIA's Confidential Computing stack, introduced with the Hopper architecture (H100/H200), is the most mature hardware attestation implementation currently available for AI workloads. The architecture has three components: GPU firmware attestation (a cryptographic measurement of the VBIOS and firmware state, signed by a device-specific key rooted in the GPU's hardware root of trust); VBIOS integrity (firmware image measured at boot and included in the attestation report); and runtime attestation (the report is issued per-session, tied to the specific workload requesting it).
The attestation report is verified against NVIDIA's certificate chain via OCSP. This is where the sovereign-deployment tension surfaces explicitly.
This is not a reason to reject hardware attestation. It is a reason to name the dependency explicitly, include NVIDIA's attestation infrastructure in the third-party risk register, and assess what the firm's posture is if that endpoint becomes unavailable or is compromised. DORA operational resilience requirements apply to this dependency: if the attestation endpoint is unavailable and the firm cannot verify GPU integrity, what is the fallback?
AMD SEV-SNP addresses the CPU-level integrity problem: memory encryption and isolation for virtual machines, with an attestation report signed by AMD's hardware root of trust. Intel TDX provides an equivalent architecture for Intel CPUs. Both carry the same structural dependency: attestation verification routes through the vendor's PKI and OCSP infrastructure.
For regulated firms at current AI infrastructure maturity, the practical posture is: enable hardware attestation where available, include the vendor attestation infrastructure in the third-party risk register, and define the manual override procedure for attestation verification failure. Document it, test it, and include it in the operational resilience scenario library.
Hardware attestation covers the boot chain. Once boot completes and the workload begins executing, the attestation boundary is the attested state: what was present at boot time. Everything that loads or executes after boot is outside the attestation scope unless the firm implements runtime integrity monitoring independently.
For a self-hosted AI inference deployment, the components that load after boot include: NVIDIA drivers (kernel module and user-space libraries), CUDA runtime, container runtime (Docker, containerd, or equivalent), orchestration layer, the inference server (vLLM, Ollama, Triton, or equivalent), and the model weights. Each is a software component in a supply chain. The hardware attestation from Layer 3 gives the firm a verified starting point. Maintaining integrity through to inference output is the responsibility of the software supply chain controls established in A2 and A3.
The connection is structural: Layer 3 hardware attestation establishes the verified boot state. Layer 2 firmware integrity establishes the trusted execution environment beneath it. A2's hash and pin discipline extends integrity through to the model weights. A3's corpus provenance controls extend it through to the inference-time inputs. The chain runs from silicon to inference output. Any break invalidates everything above it.
The specific driver supply chain risk: NVIDIA drivers are large, complex kernel modules. A malicious or tampered driver running with kernel privileges has access to GPU memory, the inference workload, and the model weights. Driver hash verification (validating the driver package against NVIDIA's published signatures before installation) is the minimum control. Driver version pinning prevents uncontrolled updates from breaking the verified baseline. A driver version change in a regulated AI deployment should receive the same governance treatment as a model version change.
The governance problem is not the probability of exploitation. It is the completeness of the control framework asserted to regulators.
The regulatory geometry
| Framework | Hardware layer application | Specific gap |
|---|---|---|
| PRA SS2/21 | Deployment scope includes the infrastructure on which the model operates. The question is not whether hardware is enterprise-grade. It is whether the firm can attest to the integrity of the environment in which its model operates. | Hardware attestation not enabled. Firmware out of scope. Third-party risk register excludes hardware vendors. |
| DORA Art. 9 + 28 | ICT systems must maintain availability, authenticity, integrity, and confidentiality throughout their lifecycle. Hardware is not carved out. GPU vendors, OEMs, firmware vendors, and attestation infrastructure providers are all third-party ICT providers subject to Article 28 risk management requirements. | In current DORA implementation practice, firmware vendors are absent from third-party risk registers. Attestation infrastructure providers (NVIDIA, AMD, Intel OCSP) are similarly unregistered. |
| MAS TRM Ch. 8 | Requires inventory of hardware components including firmware versions, and security review of firmware updates before deployment. The most prescriptive existing regulatory text on the firmware governance question. | Under-applied by non-Singapore firms with MAS scope. The firmware inventory and patching review requirements are not replicated in SS2/21 or DORA at equivalent specificity. |
What the hardware attestation gap means for firms deploying now
The absence of hardware attestation does not mean a firm cannot deploy self-hosted AI. It means the firm's current control posture rests on an unverified assumption: that the hardware layer has not been compromised. For most regulated-firm self-hosted AI deployments, this assumption is probably correct. The threat actor capable of compromising enterprise BMC firmware in a targeted attack against a financial services firm's AI infrastructure is sophisticated. The probability of exploitation is not zero but it is not high.
The governance problem is not the probability of exploitation. It is the completeness of the control framework asserted to regulators. A firm that tells its regulator it self-hosts its AI workloads and has full control over the stack is making a statement the hardware attestation gap makes incomplete. SS2/21 requires attestable claims about the deployment environment. Trusting the hardware vendor's supply chain is not attestation. It is an assumption.
- Firmware versions in the hardware asset register alongside OS versions.
- BMC and UEFI firmware in vulnerability scanning scope, with CVE feed subscriptions per OEM.
- Secure boot enabled with TPM measurement (PCR chain recorded and baselined).
- GPU attestation enabled where hardware supports it (H100/H200 with NVIDIA CC, AMD SEV-SNP, or Intel TDX).
- Firmware vendors and GPU vendors in the DORA third-party ICT risk register under Article 28.
- Named owner for hardware integrity governance, explicitly assigned rather than assumed.
This posture does not require solving the attestation sovereignty problem today. It requires naming it, registering the dependency, and including it in the operational resilience scenario library. The firm that has done this work is the firm whose regulator conversation goes smoothly when hardware supply chain risk surfaces in the next examination cycle.
The chain runs to crypto
Hardware attestation as described in this piece relies on cryptographic signatures at every layer: silicon device certificates, UEFI signing keys, TPM measurement chains, GPU attestation certificates, NVIDIA OCSP certificate chains. Every link uses current algorithms: RSA-2048 or higher, ECC P-384, SHA-256 or SHA-384.
Post-quantum cryptographic migration, targeted for completion by 2030 to 2032 under NIST's PQC standardisation timeline, requires that every one of those signatures be re-evaluated. The TPM PCR measurement chain uses SHA-256. The GPU attestation certificates use RSA. The firmware signing keys use elliptic curve cryptography. When migration to NIST's ML-KEM and ML-DSA algorithms begins in earnest, the hardware attestation layer migrates alongside the software.
The audit retention implications are material. A firm retaining signed attestation reports as evidence of inference-time hardware integrity over a seven-year financial services retention horizon will be holding reports signed with algorithms that may be considered cryptographically weak by the end of that horizon. That is A5's territory: crypto-agility across the audit retention horizon. It starts at the hardware layer.
Next in this series: crypto-agility across the audit retention horizon. Ed25519 today is correct. The PQC migration window closes before the seven-year retention horizon for financial services audit logs. The question is not whether to migrate, but whether the signatures generated now will still be verifiable when the examination request arrives.
Corrections, counterexamples, and build ideas welcome. [email protected] • Discussions • Issues • How to collaborate.
Practitioner opinion. Not legal or regulatory advice. No vendor relationships. Full disclosures.