Post-Quantum Cybersecurity Risks: Harvest Now, Decrypt Later and the Third-Party Problem
CyberRank Research
Part of: Post-Quantum Cryptography Assessment
Post-quantum risk is already a third-party risk: data you share with vendors can be recorded today and decrypted once a quantum computer can break public-key encryption, and your vendors' cryptography decides how well it survives. Quantum computers that can do this do not exist yet, but NIST's final IR 8547 now deprecates quantum-vulnerable algorithms after 2030 and disallows them after 2035, and most migrations will take years. CyberRank gives you an outside-in view of your vendors' TLS hygiene and, with its quantum-crypto exposure check (Beta), which of their public services still rely only on quantum-vulnerable cryptography.
TL;DR
- Harvest now, decrypt later means encrypted data stolen today can be read once a cryptographically relevant quantum computer (CRQC) exists.
- NIST IR 8547, final since 27 October 2026, deprecates quantum-vulnerable public-key algorithms after 2030 and disallows them after 2035.
- Most of the cryptography protecting your data is chosen by vendors, cloud providers and their own suppliers, so your exposure is inherited.
- A data flow is only as quantum-safe as its weakest hop, and classical fallback often happens silently.
- CyberRank checks vendors' public TLS configuration and quantum-crypto exposure (Beta), so readiness claims can be compared with observable evidence.
What is post-quantum third-party risk?
Post-quantum third-party risk is the chance that your data is exposed to a future quantum attack because a vendor, cloud service or partner still protects it with quantum-vulnerable cryptography.
Your own migration covers only the systems you run. Your data also lives in SaaS platforms, cloud key management, payment processors and managed services, each choosing its own algorithms.
This makes post-quantum readiness a standard question for third-party risk management, next to patching, email security and breach history. For the basics of quantum-safe algorithms and the NIST standards, see our guide to quantum security and post-quantum cryptography.
| Risk | What it means | Where it sits | How CyberRank helps |
|---|---|---|---|
| Harvested data | What it meansTraffic or files stolen today are decrypted once a CRQC exists | Where it sitsVendor endpoints and stored data | How CyberRank helpsShows vendors still using classical-only key exchange on public services (Beta) |
| Inherited timelines | What it meansA vendor's migration date becomes your migration date | Where it sitsVendor roadmaps and contracts | How CyberRank helpsTracks each vendor's posture over time |
| Fourth-party gaps | What it meansA vendor's own hosting, HSM or library supplier is not ready | Where it sitsYour vendors' suppliers | How CyberRank helpsNot visible from outside; flagged as a limit below |
| Silent fallback | What it meansConnections drop to classical key exchange without an alert | Where it sitsNetwork paths and middleboxes | How CyberRank helpsReports what each vendor's public services actually negotiate |
Why is harvest now, decrypt later a risk today?
Because the collection step needs no quantum computer: an adversary can intercept or steal encrypted data now and wait until a CRQC can break the key exchange that protected it.
Shor's algorithm, run on a large enough quantum computer, would break RSA, elliptic-curve cryptography and Diffie-Hellman. These protect key exchange in TLS, VPNs and secure messaging, so a recorded session becomes readable once its key exchange falls. CISA, NSA and NIST have jointly warned that adversaries may already be collecting such data.
Michele Mosca's test decides which data matters: add how long the data must stay confidential to how long your migration will take. If the sum is longer than the time until a CRQC exists, the data is already at risk. The mechanics are explained in our short answer on harvest now, decrypt later.
Signatures carry a related risk: forgery only matters once a CRQC exists, but certificate authorities and code-signing keys take years to replace.
How CyberRank helps: its quantum-crypto exposure check (Beta) separates key exchange from certificate signatures on each vendor's public services, so you see which vendors still expose traffic to harvesting.
How close is the threat?
No one has publicly demonstrated a CRQC. The Global Risk Institute's 2025 Quantum Threat Timeline Report surveyed 26 experts, who put the chance of one within 10 years at 28 to 49 percent and within 15 years at 51 to 70 percent. That is a credible probability within normal retention periods.
What changed with the final NIST IR 8547?
The final IR 8547 deprecates every quantum-vulnerable public-key algorithm after 2030, including RSA-3072, P-256 and Ed25519, which the 2024 draft had allowed to run until 2035.
NIST published the final report on 27 October 2026. They are disallowed after 2035, regardless of key size. The replacements are already standardised: ML-KEM (FIPS 203) for key establishment, and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures.
For European organisations, the EU Coordinated Implementation Roadmap asks Member States and organisations to start the transition by the end of 2026 and to protect high-risk use cases by the end of 2030. All dates and their sources are collected in our overview of vendor risk deadlines from 2026 to 2035.
| Milestone | Date | Source | How CyberRank helps |
|---|---|---|---|
| High-risk use cases and critical infrastructure transitioned | DateEnd of 2030 | SourceEU Coordinated PQC Roadmap | How CyberRank helpsShows which vendors are still classical-only |
| Quantum-vulnerable public-key algorithms deprecated | DateAfter 2030 | SourceNIST IR 8547 | How CyberRank helpsMeasures vendors against the 2030 line |
| US federal high-value systems use PQC key establishment, then signatures | Date31 Dec 2030 / 31 Dec 2031 | SourceUS federal guidance (EO 14412, OMB M-26-15) | How CyberRank helpsRelevant for vendors that also serve US government customers |
| Indonesian national PQC migration roadmap (in preparation) | Date2027 to 2035 | SourceBSSN task force | How CyberRank helpsSupports the inventory and monitoring phases |
| Quantum-vulnerable algorithms disallowed | DateAfter 2035 | SourceNIST IR 8547 | How CyberRank helpsTracks progress per vendor over time |
Why is post-quantum readiness a supply chain problem?
Because most of the cryptography protecting your data is chosen by someone else, and a vendor's choices decide whether your data can be harvested.
A strong internal migration does not protect data stored in a vendor's system, or traffic to a vendor endpoint that still negotiates classical-only key exchange. The same logic applies to every supply chain risk, as explained in our guide to supply chain attacks and how to prevent them.
Regulators already treat this as vendor oversight: Australia's cyber security agency published post-quantum questions for vendors in July 2026, and the PKI Consortium offers a vendor survey. In the EU, NIS2 lists cryptography among its required cybersecurity measures, as covered on our NIS2 and DORA supply chain page.
How CyberRank helps: the quantum-crypto signal (Beta) sits in the same vendor profile as the security rating, vulnerabilities and breach history, so it is reviewed with the rest of the vendor's risk.
A data flow is as quantum-safe as its weakest hop
Cloudflare reports that more than 65 percent of human traffic to its network now uses hybrid post-quantum key exchange. Yet a request through a CDN involves separate TLS sessions, and the leg from the CDN to the origin server is protected only if the origin supports the post-quantum algorithm.
Fourth parties extend the chain
Your vendors depend on their own suppliers for cryptographic libraries, certificates, cloud infrastructure and hardware. A SaaS provider may be ready at the application layer while its database host or HSM vendor is not.
Vendor timelines become your timelines
NIST notes that earlier cryptographic transitions took 10 to 20 years. Embedded devices, OT systems and network appliances often cannot be updated to new algorithms and must be replaced. If a critical supplier plans post-quantum support for 2032, your 2030 deprecation line is already at risk.
Silent fallback and new attack surface
Post-quantum keys and signatures are larger, and larger handshakes can break older middleboxes, firewalls and load balancers. When one side lacks the new algorithm, connections often fall back to classical key exchange without an alert. The migration itself also brings new libraries and firmware that need supply chain scrutiny.
Who and what is most at risk?
Exposure is highest where long-lived sensitive data meets systems that are slow to change, and in sectors with dense third-party dependencies.
Financial services faces the clearest mix of valuable data, regulatory scrutiny and third-party dependencies; our short answer on quantum readiness for banks covers the Indonesian banking angle. Telecoms, healthcare, government and critical infrastructure follow, and their suppliers will be asked to prove a roadmap during procurement.
How CyberRank helps: combining each vendor's rating with what it handles shows which supplier belongs at the top of your outreach list.
| Asset | Why it is exposed | How CyberRank helps |
|---|---|---|
| Health, insurance and financial records | Why it is exposedMust stay confidential for decades and are often retained by law | How CyberRank helpsPrioritises vendors that hold this data |
| Identity and biometric data | Why it is exposedCannot be reissued once exposed | How CyberRank helpsFlags vendors with weak public TLS |
| PKI roots, firmware and code-signing keys | Why it is exposedLong-lived trust anchors that take years to rotate | How CyberRank helpsShows certificate signatures on vendors' public services (Beta) |
| OT, medical devices, vehicles, smart meters | Why it is exposedHard-coded cryptography and service lives of 10 to 20 years | How CyberRank helpsLimited: only what is internet-facing |
| Blockchain wallets and custody systems | Why it is exposedRely on ECDSA or EdDSA, with public keys often visible on-chain | How CyberRank helpsNot covered: on-chain cryptography is outside its scope |
What does the 2026 Binance theft teach about post-quantum planning?
Nothing links the theft to quantum computing, but it shows that strong algorithms do not protect a compromised signing process, which is exactly what organisations will rebuild during migration.
On 29 October 2026, attackers drained an estimated $5.8 to 6.3 billion from Binance hot wallets across roughly ten blockchains, according to early reports. Binance says it found no evidence that wallet private keys leaked; the withdrawals carried valid signatures from its own infrastructure. Its account describes a compromised engineer's laptop, a tampered installer, a malicious code repository and an abused internal AI tool. The FBI has attributed the theft to North Korea's TraderTraitor group.
How CyberRank helps: outside-in monitoring shows the internet-facing side of a vendor's posture; it does not see internal signing pipelines, so the lessons below belong in your own controls.
- Strong algorithms do not fix a weak signing process. PQC migration has to sit alongside key management, approval controls and transaction monitoring.
- Developer tooling is a supply chain: the same channels will deliver new cryptographic libraries, and rebuilt signing services deserve high-risk change controls.
- Digital asset firms carry a separate quantum risk, because blockchains secure ownership with ECDSA or EdDSA. That played no part in this incident.
How to prepare for post-quantum third-party risk
Start with visibility and end with replacement: assign ownership, inventory your cryptography, rank data by shelf life, fix the basics, then bring vendors into the plan.
Steps 1 to 4, 6 and the contract work in step 7 are your process. The outside-in parts of steps 2, 5, 7 and 8 can be automated. For the questions to send, see our list of AI and quantum questions for vendors, and treat every self-attestation as a claim to verify.
How CyberRank helps: it automates the outside-in checks across your vendor list and keeps reassessing monitored vendors, which is the case for continuous monitoring over a one-off review.
- Assign ownership. Name an executive sponsor and a working group covering security, IT, procurement, legal and TPRM.
- Build a cryptographic inventory. Record algorithms, certificates, protocols, libraries and HSMs, often as a cryptographic bill of materials (CBOM), including vendor-run systems.
- Classify data by shelf life. Apply the Mosca test to each data flow and migrate key establishment first, as IR 8547 asks.
- Fix the basics. Move to TLS 1.3, retire legacy protocols and weak cipher suites, use AES-256 for long-term data at rest, and delete data you no longer need.
- Deploy hybrid key exchange, such as X25519MLKEM768, on high-value paths.
- Design for crypto-agility: shared libraries, no hard-coded algorithms, and algorithm choice as configuration.
- Bring vendors into the plan. Tier suppliers by data sensitivity, ask critical ones for their PQC roadmap, CBOM and ML-KEM and ML-DSA support, and write readiness dates into contracts and renewals.
- Monitor and adjust. NIST has selected HQC as a backup key encapsulation algorithm and is finalising FN-DSA; re-check vendors at each review cycle.
How CyberRank supports post-quantum third-party risk management
CyberRank gives an independent, outside-in view of your own posture and your vendors', so post-quantum readiness claims can be checked against observable evidence.
For a dedicated review of your own organisation, see the post-quantum cryptography assessment.
- Cryptographic hygiene: assessments examine internet-facing services, including TLS protocol versions, cipher suites and certificates. Hybrid post-quantum key exchange is built on TLS 1.3, so a vendor still on older TLS has foundational work to finish.
- Quantum-crypto exposure (Beta): rates each vendor's public TLS and SSH services as not, partly or fully quantum-safe, separating key exchange from signatures.
- Prioritisation: combining ratings with what each supplier handles shows where to start.
- Ongoing monitoring: monitored vendors are reassessed nightly, so regressions, new vulnerabilities and breach exposure show up between annual reviews.
- Evidence: independent ratings help TPRM teams challenge attestations and brief boards and regulators.
Where CyberRank does not help
CyberRank sees only internet-facing services. It cannot see the CDN-to-origin leg, a vendor's internal databases, backups, HSMs or code-signing pipeline, or the cryptography of your vendors' own suppliers. It cannot verify a vendor's CBOM or migration roadmap, and it would not detect a compromised internal signing process like the one described in the Binance case.
A quantum-safe posture describes what was observed on public services on the day of the check. CyberRank does not certify any vendor as quantum-safe or compliant with any regulation; questionnaires, contracts and your own architecture review cover the rest.
Conclusion
Quantum computers that break public-key encryption are not here, but the exposure is. Data harvested today stays readable later, and the final IR 8547 has turned 2030 and 2035 into planning lines. The hardest part of the transition sits with vendors, cloud services and their suppliers, whose cryptography and timelines become yours.
Inventory what you can, rank data by shelf life, fix the basics, and bring critical vendors into the plan with dated commitments. CyberRank gives you the outside-in evidence to check those commitments across your vendor list.
About this article
All text in this article reflects CyberRank's own perspective and is provided for general information. It is not legal advice. Product capabilities are described as of 15 November 2026; features marked Beta may change.
References
- NIST, IR 8547: Transition to Post-Quantum Cryptography Standards (final, 27 October 2026)
- NIST, FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (13 August 2024)
- European Commission and NIS Cooperation Group, Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography
- Australian Cyber Security Centre, Post-quantum questions to ask your vendors (July 2026)
- Cloud Security Alliance, NIST IR 8547 Final: Post-Quantum Deadlines Become Vendor Requirements (30 October 2026)
- CyberInsider, NIST IR 8547 and federal PQC deadlines
- Global Risk Institute and evolutionQ, Quantum Threat Timeline Report 2025
- Global Risk Institute, Quantum Threat Timeline 2025: Executive Perspectives on Barriers to Action
- Cloud Security Alliance, Harvest Now, Decrypt Later: Enterprise PQC Migration Gap (May 2026)
- CGI, Harvest Now, Exploit Later
- Cloudflare, Cloudflare targets 2029 for full post-quantum security (7 April 2026)
- PKI Consortium, PQC Maturity Model vendor survey
- Shared Assessments, Quantum Computing and Third-Party Risk
- SOCRadar, Binance Hack: Inside the $6.3B Hot Wallet Theft
- BleepingComputer, Binance probes potential $5.8 billion crypto-theft hack (29 October 2026)
- GovInsider, BSSN pimpin migrasi kriptografi pascakuantum
- InfoPublik, Strategi BSSN hadapi Q-Day (October 2026)
Quick answers
Short, direct answers to questions this article raises.
- Quick answerWhat Is Crypto-Agility? PQC Migration BasicsWhat crypto-agility means, why post-quantum migration depends on it, and how CyberRank shows which vendors can already switch algorithms.
- Quick answerIs Your Data Quantum-Safe End to End?Why one post-quantum connection is not enough: CDN-to-origin hops, silent fallback, fourth parties, and what CyberRank can and cannot see.
Frequently asked questions
Check your vendors' quantum exposure
See which of your vendors still rely on quantum-vulnerable TLS and SSH, with the post-quantum cryptography assessment.
Check your vendors' quantum exposure