So many NVMe/SATA drives that are locked/frozen during boot, and it turns out this is because the drives are actually behaving incorrectly when "security operations" are blocked on the drive. When "security operations" are blocked, you should not be able to set a password on the drive, but should be able to format it. So that's bug 1.

Most modern motherboards, on boot, will block "security operations" on a drive where the security password is set to the default (because it hasn't been manually set by the end-user). They do this to prevent malware from being able to set a password on a drive that hasn't had its password set. (Malware could set the password and I believe configure the drive to effectively brick it.)

But many (probably most) motherboards fail to correctly block "security operations" on a suspend/resume. This is bug 2, and makes suspend/resume often an effective workaround for a drive with bug 1, as well as a theoretical opportunity for malware to easily inflict damage on all drives that support "security operations".

So one generally ends up stuck and unable to securely erase their drive when it has bug 1 and is installed on a motherboard without bug 2. In this case, you have to hope your motherboard has a feature in its BIOS to, on next boot, not block security operations. Otherwise you're stuck and need to find another motherboard if you want to sanitize your drive, or hope that a firmware update for your drive resolves bug 1.

The full details are in this comment on a Github issue from 2016: https://github.com/linux-nvme/nvme-cli/issues/84#issuecommen... . It was one of the most rewarding bugs I've had the fortune to get to the bottom of. We were extra motivated to fully understand it when we moved to a new SSD benchmarking test system that turned out to not have bug 2: https://pcpartpicker.com/forums/topic/460000-an-ssd-that-can...