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.
Where to start
Run the scan. One command inventories both your classical TLS posture and your quantum-vulnerable surface: npx @quantakrypto/qscan ./
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.