Resources · Data security & sanitization

There is no standard for sanitizing an accelerator

It is the first question a security team asks about retired AI hardware, and there is no standards body answer to give them. This page sets out precisely where the guidance runs out — and what an honest position looks like on the other side of it.

The claim to check

Several providers cite a standard that does not mention the equipment

If you are evaluating providers for an AI estate retirement, you will encounter phrases like standards-compliant accelerator sanitization, sometimes with a specific document and revision attached. It is worth taking thirty seconds to check the citation, because in several cases the document named does not contain the word.

That is not a technicality. A control that cannot be traced to a published procedure cannot be audited against one.

We would rather explain the gap than exploit it, partly because we think it is the right way to sell something, and partly because the organisations retiring this equipment employ people entirely capable of reading the standard themselves.

The documents

What each standard covers, and where each one stops

Document	What it covers	Where it stops
NIST SP 800-88 Rev. 2	Information storage media — the sanitization programme, decision framework, verification and validation.	Does not address accelerators, on-package memory or device firmware. Revision 2 also moved technique-level detail out of scope, deferring to IEEE 2883.
IEEE 2883-2022	Storage devices and their interfaces — the technical specification NIST 800-88 Rev. 2 defers to.	Covers storage. Does not reach compute accelerators.
NSA/CSS Policy Manual 9-12	Hard copy, magnetic, optical and solid-state media, with a power-removal rule for volatile memory.	No accelerator or on-package memory entry. The volatile-memory rule applies only by analogy, and the manual itself directs out-of-scope media to a research process — an explicit acknowledgement of the gap.
R2v3	Requires a documented data sanitization plan identifying every device type and an approved method for each. Appendix B governs logical sanitization.	Device-class agnostic. Nothing accelerator-specific. It requires you to have an answer; it does not supply one.
Manufacturer erase utilities	Drives, persistent memory, controller configuration, management controller, logs and licences.	The accelerator is out of scope for every one of them. Without exception.

The system

What actually holds state in an accelerated system

Four categories, with very different answers. Most discussion of this topic collapses them into one, which is how the conversation goes wrong.

Storage media in the chassis: Not volatile. Held the datasets, checkpoints and model weights. This is the real exposure, and it is the one component class with a defensible, standards-backed sanitization path. In a dense accelerated rack there can be ninety or more of these devices.
Management controller: Not volatile. Holds credentials, network configuration, certificates and logs. Manufacturer utilities reset it to defaults — which is worth knowing, because a factory reset is not the same thing as sanitization under R2v3, and a certification programme that requires software designed to both sanitize and record will not accept one as a substitute.
On-package accelerator memory: Volatile. It is DRAM, and DRAM does not retain contents across a power-down, transport and warehousing cycle. But it is also not encrypted, so there is no cryptographic erase equivalent, and there is no published procedure, no verification step and therefore no meaningful certificate to issue.
Device firmware and configuration stores: Not volatile. These hold device configuration and service history rather than your data. They matter for authenticity and grading rather than for confidentiality — and no manufacturer publishes a reset-and-verify procedure for them.

Our position

Three rules we hold ourselves to on this equipment

Certify what can be certified

Every drive in the estate is sanitized to NIST 800-88 Revision 2 by media type and issued a certificate carrying serial, method, operator, station, timestamp and validation hash. Per device, not per lot. This is the part of the problem that has a real answer, and it is also where the real exposure sits.

Document what cannot be certified

For components with no published sanitization procedure, the honest artefact is a handling record, not a certificate. Our closeout package states plainly which components carry a certificate and which do not, so a compliance file reflects what actually happened.

Do not invent a standard

It would be straightforward to name a procedure, give it a capitalised name and imply that it satisfies something. Several providers have. We would rather your auditor find that our documentation says the same thing our sales conversation said.

How this works as a service, including what we do not claim

FAQ

What security and compliance teams ask

Is data recoverable from accelerator memory after the system is powered down?

In practical terms, no. On-package accelerator memory is DRAM, and DRAM loses its contents once power is removed — measured in seconds to tens of seconds at room temperature. Equipment that has been shut down, removed, transported and warehoused is not carrying recoverable contents in that memory. The concern that deserves attention is narrower and earlier: the interval between shutdown and removal, on your own floor, which is a physical access control question rather than a sanitization one.

Then why does it matter that there is no standard?

Because your auditor, your customer's security questionnaire and your own policy may all require documented sanitization for every data-bearing component, and because the honest technical answer above is not something you can attach to a compliance file. The gap is evidentiary rather than physical. A provider who understands that distinction will help you close the file properly; one who papers over it with a fabricated standards citation will not.

What about the research showing accelerator memory is not cleared between tasks?

It is real, it is peer-reviewed, and it spans more than a decade — but it concerns a different problem. That body of work shows that memory is not zeroed between processes or tenants on a running system, which is a multi-tenancy and driver behaviour issue. It does not show that contents survive a power-down. Conflating the two is common, and it leads organisations to demand a control that addresses neither.

Does physical destruction solve it?

It closes the evidentiary gap, and where a policy requires that for the highest-sensitivity workloads it is a legitimate choice. It is also expensive — this is high-value equipment, and destroying a high-value component to address memory that is already empty is a costly answer to a question the physics has largely settled. The right decision depends on your data classification and your risk appetite, and it should be made deliberately at scoping rather than defaulted into.

What should we require of a provider?

That they state, component by component, what their certificate covers. That they identify the storage media in the estate individually rather than by chassis. That they name any standard they cite at revision level. And that they can tell you, without hedging, which parts of the system they do not have a sanitization method for — because the correct answer to that question is not none.

Does R2v3 certification cover this?

R2v3 requires a facility to maintain a data sanitization plan identifying each device type and an approved method for each, and to have a documented fallback where sanitization is unsuccessful. It is device-class agnostic and contains nothing specific to accelerators. So certification tells you the provider has an answer written down and is audited against it — not that a recognised procedure exists for this equipment. Both things are worth knowing.

Retiring an estate and need this in writing?

We will tell you component by component what our certificate covers and what it does not, before you commit to anything.

Request an assessment (469) 718-0004