When you delete a file on an SSD, the operating system sends a TRIM command telling the controller which LBAs (logical block addresses) are no longer needed. The controller marks those pages as invalid in its flash translation layer (FTL). The physical NAND cells are not erased at this point. Most modern SSDs implement DRAT or DZAT (Deterministic Read After TRIM / Deterministic Zeroes After TRIM), which means the controller immediately returns zeroes when those addresses are read through the normal interface, even though the underlying NAND cells still hold their original charge. The actual physical erasure happens later during garbage collection, when the controller consolidates valid pages into new blocks and erases the freed blocks asynchronously. Depending on workload and idle time, that physical erasure can take minutes to hours. Once a TRIM command is fully processed, the controller intentionally blocks access to the deleted files through standard interfaces. Unless the drive suffered an immediate hardware failure preventing background garbage collection, the data is typically permanently unrecoverable via conventional software.
This is the opposite of how hard drives work. On a spinning disk, deleted files sit untouched until new data overwrites them. On a TRIMmed SSD, the data becomes inaccessible through the controller within seconds of deletion. Physical NAND erasure follows during garbage collection, but the controller will not serve the data from the moment TRIM completes.
The distinction that matters: if you deleted files and the drive kept running, TRIM has already done its job and those blocks are logically unmapped. If the drive died from a hardware failure (dead controller, shorted PMIC, firmware corruption), the data may still exist on the raw NAND. However, on modern drives with hardware-level encryption (virtually all contemporary NVMe and many SATA SSDs use Self-Encrypting Drive technology by default), the decryption keys are tied to the controller. If the controller is permanently dead and cannot be revived through firmware repair or component-level microsoldering, extracting the raw NAND yields only unreadable ciphertext. Recovery in these cases depends entirely on restoring controller functionality, not on chip-off NAND extraction.
TRIM on Windows
Windows enables TRIM automatically on any SATA or NVMe SSD using native Microsoft drivers. The Storage Optimizer (formerly Disk Defragmenter) schedules a weekly "Retrim" pass that re-issues TRIM commands for all previously deleted blocks, ensuring the controller stays current even if the initial TRIM was missed. On a healthy Windows system, deleted data is typically logically unmapped and rendered inaccessible within seconds of deletion during normal use, and any stragglers are caught by the next weekly Retrim cycle.
TRIM on macOS
On Macs with a T2 chip (late 2017 through 2020, starting with the iMac Pro) or Apple Silicon (M1/M2/M3/M4), every byte written to the internal SSD is encrypted by default using AES-256 in XTS mode, with keys managed by the Secure Enclave inside the SoC. This encryption is always-on and transparent; you do not need to enable FileVault for it to be active. When files are deleted, macOS sends a standard TRIM command, and the controller handles it like any other SSD: the LBAs are marked invalid in the FTL and reads return zeroes. The Secure Enclave does not destroy any keys in response to individual file deletions.
What makes T2/M-series recovery different is not TRIM behavior; it is the always-on hardware encryption tied to the specific SoC. Because every block on the NAND is AES-256 encrypted with keys that exist only inside the Secure Enclave on that specific chip, desoldering the NAND yields only ciphertext regardless of whether TRIM has run. Chip-off is useless on these machines. The only recovery path when the logic board is dead is board-level microsoldering to get the Secure Enclave operational again so it can decrypt in place. We will not accept payment for a case we know cannot succeed.
Crypto-shredding, where the Secure Enclave destroys the volume encryption key and makes all data on the drive permanently irrecoverable, happens only during a full disk erase (Erase All Content and Settings, or a DFU restore). That operation is instant and absolute. It is distinct from per-file TRIM, which leaves the encryption keys intact.
On older Macs without a T2 chip using third-party SSDs, TRIM is not enabled by default. Users must run sudo trimforce enable to activate it. Until that command is run, deleted files persist on the NAND and standard recovery applies.
TRIM on Linux
Linux TRIM behavior depends entirely on the distribution and file system. Many distros batch TRIM commands via a weekly fstrim.timer service, creating a window where deleted data remains on the NAND before the timer executes. However, modern setups (such as Btrfs) increasingly default to asynchronous real-time discard, which unmaps blocks in the background continuously. If real-time discard is active, the data is unmapped immediately and is unrecoverable through the controller.
Write Amplification and Garbage Collection
TRIM tells the controller which blocks are free. Garbage collection is what the controller does with that information: it consolidates valid pages from partially-empty blocks into new blocks, then erases the old ones to create clean write targets. This runs continuously in the background whenever the drive is powered on and idle. Every consolidation cycle means extra writes to the NAND that the host never requested. That ratio of actual NAND writes to host writes is called write amplification. A drive with a write amplification factor of 3x wears its cells three times faster than the host workload alone would suggest. Heavy random writes, a nearly full drive, and aggressive garbage collection all push the factor higher, accelerating the path toward ECC failure and controller lockup.
The practical takeaway: if your SSD died from a hardware failure and never had the chance to run garbage collection after the crash, the metadata in the service area is likely intact, giving us a strong chance to reconstruct the FTL. If the drive was running for days in a degraded state, grinding through garbage collection cycles before it finally locked up, the controller may have already damaged the service area beyond repair. The sooner a failing drive is powered off and sent to a lab, the better.
SSD Recovery Feasibility by Failure Scenario
| Operational Condition | Encryption Status | Physical / Logical State | Recovery Feasibility |
|---|
| TRIM enabled (NTFS, APFS) | Unencrypted | Logical deletion | Near zero; controller has zeroed the blocks |
| TRIM enabled (exFAT, FAT32) | Unencrypted | Logical deletion | Moderate; these file systems issue TRIM less aggressively |
| TRIM disabled or not issued | Unencrypted | Logical damage | High; NAND retains all data |
| TRIM disabled or not issued | Encrypted (key available via working controller) | Logical damage | High; decrypt in place, then image |
| TRIM disabled or not issued | Encrypted (key unknown or lost) | Any state | Zero; no viable decryption path |
| Any TRIM state | Any encryption | Severe physical damage (dead controller) | Depends on board repair feasibility; TRIM cannot execute on a dead controller |
TRIM cannot execute on a physically dead controller. If the drive died from a hardware failure before the OS sent TRIM commands, deleted data is still on the NAND.
