Post-Quantum Cryptography
Know what breaks before someone else does.
The encryption protecting your traffic, your backups and your signing keys was designed to withstand classical computers. However, a cryptographically relevant quantum computer does not merely weaken RSA and elliptic-curve cryptography. It breaks them.
Even so, you do not have to believe that machine will arrive soon to have a problem today. Encrypted traffic captured now can be stored and decrypted later. As a result, data with a ten-year confidentiality requirement is already exposed.
Meanwhile, NIST published the replacement standards in August 2024. The work in between is a post-quantum cryptography migration: inventory, prioritization and staged rollout. In practice, it takes longer than most organizations expect.
Start with a scan
Coming soon!
A scan tells you what you are running. For example, point it at a repository, a container image or a hostname, and it returns the cryptographic inventory with a readiness score in minutes.
Self-serve scanning is launching at quantsec.pro. Until it opens, however, we run the same scan to generate CBOMs for tracking, reporting, and compliance.
What a post-quantum cryptography migration involves
Broadly, the work falls into four stages. Each one produces something you can act on.
Discovery
First, we find the cryptography you are actually running: in your source code, in your container images and in your certificate chains. The result is a cryptographic bill of materials, or CBOM, rather than a spreadsheet someone updated by hand two years ago.
Exposure
Next, every algorithm is scored on its post-quantum standing. RSA, ECDSA and Diffie-Hellman are ranked by where they are deployed and what they protect. Therefore the list you get back is ordered by risk, not alphabetically.
Migration
Then you get a sequenced plan built on the NIST standards: ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures. Specifically, it sets out which systems move first, what each one depends on, and what breaks if they move in the wrong order.
Evidence
Finally, a report you can hand to an auditor or a board, or use to answer a customer’s security questionnaire. In addition, the underlying CBOM is attached, so the findings can be checked rather than taken on trust.
Harvest now, decrypt later
The attack does not need a quantum computer to start. Instead, it needs storage.
An adversary records encrypted traffic today and holds it. Later, when the hardware arrives, the recording is decrypted after the fact. Moreover, nothing about your current TLS configuration prevents this, because the session keys were negotiated with mathematics that will not hold.
Ask a different question
This turns the usual reasoning about cryptographic risk on its head. Normally the question is how long until the threat is real. In contrast, the right question is how long your data must stay confidential.
If the answer is longer than the time remaining before quantum decryption is practical, then the exposure is already live. Furthermore, every day of unprotected traffic adds to it.
Meanwhile, draft NIST guidance treats RSA-2048 and 256-bit elliptic-curve cryptography as deprecated after 2030 and disallowed after 2035. Migrations of this size, however, are measured in years, not quarters.
Run it privately
For most enterprises, the obstacle is not interest — it is disclosure. After all, a cryptographic inventory is a map of your weakest points. Consequently, handing it to a third-party service is a decision security teams are right to resist.
That is why the enterprise engagement runs entirely inside your environment. Specifically, the scanner is deployed on your infrastructure, your source code and images never leave your network, and no findings are sent to us. In short, you hold the CBOM, the reports and the raw output, while we provide the tooling and the people who read the results with you.
So if your requirement is that nothing about your cryptographic posture leaves your perimeter, that is the default configuration, not an upgrade.
About your environment
No two environments are alike. Therefore the honest first step is a conversation about what you run and what you have to protect.
Enterprise inquiries: [email protected]