Fill the drive 100% using data duplicator then delete everything on the drive. Repeat a few times to ensure you scrub all blocks. There is no need to physically destroy the drive.
That doesn’t work with SSDs anymore. Their controllers map “bad” blocks which are put in an RO state and writes no longer go there but data still exists. There is usually a buffer of extra space so you do see the capacity loss, but if you bypass the controller you can still read the data there.
That’s fair, I can appreciate an attack vector in cases where there are bad blocks and the drive was unencrypted. Luckily bad blocks are less common with modern SSDs and assuming the disk was encrypted, a few bad blocks are unlikely to expose any contents. So knowing the number of bad blocks and what data was stored would inform if a fill and empty approach would be suitable to sanitize the drive.
Fill the drive 100% using data duplicator then delete everything on the drive. Repeat a few times to ensure you scrub all blocks. There is no need to physically destroy the drive.
That doesn’t work with SSDs anymore. Their controllers map “bad” blocks which are put in an RO state and writes no longer go there but data still exists. There is usually a buffer of extra space so you do see the capacity loss, but if you bypass the controller you can still read the data there.
That’s fair, I can appreciate an attack vector in cases where there are bad blocks and the drive was unencrypted. Luckily bad blocks are less common with modern SSDs and assuming the disk was encrypted, a few bad blocks are unlikely to expose any contents. So knowing the number of bad blocks and what data was stored would inform if a fill and empty approach would be suitable to sanitize the drive.