First Quantum-Safe HSM Clears FIPS 140-3 Level 3
Crypto4A's QASM module is the first HSM validated at FIPS 140-3 Level 3 for the complete NIST post-quantum cryptography algorithm set.
A hardware security module built in Canada just cleared a bar no post-quantum HSM had cleared before: FIPS 140-3 Level 3, with the full set of NIST-approved post-quantum algorithms supported natively. Crypto4A Technologies announced the validation for its QASM cryptographic module on August 20, the core of its QxHSM and QxVault appliances. If you spend your days worrying about where cryptographic keys physically live, this is a more consequential story than another browser turning on hybrid TLS.
What actually got validated
FIPS 140-3 is NIST’s current standard for evaluating cryptographic modules, and it replaced FIPS 140-2 as the mandatory baseline a few years ago. Level 3 is the tier that matters when the keys you’re protecting would be catastrophic to lose: tamper-evident and tamper-resistant physical construction, identity-based operator authentication instead of just role-based, and hardware-enforced separation between the interfaces carrying plaintext key material and everything else. Pushing a module through Level 3 testing at an accredited lab typically takes a year or more, and NIST’s validation queue has been backed up for a while as vendors try to get PQC-capable modules through it.
What makes this validation worth noting isn’t just the level, it’s that QASM runs the full NIST PQC set natively: ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) for signatures, SLH-DSA (FIPS 205) as the hash-based backup, plus stateful schemes like LMS, all inside a module that’s cleared the hardest physical and operational bar NIST has. Crypto4A had already validated a PQC-capable module at FIPS 140-2 Level 3+; this is the first time anyone’s done it under the stricter 140-3 standard.
The boring layer that actually decides your timeline
Most of the PQC coverage over the past year has been about endpoints. Browsers turning on hybrid key exchange. TLS stacks adding ML-KEM cipher suites. CAs starting to issue ML-DSA certificates. That’s the visible part. Underneath it, something has to generate, store, and use the private keys those handshakes and certificates depend on, and for anything that matters, that’s an HSM, not a software keystore sitting on a server somewhere.
This is where PQC migration plans quietly stall. Swapping a TLS library’s algorithm list takes an afternoon. Swapping (or waiting on) the HSM anchoring your PKI is a procurement and compliance project measured in quarters, sometimes years, especially if you’re in a regulated industry where FIPS validation isn’t optional. Every HSM vendor in this space has been racing NIST’s validation program, and until a module clears it, “we support ML-KEM” on a spec sheet is marketing copy, not something you can point to in an audit.
DigiCert CEO Amit Sinha was quoted in Crypto4A’s announcement making roughly this point: trust in the digital economy depends on cryptographic foundations that are independently validated, not just algorithmically current. That’s not just a supportive quote for a press release. DigiCert has its own 2029 target for migrating its PKI infrastructure, and the HSMs underneath that PKI are exactly the kind of dependency that decides whether 2029 is realistic or aspirational.
What this doesn’t fix
A validated HSM removes one excuse from the migration gap. It doesn’t close the rest of it. Survey data from DigiCert earlier this year found 87% of organizations now planning, testing, or piloting PQC, but only 7% have more than half their digital certificates running on quantum-safe or hybrid cryptography, up from 5% in May 2025. That’s less than two points of movement in over a year, on a metric that’s supposed to be accelerating. Certificate inventories nobody’s finished, third-party dependencies nobody controls, and CA relationships nobody’s mapped to PQC-capable issuance are still the bigger blockers than any single vendor’s HSM roadmap.
What to do with this
If you’re evaluating HSM vendors for a migration, FIPS 140-3 Level 3 with native PQC algorithm support is now a real thing you can ask for, not a roadmap slide or a “coming Q1” promise. Ask your current HSM vendor exactly where they stand against it. If they’re not there yet, get a specific date rather than a general one. “Later this year” has been the standard answer for a while now, and the validation queue isn’t getting any shorter.