Clear, Purge or Destroy? NIST SP 800-88 Media Sanitization Explained

NIST SP 800-88 defines three ways to sanitize storage. Clear protects against simple recovery through the normal interface. Purge makes recovery infeasible even for a well equipped laboratory while leaving the device reusable. Destroy makes recovery infeasible and the device unusable. Revision 2, published September 2025, replaced Revision 1 and points to IEEE 2883 for per device techniques.

That is the short answer. The longer one matters because the guidance most teams still quote, with its per device tables and its comfortable advice about overwriting, is the 2014 version, and NIST withdrew it on 26 September 2025. Revision 2 is a different kind of document. It asks you to run a sanitization program, pick a method by how sensitive the data is, and then prove the result, rather than look up a device in a table.

Key takeaways

• Clear, Purge and Destroy are methods, not tools. Clear uses the normal read and write interface. Purge uses dedicated sanitize commands, cryptographic erase or, for older magnetic media, a correctly matched degausser. Destroy physically ends the media.
• Revision 2 (September 2025) replaced Revision 1 (December 2014). NIST removed the per media technique tables and now points to IEEE 2883 and NSA/CSS manuals for technique detail. Cryptographic erase is the only technique Revision 2 still covers in depth.
• Multi pass overwriting is obsolete, and overwriting individual files on an SSD does not work at all.
• Degaussing is not Destroy, and shredding is not automatically enough. Revision 2 limits degaussing to magnetic media and says shred and pulverize suit only the lowest security categories.
• Cryptographic erase has preconditions. No earlier plaintext, at least 128 bit strength, zeroized keys and no surviving key copies. In the cloud it is usually your only Purge option.
• Prove it. Revision 2 splits assurance into verification and validation, and recommends a certificate of sanitization for each device.

What do Clear, Purge and Destroy mean, exactly?

SP 800-88 Revision 2 opens with a definition worth memorizing: sanitization is a process that "renders access to target data on the media infeasible for a given level of effort." The phrase "for a given level of effort" is the whole idea. Each method is defined by the effort an attacker would need to get the data back.

Clear

Clear applies logical techniques to all user addressable storage locations, using the same interface the user has (the host interface). It protects against simple, non invasive recovery. In practice that means overwriting every addressable block with non sensitive data through standard write commands or, on devices that do not support rewriting (a basic phone, a printer, office equipment), using the manufacturer's reset to factory state.

Two points about Clear trip people up. It cannot reach areas the host cannot address, and flash devices keep spare cells and perform wear levelling, so overwriting cannot touch every place data once lived. And it does not need multiple passes: NIST notes past practice ran from one pass to as many as 39, and that on overprovisioned SSDs "very little confidentiality protection is achieved" by those patterns.

Purge

Purge applies physical or logical techniques that make recovery infeasible using state of the art laboratory techniques, while keeping the device in a potentially reusable state. NIST's guidance is direct: when possible, use Purge instead of Clear.

Logical Purge techniques use dedicated, standardized sanitize commands that bypass the abstraction of normal reads and writes. Revision 2 lists overwrite, block erase and cryptographic erase as examples and sends you to IEEE 2883 for which technique is acceptable on which media. The physical Purge technique is degaussing, and only for magnetic media whose coercivity the degausser is strong enough to overcome.

Destroy

Destroy makes recovery infeasible using state of the art laboratory techniques and leaves the device unable to store data again. It applies to all hard copy and most storage media, but not to logical or virtual storage, because you cannot shred a cloud bucket.

Revision 2 lists five destructive techniques: disintegrate, incinerate, melt, pulverize and shred. Then it adds two warnings that change how many disposal programs should work:

• Bending, cutting, drilling a hole through a drive or similar emergency measures "may only partly damage" the media and leave portions readable in a lab.
• "Pulverize and shred techniques for ISM should be avoided for anything but the lowest security categories of data." As data density and material hardness rise, a shredded fragment can still hold a lot of data.

NIST's July 2026 FAQ on Revision 2 explains the reasoning. Modern storage can write data in depth, so for medium and high sensitivity data it points to high powered degaussers from the NSA evaluated products list for magnetic media, and to incineration techniques such as smelting or melting for everything else, SSDs included. The FAQ also notes that IEEE 2883 deprecates shredding and pulverizing as approved destruction methods for modern hard drives and SSDs.

What changed between SP 800-88 Rev 1 and Rev 2?

The change is bigger than a refresh. Revision 1 was a practical handbook with tables listing what to do for each media type. Revision 2 is a program guide. NIST's FAQ describes the shift plainly: Revision 1 "focused heavily on hands-on, media-specific techniques," while Revision 2 focuses on keeping sensitive information confidential by building a sanitization program.

Timeline

The specific changes

Revision 2's own change log (Appendix D) and the FAQ list what moved. The ones that matter most in practice:

• Technique tables are gone. Apart from cryptographic erase, "all sanitization technique and tool details have been replaced with recommendations to comply with IEEE 2883, NSA specifications, or an organizationally approved standard." The old appendices that described media specific techniques were removed "to improve the document's longevity."
• A new term: information storage media (ISM). It replaces "electronic (soft copy) media" so the guidance covers logical storage such as cloud, object and container storage, alongside physical drives and tape.
• Multi pass overwrite is explicitly unnecessary. The change log says this "counters the obsolete DoD 5220.22-M language." A footnote adds that DoD removed overwriting specifications from that manual (the NISPOM) back in 2006.
• Degaussing is narrowed. It is a physical Purge technique for legacy magnetic media and "does not currently constitute a destroy sanitization technique, even when it renders an ISM inoperable."
• Assurance is reworked. Full or representative sampling after Clear or Purge is "not necessary" unless your policy requires it; verification and validation replace it (covered below).
• Cryptographic erase is rewritten around ISO/IEC 19790 zeroization, SP 800-57 key types and new text on externally managed keys.
• Vendor trust is addressed. Appendix B lists what to ask storage vendors instead of assuming a command named "secure erase" does what its name says.
• The decision flow starts with reuse, and the sample certificate of sanitization was updated.

If your policy, a vendor's contract or a questionnaire answer still says "per NIST 800-88 Rev 1" or "DoD 5220.22-M three pass wipe," it is citing a withdrawn document and an obsolete pattern. That is not proof the sanitization was weak, but it is a sign nobody has revisited the process since before most of your fleet moved to flash.

Why Revision 2 leans on IEEE 2883

IEEE 2883-2022, the Standard for Sanitizing Storage, specifies "methods of sanitizing logical storage and physical storage" with technology specific requirements. Storage interfaces change faster than NIST revises special publications, so deferring to it keeps SP 800-88 stable. Revision 2 also cites the companion IEEE 2883.1 (2022) for method selection and ISO/IEC 27040 for several cryptographic erase preconditions. A policy written against Revision 2 should therefore name the technique standard it follows, not just "NIST 800-88."

Why overwriting stopped being enough: the SSD evidence

The case against overwrite on flash is not theoretical. In 2011, Michael Wei, Laura Grupp, Frederick Spada and Steven Swanson at UC San Diego wrote a recognizable pattern to SSDs, applied each sanitization technique, then took the drives apart and read the flash chips directly. Their FAST 2011 paper reported:

• Built in commands were not always implemented correctly. Of 12 drives, eight supported the ATA security feature set. One encrypted data and could not be verified. Of the other seven, only four executed ERASE UNIT reliably, and one reported success while all data remained intact.
• Whole drive overwrite was usually, but not always, sufficient when run twice.
• Per file overwrite failed every time. Between 4% and 75% of the files' contents remained on the SATA SSDs, and between 0.57% and 84.9% on the USB drives. Overwriting free space failed too.

The authors concluded that reliable SSD sanitization needs built in sanitize operations that are also verifiable, which is where Revision 2 lands fifteen years later. They also noted that USB mass storage devices did not support drive level sanitize commands, which is still why removable flash so often ends up in the Destroy column.

How to choose a method per media type

Revision 2 deliberately does not give you a per device table. It tells you to decide based on the confidentiality of the data, whether the media will be reused, and whether it will leave your control, and then to pick a technique from IEEE 2883 or another approved standard. The table below is our summary of how those principles usually land. Treat it as a starting point for your own policy, not as NIST text, and confirm the technique for each model with the vendor (Revision 2 Appendix B lists what to ask).

Decision table

Laptops and desktops are several media at once

Revision 2 reminds you that a desktop can contain a hard drive, motherboard, RAM and ROM, and a mobile device can hold onboard volatile memory plus removable non volatile memory. Each needs its own decision. Most organizations focus on the non volatile parts, as NIST suggests, but the SD card in a laptop slot or the second drive in a workstation is exactly what gets missed.

Ask the manufacturer for a Statement of Volatility. Revision 2 describes it as a vendor document listing every volatile and non volatile memory location, what each stores, whether the user can reach it, and how to erase it. It is the closest thing to a sanitization bill of materials for a device, and it is worth asking for at purchase time, not at disposal.

Phones, Macs and Android devices

Modern phones and Macs encrypt storage by default, which is why their factory reset behaves like cryptographic erase rather than a slow overwrite.

• Apple Macs. Apple's "Erase All Content and Settings" requires macOS Monterey 12 or later and a Mac with Apple silicon or the Apple T2 Security Chip. Apple says it removes all your data, settings and apps while keeping the installed macOS. Older Macs follow a different erase process.
• Android. Android documentation states that Android 7.0 and higher supports file based encryption, and that all devices launching with Android 10 and higher are required to use it. The same page describes how file based encryption keys can be securely deleted on devices whose KeyMint implementation supports rollback resistance.

Asked why Revision 2 does not recommend native platform commands, NIST's FAQ says the document covers methods rather than techniques and "refrains from endorsing specific product-related measures." You decide whether a vendor's reset meets Clear or Purge for your data, using the vendor's documentation and your validation process.

What is cryptographic erase, and when does it count as Purge?

Cryptographic erase (CE) sanitizes the keys rather than the data. If every byte on a device is encrypted under a key, and every copy of that key is destroyed, the ciphertext left behind is unreadable. Revision 2 classes CE as a logical Purge technique and notes it can be performed "with high assurance much faster than with other sanitization techniques." It is the one technique Revision 2 still covers in detail, because, as the FAQ puts it, nearly all modern SSDs are self encrypting.

The speed is real. The preconditions are where CE fails in practice.

The preconditions

Revision 2 (drawing on ISO/IEC 27040) and the FAQ set these:

1. No prior plaintext. No sensitive data may have been stored on the device in plaintext before the encryption keys were established (or since the device was last sanitized). If you turned on software full disk encryption on a laptop that had been in use for a year, CE alone cannot cover the data written before.
2. Strength. The algorithm and mode must provide at least 128 bits of security strength, and the entropy of the random sources must be at least the length of the keys. Electronic codebook (ECB) mode is not allowed.
3. Zeroization. Target keys must be sanitized by zeroization as described in ISO/IEC 19790, for example overwriting with zeros, ones or random data, and all copies must be sanitizable.
4. Validated modules for federal use. US federal agencies must use cryptographic modules validated to the current FIPS 140 standard.
5. No surviving copies. Revision 2 warns that CE "should not be trusted" on devices whose keys were backed up or escrowed unless you have high confidence in how and where those copies are managed. Backed up or escrowed copies need their own sanitization policy.
6. Clear out unwrapped keys. If a wrapped key was unwrapped into volatile memory or an encryption engine register, those copies must also be eliminated, which may mean a hard reset or powering off the device for a period.

Which keys count

Revision 2 lists four key types whose sanitization can achieve CE, following SP 800-57 Part 1: symmetric data encryption keys, symmetric key wrapping keys, symmetric master or key derivation keys, and private key transport keys. Destroying a public key does not count. It also recommends eliminating every key hierarchically below the target key, as extra protection if the target key were ever recovered.

When CE is not enough

Revision 2 adds a long term caveat. Data sanitized by CE still exists as ciphertext. If the algorithm is weakened in future, or computing advances (NIST mentions quantum computing) make key recovery feasible, the data could become readable. For information that must stay confidential for decades, NIST says CE "may not be an acceptable sanitization technique." In that case, combine CE with a physical Purge or Destroy step.

Documenting CE

You cannot inspect a destroyed key, so Section 3.2.5 lists ten extra items to record, among them the storage type, key generation, algorithm and mode, which key level was sanitized, which areas are unencrypted, whether keys were ever escrowed or injected, and how the device reports a failed key sanitization. CE's effectiveness does not depend on that paperwork, NIST says, but your organization's acceptance of it probably will.

Partial sanitization with CE

Revision 2 prefers sanitizing a whole device because data spills into remapped blocks and overprovisioned space. The FAQ allows one exception: where partial sanitization is a business necessity, such as a shared drive in a multi tenant data center, you can use CE against the keys for one partition or file, provided you have "absolute confidence" the target data never left that encrypted boundary.

For more on where key destruction falls short, see key destruction and cryptographic erasure limits and crypto shredding: when deleting the key deletes the data.

Verification and validation: proving sanitization worked

Revision 2 introduces sanitization assurance as two steps.

• Verification checks the immediate outcome. For logical techniques, check the tool's completion status, errors, anomalies and the health of the device. For physical Purge, confirm the equipment completed its cycle. For destruction, inspect the remnants and identify the equipment used.
• Validation is a decision. Someone reviews the verification results against the sensitivity of the data and either approves the sanitization as effective, accepting any residual risk, or rejects it and escalates to another technique or a stronger method.

NIST's examples of results that should be rejected include part of a device no longer being reachable through its interface, a method that does not fit the media (degaussing an SSD "can complete successfully, but no sensitive data is sanitized"), unqualified staff or uncalibrated equipment, a shredder producing optical disc fragments 50% larger than policy allows, and a single pass overwrite on an overprovisioned SSD.

Revision 2 also notes that a sanitized device often does not look factory fresh and may need reconfiguration before reuse.

What should a certificate of sanitization contain?

Revision 2 recommends completing a certificate of sanitization for each sanitized device, on paper or as an electronic record. At minimum it should record:

The sample form in Appendix C adds whether the device was operational or damaged and its destination: internal reuse, external reuse, recycling facility, manufacturer or other.

Two details from the guidance are easy to skip. First, if validation succeeds and the device's confidentiality level drops, remove any labels showing the old classification. Second, a certificate only proves that one device was sanitized. NIST points out that to know whether you are sanitizing everything, you need records when media enters your environment, when it leaves its last location, and when it reaches its destination. Without those, certificates show what you sanitized, not what you lost.

Automate where you can. Revision 2 suggests scanning model and serial bar codes into a tracking application as each device is processed, and notes that electronic records are easier to search and retain.

How does SP 800-209 treat storage infrastructure and backups?

SP 800-209, Security Guidelines for Storage Infrastructure (Chandramouli and Pinhas, October 2020), sits one layer above SP 800-88. It looks at storage systems rather than individual devices: block, file and object services, networked and cloud architectures, and the configuration errors and threats that come with that complexity. Its abstract says its storage specific recommendations address "data protection, isolation, restoration assurance, and encryption," alongside general controls such as physical security, access control, change management and incident response.

For sanitization, the link between the two documents is the copies you forget. SP 800-88 Revision 2 notes that data passes through many organizations, systems and media, and that everyone who stores it, even transiently, shares responsibility for sanitizing it. It also says backed up or escrowed copies of data and keys need their own sanitization policy. So when you decommission a storage system, scope every snapshot, replica, backup set, cache tier and the key manager holding the keys. A drive by drive certificate covers none of those.

How do you sanitize cloud and virtual storage you never hold?

You cannot run a sanitize command on a disk in someone else's data center. Revision 2 says so: in logical storage, "cryptographic erase may be the only viable purge sanitization technique," and you should understand your options "prior to storing sensitive data on such ISM." The FAQ adds that you must review your cloud agreements to make sure keys are securely managed and that zeroization "can be traceably validated."

That turns cloud sanitization into a procurement and key management problem:

• Control the keys. If you hold the key in your own key management service or supply it yourself, destroying it is an action you can perform and record. If the provider holds the only key, you are relying on its process.
• Read the provider's deletion documentation. Google Cloud, for example, documents that it aims to mark data for deletion within 24 hours of a request, that a recovery period of up to 30 days may follow, that removal from active systems generally takes about two months, and that data expires from backups within about six months, with an overall commitment of about 180 days. It also describes cryptographic erasure and its own drive decommissioning process. Notice that page, last updated in 2024, describes that process as aligned with SP 800-88 Revision 1 and DoD 5220.22-M. Provider documentation lags standards, so ask what applies today.
• Map every copy. Snapshots, cross region replicas, object versioning, log sinks and exports to other accounts all hold data.
• Record it. Your certificate for a cloud resource looks different: resource identifiers instead of serial numbers, the key identifiers destroyed, the date, the person, and the provider's deletion commitment.

For deeper vendor and contract angles, see how a vendor should dispose of ePHI media and cloud storage and vendor offboarding and supply chain data destruction.

How do you handle devices that fail and cannot be wiped?

A dead drive is the hardest case, because Clear and logical Purge need a working interface. Revision 2 says overwriting "cannot be used on a non-rewriteable ISM or one that is damaged to the point of being inoperable," and that destruction "may be the only option when the ISM fails or is obsolete."

Warranty swaps are where data most often walks out. Revision 2 says a device sent to a maintenance provider can stay under your control if contracts cover the confidentiality of the information and transport is secure, but a device exchanged for warranty or rebates that will not come back is out of your control. It also notes that in some jurisdictions losing control of sensitive data can itself count as a breach.

A workable policy: where your support contract allows it, keep failed storage from sensitive systems. If a drive must go back, sanitize it first with a Purge technique, or rely on CE through key destruction if it was encrypted from first use, and record which. If neither is possible, destroy it and settle the warranty another way, or have a risk owner accept the residual risk in writing.

What does NCSC guidance add for UK readers?

The UK National Cyber Security Centre's "Secure sanitisation and disposal of storage media" (published September 2016, reviewed February 2025) is shorter and more prescriptive in places. Points worth borrowing even outside the UK:

• Scope. It targets OFFICIAL data: protection against commercial recovery tools and forensic services, not a well funded laboratory.
• Encrypted devices. A manufacturer's factory reset that deletes the keys gives satisfactory assurance for most devices, though NCSC says it cannot guarantee all user data is unreadable.
• Unencrypted devices. Overwrite all user accessible space with a fixed value (using ATA or NVMe sanitize commands where available), check metadata for remapped or bad sectors, power off for at least 15 minutes, then read back all user accessible memory to confirm the fixed value.
• Destruction. Destroy media to particles of 6 mm or less, verify the size, and erase before destroying.
• Residual risk has an owner. If the steps cannot be completed, a named risk owner must accept the remaining risk.
• Outsourcing. NCSC runs a sanitisation assurance scheme (CAS-S) for providers serving central government.

Note one difference. NCSC's process still includes a read back verification step, while NIST Revision 2 says full or representative sampling after Clear or Purge is not necessary unless your policy requires it. If you work under both, write your policy to the stricter of the two for the data in question.

How do HIPAA, PCI DSS and NIST SP 800-53 MP-6 reference sanitization?

Most organizations meet SP 800-88 through another framework that points at it.

NIST SP 800-53 Rev 5, MP-6 Media Sanitization

MP-6 requires you to sanitize system media before disposal, release out of your control or release for reuse, using techniques whose strength matches the security category of the information. Its guidance lists "clearing, purging, cryptographic erase, de-identification of personally identifiable information, and destruction" as sanitization techniques and covers digital media in scanners, copiers, printers, notebooks, workstations, network components and mobile devices, plus paper and microfilm. Useful enhancements:

• MP-6(1) Review, approve, track, document and verify sanitization and disposal actions; its record list mirrors the SP 800-88 certificate.
• MP-6(2) Test sanitization equipment and procedures.
• MP-6(3) Sanitize portable storage before first connecting it when its chain of custody is unknown.
• MP-6(7) Dual authorization.
• MP-6(8) Remote purge or wipe, including "by destroying the key necessary to decrypt encrypted data."

See our deeper guide to NIST 800-53 MP-6 media sanitization and the related SR-12 component disposal control.

HIPAA Security Rule

The device and media controls standard at 45 CFR 164.310(d) has four implementation specifications:

The rule does not name a technique. SP 800-88 is the usual reference for what "removal" means, and the accountability specification is where your asset tracking and certificates come in.

PCI DSS

PCI DSS handles media destruction in its physical security requirements: media holding cardholder data must be destroyed, or the data rendered unrecoverable, when no longer needed for business or legal reasons. We could not retrieve the current standard text for this article, so check the exact requirement wording and numbering in the latest version from the PCI Security Standards Council before quoting it in an audit response.

Step by step: sanitizing a drive from Linux

This walkthrough covers a drive attached directly to a Linux system you control: an NVMe SSD, or a SATA drive on a native SATA port. It is for drives you are retiring or reusing, with the data already backed up or no longer needed. It is not a substitute for your organization's approved procedure, and for high sensitivity data Revision 2 may push you to Destroy regardless.

Warning: every command below permanently destroys data. There is no undo. Run them only from a live or maintenance environment, never against the disk your running system booted from, and only after confirming the device path twice. On laptops and behind USB bridges, RAID cards or SAS controllers, drive level security commands can fail midway and leave the drive locked or unusable.

Step 1: Identify the exact device

List block devices with model, serial, size and transport, so you can match the serial to the label on the drive and your asset record.

lsblk -d -o NAME,MODEL,SERIAL,SIZE,TRAN,TYPE
findmnt -o SOURCE,TARGET

Write down the serial number. You will need it for the certificate, and comparing it to the physical label is your best defense against wiping the wrong disk. Make sure nothing on the target is mounted.

Step 2: Check what the drive supports (NVMe)

nvme-cli reports the controller's sanitize capabilities. Option names have changed across nvme-cli versions, so check nvme help on your build.

sudo nvme list
sudo nvme id-ctrl /dev/nvme0 -H | grep -i -A4 sanicap

Look for which of crypto erase, block erase and overwrite the controller says it supports. Revision 2 Appendix B warns that a command's name does not prove it meets a method's requirements, so match this against what the vendor documents for the model.

Step 3: Run NVMe Sanitize

Warning: this erases every namespace on the controller, not just one partition. Confirm the controller path (for example /dev/nvme0) belongs to the serial number you recorded in Step 1. Do not run it on the controller holding your running system.

The nvme-cli documentation defines the sanitize action values: 0x02 starts a block erase, 0x03 an overwrite and 0x04 a crypto erase. Prefer crypto erase or block erase on flash.

# Re-check the device path and serial immediately before running
sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn) '

# Start a crypto erase sanitize on the whole controller
sudo nvme sanitize /dev/nvme0 --sanact=start-crypto-erase

Recent nvme-cli releases also document a purge request option that asks the controller to purge user data per IEEE 2883 and to fail if the operation would not. Use it if your build and drive support it.

Step 4: Watch progress and record the result

# Older nvme-cli builds; newer ones document "nvme log sanitize" instead
sudo nvme sanitize-log /dev/nvme0

Wait until the log shows the most recent sanitize completed successfully. Save the output. That log is your verification evidence for the certificate.

Step 5: SATA drives with hdparm

For SATA drives, the classic route is the ATA Security feature set via hdparm. The Linux kernel ATA wiki that documents it is archived and marked obsolete, so treat these steps as background and prefer the vendor's documented procedure or the ATA Sanitize feature where the drive supports it.

Warning: setting a drive password and issuing a security erase can permanently lock or brick a drive if anything interrupts it. Use a direct SATA connection, not a USB adapter or RAID controller. Avoid hdparm versions older than 9.31, which hard code a two hour timeout. Confirm the device path and serial before every command.

# 1. Confirm the device and that security is "not frozen"
sudo hdparm -I /dev/sdX | grep -E 'Model Number|Serial Number|frozen|ERASE'

# 2. Set a temporary user password (it is cleared by a successful erase)
sudo hdparm --user-master u --security-set-pass TEMPPASS /dev/sdX

# 3. Issue the erase and time it
time sudo hdparm --user-master u --security-erase TEMPPASS /dev/sdX

# 4. Verify security is "not enabled" again
sudo hdparm -I /dev/sdX | grep -A8 '^Security'

If the drive reports "frozen," the BIOS has locked the security state at boot. The wiki lists suspend and resume or a power cycle as workarounds. The hdparm -I output also shows the drive's own time estimate for the erase. The wiki's author saw about 40 seconds on an 80 GB SSD and notes a 1 TB hard disk might take three hours or more.

Step 6: Validate and certify

Decide whether the result is acceptable for the data that was on the drive: did the command complete without errors, was it the right technique for the media, and does it meet your policy for this sensitivity? If yes, fill in the certificate with the serial, method, technique, tool version, the saved log and your name. If not, escalate to a stronger method or to Destroy.

The disposal and recycling workflow

Putting it together, a defensible end of life process for any device holding data looks like this:

1. Inventory at intake, with serial numbers, and decide sanitization at design time, as Revision 2 advises. Prefer drives with documented sanitize and CE support.
2. Revoke before you wipe. List and revoke what a developer laptop or build server could reach: Git hosting, package registry and cloud tokens, SSH and signing keys. See our developer laptop offboarding checklist and files on a developer laptop that hold credentials.
3. Check records retention with privacy and records officers, as Revision 2 advises, so you do not destroy something you must keep.
4. Choose the method from data sensitivity, reuse and control.
5. Sanitize at the desk if you can. Revision 2 suggests CE at the user's desk before a device goes to a sanitization facility.
6. Track custody to the facility with sealed containers and signed handoffs.
7. Verify, validate and certify every device, then reconcile certificates against the intake inventory.
8. Recycle responsibly. NCSC mentions the UK WEEE rules as one example of environmental obligations.

For consumer smart devices, see factory reset smart devices before selling or giving them away.

Where Safeguard fits, honestly

Safeguard does not sanitize media, manage assets or track disposal, and it does not scan firmware or inspect devices. Media sanitization sits outside what it does.

The indirect link is the inventory you need before a wipe. A developer machine or build agent is part of your software supply chain: it holds repositories, lockfiles, package manager configuration and credentials. Knowing what projects lived on a machine tells you what to re check when they are rebuilt elsewhere. Safeguard scans repositories, container images and SBOM files with safeguard scan, shows which projects contain a given component and version, and its local runner keeps those checks running on a rebuilt or offline machine, as described in how the local runner and offline mode work. That helps after a device is retired and replaced. It does not tell you which tokens were on the old disk; that list comes from your own credential inventory.

Common mistakes

• Citing Revision 1 or "DoD three pass" in policies and contracts. Reference Revision 2 and name your technique standard.
• Overwriting files or free space on an SSD, or degaussing one. Neither reaches the data.
• Assuming a dead drive is a safe drive. A failed or degaussed drive can still hold readable data.
• Trusting CE on a device that held plaintext first, or whose keys were escrowed somewhere you have not also sanitized.
• Forgetting the second storage device: the SD card, the hybrid drive's flash cache, the printer's internal disk.
• Shipping drives back under warranty without sanitizing them first.
• Running drive security commands through a USB enclosure, which can interrupt the command and lock the drive.
• Issuing certificates without an intake inventory, so you can prove what you wiped but not that you wiped everything.

FAQ

What is the difference between Clear, Purge and Destroy in NIST 800-88?

Clear uses the normal interface to overwrite or reset all user addressable storage, protecting against simple recovery. Purge uses dedicated sanitize commands, cryptographic erase or a matched degausser to defeat laboratory recovery while keeping the device potentially reusable. Destroy makes recovery infeasible and the device unusable.

Is NIST SP 800-88 Rev 1 still valid?

No. NIST withdrew Revision 1 on 26 September 2025, the day Revision 2 was published. Revision 1 is still a useful historical reference, but new policies and audit evidence should cite Revision 2.

What is new in NIST SP 800-88 Rev 2?

It moves from per media technique tables to a sanitization program, defers technique detail to IEEE 2883 and NSA/CSS manuals, introduces the term information storage media to cover cloud and object storage, drops multi pass overwrite, narrows degaussing to a Purge technique, rewrites cryptographic erase guidance, and adds verification and validation.

Does NIST 800-88 require multiple overwrite passes?

No. Revision 2 states that Clear does not need multi pass overwriting and calls the DoD 5220.22-M pass patterns obsolete. A single pass over all addressable space is the typical Clear technique on media where overwrite applies.

Is a factory reset enough to sanitize a phone?

On a modern phone with always on, hardware backed encryption, a manufacturer reset destroys the keys, which NCSC says gives satisfactory assurance for most devices. Whether it meets Clear or Purge for your data is your decision under SP 800-88. Remove SD cards and deal with cloud backups separately.

Can you degauss an SSD?

No. Degaussing affects magnetic media only, and Revision 2 says it should not be used on flash storage.

Is shredding a hard drive NIST compliant?

Shredding is a listed Destroy technique, but Revision 2 says pulverize and shred should be avoided for anything but the lowest security categories on modern storage. For higher categories, the FAQ points to NSA listed degaussers for magnetic media and melting or incineration for other media.

How do you sanitize data in the cloud?

Usually with cryptographic erase, because you cannot reach the physical disks. Hold the keys yourself where possible, read your provider's deletion timelines, account for snapshots, replicas and backups, and record which keys you destroyed and when.

What should a certificate of sanitization include?

Manufacturer, model, serial number, asset number, media type and source, method, technique, tool and version, verification method, and the name, title, date, location, contact and signature of the people who verified and validated it, plus the device's destination.

Fix it without waiting for upstream

Media sanitization is about the end of a device's life, but the machines that replace it start their lives by pulling dependencies again. A rebuilt developer laptop or build server reinstalls packages, toolchains and container images, and that is where software supply chain hygiene still applies, even though Safeguard plays no part in the wipe itself.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Neither demo sanitizes a drive; Safeguard does not do that. They show the step after disposal, when a replacement machine pulls your projects down again.

The first demo sets up the local runner on your own machine, approves it with its device code and runs a scan from the terminal. On a laptop or build agent that replaces a sanitized one, that is how you confirm each project resolves to a current, reviewed dependency tree before anything is built on the new hardware.

Click through it at your own pace, or open it full screen.

The second demo is a real CLI session. You install the CLI, open the interactive terminal and ask it to fix the lodash CVE in a repository. It reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. If the scan on the rebuilt machine turns up an outdated dependency, the same flow fixes it with you approving each step.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard at safeguard.sh/download and read the CLI documentation.

Quick check

Sources

• NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization (publication page)
• NIST SP 800-88 Rev. 2 full text (PDF)
• NIST: Frequently Asked Questions for SP 800-88r2 (PDF)
• NIST SP 800-88 Rev. 1 (withdrawn)
• NIST SP 800-209: Security Guidelines for Storage Infrastructure
• NIST SP 800-111: Guide to Storage Encryption Technologies for End User Devices
• NIST SP 800-53 Rev. 5 OSCAL catalog (MP-6 Media Sanitization)
• IEEE 2883-2022: IEEE Standard for Sanitizing Storage
• NCSC: Secure sanitisation and disposal of storage media
• Wei, Grupp, Spada, Swanson: Reliably Erasing Data From Flash-Based Solid State Drives (FAST 2011)
• 45 CFR 164.310: Physical safeguards (Cornell LII)
• Google Cloud: Data deletion on Google Cloud
• Android Open Source Project: File-based encryption
• Apple Support: Erase your Mac and reset it to factory settings
• nvme-cli documentation: nvme-sanitize
• nvme-cli documentation: nvme-sanitize-log
• Linux kernel ATA wiki (archived): ATA Secure Erase
• NVM Express: Specifications

Last reviewed: 23 October 2026.