Supply-Chain Security & Hardware Provenance

Every other chapter in Part 11 defends the data center as it runs. This one defends it before it runs and after it stops. The threat here is not an attacker who breaches a live system but one who arrives inside the hardware you bought, having compromised a component, a firmware image or a shipment somewhere along a supply chain that now spans a fab in Taiwan, HBM stacks from Korea, substrate and CoWoS packaging, a board house, an integrator, two freight forwarders and a customs broker. Any of those can host a counterfeit substitution, a soldered-in implant, or malicious firmware that can survive an ordinary OS wipe.

AI infrastructure raises the stakes through asset-value density. A single NVL72-class rack (GB200 basis, 2025; GB300 NVL72 is a separate platform profile) costs about $3.1M for the server alone in SemiAnalysis’s August 2025 model (take the rack mass for receiving and handling from the OEM you choose). A frontier training cluster packs billions of dollars of the most allocation-constrained and most export-controlled components in the world, and prime targets for counterfeiting and diversion, into a few halls. That makes the supply chain both the highest-value target and the longest, least-observable attack surface in the building.

The controls that defend it fall into four groups: supplier vetting and country-of-origin risk; tamper-evident logistics and chain of custody; cryptographic device provenance (NIST SP 1800-34 platform certificates, HBOM/SBOM and the Reference Integrity Manifest) with audited firmware (OCP S.A.F.E.); and secure decommissioning, media sanitization and the data-remanence trap on the way out. All four rest on one rule: receiving must reconcile supplier authorization, physical identity, custody, firmware measurements and acceptance results, because no single one proves the rest.

Every supply-chain control you buy or skip follows from one question: where do you begin to trust the hardware? There are three defensible answers, and they differ in cost and in strength.

Trust at the dock is the legacy default. You accept the integrator's certificate of conformance, check the pallet for obvious damage, and rack it. That is cheap and fast, and blind to everything upstream: a counterfeit memory module that passes power-on, an implant added at a transshipment point, a firmware image flashed before the truck arrived.

Trust at acceptance test adds a provenance gate at receiving. You scan each platform, build a hardware manifest, and compare it cryptographically with a signed platform certificate the vendor stored in the device (the NIST SP 1800-34 model). A mismatch or missing reference makes the lot unverified and sends it to quarantine and a manual decision. On its own it does not prove substitution or in-transit tampering; that takes the other evidence layers described below. The reference must also be populated at manufacture, a term you win in the contract, not at the dock.

Trust at the silicon is the strongest and the most demanding. A hardware root of trust on each device measures its own firmware at boot and attests it against a Reference Integrity Manifest. Provenance then stops being a one-time receiving check and becomes a property you can re-verify continuously over the asset's life (the bridge into Chapter 11.4).

The cost of choosing wrong is asymmetric. Choose dock-trust to save money, and a nation-state-tier adversary (RAND's highest attacker tier, the relevant one for frontier weights) walks an implant past you that no perimeter, network segmentation or confidential-computing TEE downstream can detect, because the compromise sits beneath all of them. Choose silicon-trust and you pay an upfront premium in procurement terms, receiving labor and tooling, but device identity and firmware evidence are anchored in silicon rather than paperwork, where you can re-verify them for the asset's life. Silicon evidence still assumes physical custody: DDRop (September 2026), run on a host the attacker controls and can touch, used a DDR5 interposer costing about $159 in parts per unit at a ten-unit build to forge Intel TDX launch measurements, and Intel and AMD treat such physical memory attacks as out of scope (→ Chapter 11.5). What you have bought is re-verifiable evidence, not a survival guarantee. The fork is irreversible in practice: provenance you did not capture at manufacture cannot be reconstructed after delivery. → asset taxonomy and attacker tiers in Chapter 11.1.

Three distinct threats live on the supply chain, and conflating them produces the wrong controls.

Counterfeiting is the substitution of a fake or repurposed part for a genuine one: re-marked older silicon, recycled e-waste components, cloned modules, factory rejects sold as good. It is overwhelmingly an open-market procurement risk. When allocation is tight and you buy GPUs, HBM or power components from brokers and gray-market distributors to hit a ramp date, you walk straight into the channel where counterfeits concentrate. The export-control picture keeps moving: small licensed H200 batches reached ByteDance and Tencent in 2026, reportedly tied to deployment in Hong Kong (FT), which makes an unlicensed H200 more suspicious, not less. Blackwell-class parts remain outside the licensed path (→ Chapter 3.12).

ERAI's 2025 report logged 748 suspect-part submissions, with active (in-production) components at ~36% of reports. The finding that matters most for AI builders is that ~24% of suspect parts passed electrical test and would have evaded detection if electrical testing were the only screen. A counterfeit that boots is the dangerous kind.

Hardware implants are deliberate malicious additions, such as an extra component, a modified board or a substituted firmware chip, inserted to create a covert channel or a kill switch. Implants are the nation-state threat and the reason dock-trust fails against the top attacker tier: one added at a board house or transshipment point may evade functional tests and software measurements that do not cover the modified component. Tampering-in-transit applies the same idea to the logistics leg: a shipment opened, modified and re-sealed between the integrator's dock and yours, exploiting the long, multi-party, low-observability freight path that AI hardware now takes across borders. The defense against implants and tampering-in-transit is the same instrument: tamper-evidence and an unbroken chain of custody, with receipt inspection and exception handling. Seals can fail to reveal a substitution, and they cannot prove firmware integrity.

Vetting is the cheapest high-leverage control in this chapter, because it shrinks the attack surface before any tamper-evidence or provenance tooling has to work. The discipline is NIST SP 800-161 cyber supply-chain risk management (C-SCRM): tier your suppliers by criticality, require security attestations proportional to tier, and extend the requirements to sub-tier suppliers. The counterfeit or implant rarely enters at your direct vendor. It enters two or three tiers down, at the component maker, the board house, or the gray-market broker your integrator quietly used to hit allocation. A vetting program that stops at tier 1 misses exactly where the threat enters.

Country-of-origin risk turned from a compliance footnote into a board-level constraint over 2024–2026, as two forces collided. The first is concentration. Leading-edge logic is effectively single-sourced at TSMC. HBM is concentrated across three vendors (SK hynix, Samsung and Micron), each of which still has to be qualified per accelerator generation. CoWoS packaging runs on a handful of lines. A geopolitical shock to one node is therefore a fleet-wide supply shock, and the pressure to buy from less-trusted channels to compensate is exactly the pressure that lets counterfeits in.

The second force is export controls. US restrictions gate where the highest-end accelerators can legally sit, which fragments the legitimate channel and inflates a smuggling and gray market for controlled GPUs. That market is, by construction, a counterfeit-and-tamper vector with no provenance guarantees whatsoever. Origin rules now reach the power side too: Executive Order 14421 (August 26, 2026) lets DOE block or unwind purchases of bulk-power equipment from covered foreign entities, including transformers, breakers, inverters, BESS and controls on the 69 kV-and-above system (Chapter 2.3).

Location evidence after delivery is starting to become a product. In December 2025 Reuters reported that NVIDIA had built opt-in fleet-management software, Blackwell first, that infers which country a GPU runs in from its network latency to NVIDIA’s servers. NVIDIA’s own announcement the same day (December 10, 2025) describes an opt-in, customer-installed telemetry service with a client agent slated to be open-sourced, and says its GPUs have no hardware tracking, kill switches or backdoors. The Chip Security Act (H.R. 3447) would make location verification mandatory on advanced chips before export. It cleared the House Foreign Affairs Committee 42–0 on March 26, 2026, but had not passed the House by mid-October 2026. Ask whether NVIDIA’s software ships for your SKU, and decide whether you want that telemetry leaving your site, before a regulator or a customer asks you to prove where your GPUs are.

The decision this forces: do you accept gray-market or unauthorized-channel parts to make a ramp date? For any facility holding frontier weights the answer is no, and the cost is a slower ramp. Name that trade explicitly rather than discover it after a counterfeit bricks a tray. → procurement framing in Chapter 1.6; the depreciation/refresh side in Chapter 14.9.

Between the integrator's verified dock and yours lies the least-observable leg of the whole lifecycle, and the one an implant or tampering attack exploits most cheaply. The defense is to make the freight path evidentiary. Use tamper-evident seals and packaging. Log each seal by ID and photograph, and compare it with that record at every handoff. Keep a signed chain of custody that names every party who touched the shipment. For the highest-value lots, add in-transit telemetry (GPS, shock and temperature loggers) that detects an unscheduled stop or an opening. In 2006 the Los Alamos vulnerability-assessment team (later at Argonne) reported defeating 244 seal designs, commercial and government, with low-tech methods; the median attack took 43 seconds. How you inspect counts as much as the seal itself. Receiving then becomes a verification step, not an unboxing: seal intact, custody log complete, telemetry clean, or the lot is quarantined and re-verified, not racked.

The decision is which shipments get the full treatment, because tamper-evident logistics with custody attestation and telemetry is not free and does not scale to every cable reel. The rational policy tiers it by what the shipment can compromise: full chain-of-custody and tamper-evidence for accelerators, server boards, BMCs, and anything firmware-bearing; lighter handling for commodity passive and mechanical components. Skip the tiering and you either overspend on tamper-evidence for power cabling or, far worse, under-protect the one shipment whose compromise matters: the trays that hold the silicon that holds the weights.

Supply-chain assurance is a stack of distinct questions. Genealogy records the declared part or device lineage. Custody records who controlled it and when. Tamper evidence indicates whether a protected boundary may have been opened. Authentication tests a credential or identity against a trusted issuer. Measured firmware state compares current measurements with signed expected values. Acceptance is the buyer's disposition after weighing all of that evidence against contract criteria.

In the NIST SP 1800-34 pattern, the vendor supplies a signed platform certificate describing the expected components. The provisioner scans the delivered platform and compares the observed hardware manifest with that reference. A match supports that specific comparison. A mismatch, a missing certificate or an unverifiable signature means unverified: quarantine the lot, preserve the evidence, investigate, and make a documented manual acceptance or rejection decision. It is not proof that the device is counterfeit or that a particular attack occurred.

• HBOM — the declared physical bill against which an observed manifest can be compared; it does not establish custody or physical authenticity by itself.
• SBOM — declared software and firmware components and versions; it supports vulnerability and change review, not physical-part genealogy.
• RIM — signed expected firmware and boot measurements a root of trust uses to attest measured state; it does not prove the physical supply chain or commercial acceptance.

Use these layers together and keep the final acceptance decision explicit. Continuous measurement and attestation are engineered in Chapter 11.4; the evidence depth you need follows the Weights Security Level in Chapter 11.1.

Firmware is the implant surface that survives everything else. A malicious or vulnerable image in a BMC, NIC, SSD controller or power component persists across every disk wipe, OS reinstall and ownership transfer, because none of those touch it. That makes firmware the favored persistence mechanism for a sophisticated adversary, and it is why firmware assurance belongs in the supply-chain chapter as well as the operations one. At fleet scale you cannot audit every supplier's firmware yourself, and having each operator do it independently duplicates enormous effort on the same images.

The OCP S.A.F.E. (Security Appraisal Framework and Enablement) program centralizes the audit. A device or firmware vendor engages an approved, independent Security Review Provider (SRP) to run a standardized security review against a common checklist, and the resulting endorsement is something you can inherit instead of re-running. Endorsement attaches to a specific product and firmware version, identified by hash in a signed short-form report. The framework expects every production firmware version to be assessed, so check that the report covers the exact image you received.

The decision this hands the operator is clear: require an OCP S.A.F.E. (or equivalent independently audited) attestation as a procurement term for firmware-bearing devices, and require a RIM you can attest against, or accept the vendor's unverified word and own the residual. For a facility at a high Weights Security Level, the former is effectively mandatory. The audited-firmware requirement is the supply-chain half of the firmware-integrity story that Chapter 11.4 completes on the platform side.

The supply chain has a tail: storage that held weights, checkpoints or customer data needs an evidence-backed disposition before it leaves your control. In a 2019 Blancco-sponsored study of 159 used drives bought on eBay, 42% still held sensitive data, although each seller had said the drive was properly sanitized. Those were consumer resales, not data-center disposals, but a weights drive whose erasure nobody checked can fail the same way. NIST SP 800-88 Rev. 2 (September 2025) defines three sanitization methods, not assurance levels. Clear makes access to the target data infeasible through simple, non-invasive techniques. Purge makes recovery infeasible even with state-of-the-art laboratory techniques, while normally preserving reusability. Destroy makes the information-storage medium unusable for data storage.

Choose the method from the information's sensitivity, the medium, its condition and the intended disposition. Then pick a technology-specific technique under current IEEE 2883 guidance and the device documentation. A normal host write may not reach over-provisioned or remapped SSD cells. A dedicated device sanitize command may use a qualified sanitize-overwrite, block erase or cryptographic erase, but each depends on media support, implementation, coverage, preconditions and verification. Cryptographic erase is not automatically valid just because a drive advertises encryption, and physical destruction is not the default whenever Purge is desired.

End-of-life selection is a risk decision, not a blanket SSD rule. Classify the information, identify the actual storage medium and its accessible and inaccessible areas, record device health and encryption and key pedigree, choose the post-sanitization disposition, and select Clear, Purge or Destroy accordingly. Cryptographic erase can preserve the drive's value when its preconditions and coverage are proven. A qualified device sanitize-overwrite or block erase may also support Purge (NIST SP 800-88 Rev. 2, §§3.1–3.2; IEEE 2883-2022). Destroy fits when the risk, a failed or obsolete medium, policy, or an inability to validate a reusable technique requires it. A weights-bearing label raises the assurance requirement but does not replace the media-specific analysis.

Maintain custody, record the command or destruction process, verify completion, validate that the result meets the confidentiality risk, and repeat or escalate on failure. A certificate documents evidence; it does not substitute for it. Plan encryption and sanitization capability at deployment, because they determine your options later. → key management and weight protection in Chapter 11.8; ITAD mechanics, including the export license a resold accelerator can still need, in Chapter 14.9.