NIST Special Publication 800-88 is the reference most US contracts and vendor pages name.
Revision 1 came out in December 2014 and became the reference that contracts, policies and marketing pages cited for a decade. It was withdrawn on September 26, 2025, superseded by Revision 2.
So a page claiming "NIST 800-88 Rev. 1 compliant" as current practice is citing a withdrawn document. Naming Rev. 1 is still right in one case: when your own contract cites it. Then the honest move is to say so out loud rather than quietly work to something else.
The three methods, as defined
Abridged from Revision 2's glossary. The full clear entry also covers resetting a device to factory state where rewriting isn't supported, which matters and is dealt with below:
clear - applies logical techniques to sanitize data in all user-addressable storage locations for protection against simple, non-invasive data recovery techniques using the same interface available to the user.
purge - applies physical or logical techniques to render target data recovery infeasible using state-of-the-art laboratory techniques.
destroy - renders target data recovery infeasible using state-of-the-art laboratory techniques and results in the subsequent inability to use the media to store data.
Read what each one is defended against, because that's where the real difference sits. Clear protects against "simple, non-invasive data recovery techniques using the same interface available to the user." Purge and destroy both go further, to "state-of-the-art laboratory techniques."
That's the gap. Clear defeats someone with the device and the standard software. Purge defeats someone with a lab. If your data would interest the second kind of attacker, clear isn't your method.
And note that both of the stronger definitions are still bounded by what a laboratory can currently do. They're risk statements, not guarantees. A provider offering you 100% or "absolute" anything is promising something the standard itself declines to.
And destroy isn't defined as more secure than purge. It's defined by the medium being unusable afterwards. Those are different properties and people conflate them constantly.
Three things the current revision changed
Multi-pass overwriting isn't necessary. The FAQ is blunt: "Does the 'clear' method still require a multi-pass overwrite pattern as the old DoD 7-pass standard did? A: No." On flash media it achieves very little and shortens the drive's life. A pass count is a 1990s specification.
Physical destruction has limits. The same FAQ says destructive techniques like pulverizing and shredding are ineffective for medium and high security categories because of data density, and notes that IEEE 2883 deprecates them for modern drives. Modern storage packs so much into so little space that a fragment can still hold a usable amount.

Verification changed. Rev. 1 specified two separate things, and they are worth keeping apart because they cost differently. First, verification on each piece of media after sanitization. Second, a secondary verification on at least 20% of sanitized media by number of items — each of those fully verified, using a different tool, from a separate developer (§4.7). The often-quoted sampling figure is a different rule: it governs how much of a single device's addressable space a contents check should cover, and Rev. 1 works it out to about 10% — two non-overlapping samples of at least 5% per subsection. A provider quoting you "20% sampling" has merged the two. Rev. 2 removes almost all of that language and replaces it with a two-phase idea: verification, meaning inspecting the immediate outcome, and validation, meaning an organizational decision that the outcome was adequate for the sensitivity of the data.
If your internal policy still specifies the Rev. 1 regime, that's a policy choice you're entitled to keep and a provider should be able to work to it. Say so at scoping.
One thing NIST doesn't do
It doesn't certify anyone. NIST publishes guidance and operates no vendor certification program. There's no such thing as being NIST 800-88 certified, and a company claiming it is describing something that doesn't exist.
It also says should, not shall. Section 4.6 opens with "a certificate of sanitization should be completed for each ISM that has been sanitized, per the organization's policies." Good practice, not a mandate, and a provider telling you NIST requires it is overstating the document.

Is a factory reset enough?
Sometimes, and NIST says so. SP 800-88r2 defines the clear method to include "using a menu option to reset the ISM to the factory state if rewriting is not supported," and states that where rewriting isn't supported, manufacturer resets "still meet the definition for the clear sanitization method as long as the device interface available to the user does not facilitate retrieval of the original data."

On current iPhones, iPads and Apple-silicon Macs, the erase function works by destroying the encryption keys rather than the data. Apple's documentation says it "obliterates all the keys in effaceable storage and renders all user data cryptographically inaccessible." NIST classes key destruction as cryptographic erase, a purge technique stronger than clear.
Self-encrypting drives can be cryptographically erased too, but through a dedicated sanitize command rather than a menu reset. Don't assume the two are the same thing. A generic operating-system or firmware "reset" on a self-encrypting drive doesn't by itself invoke the command that performs the crypto erase, and a Windows PC with an SED is not the same case as the Apple hardware above, where the erase function is the key destruction.
What the reset doesn't do is settle the question on its own. Three things decide it.
Where the device is going. NIST says "when possible, the purge sanitization method should be used instead of the clear sanitization method." It notes that media control can change on lease return, donation, resale outside the organization or shipment to a recycler, and treats warranty exchanges that don't come back as out of organizational control outright. If the asset is leaving your control, plan for purge and treat clear as the floor.
How sensitive the data is. NIST allows an owner to accept the risk of clear for moderate sensitivity data. For regulated or high sensitivity data, don't.
What else is in the device. A reset addresses the device's own storage. NIST notes mobile devices "can contain on-board volatile memory and non-volatile removable memory," so removable cards and detached drives need separate handling.
If you're relying on the encryption path, check the preconditions. NIST adopts ISO/IEC 27040's precondition that no sensitive data was written in plaintext before encryption was established, and it warns that cryptographic erase "should not be trusted on ISM that have been backed up or escrowed" without high confidence in where those keys went.
That plaintext rule has a limit worth knowing, because it decides whether a drive is a candidate at all. Footnote 10 to Section 3.2.2 applies the prohibition only since the last sanitization, for media previously sanitized with an appropriate technique. A drive with a clean sanitization history is not disqualified by whatever was written on it before that.
Separate from the ISO/IEC 27040 preconditions, and often quoted as though it were one of them: federal agencies must use cryptographic modules validated to the current FIPS 140 standard. That is a federal requirement rather than a condition of the international standard, and it binds agencies, not everyone.
Practical test: ask which NIST method was applied per device, which technique implemented it, how it was verified, and what the certificate records. A reset with no verification record isn't evidence of anything.
Common questions
What is the NIST 800-88 Purge standard?
Purge is one of the three methods, not a standard in itself. It applies a technique that renders data recovery infeasible using state-of-the-art laboratory techniques — a higher bar than clear, which only defends against recovery through the device's own interfaces.
What is the latest revision of NIST 800-88?
Revision 2, issued September 2025. Revision 1 was withdrawn on 26 September 2025. Most vendor pages still describe Rev. 1, so check the revision before you rely on a summary.
Is NIST 800-88 a standard?
It is a Special Publication — guidance, not a binding standard, and NIST runs no certification against it. Contracts and policies frequently make it binding on you, which is a different route to the same place.
Are NIST standards mandatory?
Not by default. They become mandatory when a regulation, a contract or your own policy adopts them. DFARS 252.204-7012 is the common route for defense work. Which revision your assessor scores
What is the NIST 800-88 certificate of destruction?
NIST calls it a certificate of sanitization, provides a sample at Appendix C, and says in Section 4.6 it "should" be completed for each item of media. There is no NIST-issued certificate and no NIST vendor certification. What one should contain
What are proper data sanitization methods according to NIST?
Clear, purge and destroy, chosen against the confidentiality of the data and the media type — not a single method applied to everything.
What does NIST 800-88 define as media sanitization?
Rendering access to target data infeasible for a given level of effort. The level of effort is the part people skip, and it is what separates the three methods.
Where to read it yourself
SP 800-88 Revision 2 and the FAQ NIST published for it (dated 16 July 2026), both from NIST directly rather than through anyone's summary. The withdrawn Revision 1 is still worth having to hand if your policy cites it — the verification rules described above are in its Section 4.7.
This is general information, not legal advice. R2 Revive is not a law firm. What applies to you depends on your data, your contracts and your own policies, so check this with your counsel or compliance function before you act on it. Regulatory content on this page last reviewed: 2026-09-12 · Why we put it that way
How we handle sanitization projects · Talk to a person · Use the project checklist