Traffic recorded today can be read tomorrow
An attacker who stores your encrypted traffic now can decrypt it once a quantum computer breaks the public-key step that protected it. Data that must stay confidential for years is exposed today, before that computer exists.
- What is at risk
- Key exchange with RSA or ECC
- When it starts
- The day the data is recorded
- First step
- An inventory of key establishment
The threat
The cipher holds; the key exchange is the weak point
Most encrypted traffic uses a symmetric cipher with a key agreed through RSA or elliptic-curve Diffie-Hellman. Shor's algorithm, run on a cryptographically relevant quantum computer (CRQC), would recover that key from a recorded exchange, and with it everything the session carried.
Such a computer has not been demonstrated, and no one can give you its date. The exposure does not depend on that date alone: it depends on how long your data must stay secret.
Sessions and tunnels
TLS sessions, VPN tunnels and SSH connections whose key exchange used RSA or elliptic curves.
Wrapped keys
Backups and archives whose data keys were encrypted with an RSA public key.
Symmetric ciphers
Ciphers with 256-bit keys are not the urgent problem. The public-key step that agreed the key is.
Mosca's inequality
You are exposed when X + Y is greater than Z
X is how long the data must stay confidential. Y is how long your migration will take. Z is the time until a CRQC exists. If X + Y exceeds Z, data you send today will still matter when it can be read.
| Data | X: must stay secret for | Y: your migration | Exposed if a CRQC arrives within |
|---|---|---|---|
| Session tokens | Hours | 3 years | About 3 years |
| Contracts and financial records | 10 years | 3 years | 13 years |
| Health and genomic records | Decades | 3 years | Decades |
| State and defence secrets | 25 years or more | 5 years | 30 years or more |
Illustrative values. Put in your own X and Y. Because Z is unknown, the useful question is which data has the largest X + Y, not which year to wait for.
What to do now
Find the exposed key exchanges, then move the long-lived ones first
- 01
Rank your data by shelf life
For each system, write down how long its data must stay confidential. That is X in the inequality.
- 02
Inventory key establishment
Export a CycloneDX 1.6 cryptographic bill of materials (CBOM) from the discovery tools you already run.
- 03
Evaluate the inventory
QuantumLock evaluates the CBOM against a versioned post-quantum policy pack and returns a pass, review or fail decision with a reproducible id. See Cryptographic inventory.
- 04
Move the longest-lived data first
Migrate key establishment for those systems to ML-KEM (FIPS 203), the NIST standard for post-quantum key establishment, in your TLS, VPN and messaging stacks.
- 05
Evaluate again
Re-import the updated CBOM against the same pack version and track the decisions over time.
Policy rules
The checks that matter for harvest now, decrypt later
Three rules of the softquantus-pqc-baseline pack bear directly on recorded traffic. The pack has six; the full list is on the cryptographic inventory page.
| Rule | Severity | What it reports |
|---|---|---|
| PQC-001 | Critical | A key agreement, key encapsulation, public-key encryption or signature primitive declared at NIST quantum security level 0 |
| PQC-002 | High | A primitive with no declared quantum security level, reported as unknown rather than vulnerable |
| PQC-006 | Info | Certificates, protocols and related crypto material, reported as not evaluated by the pack |
PQC-006 means a pass never covers your TLS or VPN configuration. Those protocols need their own review.
Scope
What QuantumLock does and does not do here
Evaluates your CBOM
Imports a CycloneDX 1.6 CBOM and judges it against a versioned policy pack, so every team is measured the same way.
Does not scan your network
Discovery stays with your own tools. QuantumLock evaluates the inventory they produce.
Does not establish keys
QuantumLock does not provide key establishment or TLS. Its ML-KEM support is limited to key generation.
Does not detect harvesting
Recorded traffic leaves no trace you can check for. The defence is to change the key exchange before the data's shelf life runs out.
Signs what must stay trusted
The same threat applies to signatures: forged once the algorithm falls. QuantumLock signs with ML-DSA (liboqs, not CAVP-validated). See quantum-safe signatures.
Plans against dates
The NIST draft IR 8547 names 2030 and 2035, and the EU roadmap targets the end of 2030 for high-risk uses. See the post-quantum timeline.
Questions
What security teams ask about harvest now, decrypt later
What is harvest now, decrypt later?
The practice of recording encrypted data today in order to decrypt it later, once a quantum computer can recover the keys. It is also called store now, decrypt later.
When will a quantum computer break RSA?
No one can say. A computer able to break RSA and elliptic-curve cryptography has not been demonstrated. Mosca's inequality turns that uncertainty into a planning question: how long must your data stay secret, and how long will migration take?
Is AES at risk?
Not in the same way. Symmetric ciphers with 256-bit keys are not the urgent problem. The exposure is the public-key exchange that agreed the key.
Does QuantumLock encrypt our traffic with ML-KEM?
No. QuantumLock does not provide key establishment or TLS, and its ML-KEM support is limited to key generation. It helps you find where quantum-vulnerable key exchange is used and decide what moves first.
Does a passing CBOM evaluation mean our TLS is quantum-safe?
No. The policy pack reports certificates and protocols as not evaluated, so a pass covers the declared algorithms only.
Related
More on the post-quantum migration
Start with the inventory
Send us a CBOM from your discovery tools. We will evaluate it against the post-quantum policy pack and walk you through what is exposed.