Quantum Security: Post-Quantum Cryptography Deadlines and Your Vendors
CyberRank Research
Part of: Post-Quantum Cryptography Assessment
Quantum security is the work of protecting data and systems against future quantum computers that could break today's public-key encryption, mainly by moving to post-quantum cryptography (PQC) before that happens. The deadline is no longer vague: NIST plans to deprecate quantum-vulnerable algorithms such as RSA and elliptic-curve cryptography after 2030 and disallow them after 2035, and data sent through your vendors today can be recorded now and decrypted later. CyberRank's quantum-crypto exposure check (Beta) shows which of your vendors' internet-facing TLS and SSH services still rely only on quantum-vulnerable cryptography.
TL;DR
- Quantum computers that can break RSA and elliptic-curve cryptography do not exist yet, but encrypted traffic captured today can be decrypted once they do.
- NIST will deprecate quantum-vulnerable public-key algorithms after 2030 and disallow them after 2035; symmetric AES and SHA-2/SHA-3 remain approved.
- The replacement standards are final: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA).
- Your exposure includes your vendors: a supplier that still negotiates classical-only key exchange puts your data at risk.
- CyberRank's quantum-crypto exposure check (Beta) rates each vendor's TLS and SSH as not, partly or fully quantum-safe.
What is quantum security?
Quantum security covers the risks that large quantum computers create for cryptography, and the controls that reduce them.
A sufficiently large quantum computer running Shor's algorithm would break the public-key cryptography behind TLS, SSH, VPNs, code signing and certificates. Symmetric encryption is affected much less. The fix is a migration to new algorithms, not a new product category.
How CyberRank helps: these terms map to observable signals on a vendor's public services, which is where CyberRank's outside-in assessment of the attack surface starts.
| Term | What it means | How CyberRank helps |
|---|---|---|
| Cryptographically relevant quantum computer (CRQC) | What it meansA quantum computer large enough to break RSA or elliptic-curve cryptography in practice | How CyberRank helpsNot something CyberRank measures; it measures your vendors' readiness for one |
| Post-quantum cryptography (PQC) | What it meansClassical algorithms designed to resist quantum attacks, such as ML-KEM and ML-DSA | How CyberRank helpsDetects PQC key exchange on vendors' public TLS and SSH services (Beta) |
| Hybrid key exchange | What it meansA classical and a post-quantum algorithm combined, for example X25519 with ML-KEM-768 | How CyberRank helpsCounts a hybrid group as quantum-safe key exchange for that service (Beta) |
| Quantum key distribution (QKD) | What it meansKey exchange over physics-based channels; not the same as PQC | How CyberRank helpsNot covered |
| Crypto-agility | What it meansThe ability to swap algorithms without redesigning systems | How CyberRank helpsIndirectly visible: vendors that already offer hybrid groups show agility |
Why act before a quantum computer exists?
The urgency comes from "harvest now, decrypt later" (HNDL): an attacker records encrypted traffic today and stores it until a quantum computer can break the key exchange.
Data that must stay confidential for ten years or more, the kind whose exposure would count as a data breach years later, such as health records, banking data, contracts and state information, is already at risk if it travels over classical-only key exchange. Nobody can say exactly when a CRQC will exist, and that uncertainty is the reason standards bodies have set fixed migration dates rather than waiting.
HNDL also explains why key exchange is the first priority. A forged signature only matters once a quantum computer exists; recorded key exchange can be broken retroactively. The supply chain angle, covered in detail in our article about supply chain attack examples and prevention, is that much of your sensitive traffic runs through vendors' systems, not yours.
How CyberRank helps: it checks key exchange separately from certificate signatures, so you can see which vendors already protect traffic against HNDL.
What are the post-quantum deadlines?
NIST deprecates quantum-vulnerable public-key algorithms after 2030 and disallows them after 2035; the EU roadmap asks organisations to start by the end of 2026 and protect high-risk use cases by 2030.
NIST's transition document became final on 27 October 2026. It names ML-KEM-768 as the default key-establishment parameter set and accommodates hybrid key establishment during the transition.
How CyberRank helps: the dates give you a policy line to measure vendors against, and CyberRank shows where each vendor stands today.
| Date | What happens | Source | How CyberRank helps |
|---|---|---|---|
| 13 Aug 2024 | What happensFIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) published as final standards | SourceNIST FIPS 203 | How CyberRank helpsRecognises these algorithm families on vendors' public services (Beta) |
| End of 2026 | What happensEU Member States and organisations begin PQC transition planning and inventories | SourceEU PQC roadmap | How CyberRank helpsGives a first outside-in inventory of vendors' exposed cryptography |
| 2030 | What happensNIST deprecates quantum-vulnerable public-key algorithms (RSA, ECDSA, EdDSA, DH, ECDH); EU roadmap targets high-risk use cases | SourceNIST IR 8547 | How CyberRank helpsShows which vendors would still be classical-only at that point |
| 31 Dec 2030 / 2031 | What happensUS federal high-value systems: PQC key establishment by end of 2030, signatures by end of 2031 | SourceNIST IR 8547 and US federal guidance | How CyberRank helpsUseful for vendors that also serve US government customers |
| 2035 | What happensNIST disallows quantum-vulnerable public-key algorithms | SourceNIST IR 8547 | How CyberRank helpsTracks progress per vendor over time |
What is quantum-vulnerable and what is not?
Public-key key exchange and signatures (RSA, DH, ECDH, ECDSA, EdDSA) are broken by a large quantum computer; symmetric AES and SHA-2/SHA-3 are only weakened and remain approved.
The practical point: "quantum-safe" is about public-key cryptography. A vendor that encrypts storage with AES-256 can still expose your data through a classical-only TLS handshake.
How CyberRank helps: it separates findings that a quantum computer would break from findings it would only weaken, so you fix the broken ones first.
| Algorithm or family | Typical use | Quantum impact | Status after the NIST transition | How CyberRank helps |
|---|---|---|---|---|
| RSA, DH, ECDH (incl. X25519) | Typical useTLS and SSH key exchange | Quantum impactBroken by Shor's algorithm | Status after the NIST transitionDeprecated after 2030, disallowed after 2035 | How CyberRank helpsFlags classical-only key exchange (Beta) |
| RSA, ECDSA, EdDSA signatures | Typical useCertificates, code signing | Quantum impactBroken by Shor's algorithm | Status after the NIST transitionSame dates | How CyberRank helpsFlags quantum-vulnerable certificate signatures (Beta) |
| AES-128, AES-256 | Typical useBulk encryption | Quantum impactWeakened (Grover), not broken | Status after the NIST transitionApproved; AES-256 gives the largest margin | How CyberRank helpsWeak cipher findings appear in the normal rating |
| SHA-2, SHA-3 | Typical useHashing, integrity | Quantum impactWeakened, not broken | Status after the NIST transitionApproved | How CyberRank helpsNot a quantum finding |
| ML-KEM (FIPS 203) | Typical useKey exchange | Quantum impactDesigned to resist | Status after the NIST transitionApproved | How CyberRank helpsDetected on TLS and SSH (Beta) |
| ML-DSA, SLH-DSA (FIPS 204, 205) | Typical useSignatures | Quantum impactDesigned to resist | Status after the NIST transitionApproved | How CyberRank helpsDetected in certificates when used (Beta) |
Why is quantum security a third-party risk?
You can migrate your own systems and still be exposed, because your data also travels through your vendors' cryptography.
Payroll data, customer files and API traffic pass through SaaS providers, payment processors, managed service providers and their suppliers. Each connection has its own key exchange, chosen by the vendor. That makes quantum readiness a standard third-party risk management question: which vendors handle data with a long confidentiality life, and what cryptography do they use to move it?
Regulators are moving in the same direction. EU financial entities already treat cryptography as part of ICT risk under DORA, and NIS2 lists cryptography and encryption among its required cybersecurity measures, as explained in detail on our NIS2 and DORA supply chain page.
How CyberRank helps: the quantum-crypto signal sits in the same vendor profile as the security rating, vulnerabilities, email security and breaches, so it is reviewed with the rest of the vendor's risk.
How do you assess vendor quantum readiness?
Rank vendors by how long their data must stay secret, check what their public services expose, then turn the gaps into questionnaire items, contract dates and ongoing checks.
Steps 1, 4 and 5 are your process; steps 2, 3 and 6 can be automated. For the discovery workflow in more depth, see our guide to quantum and AI exposure discovery.
How CyberRank helps: it automates the outside-in steps across your whole vendor list and keeps re-checking monitored vendors.
- Rank vendors by data lifetime. Start with vendors that process data which must stay confidential beyond 2030: health, financial, identity, legal and government data.
- Check what they expose publicly. Look at the key exchange and certificate signatures on the vendor's websites, APIs, VPN and SSH endpoints. This needs no cooperation from the vendor, the same principle as an external security sensor.
- Look for hybrid key exchange. A vendor offering a hybrid group such as X25519MLKEM768 has started the migration for that service. Classical-only key exchange means it has not.
- Ask for the roadmap. Add three questions to your questionnaire: does the vendor have a cryptographic inventory, when will key exchange be quantum-safe on services that carry your data, and how will signatures and certificates follow?
- Write it into contracts. For critical vendors, add a clause requiring PQC key exchange on services carrying your data by an agreed date, aligned with the 2030 line.
- Re-check over time. Readiness changes as vendors update servers and libraries, so a single check goes stale; this is the case for continuous monitoring.
How does CyberRank show quantum-crypto exposure?
CyberRank's quantum-crypto exposure check is in Beta. For each vendor it looks at the public TLS and SSH services found during the outside-in assessment and gives one of three postures.
Detected post-quantum support lowers the risk the quantum findings contribute; it does not delete the underlying findings, so you keep the evidence trail. The list of recognised algorithms and groups is reviewed and updated regularly. For a dedicated assessment of your own organisation, see the post-quantum cryptography assessment.
How CyberRank helps: you get a posture per vendor without sending a single questionnaire (you can try the outside-in view with the free security rating tool), and you can then question the vendors that matter.
| Posture | What it means | Typical next step | How CyberRank helps |
|---|---|---|---|
| Not quantum-safe | What it meansEvery observed service uses only quantum-vulnerable key exchange and signatures | Typical next stepAsk for a PQC roadmap; prioritise if the vendor handles long-life data | How CyberRank helpsLists the affected services and algorithms |
| Partly quantum-safe | What it meansSome services, or key exchange but not signatures, use post-quantum or hybrid algorithms | Typical next stepAsk when the remaining services and certificates follow | How CyberRank helpsShows which services are covered and which are not |
| Quantum-safe | What it meansObserved services use post-quantum or hybrid key exchange, and signatures are covered | Typical next stepRe-check periodically | How CyberRank helpsKeeps the result in the vendor's history |
How does this compare with other security rating providers?
Other outside-in security rating providers, such as SecurityScorecard, Bitsight and UpGuard, also rate vendors from public signals, and encryption settings are part of what security ratings look at. What each provider checks for post-quantum readiness differs and changes over time, so ask any provider, CyberRank included, exactly which services and algorithms its quantum check covers.
CyberRank's check (Beta) looks at both TLS and SSH, separates key exchange from certificate signatures, and reports a posture per vendor. Like any security rating, it describes what was observed from outside; it is not a quantum-safe certificate.
Where CyberRank does not help
CyberRank sees only internet-facing services. It cannot inventory a vendor's internal cryptography, databases, backups, hardware security modules or code-signing pipeline, and it cannot confirm a vendor's migration plan. It does not test whether a quantum computer could break a specific key, does not cover quantum key distribution, and does not certify a vendor as quantum-safe for any regulation.
A "quantum-safe" posture describes what was observed on public TLS and SSH on the day of the check, nothing more. Use questionnaires, contract clauses and your own architecture review for everything behind the perimeter.
Conclusion
Quantum security has moved from research to a dated migration. Key exchange comes first because of harvest-now-decrypt-later; signatures follow; the NIST 2030 and 2035 lines set the pace. Your own migration is only half the picture, because your data also travels through your vendors' cryptography.
Start with vendors that hold long-life data, see what their public services expose, and turn the gaps into questionnaire items and contract dates. CyberRank's quantum-crypto exposure check (Beta) gives you that starting picture across your vendor list.
References
- NIST, FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (13 August 2024)
- NIST, FIPS 204: Module-Lattice-Based Digital Signature Standard (13 August 2024)
- NIST, FIPS 205: Stateless Hash-Based Digital Signature Standard (13 August 2024)
- NIST, IR 8547: Transition to Post-Quantum Cryptography Standards (final, 27 October 2026)
- European Commission and NIS Cooperation Group, Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography
- NIS2 Directive, (EU) 2022/2555, Article 21(2)(h)
Quick answers
Short, direct answers to questions this article raises.
- Quick answerHarvest Now, Decrypt Later ExplainedWhat harvest-now-decrypt-later attacks are, which data is at risk today, and how CyberRank shows vendors still using quantum-vulnerable key exchange.
- Quick answerQuantum Readiness for Indonesian BanksWhich bank vendors to check first for post-quantum readiness, what to ask payment providers, and how CyberRank shows their TLS and SSH posture.
Related questions
Short answers that connect this article with our other guides.
- Quick answerAI and Quantum Questions for Your VendorsEight questions to add to vendor questionnaires on AI use and post-quantum readiness, and how CyberRank checks what vendors expose (Beta).
- Quick answerWhich Vendors Should You Review First?How to rank vendors for review by impact, data, AI use, quantum exposure and the software they ship, and how CyberRank's tiers and heat map help.
- Quick answerHow to Find Hidden Supply Chain RiskWhere supply chain risk hides: software updates, your vendors' suppliers, AI models and vendor cryptography, and how CyberRank brings it into view.
- Quick answerAI and Quantum Vendor Risk Deadlines, 2026–2035The AI Act and post-quantum dates from 2026 to 2035 in one table, what to ask vendors before each, and how CyberRank tracks vendor readiness.
Frequently asked questions
Get your free security rating
Run a free CyberRank security rating for any organisation and see the same vendor risk signals our customers use.
Get your free security rating