Supply-Chain Security & Hardware Provenance

Every other chapter in Part 11 defends the data center as it runs. This one defends the data center before it runs — and after it stops. The threat model here is not the attacker who breaches a live system but the 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 one of which is a place to substitute a counterfeit, solder in an implant, or flash a malicious firmware that survives every wipe you will ever perform.

The reason this matters more for AI infrastructure than for any prior generation of IT is asset-value density. A single NVL72-class rack (GB200 basis, 2025; GB300 NVL72 is the 2026 volume platform) is roughly $3–4M of silicon in 1.36 tonnes; a frontier training cluster concentrates billions of dollars of the most allocation-constrained, most export-controlled, most counterfeited components in the world 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), HBOM/SBOM and the Reference Integrity Manifest, OCP S.A.F.E.; and secure decommissioning, media sanitization, and the data-remanence trap on the way out. Every one of them rests on the same rule: a provenance claim you cannot independently re-verify buys you nothing.

Every supply-chain control you will or won't buy is downstream of a single question: where do you begin to trust the hardware? There are three defensible answers, and they are not equally expensive or equally strong.

Trust at the dock is the legacy default: you accept the integrator's certificate of conformance, inspect the pallet for obvious damage, and rack it. It is cheap and fast, and it is blind to everything that happened 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 against a signed platform certificate the vendor stored in the device (the NIST SP 1800-34 model). This compares an observed hardware manifest with a signed reference. A mismatch or missing reference makes the lot unverified and triggers quarantine and manual disposition; it does not by itself prove substitution, physical authenticity, cause, or in-transit tampering. Those questions also require genealogy, custody, tamper evidence, authentication, and acceptance criteria. The reference must still be populated at manufacture, which is a procurement term you must win at the contract, not 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, so provenance is not a one-time receiving check but a property you can re-verify continuously over the asset's life (the bridge into Chapter 11.4).

The consequence of choosing wrong is asymmetric. Pick 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, no network segmentation, and no confidential-computing TEE downstream can detect, because the compromise is beneath all of them. Pick silicon-trust and you pay an upfront premium in procurement terms, receiving labor, and tooling, but you have moved the security boundary to the only place that survives a sophisticated supply-chain attack. 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 (and the export-control geography keeps moving: as of Aug 2026 small licensed batches of H200s are legally entering China — ~10,000 each to ByteDance and Tencent per FT/Reuters — which makes an unauthorized H200 more suspicious, not less; Blackwell remains outside the licensed window; → Chapter 3.12): 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. ERAI's 2025 report logged 748 suspect-part submissions, with active (in-production) components at ~36% of reports — and 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 — an extra component, a modified board, a substituted firmware chip — inserted to create a covert channel or a kill switch. Implants are the nation-state threat, and they are the reason dock-trust fails against the top attacker tier: an implant added at a board house or a transshipment point is invisible to functional test and to every downstream software defense. Tampering-in-transit is the same idea applied to the logistics leg specifically — 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 traverses across borders. The defense against the second and third is the same instrument: tamper-evidence and an unbroken chain of custody, so that any opening of the package between two trusted endpoints leaves a signature you detect on receipt.

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 — critically — extend the requirements to sub-tier suppliers, because the counterfeit or the 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 is the axis that turned from a compliance footnote into a board-level constraint over 2024–2026. Two forces collide. First, concentration: leading-edge logic is effectively single-sourced at TSMC, HBM at two Korean suppliers, CoWoS packaging at a handful of lines — so a geopolitical shock to one node is a fleet-wide supply shock, and the pressure to buy from less-trusted channels to compensate is exactly the pressure that lets counterfeits in. Second, export controls: US restrictions gate where the highest-end accelerators can legally sit, which both fragments the legitimate channel and inflates a smuggling/gray-market for controlled GPUs — a market that is, by construction, a counterfeit-and-tamper vector with no provenance guarantees whatsoever. 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 — precisely the kind of trade the strategist must name explicitly rather than discover 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 entire lifecycle, and it is the leg an implant or tampering attack most cheaply exploits. The defense is to make the freight path evidentiary: tamper-evident seals and packaging that cannot be opened and re-closed without leaving a detectable signature; a documented, signed chain of custody that names every party who touched the shipment; and, for the highest-value lots, in-transit telemetry — GPS, shock, and temperature loggers that detect an unscheduled stop or an opening. The receiving process 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 here 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/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 evaluating all of that evidence against contract criteria. No one layer proves the others.

In the NIST SP 1800-34 pattern, the vendor supplies a signed platform certificate describing 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, missing certificate, or unverifiable signature means unverified: quarantine the lot, preserve evidence, investigate, and make a documented manual acceptance/rejection disposition. 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/firmware components and versions; it supports vulnerability and change review, not physical-part genealogy.
• RIM — signed expected firmware/boot measurements used by a root of trust 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 required evidence depth 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 — which is exactly why it is the favored persistence mechanism for a sophisticated adversary and the reason firmware assurance belongs in the supply-chain chapter, not just the operations one. The problem at fleet scale is that you cannot audit every supplier's firmware yourself, and asking each operator to do so independently is enormous duplicated effort for the same images.

The OCP S.A.F.E. (Security Appraisal Framework and Enablement) program solves this by centralizing the audit: a device or firmware vendor engages an approved, independent Security Review Provider (SRP) to perform a standardized security review against a common checklist, and the resulting endorsement is something you can inherit instead of re-running — with a gap analysis required for each new firmware release so the assurance does not silently expire. The decision this hands the operator is clean: 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 must receive an evidence-backed disposition before it leaves control. NIST SP 800-88 Rev. 2 (September 2025) defines three sanitization methods, not assurance levels: Clear makes target-data access infeasible through simple, non-invasive techniques; Purge makes recovery infeasible using state-of-the-art laboratory techniques while normally preserving reusability; Destroy makes the information-storage medium unusable for data storage.

Select the method from information sensitivity, the medium, its condition, and intended disposition, then select a technology-specific technique under the current IEEE 2883 guidance and device documentation. A normal host write may not reach over-provisioned or remapped SSD cells. A dedicated device sanitize command may use qualified sanitize-overwrite, block erase, or cryptographic erase, but each technique depends on media support, implementation, coverage, preconditions, and verification. Cryptographic erase is not automatically valid merely because a drive advertises encryption, and physical destruction is not the default whenever Purge is desired. Verify execution, validate the result against the risk, and repeat or escalate when the outcome is not acceptable.

End-of-life selection is a risk decision, not a blanket SSD rule. Classify the information, identify the actual storage medium and accessible/inaccessible areas, record device health and encryption/key pedigree, choose the post-sanitization disposition, and select Clear, Purge, or Destroy accordingly. Cryptographic erase can preserve value when its preconditions and coverage are proven; qualified device sanitize-overwrite or block erase may also support Purge; Destroy is used when the risk, failed/obsolete medium, policy, or 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 later options. → key management and weight protection in Chapter 11.8; ITAD mechanics in Chapter 14.9.