SSD Sanitization: The Flash Translation Layer and Coverage

Short answer

An SSD translates host-visible logical addresses into physical NAND locations. A host overwrite updates the logical address space through that translation; it does not let the host select and erase every physical location that has held the data. Wear leveling, spare capacity and remapping therefore matter when deciding what an overwrite report actually proves.

Choose a supported, policy-approved sanitization technique for the exact device and connection path. Verify its completion and documented scope. Neither repeated overwrites, a successful format, TRIM, nor a zero-filled readback alone establishes that all prior physical copies have been sanitized.

Who this is for

This guide is for authorized teams evaluating NAND-based SSD sanitization before reuse or disposal. It explains the flash translation layer, usually abbreviated FTL, and the evidence needed to choose a procedure. It is not a destructive command recipe or a guarantee about a particular controller or firmware revision.

SATA and NVMe are different command interfaces. M.2 describes a form factor and does not, by itself, tell you which protocol a drive uses. Confirm the interface and exact model before applying instructions found for another SSD.

What changes between a logical write and a physical erase?

NAND is organized into pages within erase blocks. Programming and erasing operate at different granularities. Controllers use mapping, free space and background management to keep ordinary host writes working without requiring the host to manage those physical details.

Consider a deliberately simplified teaching example. Logical block L initially maps to physical page A. A later host write to L can cause the controller to write page B and update its mapping. Subsequent host reads of L return the current data through that mapping. Page A may no longer be reachable through that address, while its eventual physical treatment depends on controller operations.

Before update: host address L -> physical page A
After update:  host address L -> physical page B
Host readback examines the current mapping.
It does not directly inspect every prior physical location.

This is an abstraction, not a trace captured from a real drive. Mapping granularity and placement algorithms vary. It establishes a coverage distinction, not a claim that an old page always survives for a known time or can necessarily be recovered.

Why overprovisioning and retired locations matter

Overprovisioning reserves capacity for controller use rather than exposing it as ordinary host storage. Garbage collection can reclaim storage containing invalid pages, and wear leveling distributes use across NAND. These functions support operation and endurance; they are not an asset-level certificate that a requested sanitization has completed.

Remapping and inaccessible regions create another evidence question: what does the selected device operation promise about locations outside the current host map? Do not infer the answer from an operating system's capacity display or from the number of bytes a host utility wrote.

NIST SP 800-88 Rev. 2 specifically cautions that native read/write overwrites cannot directly address all locations that may have held sensitive data on flash media using spare cells and wear leveling. A device-specific technique must be assessed on its actual coverage, not on a familiar disk-wiping label.

What TRIM and garbage collection do not prove

TRIM lets the host communicate that certain logical data is no longer needed; garbage collection manages reusable flash space inside the controller. Their effects and timing depend on the implementation and the storage path.

A returned zero does not identify whether a particular old physical page has been erased. A completed discard request also does not document the treatment of every data-bearing location. Do not use an idle interval, an empty filesystem or a fast format as a substitute for supported sanitization status.

This distinction does not make ordinary deletion useless. It means deletion, space reclamation and a validated disposal decision answer different operational questions.

When to use this

Use this guide when replacing a host overwrite procedure with a medium-appropriate workflow, reviewing an SSD tool's scope, or deciding whether an enclosure exposes the required controller functions. Determine those facts before choosing a destructive operation.

When not to use this

Do not treat this architecture explanation as approval for an unsupported command, a universal recovery claim, or an instruction to experiment on the system's active drive. Retention, backup and authorization decisions must already be resolved before irreversible work.

Workflow

1. Identify the physical asset, model, firmware, protocol, namespaces or logical presentation, and connection path.
2. Read the exact device documentation for supported sanitization operations and prerequisites. Separate the command name from its requested action and scope.
3. Confirm that the enclosure, controller or array forwards the required operation and completion status. A visible disk is not proof of command pass-through.
4. Select the policy-approved technique and document its coverage, including any uncertainty about remapped or inaccessible storage.
5. Execute only the approved device-specific procedure. Preserve status and errors; do not guess after interruption.
6. Validate the evidence against the required disposition. Quarantine an unresolved asset rather than substituting repeated host writes.

For a Linux system with nvme-cli, Kingston's Linux support procedure uses the following read-only inventory command before any erase step:

sudo nvme list

Use it only to enumerate accessible NVMe devices. Confirm the reported identity against the physical asset and your approved procedure; do not rely on size alone. A SATA drive or a device hidden by an unsupported bridge may not appear. Permission or discovery failure is an inventory exception, not evidence of an empty or sanitized drive. No erase command is included here because support and scope must be resolved for the actual model.

Are device commands automatically sufficient?

No. Dedicated device operations can address storage beyond ordinary host reads and writes, but their implementation, supported actions and completion semantics must be documented for the device. NVMe Format and Sanitize are not interchangeable names for every operation a vendor tool calls “secure erase.”

Cryptographic erase introduces additional prerequisites: all target data must have appropriate encryption protection, and the relevant keys and copies must be handled correctly. A product's encryption checkbox is not a complete key-lifecycle record. Failed or unsupported media may need a different approved disposition.

Verification note: criteria for an actual SSD job

No physical SSD was sanitized or measured for this article. The teaching example is conceptual and the inventory command is corroborated by vendor documentation. For a real job, require identity, firmware and command-path evidence, documented operation scope, completion status, errors, exceptions and an authorized acceptance decision.

Verification checklist

• Match the physical serial number and model with the operation record.
• Distinguish host-visible comparison results from physical coverage claims.
• Retain the exact requested device action, not only the tool's friendly label.
• Review interruption, unsupported-feature and pass-through failures explicitly.
• Reject unresolved scope or completion evidence before release.

Resale and evidence checklist

Attach the selected procedure, result and exceptions to the asset record. A clean-looking partition table can help prepare reuse but does not replace the sanitization decision. Preserve the distinction between operational readiness and confidentiality acceptance.

What not to publish

Do not expose customer data, device passwords, encryption keys or sensitive asset identifiers in public examples. Keep the full evidence in the approved internal system.

Common mistakes

Avoid assuming that additional overwrite passes reach additional physical regions, that all M.2 drives speak NVMe, or that every USB enclosure forwards every management operation. Do not interpret background garbage collection as a timed, observable sanitization guarantee.

CliDeck workflow fit

Keep device identification, the approved procedure and the result together in a repeatable evidence workflow. This article makes no claim about the supported drives, erase features, certification or availability of forthcoming CliDeck wiping software.

FAQ

Does reading zeros prove all NAND was erased?

No. It describes the response through the current interface and mapping. Physical coverage needs evidence appropriate to the selected device operation.

Does an inaccessible page necessarily contain recoverable customer data?

No. Inaccessibility is a coverage limit, not a measured recovery result. Do not assign a survival time or recovery probability without applicable evidence.

Related guides

Use the NIST process guide for acceptance decisions and the DoD-label review when a legacy pass-count requirement obscures the actual technique or medium.