For SATA SSDs i've used the hdparm secure erase and then verified that dd | hexdump is all zeros. That was good enough for me.

Indeed, LUKS + F2FS for /home with an external key file imported into initrd solves a lot of issues.

Primarily, when an SSD slowly fails the sector replacement allotment has already bled data into read-only areas of the drive. As a user, there is no way to reliably scrub that data.

If the drive suddenly bricks, the warranty service will often not return the original hardware... and just the password protection on an embedded LUKS key is not great.

There are effective disposal methods:

1. shred the chips

2. incinerate the chips

Wiping/Trim sometimes doesn't even work if the Flash chips are malfunctioning. =3

Used to do recycling. Before secure erase was widespread there used to be cheapish 16 and 32GB SSDs for embedded devices, but a few of them made it into the thin/zero client space and a few white labelled low end pc's. they were actually twice the size. Basically 2 16s in a single 16 chassis. And what you would get is that the 2 drives were sort of in sync, I think it was a failover mechanism to deal with shitty drive quality. If drive A failed it would just connect to drive B instead and the user might not know about the failure. But the second drive would not wipe necessarily depending on how you wiped the first one. A few people retrieved data from the second disk under lab conditions, after wiping the first, so we had a report come through that we couldnt certify these disks as erased until they demonstrated compliance with secure erase. So we shredded probably a few thousand of them.

I heard of similar issues with early nvme drives.

If compliance is the goal, just use FIPS certified self-encrypting drives and trust them to wipe their encryption keys when instructed to do so. At that point, any failure is clearly the vendor's fault, not your own.

Tip: Get a barcode scanner. The PSID is usually encoded in a bar/matrix code on the drive's label, next to the plaintext PSID.