Also mentioned
RSARSARivest, Shamir and AdlemanA widely used public-key algorithm for encryption and digital signatures whose security relies on the difficulty of factoring large numbers.Read the full entry (new tab), ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry (new tab), KEMKEMkey encapsulation mechanismA public-key mechanism for securely establishing a shared secret key: the sender encapsulates a random secret to the recipient's public key, and the recipient decapsulates it with their private key.Read the full entry (new tab), TLSTLSTransport Layer SecurityTransport Layer Security, the protocol that encrypts and authenticates most internet traffic, including HTTPS. It uses key exchange, certificates, and symmetric encryption to protect a session.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab), PQCPQCpost-quantum cryptographyCryptographic algorithms designed to run on today's classical computers while remaining secure against attacks by both classical and future quantum computers.Read the full entry (new tab), CBOMCBOMcryptographic bill of materialsA Cryptographic Bill of Materials, a structured, machine-readable inventory of the cryptographic assets used by a system or application, often expressed as an extension of a software bill of materials (SBOM).Read the full entry (new tab) are defined in the glossary.
Read this first
We built a scanner to inventory quantum-vulnerable cryptography and ran it across 43 popular open-source projects. It flagged the RSA and elliptic-curve keys we expected and, more often than we'd like, something far more basic: TLS certificate verification switched off in production. The post-quantum lesson turns out to be the classical one: you can't migrate, or defend, cryptography you can't see.
We build qscan to answer a specific question: where does an organisation use cryptography a quantum computer will eventually break? To pressure-test it, we pointed it at 43 widely-used open-source projects: automation platforms, CMSs, data tools, the kind of software thousands of companies run in production.
We got the RSA and elliptic-curve inventory we expected. We also got a recurring surprise that has nothing to do with quantum computers.
The pattern we weren't looking for
rejectUnauthorized: false, hardcoded, with no way to switch it back on, sitting in the exact code paths that carry database passwords, SMTP credentials, and secret-manager API keys. The TLS handshake still happens; the certificate is simply never checked. Any machine between the app and the server can present its own certificate and read everything.
It's a bank-vault door, installed and then propped open with a brick.
Why a post-quantum team cares about a classical bug
Two reasons. First, disabling certificate verification removes the one control that stops a man-in-the-middle, the same adversary the whole "harvest now, decrypt later" concern is built around.
But the deeper reason is visibility. Every one of these findings was invisible until something actually looked. And that is the real story of the post-quantum transition too: the hard part was never choosing ML-KEM. It is building an inventory of every place cryptography lives and how it is configured. A project that can silently ship with TLS verification off is a project that has no map of its own crypto surface, which is precisely the gap that stalls a PQC migration before it starts.
The good news and the bad
- Bad: verification-off is a defense-in-depth failure that only bites under an active attacker, so it sails through code review and passes every test.
- Good: it is almost always a one-line fix. Verify by default, and let operators opt out explicitly for self-signed hosts.
- Better: the same scan that surfaces it also inventories your quantum-vulnerable crypto. One pass, two horizons.
Where we found these, we have been sending hardening fixes upstream: secure-by-default with an explicit opt-out, matching each project's own conventions. The same reading, done against a codebase somebody owns and has to defend, is what an audit is.
Where to start
Run the scan. One command inventories both your classical TLS posture and your quantum-vulnerable surface: npx @quantakrypto/qscan ./
This is the canonical CWE-295: Improper Certificate Validation: and it is exactly why the classical and quantum findings belong in one scan. A disabled certificate check does not just expose you today; it also renders any future post-quantum handshake worthless. Hybrid X25519MLKEM768 protects the key exchange against a harvest-now-decrypt-later adversary, but if the endpoint never verifies who it is talking to, an active attacker terminates the connection and reads everything regardless of how quantum-safe the KEM is. Migration and hygiene are the same discipline pointed at two horizons.
The headline risk is a decade out. The habit that closes it, measuring your cryptography instead of assuming it, pays off today. Classical or post-quantum, crypto you can't see is crypto you can't defend.
References
- CWE-295: Improper Certificate Validation (MITRE): the weakness class behind a disabled TLS check.
- Harvest now, decrypt later (Wikipedia): the adversary model the quantum half of the scan targets.
- Quantum-Readiness: Migration to Post-Quantum Cryptography, CISA, NSA & NIST: the joint factsheet urging cryptographic inventories.
- Post-Quantum Cryptography project, NIST (FIPS 203/204/205), and Post-quantum cryptography (Wikipedia).
- Cryptography Bill of Materials (CBOM), CycloneDX: the machine-readable inventory format.