A host overwrite can write new data to a different physical page while the prior page remains invalid but not yet erased. For enterprise sanitization, use a device-supported, approved technique whose scope and result can be verified, or physically destroy the complete solid-state storage when Purge cannot be validated or Destroy is required.
NAND Architecture in One Table
| Layer | Function | Sanitization issue |
|---|---|---|
| Cell | Stores one or more bits as threshold-voltage states | Prior state persists until block erase and can degrade over time |
| Page | Unit commonly programmed and read | A page is not normally overwritten in place |
| Block | Group of pages erased together | Erase granularity is larger than write granularity |
| Die and package | Physical flash components | One SSD can contain several packages and dies |
| Controller | Manages mapping, error correction, wear, cache, and commands | Host does not directly control every physical location |
| Flash translation layer | Maps logical block addresses to physical pages | New writes can move rather than replace old physical data |
| Overprovisioned area | Capacity reserved from normal host access | Ordinary overwrite cannot directly address it |
Why NAND Uses Erase-Before-Write
NAND pages can be programmed, but they generally cannot be freely overwritten in place. A containing block must be erased before its pages can be programmed again.
When data changes, the controller can:
- Write the new data to a free page.
- Update the logical-to-physical map.
- Mark the old page invalid.
- Reclaim the containing block later through garbage collection.
The old physical page can therefore persist after the host sees only the new logical content.
Wear Leveling and Remanence
NAND cells have finite program-and-erase endurance. Wear leveling distributes writes across physical blocks so a small region does not wear out early.
This means repeated writes to one logical address do not guarantee repeated writes to one physical cell. A host overwrite can create new versions in different locations.
Static wear leveling can also move long-lived valid data to balance wear, creating additional historical physical locations during normal operation.
Overprovisioning, Spare Blocks, and Remapping
SSDs and managed flash reserve capacity for:
- Garbage collection
- Wear leveling
- Performance
- Bad-block replacement
- Error recovery
- Manufacturing variance
These areas are outside ordinary host addressing. When a block fails or reaches an error threshold, the controller can remap data and retire the block. A retired physical location may not be reachable through standard reads or writes.
NIST SP 800-88 Rev. 2 warns that sanitization must consider inaccessible portions and device-specific implementation.
TRIM and Garbage Collection
TRIM is a host notification that certain logical blocks are no longer needed. It is not itself proof that every related NAND cell was immediately erased.
After TRIM:
- The controller can mark mappings invalid.
- Host reads may return zeros or another defined result.
- Garbage collection can erase blocks later.
- Timing depends on firmware, power, workload, free space, and device state.
- Old physical pages can become inaccessible before physical erase.
See SSD TRIM vs. Secure Erase for the enterprise decision.
Data Retention vs. Data Remanence
Retention is the ability of valid NAND data to remain readable over time. Remanence is the residual presence of previous target data after an attempted deletion or sanitization event.
Retention depends on:
- NAND type
- Program-and-erase history
- Temperature
- Cell wear
- Error-correction capability
- Storage duration
- Manufacturing and controller behavior
A worn or unpowered device can lose valid data over time, but age and degradation are not approved sanitization techniques.
SLC, MLC, TLC, and QLC
NAND can store different numbers of bits per cell:
- SLC: one bit
- MLC: commonly two bits
- TLC: three bits
- QLC: four bits
More bits require more threshold-voltage states. This affects performance, endurance, retention, and error management. It does not create a universal sanitization rule. Technique selection depends on the complete device, controller, firmware, interface, and vendor evidence.
Why HDD Overwrite Logic Does Not Transfer Cleanly
HDD sectors map more directly to magnetic locations than host logical addresses map to NAND pages. On NAND:
- Writes are out of place
- Erases occur by block
- Mapping is controller-managed
- Spare areas are hidden
- Bad blocks are remapped
- Data can exist in cache or metadata
Repeated overwrite passes can add wear while failing to address old inaccessible pages. DoD overwrite-pass patterns are not a current universal SSD method.
Device Sanitize Commands
Dedicated sanitize commands can operate below ordinary file-system and host-write abstractions. Their effectiveness still depends on device support and implementation.
Possible operations include:
- Block erase
- Cryptographic erase
- NVMe Sanitize
- NVMe Format with secure erase settings
- ATA Sanitize
- Vendor-specific operations
Ask vendors for:
- Supported commands
- Scope
- Areas included and excluded
- Completion and status behavior
- Power-interruption handling
- Failure state
- Firmware limitations
- Validation evidence
A button labeled “Secure Erase” does not identify the command or outcome.
Cryptographic Erase
Cryptographic erase can support Purge when:
- Encryption was enabled before target data was written
- All target data was encrypted
- Algorithm and implementation meet policy
- Key hierarchy is understood
- Every relevant key copy can be sanitized
- Escrow, backup, and external key systems are addressed
- Key sanitization is verified
- Plaintext copies are addressed separately
Deleting one key record does not establish these conditions automatically.
Failed SSDs and Controller Failure
A failed controller can prevent logical sanitization while NAND packages retain data.
Route to physical destruction when:
- Device will not enumerate
- Sanitize command is unsupported
- Completion cannot be verified
- Firmware reports failure
- Encryption conditions are unknown
- Policy requires Destroy
- Reuse is prohibited
Destroy the complete solid-state device with equipment and output suitable for NAND packages. An HDD crusher can leave flash packages substantially intact.
Physical Destruction and Chip-Level Risk
A NAND package can contain several dies with high storage density. Effective destruction must address:
- Every NAND package
- Removable storage
- Controller-related persistent storage
- Package and die fragments
- Oversize remnants
- Reprocessing
See SSD Shredding and Chip-Level Destruction.
NIST SP 800-88 Rev. 2 does not set one universal commercial SSD particle size. Applicable agency or contract requirements can specify an output.
Verification and Evidence
For logical sanitization, record:
- Device make, model, serial, firmware, and capacity
- Interface
- Exact command or operation
- Tool and version
- Encryption state
- Scope
- Start, completion, and status
- Errors and anomalies
- Verification and validation
For physical destruction, record equipment, configuration, complete-device processing, output inspection, reprocessing, operator, date, and location.
Procurement Questions
- Which sanitize commands does the device support?
- Which physical regions do they address?
- Is sanitize status available?
- What happens after power loss?
- How are failed blocks handled?
- Is all user data encrypted from first use?
- Where are keys stored and backed up?
- What vendor validation exists?
- What firmware limitations apply?
- What is the approved failed-device route?
Sanitization capability should be evaluated before buying storage.
Frequently Asked Questions
Does deleting an SSD file erase the NAND cells?
Not necessarily. The file system and controller can invalidate mappings before garbage collection physically erases the containing block.
Does TRIM sanitize an SSD?
No. TRIM is a deallocation notification, not a verified whole-device sanitization result.
Can overwriting reach overprovisioned NAND?
Ordinary host writes cannot directly address capacity hidden by the controller.
Does factory reset erase every NAND device?
Not universally. Reset behavior depends on product design, encryption, firmware, and storage components.
Can NAND be degaussed?
No. NAND stores electrical states, not magnetic domains.
Can data remain after the SSD stops working?
Potentially. Controller failure can block access while NAND packages retain information.
Does old NAND eventually lose data?
Retention degrades with wear, temperature, and time, but natural degradation is not a controlled sanitization method.
Request an SSD Disposition Assessment
Provide device types, models, quantities, condition, encryption state, reuse plan, and required outcome.
Request an SSD Destruction Quote
Call: (866) 850-7977
Sources
- NIST, SP 800-88 Rev. 2, September 2025.
- NIST, SP 800-88 Rev. 2 PDF.
- Hasan et al., Data Recovery From Scrubbed NAND Flash Storage, USENIX Security 2020.
- KIOXIA, Understanding NAND Flash Memory Data Retention.