SSD Reuse vs Shredding: What Makes Reuse Defensible, and What Your Contract Should Say

Most ITAD contracts treat shredding as the safe default for SSDs. NIST disagrees, in writing.

SP 800-88 Rev. 2, Section 3.1.3: "Pulverize and shred techniques for ISM should be avoided for anything but the lowest security categories of data." (ISM is NIST's term for information storage media.) NIST's July 2026 FAQ goes further: for media such as SSDs holding medium- or high-security data, it points to incineration techniques such as smelting or melting.

At the same time, memory is expensive. New DRAM and NAND contract prices hit records this year (see our look at the memory squeeze), which puts a real price on every working drive that goes into a shredder. This article covers when SSD reuse is defensible, what evidence it needs, and what the contract with your customer should say so that nobody has to argue about it later.

---

1. What NIST actually says about shredding

Three passages from the final Rev. 2 text and NIST's FAQ matter here:

• Shredding has limits. Section 3.1.3: "As the density of data and the hardness of the component materials increase on an ISM, certain destructive techniques can become ineffective." Hence the advice to avoid shred and pulverize above the lowest security category.
• What NIST recommends instead for SSDs. The FAQ (Q10) says pulverize and shred "are ineffective for medium- and high-security categories due to data density," and that "techniques like incineration (e.g., smelting, melting) should be used for all other media (e.g., SSDs)." The FAQ (Q11) also reports that IEEE 2883 deprecates shredding and pulverizing as approved destruction methods for modern HDDs and SSDs.
• Destroy means destroyed in the lab, not just unusable. Section 3.1.3 says media is not considered destroyed "unless target data access or recovery is infeasible using state-of-the-art laboratory techniques."

None of this says shredding is useless. For low-sensitivity data, NIST's own wording leaves it available, and many facilities work to particle-size requirements set by customers or other standards. The point is narrower: "we shred everything" is not the gold standard it is often sold as, particularly for flash storage holding sensitive data.

2. What NIST says about reuse

Rev. 2 is explicit that sanitizing for reuse is a legitimate outcome:

• Purge keeps the drive usable. Section 3.1.2: purge techniques "make the recovery of target data infeasible using state-of-the-art laboratory techniques but preserves the ISM in a potentially reusable state." For SSDs, it points to IEEE 2883 for acceptable techniques, including block erase and cryptographic erase using the drive's own sanitize commands.
• Reuse is a valid reason to choose purge. Section 4.3: purge "may be more appropriate than destroy sanitization techniques when factoring in contractual obligations (e.g., lease returns), environmental concerns, the desire to reuse the ISM (either within the organization or by selling or donating the ISM), the cost of an ISM, or the difficulties in physically destroying some types of ISM."
• Destroy is the simple answer only when reuse isn't planned. Section 4.3.3: if media is not intended for reuse, "the simplest and most cost-effective sanitization method can be to destroy the media."

Two traps sit alongside this. First, a plain overwrite (clear) is not enough for reuse outside the organization when data is sensitive: on SSDs, overprovisioning can leave user data untouched, which is why NIST prefers purge "when possible." Second, degaussing does nothing to flash; Rev. 2 says it "should not be used for non-magnetic ISM (e.g., flash storage, such as SSDs)." Our DBAN for SSDs article covers why the method has to match the media.

3. The certification view: R2v3

SERI makes the same argument from the reuse side. On its Specialty Process Requirements page, it notes that customers sometimes require physical destruction because they worry logical sanitization won't be effective, and that "the unintended consequence is that destruction sacrifices the opportunity for good that comes when someone else can reuse your electronics."

R2v3 also sets a higher bar for reuse than for destruction. For logical sanitization, Appendix B requires records created by sanitization software for each device, and SERI's quality-control guidance describes a minimum 5% of logically sanitized media being sampled by a competent, independent party to show data is not recoverable by commercial software. If your facility is R2v3 certified, reuse evidence has to meet that standard.

4. What makes SSD reuse defensible

Reuse holds up when every drive can answer five questions without anyone's memory. The fields follow NIST's certificate list (Sec. 4.6, covered in our Rev. 2 evidence guide); the health and route rows are our additions.

Two rules keep this honest:

1. A drive that fails sanitization can't be reused. Record the failure, then route it to a stronger method or destruction, and keep both events in the history.
2. Health is part of reuse, not an afterthought. A perfectly sanitized drive that is close to failure is a returns problem. Check it before you decide its route.

5. What the contract should say

Most disputes about SSD reuse come from contracts that say "destroy all media" or say nothing at all. A contract that allows reuse should cover the following. This is our checklist, not a legal template; have counsel draft the actual terms.

For customers whose policy defaults to destruction, the conversation is easier with the NIST text in hand. Rev. 2 itself lists "the desire to reuse the ISM" and "environmental concerns" as reasons to choose purge, and its own caution about shredding weakens the assumption that destruction is always the stronger option.

6. Where reCore fits

reCore produces the per-drive evidence reuse depends on:

• Purge techniques where the hardware supports them. ATA secure erase on Windows and Linux; NVMe format and sanitize, including cryptographic erase, from the Linux boot environment.
• A policy that refuses to fall back. Organizations that set ADISA DIAL 3 get purge-required behaviour: if a drive doesn't support a hardware purge, the wipe fails rather than dropping to an overwrite, and verification reads back 100% of the drive.
• Health checks before the wipe. SMART status, reallocated sectors and power-on hours are checked, and a critically failing drive is blocked from wiping.
• One record per drive with method, technique, tool version, verification coverage and result, a separate approval by an administrator, and a SHA-256 hash of the certificate at approval. Failed attempts stay in the history.
• The route is part of the record. Each drive's disposition (reuse, transfer or destroy), a detail such as "External Sale", and the downstream vendor sit inside the hashed certificate.

reCore does not physically destroy drives, doesn't record a drive's current encryption state, and doesn't decide what your contract permits. It records what happened to each drive so that the decision can be defended. See the data wipe and compliance pages for more.

Conclusion

Shredding is simple, and simple is appealing. But NIST's current guidance doesn't treat it as the strongest option for sensitive data on modern flash, and it explicitly supports purge when reuse is the goal. With memory prices where they are, the question for most facilities isn't whether SSD reuse is safe in principle. It's whether each drive's record, and each customer's contract, is good enough to support it.

---

Sources

• NIST, SP 800-88 Rev. 2, Guidelines for Media Sanitization, September 2025. Sections 3.1.2, 3.1.3, 4.3, 4.3.3, 4.5 and 4.6.
• NIST, Frequently Asked Questions for NIST SP 800-88r2, July 16, 2026. Q10 and Q11.
• SERI, Specialty Process Requirements.
• SERI, Verifying the Effectiveness of the Data Sanitization Process, updated June 14, 2022.