What changed, and why it matters
Revision 1 (December 2014) was a technique manual with a decision flow attached. Revision 2 (September 2025) is a program standard with techniques referenced out.
NIST published Special Publication 800-88 Revision 2, Guidelines for Media Sanitization, in September 2025 and formally withdrew Revision 1. The stated purpose is to help organizations set up “a media sanitization program with proper and applicable techniques and controls for sanitization and disposal based on the sensitivity of their information.” That sentence is the revision in miniature: program, controls, sensitivity. The document’s structure follows — an introduction and background, a summary of sanitization methods (Section 3), a media sanitization program (Section 4), references, and appendices holding the glossary, device characteristics, the certificate form, and a change log.
Four shifts matter most to anyone running or buying disposition. First, technique detail moved out: where Rev. 1 carried long per-media appendix tables, Rev. 2 says IEEE 2883 “should be consulted to determine acceptable purge sanitization techniques” and points to NSA/CSS Policy Manual 9-12 for degaussing and destruction. Second, the standard now draws a clean line between logical techniques (commands issued over the device’s interface) and physical techniques (external action on the media). Third, cryptographic erase gets detailed pre-conditions rather than a mention. Fourth, assurance is formalized: verification and validation are distinct steps, and a Certificate of Sanitization form is included.
The practical consequence is that a policy or SOP written to Rev. 1’s tables is not wrong about methods — the method names and the physics did not change — but it is silent on most of what Rev. 2 now expects an organization to be able to show.
Same three words, different document. Rev. 2 asks: who decides, on what basis, with what technique standard, verified how, validated how, and recorded where. If your program can answer those six questions, you are aligned; if it can only name a method, you are aligned with 2014.
Clear, Purge, Destroy — the definitions that carry everything
The three sanitization methods are defined in Section 3.1 with more precision than most certificates that cite them.
Clear (Section 3.1.1) “applies logical techniques to sanitize data in all user-addressable storage locations” and protects against “simple, non-invasive data recovery techniques using the same interface that is available to the user.” The key limits are in the words: logical, user-addressable, same interface. Clear does not reach spare blocks, remapped sectors, or anything a laboratory could get to by bypassing the interface.
Purge (Section 3.1.2) applies “physical or logical techniques that make the recovery of target data infeasible using state-of-the-art laboratory techniques but preserves the ISM in a potentially reusable state.” (ISM — information storage media — is the revision’s term of art.) Purge is the method for media leaving your control that you want someone to reuse: infeasible recovery, working device.
Destroy (Section 3.1.3) renders “target data recovery infeasible using state-of-the-art laboratory techniques” and results in “the subsequent inability to use the ISM for the storage of data.” Same assurance bar as Purge; the device does not survive. The standard notes Destroy is “appropriate for all hard copy and most ISM, except for logical/virtual storage” — you cannot shred a cloud volume.
| Method | Assurance target | Media afterward | Typical techniques (per IEEE 2883 / NSA guidance) |
|---|---|---|---|
| Clear | Simple, non-invasive recovery through the user interface | Reusable | Overwrite via standard commands; factory reset where it clears user-addressable space |
| Purge | State-of-the-art laboratory recovery infeasible | Reusable | Sanitize commands (block erase, overwrite, crypto erase); degaussing where appropriate to the media |
| Destroy | State-of-the-art laboratory recovery infeasible | Unusable | Shred, disintegrate, pulverize, incinerate, melt |
Rev. 2 does not define a fourth sanitization level called Disposal. Disposal is what happens to media after a sanitization decision — and the standard permits “disposal without sanitization” only when disclosure “would have no impact on the organization’s mission… and would not result in financial loss or harm to any individuals” (Section 4.3.1). Summaries that list Clear, Purge, Destroy, and Disposal as four tiers are collapsing a decision into a method.
The decision flow: confidentiality first, media type last
Section 4.3.6 and its Figure 1 are the revision’s operational core. The sentence to remember: “The decision process is based on the confidentiality of the information rather than the type of media.”
The flow starts where a security program starts. Categorize the information’s confidentiality — the standard uses FIPS 199’s low, moderate, and high impact levels, which non-federal organizations can map to their own data classification. Then decide whether the media will be reused: internal transfer, donation, refurbishment, resale — or not. Then ask whether the media will remain under organizational control. Then weigh any contextual sensitivity within the category. Only after those four judgments does the flow arrive at selecting a method — and the method selection is where media type finally enters, because it determines which techniques can achieve the chosen assurance level.
Section 4.3.3 is explicit about the reuse fork: “A key sanitization decision is whether the media… is planned for reuse (e.g., internal transfer, donations, refurbishment). If the media is not intended for reuse… the simplest and most cost-effective sanitization method can be to destroy the media.” Conversely, “purge sanitization techniques (and clear sanitization techniques, where applicable) may be more appropriate than destroy sanitization techniques when factoring in… the desire to reuse the ISM (either within the organization or by selling or donating the ISM).”
After method selection the flow continues: perform the sanitization using an approved technique, verify the operation completed, validate that the target data is infeasible to recover, and document with a Certificate of Sanitization. For an IT asset disposition program this maps directly onto triage: classify the device’s data, decide reuse or end-of-life, choose purge or destroy accordingly, and keep the record.
Rev. 2’s order of operations: confidentiality → reuse? → under your control? → contextual sensitivity → method → perform → verify → validate → certificate. A program that starts at “what kind of drive is it?” has skipped the first four steps.
The roles the standard names
Section 4.7 is the part most organizations have never had: a table of who is responsible for what in a sanitization program.
Rev. 2 enumerates responsibilities for program managers and agency heads (establish governance, resource the program), the CIO (promulgate policy that includes disposition), the information system owner (ensure maintenance and contractual arrangements protect confidentiality), the information owner or steward (understand the sensitivity of the information and supervise on-site media maintenance), the senior agency information security officer (ensure policy is implemented), the system security officer (day-to-day implementation), the property management officer (track media that is redistributed, donated, or destroyed), the records management officer (advise on retention before anything is sanitized), the privacy officer (guidance on privacy information), and users (understand confidentiality levels and handle media accordingly).
The federal titles translate easily. The roles that most often go unfilled in enterprises are the last four: property management (does anyone own the asset record from removal to certificate?), records management (has anyone confirmed retention obligations before the drive is shredded?), privacy (does anyone know which devices held regulated personal data?), and users (does the person cleaning out a storeroom know a drawer of drives is a sanitization event?). The revision’s implicit claim is that sanitization fails at the seams between these roles more often than at the shredder.
The disposition breaches in the public record are role failures — assets nobody tracked, vendors nobody supervised, records nobody kept — not technique failures. Rev. 2 is the first edition to say so in a table.
Cryptographic erase: the conditions that make it count
Section 3.2 gives cryptographic erase (CE) the detailed treatment Rev. 1 lacked — and every condition is a question a buyer can ask.
Cryptographic erase sanitizes by destroying the key that encrypted the data, leaving ciphertext nobody can read. Rev. 2 accepts it as a purge technique only when several conditions hold. The encryption must be strong enough: “the security strength of the cryptographic algorithm (including the mode of operation) used to encrypt the target data is at least 128 bits,” with random sources whose entropy matches the key length (Section 3.2.1). The data must have been encrypted from the start: CE is appropriate only where “no sensitive data has previously been stored on the ISM in plaintext form” (Section 3.2.2). All copies of the key must be sanitizable, with zeroization — overwriting the key with zeros, ones, or random data — the recommended technique (Section 3.2.3). And the implementation must be trustworthy: federal agencies must use encryption modules validated to the current FIPS 140 “in order to have assurance” of proper implementation (Section 3.2.4).
The revision also states the limitation plainly. Because the data remains on the media as ciphertext, “future recovery of the data can be a concern” for long-lived sensitive information if cryptographic weaknesses emerge. For most enterprise data that is an acceptable residual risk; for data with a decades-long sensitivity horizon, it is an argument for Destroy.
For self-encrypting drives, the operational question is whether the conditions were true at deployment — encryption enabled before the first byte of sensitive data landed — not whether a “crypto erase” command exists at retirement. The SSD, SED & NVMe field guide covers how to establish that.
CE counts as Purge when: ≥128-bit strength, encrypted from first use with no plaintext history, every key copy sanitized (zeroized), and a validated implementation. Miss one and Rev. 2 does not consider the media purged.
Verification vs. validation: two steps, not one
Rev. 2 splits assurance into two activities with different goals, and the split explains a lot about what a defensible certificate has to say.
Verification (Section 4.5.1) aims “to determine the outcome of the sanitization technique used during the sanitization operation.” For non-destructive methods it means checking “completion status of the tools and identifying errors, anomalies, and the health of the ISM” — did the sanitize command return success, did the tool log an error, did the drive report bad sectors it could not process. Verification is about the operation.
Validation (Section 4.5.2) aims “to ensure that the target data was effectively sanitized” — is the data actually infeasible to recover. Validation is about the outcome, and it has a failure branch: a validation that finds recoverable data results in rejection and a repeat “with a different technique.” For destruction, validation is the inspection that the particle size or deformation meets the specification; for logical techniques, it is read-back sampling or full verification of the addressable space.
The distinction matters because most disposition evidence stops at verification — the tool said done. Rev. 2 wants the second question answered too, and wants the answer recorded.
The Certificate of Sanitization
Section 4.6 and the appendix form make explicit what a sanitization record should contain. Compare it to the certificate you last received.
The certificate should record the media’s manufacturer, model, and serial number, its media type, the sanitization method and technique applied, the tool used, the verification method, and for the people involved the name, position or title, date, location, contact information, and signature of those performing and validating the work. It is a per-device document by construction — a serial number is a field, not a footnote.
Two implications for buyers. A certificate that lists a pallet weight and a date is not a Certificate of Sanitization in Rev. 2’s sense, however official it looks. And a certificate that names a method (“NIST 800-88 Purge”) without naming the technique and tool has skipped two fields the standard considers essential — because “Purge” on a flash drive by an unnamed tool is not a verifiable claim. Our certificate test is the thirty-second version of this section; the due-diligence scorecard scores a vendor’s sample certificate against it.
Rev. 2’s certificate is per-serial and names method, technique, tool, verification method, and the accountable people. Ask any vendor for a sample certificate and read it against that list before you read anything else.
Where the technique detail went: IEEE 2883 and NSA/CSS
Rev. 2’s most consequential editorial decision was to stop maintaining per-media technique tables and point to the standards that do.
For purge techniques, Section 3.1.2 states that “IEEE 2883 should be consulted to determine acceptable purge sanitization techniques,” and Section 4.4 expects sanitization to comply with IEEE 2883 or with a standard an organization’s policy identifies as acceptable. IEEE 2883-2022, Standard for Sanitizing Storage, is where the interface-level detail now lives: which ATA, SCSI, and NVMe commands achieve what, how block erase and cryptographic erase are performed on flash, how tape and optical are handled. Our IEEE 2883 field guide walks it.
For degaussing and destruction, Rev. 2 cites NSA/CSS Policy Manual 9-12 — the classified-media sanitization manual behind the NSA/CSS Evaluated Products Lists — and allows NSA/CSS Policy 6-22 and 9-12 as organizational policy alternatives. That is a strong signal about what “destroy” should mean even for unclassified programs: the equipment and particle-size specifications that the national security community has already evaluated. Our NSA/CSS 9-12 & NISPOM guide covers that layer.
The practical reading: a Rev. 2-aligned program cites three documents, not one — 800-88 for the program and decision, IEEE 2883 for logical and physical technique, and the NSA/CSS manual and EPLs for destruction equipment. A vendor whose SOP cites only “NIST 800-88” is citing the part that no longer specifies techniques.
Cloud, virtual, and media you don’t hold
Rev. 2 is candid about a limit Rev. 1 barely acknowledged: much of the storage an organization “retires” today is not a device it can touch.
For “logical/virtual storage (e.g., cloud storage),” Section 3.1.2 states that “cryptographic erase may be the only viable purge sanitization technique option” because “the underlying physical ISM is abstracted” and “the data owner has no direct access to the physical ISM.” Destroy is explicitly inapplicable to logical and virtual storage. And the standard tells organizations to plan for this before the fact: they “should clearly understand their purge sanitization technique options and the effectiveness of the technique prior to storing sensitive data” on such media.
The disposition implication is a sequencing one. Cloud and virtual data are sanitized at the provisioning decision — encrypt with keys you control, or accept the provider’s assurance — not at retirement. Physical media you hold remains the domain where the full flow, including Destroy, is available; which is one reason the decommissioning of on-premises hardware is the last place an organization can still exercise complete control over its data’s end of life.
Aligning an ITAD program to Rev. 2
Nothing in Rev. 2 requires an enterprise to become a laboratory. It requires a program with answers. These are the answers.
- Classify before you sanitize. Map devices to data confidentiality levels (your classification scheme standing in for FIPS 199). The method follows the classification, not the form factor.
- Make the reuse decision explicit and early. Reuse or resale → Purge with verification and validation. End of life → Destroy is usually simplest and most defensible.
- Fill the four unfilled roles. Someone owns the asset record to certificate (property), someone clears retention (records), someone flags regulated personal data (privacy), and everyone knows a drawer of drives is a sanitization event (users).
- Cite three standards in your SOP. 800-88 Rev. 2 for the program and decision flow; IEEE 2883 for technique; NSA/CSS 9-12 and the EPLs for destruction equipment. Retire any citation to Rev. 1 as current guidance.
- Treat crypto erase as a deployment decision. It counts at retirement only if encryption was on from first use with validated implementation and sanitizable keys. Establish that at imaging, not at the dock.
- Demand both assurance steps. Verification (the operation completed) and validation (the data is gone) — and a certificate that records the validation method.
- Read certificates against Section 4.6. Per serial; method, technique, tool, verification method; named, signed, dated people. Anything less is a receipt.
- Sanitize cloud at provisioning. Keys you control, or a documented provider assurance — decided before sensitive data lands.
CyberCrunch’s practice statement, for the record: sanitization and destruction performed to NIST SP 800-88 Rev. 2 with technique selection per IEEE 2883, verified and validated, and documented with serialized certificates per device. The Data Destruction Field Manual covers the same standard media-type by media-type; this guide covers the standard itself.
Classify, decide reuse, fill the roles, cite three standards, treat CE as a deployment decision, verify and validate, read certificates per serial, and handle cloud before the data lands. That is a Rev. 2 program.
Frequently asked questions
What is the difference between NIST 800-88 Rev. 1 and Rev. 2?
Rev. 2 (September 2025) keeps the Clear, Purge, and Destroy methods but rebuilds the document around a media sanitization program: it names roles, drives method selection from information confidentiality rather than media type, sets explicit conditions for cryptographic erase, separates verification of the operation from validation of the outcome, and includes a Certificate of Sanitization form. It also removes the long per-media technique tables, pointing instead to IEEE 2883 for techniques and NSA/CSS Policy Manual 9-12 for degaussing and destruction. Rev. 1 (December 2014) is formally withdrawn.
Does NIST 800-88 define Disposal as a fourth sanitization method?
No. Rev. 2 defines three sanitization methods: Clear, Purge, and Destroy. Disposal is what happens to media after the sanitization decision, and the standard allows disposal without sanitization only where disclosure would have no impact on the organization's mission and would not result in financial loss or harm to any individuals. Lists that present Clear, Purge, Destroy, and Disposal as four levels are conflating a decision with a method.
When does cryptographic erase satisfy NIST 800-88 Rev. 2?
When four conditions hold: the encryption has a security strength of at least 128 bits with matching entropy; no sensitive data was ever stored on the media in plaintext; every copy of the target key can be sanitized, with zeroization the recommended technique; and the implementation is trustworthy, which for federal agencies means a module validated to the current FIPS 140. The standard also notes the residual risk that ciphertext left on the media could be exposed by future cryptographic weaknesses, which argues for Destroy where data has a very long sensitivity horizon.
What should a NIST 800-88 certificate of sanitization include?
Per Section 4.6 and the appendix form: the media's manufacturer, model, and serial number; the media type; the sanitization method and the specific technique; the tool used; the verification method; and, for the people performing and validating the work, name, position or title, date, location, contact information, and signature. It is a per-device record. A document that gives a pallet weight and a date, or names a method without the technique and tool, does not meet that description.
Does NIST 800-88 Rev. 2 still tell me which technique to use for each media type?
Largely not. The revision delegates technique detail: it says IEEE 2883 should be consulted to determine acceptable purge techniques and expects sanitization to comply with IEEE 2883 or a standard your policy identifies as acceptable, and it cites NSA/CSS Policy Manual 9-12 for degaussing and destruction. A current sanitization SOP therefore cites three documents, with 800-88 supplying the program structure and decision flow rather than the command-level instructions.
Sanitization to Rev. 2 — verified, validated, and certified per serial
CyberCrunch performs sanitization and destruction to NIST SP 800-88 Rev. 2 with technique selection per IEEE 2883 — verified, validated, and documented with serialized certificates that carry the fields Section 4.6 asks for. Ask for a sample certificate and read it against this guide.
This guide is informational only and reflects NIST Special Publication 800-88 Revision 2, Guidelines for Media Sanitization (September 2025), as published by the National Institute of Standards and Technology, together with the referenced IEEE and NSA/CSS documents, as of September 2026. Quotations are from the published standard; section numbers refer to that edition. It is not legal or compliance advice, and it does not certify any organization’s conformance; standards are revised, and organizations should read the current publication at csrc.nist.gov and consult qualified counsel or a security professional before relying on any summary. CyberCrunch practice statements reflect its procedures at the time of publication.