Enterprise AI GPU Data Security at End-of-Life — Part 2: The ITAD Access Gap and Three Paths to Certified Remarketing

GPU data security at end-of-life is more complex than the industry acknowledges — and the gap between shredding and certified remarketing is where billions in value disappear

GPU Resource, in partnership with Cirkadis | June 2026 | Part 2

When a hyperscaler or financial institution retires a cluster of NVIDIA H100s, the hardware doesn’t always find its way to the secondary market. In some cases, it gets shredded — physically destroyed at significant cost, with tens of thousands of dollars per unit written off rather than recovered.

Understanding why this happens — and why it doesn’t have to — is the subject of this paper. Part 1 examined the hardware in detail and reached a finding that reframes the disposal question: an enterprise AI GPU is not one memory but three. Its high-bandwidth memory (HBM) is volatile — it clears completely when power is removed, so it needs no active sanitization. Its VBIOS and its Baseboard Management Controller (BMC), by contrast, are non-volatile flash: they retain firmware, configuration, administrative credentials, and network topology indefinitely after power-off, and must be actively sanitized before a GPU is remarketed. IEEE 2883-2022 assigns each layer a specific method — Purge for the volatile memory (§8.9.1.2, power-off), Clear for the non-volatile flash (§8.8.1, factory reset), with Purge not applicable to embedded flash and any higher assurance routed to Destruct. This second paper applies that foundation to the ITAD and secondary-market channel, where the real obstacle is not knowing what to sanitize, but the structural ability of an independent processor to execute and document it.

Research conducted by GPU Resource in partnership with Cirkadis, a leading aftermarket processor of GPUs, whose lab testing on retired DGX A100 and H100 systems validated the technical claims in this article. Cirkadis is a sponsor company to GPU Resource.

The Compliance Gap That Drives Shredding

Faced with this compliance reality and the absence of a well-defined, certified GPU-specific sanitization standard, risk-averse security teams in financial services, healthcare, and AI-IP-sensitive enterprises are making the documented decision to destroy rather than remarket. Public ITAD case studies confirm this as observed market behavior, not hypothesis — STS Electronic Recycling, a NAID AAA-certified, R2v3-certified processor, publicly describes physical shredding of entire GPU chassis for AI data center clients, citing financial-services data-destruction requirements and internal AI-model-IP-protection policy as the driving compliance need.

The 3rd-Party Access Problem: Why Independent ITADs Can’t Close the Loop Alone

The compliance target above is the same in any modern data center — sanitization demonstrated to the IEEE 2883-2022 tiers (Clear/Purge/Destruct), evidenced under a recognized ITAD audit framework (SERI R2v3 Appendix B and ADISA 8.0), at a level sufficient to satisfy the client’s governing data-protection regime (HIPAA, GDPR, PCI DSS, FTC Safeguards Rule). The mechanics are familiar: define the data classification, apply the appropriate sanitization tier at each hardware layer, document the result, retain the certificate. What changes when the asset in question is an enterprise AI GPU is not the compliance framework — it is the structural ability of an independent 3rd-party ITAD to actually execute against that framework. GPU Resource’s research with Cirkadis surfaced four access constraints that, in combination, make a fully independent GPU sanitization workflow structurally hard to assemble.

The NVIDIA Enterprise Support Entitlement Gate

The firmware update tooling required to perform VBIOS re-imaging and BMC factory reset on DGX-form-factor enterprise AI GPUs — nvfwupd and the .fwpkg firmware bundles it consumes — is distributed exclusively through the NVIDIA Enterprise Support Portal. Portal access requires an active support entitlement. NVIDIA’s own Enterprise Support and Services User Guide states: “Support entitlements are non-transferable, non-assignable and may be terminated when the product is transferred to another party.” [14]

When a DGX system reaches an independent 3rd-party ITAD, the entitlement that authorized access to the firmware update tooling has typically terminated. The ITAD has the asset; the entitlement and its tools live with the original purchaser. The open-source open-nvfwupd utility on NVIDIA’s GitHub will run for anyone, but the signed firmware bundles it requires remain gated behind the active entitlement that the ITAD does not have.

Source: NVIDIA Enterprise Support and Services User Guide (March 2023) — establishes that support entitlements are non-transferable and may be terminated when the product is transferred to another party [14]

The Form-Factor Split

The access picture is not uniform across NVIDIA’s product line. PCIe-form-factor H100 and A100 cards installed in 3rd-party-OEM servers (Dell, HPE, Supermicro) have at least a partial OEM-channel escape: Dell, for example, publishes signed H100 PCIe VBIOS firmware on its public driver portal without requiring login or active warranty entitlement, gated only by Dell PowerEdge platform compatibility. [15] HPE’s coverage is more mixed; Supermicro’s GPU-specific VBIOS pathway is less clearly documented in public channels.

The asset class where the gate is most absolute is DGX-form-factor — SXM modules on HGX baseboards inside NVIDIA-built chassis. This is also the asset class with the highest aftermarket recovery value per unit, the highest concentration of AI-IP-sensitive data residues, and the largest installed base at major hyperscalers and AI infrastructure operators. The access problem and the value-recovery problem coincide on the same hardware.

Audit Trail vs Bytes: The Compliance Distinction That Matters

IEEE 2883-2022 and R2v3 Appendix B require documented, verified sanitization with serial-number-keyed chain of custody. The compliance question is never whether the bytes on the flash are clean. It is whether a documented, accountable actor performed the sanitization following an auditable process. Even if an ITAD could somehow get a DGX GPU into a technically clean state through an ad-hoc path, the absence of entitled-actor documentation breaks the audit trail.

NVIDIA as Competitor in the Aftermarket

NVIDIA offers two services that sit directly in the ITAD-class workspace: DGX Lifecycle Management (which explicitly includes “data sanitization and asset disposal of older systems”) and the DGX-Ready Managed Services partner program. Independent ITADs operating outside the certified partner program have no first-party NVIDIA-blessed path to perform GPU sanitization on transferred DGX assets. This is a market-structure observation that helps explain why the independent-ITAD documentation gap has not been closed from NVIDIA’s side: the structure currently routes the work into NVIDIA’s own commercial channels.

Three Paths to Defensible GPU Sanitization in the Aftermarket

The three paths described below all share the same compliance backbone: documented, verified sanitization with serial-number-keyed chain of custody, organized to satisfy IEEE 2883 sanitization tiers and R2v3 Appendix B audit requirements. The differentiator between the paths is operational, not regulatory. Each is in active use somewhere in the aftermarket today; each has trade-offs for the client and the ITAD; and each requires the same intake-documentation foundation.

Intake Documentation: What the ITAD Should Require at Receipt

Regardless of which path applies, the ITAD’s chain of custody begins at the moment of asset receipt. Before accepting custody of a retired enterprise AI GPU, the ITAD should require the client to provide written documentation of: the data classifications processed on the asset during its deployment life; any sanitization measures performed prior to retirement (tool, version, operator, timestamp, device serial number); the BMC and management network state at decommission (whether credentials and configuration were purged or remain); and whether the asset was registered under an active NVIDIA support entitlement at decommission. This documentation is not optional — it is the foundation that the rest of the workflow builds on.

Path 1 — Client-Performed Pre-Transfer Sanitization

The cleanest path from a compliance-chain perspective. The client, while their NVIDIA support entitlement is still active, runs the full nvfwupd workflow themselves: VBIOS re-imaging via update_fw, BMC factory reset via perform_factory_reset, and any required memory-clear operation. The client then provides the ITAD with a per-device sanitization certificate documenting tool version, command exit status, post-flash version confirmation, operator identity, and timestamp. The ITAD’s role in this path is verification: confirming the certificate’s claims against the received hardware, documenting the chain of custody from client transfer through ITAD intake, and issuing the final remarketing-ready compliance package. Path 1 places the operational burden on the client — which is also its limiting constraint, since the client must have the in-house capability and willingness to do the work.

Path 2 — ITAD-as-Agent at Client Site

A contractual arrangement in which the ITAD acts as the client’s authorized agent for sanitization work performed at the client’s facility, before ownership of the asset transfers. The client’s active entitlement and management credentials remain the legal basis for the work; the ITAD provides the technical execution. Path 2 is operationally useful where the client lacks the bandwidth or in-house expertise to perform the work, but wants the asset out of their environment quickly and wants the sanitization to occur before chain-of-custody complications arise. Cirkadis lab work has confirmed that Path 2 is operationally feasible when the agency contract is structured to give ITAD personnel appropriate access under the client’s authority, and that the resulting sanitization certificate has the same compliance standing as Path 1.

Path 3 — Asset-and-Firmware Bundled Transfer

The practical workhorse of the aftermarket today. The client, while their NVIDIA Enterprise Support entitlement is still active, downloads the standard NVIDIA firmware update package and nvfwupd tooling they already have rights to under their existing support agreement, and transfers them together with the asset to the ITAD. The ITAD then performs the sanitization in its own controlled facility, applying the client-supplied firmware and tooling to the specific asset they were supplied with. The compliance backbone is the same as Paths 1 and 2: documented access to the firmware by an entitled party, documented chain of custody from client download through ITAD execution, and documented per-device sanitization certificate.

The operational advantages of Path 3 are practical: the ITAD’s facility has the controlled environment, testing benches, and documentation infrastructure that field execution typically lacks, and the client’s IT and security teams are not asked to perform unfamiliar work during an already-busy decommission window. The absence of explicit NVIDIA guidance on the Path 3 workflow — bundling client-downloaded firmware and tooling with the transferring asset for ITAD execution — is precisely the gap the industry conversation now needs to address. The practice exists; the standards-body workflow to formalize and audit it does not yet.

HBM Clearing: One Step That Works for Everyone

Across all three paths, the memory layer of the GPU is the simplest. HBM is volatile DRAM; the data clears physically at power-off, satisfying IEEE 2883 Purge at the memory layer via volatility alone. For regulated environments that require documented evidence of a sanitization operation regardless of physics — particularly government, defense, and intelligence community frameworks — NVIDIA’s gpu-admin-tools utility is publicly available on GitHub at NVIDIA/gpu-admin-tools and supports Pascal-and-newer GPUs including the H100. The –clear-memory flag provides an auditable command-exit-status record for the memory-clear operation. This is the one step in the sanitization workflow that does not require any entitlement-gated tool or access. [8]

Verification and Certificate of Sanitization

The compliance value of any of the three paths is realized only at the verification step. R2v3 Appendix B requires that every sanitization operation be confirmed at the command-completion level, logged, and tied to the individual device’s serial number — and that at least 5% of logically sanitized media be independently verified by a competent party as unrecoverable. Applied to GPU sanitization, the per-device certificate of sanitization documents: device make, model, and serial number; each sanitization step performed and the tool used (with version number); the IEEE 2883-2022 sanitization tier achieved at each hardware layer (Purge at the memory layer via §8.9.1.2 power-off, Clear at the VBIOS layer via signed re-flash (§8.8.1), Clear at the BMC layer via factory reset (§8.8.1)); the verification method and confirmed outcome for each step; operator identity; date and timestamp; and the path under which the sanitization was executed (Path 1, 2, or 3). This certificate is the document that transforms a sanitized GPU into a demonstrably compliant remarketable asset. [11]

The Bottom Line

GPU Resource undertook this research with Cirkadis because the aftermarket conversation around enterprise AI GPU sanitization has lacked a technical and compliance framework. The result has been operational uncertainty for ITADs, conservative shred-rather-than-remarket decisions by risk-averse security teams, and the destruction of hardware that the secondary market could otherwise have absorbed.

The three-paths framework above is the working position GPU Resource and Cirkadis have converged on after lab-validating the technical claims. It is what is possible today. The bigger structural fix — NVIDIA explicitly blessing one of these paths as the supported independent-ITAD workflow, or the established media-sanitization standards bodies publishing a GPU-specific Appendix B addendum — is what would close the gap permanently. Until that happens, the practical wisdom for both clients and ITADs is to treat sanitization documentation as the chain-of-custody foundation it is: collected at intake, structured by path, verified at completion, and preserved as the artifact that turns a sanitized GPU into a defensibly remarketable asset.

Sources

[8] NVIDIA/gpu-admin-tools (GitHub) — github.com/NVIDIA/gpu-admin-tools

[10] IEEE 2883-2022: IEEE Standard for Sanitizing Storage — standards.ieee.org/ieee/2883/10277/

[11] SERI R2v3 Standard — Appendix B: Data Sanitization — sustainableelectronics.org/r2/

[12] NIST SP 800-88 Rev. 2 (Final, 26 September 2025): Guidelines for Media Sanitization — csrc.nist.gov/pubs/sp/800/88/r2/final

[13] STS Electronic Recycling, AI Data Center GPU Decommissioning ITAD case study — stselectronicrecyclinginc.com/ai-gpu-data-center-itad-2026

[14] NVIDIA Enterprise Support and Services User Guide (March 2023) — establishes that support entitlements are non-transferable and may be terminated when the product is transferred to another party, and that firmware/security updates are accessible only via active Enterprise Support Portal entitlement. Relevant to ongoing analysis of independent-ITAD access constraints.

[15] Dell Support — Rollback Protected Firmware for the H100 PCIE VBIOS and ERoT, distributed publicly on dell.com/support without login or warranty entitlement, gated only by Dell PowerEdge platform compatibility — dell.com/support/home/en-us/drivers/driversdetails?driverid=dthfh

Coming Next

Coming next — From H100 to B200: How the GPU Data-Security Gap Extends Across the NVIDIA Lineage. The three-layer architecture and its sanitization constraints are not unique to the A100 and H100. The next paper traces the same data-security profile across the current and emerging NVIDIA lineage — H200, GH200 Grace Hopper, and the Blackwell B100/B200 generation — showing where the value-at-risk rises and where the mechanics shift.

Continued in Part 3: From H100 to B200 →