h/t
MacInTouch
For those who aren't seriously into computer technology, there are technological issues with erasing an SSD.
With a hard drive, you can use all kinds of standard disk-erase utilities to write zeros to every block. If you're paranoid about leaving magnetic after-images, there are various algorithms for writing various patterns designed to obscure any magnetic residue of old files. They take a long time, but are generally considered secure enough for all but the most sensitive data (which should only be "erased" via physical destruction of the drive.)
With an SSD, however, erasure by overwriting new data is not effective. Tehnologies like wear leveling, garbage collection and TRIM make it difficult or impossible to know if data has truly been erased. Writing zeros to a logical block of data does not necessarily overwrite the flash memory containing the old data - it is more likely that the flash memory will be marked as "garbage" for collection (which will truly erase it) at some non-deterministic time in the future. That time might be quickly, or it might not be for days or even months, depending on the SSD controller's algorithm and the drive's usage pattern.
Mind you, this "garbage" data is not accessible using any software-accessible interface (SATA, SCSI, USB, etc.) The only way to read garbage data is to install special firmware into the SSD controller or to physically remove the chips. But both options are possible for someone willing to pay a data recovery company or some other similarly capable forensics lab.
Which is where the ATA secure erase command comes into play. The ATA specification (at the heart of all ATA and SATA devices) includes a command for explicitly and securely erasing a device. When supported on an SSD, it performs a flash-level erase on every single block, ensuring that no data will be available to recover.
And now, with this background material in mind, the linked MacInTouch posting now make sense. It would appear that the act of installing Windows 8 or 10 on an SSD involves writing some data to the drive that disables the secure erase command. Why they do this may be an interesting topic for discussion, but doesn't really matter if you've got a retired drive that you want to erase.
To get around this problem, you need to get a copy of the SSD manufacturer's drive utility. You can use this utility to reset the SSD's firmware, which will re-enable the secure erase command. Unfortunately, in order for this to work, you need the drive's PSID code - this is a secure ID designed to prevent malware from bypassing security features. Fortunately, most SSDs print the PSID on the drive's label. Unfortunately, if your label is removed or damaged, you may not be able to read it and there is usually no other way to get this number.
I suppose the important lesson here is that when you install a new SSD into a computer, photograph the cover to make a record of the PSID number. If you are concerned that a hacker might get this image, print a few copies and store them in a secure location (like a file cabinet) and then erase the image file.
If all this seems like too much, there's another alternative - use whole-drive disk encryption before you copy any data to the SSD. Later on, when it's time to retire the SSD, blow away the decryption key. A simple drive-erase (without decrypting it) will do it just fine. Or if you want to make it even simpler, change the drive's password to a long string of gibberish characters (30-50 characters should do nicely) and promptly forget what they are. Anybody who gets the drive in the future will not be able to access the data without this string, and it is highly unlikely that they will ever be able to provide it. Of course, you can also delete all the files and empty-trash before changing the string, to provide an additional level of protection.
Finally, you might want to encrypt the drive anyway. This way you will be protected in case the drive controller fails, since you won't be able to perform any kind of secure erase operation at that point, but your encrypted data will not be recoverable through forensic analysis without the decryption key.
