How an SSD Is Made: 3D NAND Flash, Controllers and Firmware

An SSD is made by building 3D NAND flash on silicon wafers, where hundreds of alternating thin films are stacked and then pierced by deep vertical "channel holes" that become strings of memory cells. The good dies are cut out, stacked inside a package and soldered to a circuit board next to a controller chip, which runs firmware that hides the quirks of flash behind a simple block interface. Finally the drive is loaded with firmware, stressed in burn-in ovens and tested before it ships, and that firmware keeps managing wear, errors and encryption for the life of the drive.

This post goes one level deeper than our semiconductor explainer and the storage sections of our laptop build and smartphone build posts. It covers the NAND, the controller, assembly, interfaces, encryption, firmware updates, health logs and disposal. For erase commands in depth, see our companion post on NVMe and ATA sanitize.

Memory makers keep yields and process recipes secret, so where no primary source publishes a number we say so, and any arithmetic we show is labelled illustrative.

Key takeaways

• 3D NAND stacks cells vertically: hundreds of film layers are deposited, deep channel holes are etched through them, and each hole becomes a string of cells. Samsung announced the first mass produced 3D vertical NAND on 6 August 2013 with up to 24 layers.
• "200+ layers" counts stacked word line layers, usually built as two or more decks. It is not a speed or quality rating.
• Each extra bit per cell doubles the voltage states a cell must hold apart: SLC has 2, TLC 8, QLC 16, PLC 32. That is why endurance falls as density rises.
• The controller's firmware runs the flash translation layer, garbage collection, wear levelling and LDPC error correction. Without it, raw NAND is unusable as a disk.
• The Open Compute Project datacenter SSD specification requires signed firmware, checked at commit, with fallback if a new image fails to start.
• Self-encrypting drives can be badly broken: research presented at IEEE Security and Privacy in May 2019 found drives whose data key was not derived from the password.
• For disposal, NIST SP 800-88 Revision 2 (September 2025) defines clear, purge and destroy and points to IEEE 2883 for SSD techniques.

Wafer to finished drive: the step table

The table below is the map for the rest of the post. Yields per stage are not published by any manufacturer we could find, so the table names the check at each stage instead of inventing a percentage.

A dated timeline of the milestones

Dates are checked against the sources listed at the end.

How is 3D NAND built?

Why flash went vertical

Planar NAND put cells side by side and added capacity by shrinking them. Samsung's August 2013 announcement explains why that stalled: approaching the 10 nanometre class, "cell-to-cell interference" hurt reliability and raised cost. 3D NAND keeps cells larger and stacks them, so capacity grows with layers rather than lithography. That first product stacked up to 24 layers, connected by holes etched from the top layer to the bottom.

The layer stack and the channel hole

Deposition tools lay down alternating thin films on the wafer, typically silicon oxide and silicon nitride. Each pair eventually becomes one word line, the horizontal wire that selects one cell on every string it crosses.

Then an etch tool drills channel holes straight through the whole stack, the hardest step in the process: each hole is far deeper than it is wide and must stay straight and open cleanly at the bottom. Samsung's April 2024 announcement for its 9th generation V-NAND calls out "channel hole etching" as the key process capability and describes drilling through a record layer count in a double stack structure.

Inside each hole, a sequence of very thin layers is deposited on the walls, from the outside in:

1. A blocking oxide that keeps charge from leaking to the word line.
2. A charge storage layer, normally silicon nitride in charge trap designs.
3. A tunnel oxide that electrons cross when the cell is programmed or erased.
4. A thin polysilicon channel, the conductive path that runs vertically through every cell on the string.
5. An insulating core filling the middle.

Where each horizontal word line wraps around the hole, it forms one memory cell. A hole that passes through 200 word line layers is a string of roughly 200 cells in series, plus select transistors at the top and bottom that connect the string to its bit line and to the common source.

Slits are then cut to divide the array into blocks. Through them, the sacrificial nitride is etched out and replaced with metal, usually tungsten, to form the word lines. A staircase etched at the array edge gives every word line its own contact.

Charge trap versus floating gate

Both cell types store a bit by placing electrons where they shift the threshold voltage of a transistor. The difference is where the electrons sit.

Samsung's 2013 release describes the charge being held in a non-conductive silicon nitride layer instead of a floating gate. Because nitride does not conduct, one leaky spot cannot empty the cell. Exact cell structures for a given product are rarely published, so treat third party claims about a specific drive with care.

What "200 layers" and "300 layers" actually mean

A layer count is the number of word line layers, a measure of vertical scaling, not speed or quality. Behind it:

• Decks. High counts are often built as two or three separately etched decks stacked and aligned. Samsung's 9th generation is a double stack.
• Dummy layers. Some layers at deck boundaries store no data, and announcements do not always say whether they are counted.
• Periphery placement. Early 3D NAND put the control logic beside the array, which wasted area. Later designs put the CMOS logic under the array, or, as Kioxia describes for BiCS FLASH generation 8, build it on a separate wafer and bond it to the array wafer with "CMOS directly Bonded to Array (CBA)." That lets each wafer use the process that suits it.

Worked example: from layers to bits on a die

This is illustrative arithmetic, not any manufacturer's die. Imagine a 3D NAND die where each layer offers a fixed array of cell positions. If moving from 176 to 232 usable word line layers keeps the footprint the same, the cell count rises by 232 divided by 176, about 1.32, so roughly 32 percent more cells per die.

Now store data differently. Moving those cells from TLC (3 bits per cell) to QLC (4 bits per cell) raises bits by 4 divided by 3, about 1.33, another 33 percent. Doing both multiplies: 1.32 times 1.33 is about 1.75, so roughly 75 percent more bits per die from the same footprint, before any change in cell pitch.

That is why makers push both levers, and why Samsung's 9th generation announcement says bit density rose by about 50 percent rather than leading with a layer number.

What are SLC, MLC, TLC, QLC and PLC?

These names describe how many bits each cell stores. A cell holds a bit pattern by sitting at one of several threshold voltage levels. Store n bits and you need 2 to the power n distinct levels, all squeezed into roughly the same voltage window.

The "bits gained" column shows the diminishing return. Going from SLC to MLC doubled capacity. Going from QLC to PLC adds only a quarter, while doubling the number of states the controller must keep apart.

Why more bits per cell means less endurance

Every program and erase cycle pushes electrons through the tunnel oxide, and some get stuck in places they should not be. Over time the oxide wears, states drift and the voltage distributions for each level widen. With 2 states, there is a wide margin between them and a lot of drift is tolerable. With 16 states in the same window, the margin is tiny. A small amount of wear makes adjacent states overlap, and reads start returning errors.

More states also cost time: programming means nudging the cell in small verified steps into a narrow band, and reading needs more reference voltages. So QLC and PLC write more slowly, need stronger error correction and carry lower cycle ratings than TLC.

SLC caching: why a QLC drive feels fast until it does not

Most TLC and QLC drives run part of their free NAND in SLC mode as a write cache, then fold the data into the denser format in the background. Bursts are fast. A sustained write that fills the cache drops to the native rate, and the cache shrinks as the drive fills. This is firmware policy and varies between products.

Worked example: what a TBW rating means

Endurance is usually published as total bytes written (TBW) or drive writes per day (DWPD) over the warranty period. The two convert like this:

DWPD = TBW / (capacity x 365 x warranty years)

Example A, a client drive (illustrative numbers). A 2 TB drive rated for 1,200 TB written over 5 years:

• Capacity times days: 2 TB x 365 x 5 = 3,650 TB.
• DWPD = 1,200 / 3,650 = about 0.33. You could write a third of the drive every day for five years.

Example B (illustrative). A 3.84 TB datacenter drive rated at 1 DWPD for 5 years: TBW = 1 x 3.84 x 365 x 5 = 7,008 TB, about 7 PB.

Ratings come from manufacturer testing, and the workload matters. JEDEC's JESD218 and JESD219 standards define how endurance is meant to be measured; we could not retrieve them for this post, so read them directly before relying on details. The Open Compute Project datacenter specification, which we did read, asks vendors to state the physical bytes the drive can absorb at a write amplification of 1, and requires the Percentage Used field in the drive's health log to "track linearly with bytes written" and reach 100 percent at that rated value.

What does the SSD controller do?

Raw NAND is awkward. You program it in pages of several kilobytes but erase only in blocks of hundreds of pages, and you cannot overwrite a page in place. Cells wear out, some blocks are bad from the factory, and bits flip. The controller, a multi core processor with hardware engines, turns this into a clean array of logical blocks, and almost everything it does is firmware.

The flash translation layer

The flash translation layer (FTL) is the mapping between the logical block addresses the host uses and the physical pages where data actually lives. When the host overwrites logical block 1,000, the controller does not touch the old page. It writes the new data to a fresh page somewhere else, updates the map, and marks the old page as stale.

That map is large. With one 4 byte entry per 4 KiB, it needs about 1 GB per 1 TB of NAND, which is why many drives carry DRAM of roughly a thousandth of their capacity. DRAM-less drives cache part of the map, or borrow host memory through the NVMe Host Memory Buffer feature.

Garbage collection and write amplification

Stale pages pile up. To get free blocks back, the controller picks a block with many stale pages, copies the still valid pages elsewhere, and erases the block. That is garbage collection. It means the NAND sees more writes than the host sent. The ratio is the write amplification factor (WAF):

WAF = bytes written to NAND / bytes written by the host

Worked example. A host writes 100 GB of small random updates. To make room, the controller relocates 60 GB of still valid data during garbage collection. NAND writes total 160 GB, so WAF = 160 / 100 = 1.6. If the drive's NAND can absorb 1,600 TB of physical writes, the host can write about 1,600 / 1.6 = 1,000 TB before the NAND is worn. Halve the WAF and you nearly double the useful life.

Three things push WAF down: free space, so the controller can choose blocks that are mostly stale; TRIM or Deallocate commands from the host, which tell the drive which data is no longer needed; and write patterns that group data with similar lifetimes. That last point is exactly what Zoned Namespaces formalise, covered below.

Wear levelling

If a few blocks took all the writes, they would wear out while the rest stayed fresh. Wear levelling spreads program and erase cycles across all blocks. Dynamic wear levelling sends new writes to the least worn free blocks. Static wear levelling also moves cold data, the files that never change, off low wear blocks so those blocks can take a share of the writes. The OCP datacenter specification makes this explicit, requiring a device without endurance groups to wear level across all of its physical media.

Wear levelling has a security side effect that matters later in this post: old copies of data, including old copies of secrets, can survive in blocks that the host can no longer address.

Error correction: from BCH to LDPC

Every page carries parity bits. Early SSDs used BCH codes on hard read results. Modern controllers mostly use low density parity check (LDPC) codes, which can use soft information: the page is reread at shifted reference voltages to estimate confidence per bit, and the decoder iterates. That corrects far more errors, which aging TLC and QLC need. Many controllers add parity across dies or planes, like RAID inside the drive. The OCP specification reflects these layers. It defines a Soft ECC Error Count for reads that first level ECC cannot correct, treats a read as uncorrectable only after read retries, every ECC level and XOR parity fail, and sets an uncorrectable bit error rate target of fewer than 1 sector per 10 to the power 17 bits read.

Over-provisioning: the capacity you never see

Drives keep spare NAND that the host cannot address. The controller uses it for garbage collection headroom, for replacing bad blocks and for its own metadata. Some spare comes from a units mismatch.

Worked example. NAND is built in binary units and drives are sold in decimal ones. 512 GiB of NAND is 549,755,813,888 bytes; a drive sold as 512 GB exposes 512,000,000,000. The 37,755,813,888 byte difference is about 7.37 percent spare before any deliberate extra. Sold as 480 GB, the same NAND leaves about 14.5 percent. That is why 3.84 TB and 3.2 TB drives can share raw NAND, the smaller one usually carrying a higher DWPD rating.

Power loss protection and the rest

Many enterprise drives carry capacitors to flush in-flight data and map updates if power drops; client drives usually journal the map instead. The controller also runs thermal throttling, the AES engine, the health log and firmware updates, which is why a drive's firmware revision matters as much as its hardware.

How are SSDs assembled and tested?

Wafer sort and die grading

Every NAND wafer is probed before it is cut: each die is programmed, erased and read, and failing blocks are recorded. A few bad blocks are normal, and the list travels with the die. Dies are graded for different products, though makers do not publish their binning rules.

Packaging

The wafer is thinned and diced. Good dies are stacked, offset like a staircase so each die's bond pads are exposed, wire bonded to a substrate, moulded in epoxy and given solder balls underneath, making a ball grid array (BGA) package. Packages are tested again, because stacking and moulding can crack dies.

Board assembly

The board is assembled like any other: solder paste, pick and place of the controller, NAND, DRAM and power parts, then reflow and inspection. Datacenter drives add more NAND packages, power loss capacitors and a metal enclosure that doubles as a heatsink.

Firmware load, format and burn-in

At first power on, factory firmware is loaded, scans the NAND, merges the bad block lists, builds the spare pool and initialises the FTL. Burn-in then runs workloads at raised temperature so weak parts fail before shipping; durations and temperatures are not published. Drives then get production firmware, serial number and identity data, a final test and a label. The OCP specification adds requirements that reach back into this stage, including that one firmware image must cover every capacity and form factor in a product family, and that an end of life drive must retain powered off data for at least a month at 40°C.

What do NVMe, form factors and Zoned Namespaces change?

NVMe: the protocol

SATA was designed for spinning disks with a single command queue. NVM Express (NVMe) was designed for flash on PCI Express, with many deep queues that map to CPU cores. NVM Express describes itself as the standard for SSDs "in all form factors (U.2, M.2, AIC, EDSFF)." The specification is now a family: a base specification; command set specifications including the NVM command set, Zoned Namespaces and key value; transport specifications for PCIe, RDMA and TCP; a management interface (NVMe-MI); and a boot specification. According to the NVM Express specifications page, the latest set was released on 4 August 2026.

Form factors

Form factor is the physical shape and connector, separate from the protocol.

The SFF document numbers come from the OCP specification's form factor sections; we could not retrieve the SFF documents themselves, so no further dimensions are quoted.

Zoned Namespaces

A conventional SSD pretends to be a disk where any block can be overwritten at any time. That illusion is what forces the FTL, garbage collection, spare capacity and big DRAM maps. Zoned Namespaces (ZNS) drop part of the illusion. The Zoned Storage documentation describes a ZNS device as exposing its capacity as zones that can be "read in any order but must be written sequentially." The host writes each zone from start to end and resets it as a whole, which matches how NAND erase blocks behave.

The USENIX ATC 2021 paper that introduced ZNS to a wide audience calls the cost of the old interface a "block interface tax": over-provisioning, DRAM for mapping tables and garbage collection overhead. With ZNS, garbage collection moves up into the host software, which knows which data belongs together. The paper reports that a zone aware RocksDB showed at least 2 to 4 times lower 99.9th percentile random read latency and twice the write throughput compared with the same hardware behind a block interface.

ZNS is not drop in: file systems and applications must understand zones. Media reliability stays inside the SSD, as the Zoned Storage documentation notes.

How does self-encryption work, with TCG Opal and Pyrite?

The basic design

A self-encrypting drive (SED) encrypts everything with an AES engine in the controller, using a disk encryption key (DEK), the Media Encryption Key in Opal terms, generated inside the drive. The DEK should be wrapped with a key derived from the user's credential, so at power on the host supplies the credential and the drive unwraps the DEK. Changing a password only rewraps the DEK, and replacing the DEK makes all existing data unreadable in seconds: cryptographic erase.

TCG Opal

The Trusted Computing Group's Opal Security Subsystem Class (SSC) is the most common standard for client and many datacenter SEDs. As the 2019 research paper summarises it, Opal allows multiple credentials, called authorities, and multiple locking ranges, each with its own DEK, so each range can be locked and erased independently. Admin authorities provision and configure; user authorities unlock specific ranges.

Large buyers set their own baselines on top. The OCP datacenter specification requires TCG Opal v2.02 or later for TCG devices and covers features such as Block SID Authentication, which lets the platform firmware stop software from taking ownership of an unprovisioned drive during a boot.

TCG Pyrite

The Trusted Computing Group also publishes a Pyrite SSC for devices that want the same locking and management interface without media encryption. Pyrite drives can lock access to data with a credential, but because the stored data is not encrypted, they cannot offer cryptographic erase in the same way. The TCG specification pages refused our scripted requests during research, so check the current Pyrite revision on the TCG site before relying on details beyond this outline.

Windows encrypted hard drive

Microsoft distinguishes generic SEDs from an "encrypted hard drive" for Windows, which must meet specific TCG protocols and IEEE 1667. On such a drive, BitLocker can hand encryption to the drive, which generates a per volume media key that "is never exposed outside the disk."

What went wrong in published SSD encryption research?

Carlo Meijer and Bernard van Gastel of Radboud University and the Open University of the Netherlands wrote "Self-encrypting deception: weaknesses in the encryption of solid state drives," presented at the IEEE Symposium on Security and Privacy, held 20 to 22 May 2019. They reverse engineered firmware from SSDs made by three manufacturers between 2014 and 2018, covering SATA, NVMe and USB models. Their abstract reports critical weaknesses arising from specification, design and implementation, and says that for many models the flaws allowed "complete recovery of the data without knowledge of any secret."

The flaws fell into recurring classes. We describe them conceptually; the paper and vendor advisories hold the details.

The National Vulnerability Database entry for CVE-2018-12037, published on 20 November 2018, describes the core issue for several affected models as the "absence of a cryptographic link between the password and the Disk Encryption Key."

The paper's sharpest point was about defaults. It noted that BitLocker, by default, turned off its own software encryption and relied entirely on the drive when the drive advertised hardware encryption. So users who thought they had software full disk encryption were trusting the drive firmware. On 6 November 2018, citing reports of weaknesses in some self-encrypting drives, Microsoft published advisory ADV180028. It said BitLocker "will use hardware encryption by default" on self-encrypting drives, explained how to check with manage-bde -status, and told administrators how to force software encryption with Group Policy. It added a point people often miss: changing the policy is not enough for drives already encrypted in hardware. The drive must be decrypted and then encrypted again in software.

The lessons for any team: check which encryption is actually active on each machine; layer software full disk encryption over drive encryption for sensitive data; keep SSD firmware current, since fixes for this class arrive as firmware; and rely on cryptographic erase only where you trust the drive's key handling.

How are SSD firmware updates shipped and verified?

Firmware slots

NVMe drives keep firmware in up to seven numbered slots, and slot 1 may be read only. Identify Controller data reports the slot count, and the Firmware Slot Information log shows the revision in each slot.

Download, then commit

An update is two separate commands. The nvme-cli documentation describes Firmware Image Download as copying all or part of a new image to the controller, possibly in several pieces, and notes that the download alone does not apply it. The Firmware Commit command then verifies the image and commits it to a slot. Commit actions, as listed in the nvme-cli documentation:

Activation usually needs a controller reset. The nvme-cli page notes that "no further action is automatically taken to reset the device," and that on recent kernels a reset can be issued through sysfs.

Signatures and fallback

The commands move bytes; the drive decides whether to accept them, and whether a consumer drive checks a signature is often undocumented. The OCP datacenter specification makes it a requirement for drives built to it: every image must carry a firmware signature, the device must check it while processing any Firmware Commit command, and a failed check aborts the commit with an Invalid Firmware Image status. Its signature requirement references FIPS 186-5 and the OCP Hardware Secure Boot specification.

The same specification covers failure handling. If the active image is corrupt, the device must fail over to a backup copy of the same image, following NIST SP 800-193 guidance, and when new firmware is activated into the running slot, the drive must keep the old image until the new one has initialised successfully at least once.

Shipping updates to Linux machines with fwupd

On Linux desktops and laptops, many drive updates arrive through fwupd and the Linux Vendor Firmware Service, which we cover in our fwupd and LVFS post. The fwupd NVMe plugin documentation says firmware "is sent in 4kB chunks and activated on next reboot," that devices are matched using identifiers built from the PCI vendor and device IDs and sometimes the model string, and that the plugin has been available since fwupd 1.1.2. The update itself still uses the standard download and commit commands; the trust comes from the signed metadata in LVFS and the vendor's own image checks.

Step by step: inventory, health, firmware and disposal

These steps use nvme-cli on Linux, with Windows equivalents. nvme-cli 3.0 renamed several commands to a two word form; the older hyphenated forms still work as deprecated aliases. We show the older form, which most distributions ship today, with the new form noted.

Warning. Steps 4 and 6 change firmware or destroy data. Run them only on a drive you have identified by model and serial number, with verified backups, and never on the drive you booted from unless you mean to.

1. Identify every NVMe drive

sudo apt install nvme-cli   # or: sudo dnf install nvme-cli
sudo nvme list
lsblk -o NAME,MODEL,SERIAL,SIZE,MOUNTPOINTS

nvme list shows each controller, its namespaces, model, serial number, capacity and firmware revision. Match these against your asset inventory.

2. Read identity, firmware slots and capabilities

sudo nvme id-ctrl /dev/nvme0 -H | grep -E '^(mn|sn|fr) |frmw|Firmware Slot|oacs|sanicap' -A3
sudo nvme fw-log /dev/nvme0

Look at fr (current firmware revision), the firmware slot count, and whether the drive supports Security Send and Receive (needed for TCG) and which sanitize actions it supports.

3. Read the health log

sudo nvme smart-log /dev/nvme0      # nvme-cli 3.0: nvme log smart /dev/nvme0

The fields that matter most:

Worked example. data_units_written reads 1,953,125,000. Multiply by 512,000 bytes: 1,000,000,000,000,000 bytes, or 1 PB written. Against a 1,200 TBW rating that is about 83 percent of rated endurance, and percentage_used should be in the same region if the drive tracks it linearly, as the OCP specification requires for datacenter drives.

On Windows, Get-PhysicalDisk | Get-StorageReliabilityCounter | Format-List shows wear, temperature and error counters for supported drives.

4. Update firmware (data at risk; read the warning above)

Prefer the vendor's documented method or fwupd. If you must use nvme-cli, use only an image the drive's manufacturer published for that exact model.

# Confirm the target first. Stop if the model or serial is not the one you expect.
sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn|fr) '

# Download the image to the controller (nvme-cli 3.0: nvme fw download)
sudo nvme fw-download /dev/nvme0 --fw=/path/to/vendor-image.bin

# Commit to slot 2 and activate at next reset (nvme-cli 3.0: nvme fw commit)
sudo nvme fw-commit /dev/nvme0 --slot=2 --action=1

# Reboot, then confirm the new revision
sudo nvme fw-log /dev/nvme0

If the drive rejects the commit with an invalid image status, stop. Do not try other images. For fwupd:

fwupdmgr refresh
fwupdmgr get-updates
fwupdmgr update

5. Check what encryption is actually active

On Windows, from an elevated prompt:

manage-bde -status

If the Encryption Method for a volume says "Hardware Encryption," BitLocker is relying on the drive. Microsoft's advisory explains how to force software encryption by Group Policy, and that existing volumes must be decrypted and encrypted again for the change to take effect. On Linux, LUKS shows its cipher with sudo cryptsetup status <mapper-name>; if you use the kernel's Opal support or an Opal management tool, record which drives are provisioned and who holds the admin credentials.

6. Plan disposal (destroys all data; read the warning above)

# Re-check identity. Compare serial number against the disposal ticket.
sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn) '
lsblk -o NAME,MODEL,SERIAL,MOUNTPOINTS /dev/nvme0n1   # must show no mounted filesystems

# Check which sanitize actions the drive supports
sudo nvme id-ctrl /dev/nvme0 -H | grep -i -A4 sanicap

# Start a crypto erase sanitize, then poll progress
sudo nvme sanitize /dev/nvme0 --sanact=start-crypto-erase
sudo nvme sanitize-log /dev/nvme0

The nvme-cli documentation lists sanitize actions for block erase, overwrite and crypto erase, plus an exit from failure mode. Which to choose, and why sanitize is better than a format or a host side overwrite on flash, is the subject of our sanitize commands post. Record the result in your disposal log with the serial number, the method, the date and who ran it.

7. Record it

Per drive, keep model, serial, firmware revision, encryption method, a health snapshot and, at end of life, the sanitize method and result. The next firmware advisory then becomes a lookup.

How should you plan secure disposal of SSDs?

NIST SP 800-88 Revision 2, published in final form on 26 September 2025, defines three sanitization methods. Clear uses standard read and write commands, such as overwriting addressable space, and protects against simple recovery. Purge uses physical or logical techniques that make recovery infeasible even with laboratory effort while leaving the media reusable; for SSDs that means dedicated sanitize commands. Destroy makes the media unusable through techniques such as shredding, disintegrating, pulverising, melting or incinerating.

Revision 2 moved technique detail out of the NIST document itself. It tells readers to consult IEEE 2883 for acceptable purge techniques, which can include overwrite, block erase and cryptographic erase through standard device sanitize commands.

On cryptographic erase, the guidance is careful:

• It calls CE "noteworthy in its ability to rapidly sanitize target data," but its strength depends on the encryption and key handling inside the drive.
• Federal agencies must use encryption modules validated to the current FIPS 140 standard to rely on CE for a self-encrypting drive.
• CE only covers data that was always encrypted. Citing ISO/IEC 27040, the document says CE is only valid if no sensitive data was ever stored on the media unencrypted.
• Long lived secrets deserve extra thought, because the ciphertext remains on the media and future cryptanalysis or computing advances could, in principle, expose it.

Flash needs this care because spare blocks, retired bad blocks and stale pages hold data the host cannot address, so a host side overwrite can miss them; the encryption research above found key material surviving the same way. A sanitize command runs inside the controller and can reach every block. A workable plan: classify drives by sensitivity, pick clear, purge or destroy per class, sanitize and confirm from the sanitize log, destroy drives that fail, and record each serial number.

Common mistakes

• Treating layer count as a quality score. It says the stack is taller. Endurance and speed depend on cell type, controller, firmware and spare area.
• Buying QLC for sustained writes. The SLC cache hides native QLC write speed only until it fills.
• Reading TBW without write amplification. Small random writes on a nearly full drive burn endurance faster than the rating assumes.
• Running drives nearly full. Less free space means more garbage collection and slower writes.
• Assuming hardware encryption is on and sound. Check manage-bde -status or your Linux setup.
• Changing the BitLocker policy and stopping there. Existing volumes must be decrypted and encrypted again.
• Flashing firmware from an unofficial source, or forgetting the reset. Use the maker's image for the exact model; most commit actions activate only at the next reset.
• Wiping SSDs with a host side overwrite. Use the drive's sanitize command, then destroy if it fails.
• Not recording serial numbers and firmware revisions. Without them, a firmware advisory turns into a hunt.

FAQ

How is an SSD made, step by step?

NAND is built on wafers by stacking hundreds of film layers and etching vertical channel holes that become strings of cells. Wafers are tested, diced and packaged, the packages are soldered to a board with a controller, firmware is loaded, and each drive is burned in and tested.

What does 3D NAND mean?

Cells are stacked vertically in many layers instead of laid out flat, so capacity grows with layer count rather than by shrinking cells until they interfere with each other.

What is the difference between SLC, MLC, TLC and QLC?

They store 1, 2, 3 and 4 bits per cell, needing 2, 4, 8 and 16 voltage levels. More bits mean more capacity but lower endurance and slower writes.

What is the difference between charge trap and floating gate flash?

Floating gate stores charge in a conductive polysilicon island that one defect can drain. Charge trap stores it in insulating silicon nitride, where it stays put, which suits 3D NAND.

What does an SSD controller do?

It maps logical blocks to physical pages, runs garbage collection and wear levelling, corrects errors with codes such as LDPC, manages spare blocks and encryption, and handles firmware updates.

What is the difference between M.2, U.2, E1.S and E3.S?

They are physical form factors. M.2 is the small card in laptops and desktops, U.2 the 2.5 inch hot swap server shape, and E1.S and E3.S are newer EDSFF server shapes defined in SFF-TA-1006 and SFF-TA-1008. All can carry NVMe.

Are self-encrypting SSDs safe?

Some are, but published research found drives whose key was not tied to the password. Check which encryption is active, keep firmware current and layer software encryption for sensitive data.

How do I update SSD firmware on Linux?

Use fwupd (fwupdmgr get-updates, then fwupdmgr update) or the maker's tool. With nvme-cli, nvme fw-download then nvme fw-commit, then reset or reboot, using only the vendor's image for that model.

How do I check SSD health?

Run sudo nvme smart-log /dev/nvme0 on Linux or Get-PhysicalDisk | Get-StorageReliabilityCounter on Windows, and trend critical warning, available spare, percentage used, media errors and data written.

How do I securely erase an SSD before disposal?

Use the drive's sanitize command, confirm completion in the sanitize log, record it, and follow NIST SP 800-88 Revision 2 to choose clear, purge or destroy. Destroy drives that cannot be sanitized.

Where Safeguard fits, honestly

Safeguard does not make, test or analyse SSDs. It does not scan drive firmware, verify firmware signatures, generate a hardware bill of materials, manage devices or erase media; its models are single-purpose security models for software. The fit is narrower: the software around storage is ordinary software, such as inventory agents that collect nvme list output, health dashboards, disposal trackers, and the nvme-cli and fwupd packages inside your images. Safeguard scans repositories, container images and SBOM files for known vulnerable components, shows which projects carry a given component and version, and can open fix pull requests when a fixed version exists, with autonomous remediation switched off by default.

Every time a server or laptop image is rebuilt, it pulls storage tools, update clients and their libraries again, and those open source components carry their own known vulnerabilities. The fit is indirect, since Safeguard does not touch SSD hardware or firmware, but the software you build to manage drives is part of your supply chain like everything else.

Fix it without waiting for upstream

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

The first demo is a real Safeguard CLI session asked to fix a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json, runs npm install and npm test with approval and pushes nothing. The same flow fits a storage inventory service or drive health dashboard your team maintains.

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

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. That suits teams who build server and desktop images, nvme-cli and fwupd included, on their own hardware.

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

The third demo is a real Android session: send work to a computer running the CLI and approve each command on the phone with Allow once, Allow for turn or Deny. An on call engineer can approve a fix in a fleet tooling repository without anything running unattended.

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

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Samsung Newsroom, Samsung Starts Mass Producing Industry's First 3D Vertical NAND Flash (6 August 2013)
• Samsung Newsroom, Samsung Electronics Begins Industry's First Mass Production of 9th-Gen V-NAND (23 April 2024)
• SK hynix Newsroom, SK hynix Starts Mass Production of World's First 321-High NAND (21 November 2024)
• Kioxia America, BiCS FLASH 3D flash memory
• Micron, 3D NAND products
• NVM Express, Specifications
• Open Compute Project, Datacenter NVMe SSD Specification version 2.5
• Zoned Storage, NVMe Zoned Namespaces (ZNS) Devices
• USENIX ATC 2021, ZNS: Avoiding the Block Interface Tax for Flash-based SSDs
• Meijer and van Gastel, Self-encrypting deception: weaknesses in the encryption of solid state drives (paper PDF)
• IEEE Symposium on Security and Privacy 2019, accepted papers
• Microsoft Security Response Center, ADV180028: Guidance for configuring BitLocker to enforce software encryption (6 November 2018)
• NIST National Vulnerability Database, CVE-2018-12037
• Microsoft Learn, Encrypted hard drive
• NIST CSRC, SP 800-88 Rev. 2, Guidelines for Media Sanitization (September 2025)
• NIST, SP 800-88 Rev. 2 full text (PDF)
• nvme-cli documentation, nvme-fw-download
• nvme-cli documentation, nvme-fw-commit
• nvme-cli documentation, nvme-log-smart
• nvme-cli documentation, nvme-smart-log (deprecated alias)
• nvme-cli documentation, nvme-sanitize
• fwupd, Plugin: NVMe

Last reviewed: 23 October 2026.