Post-Quantum Readiness
What a Post-Quantum Readiness Score Tells You (and How to Improve It)
What a post-quantum readiness score means: TLS versions, certificate hygiene, RSA/ECC exposure, security headers, and concrete steps to improve it.
What a Post-Quantum Readiness Score Tells You (and How to Improve It)
You ran a readiness scan and got back a number. Now what? A post-quantum readiness score takes a pile of technical cryptographic findings — TLS protocol versions, certificate key algorithms, expiry hygiene, security headers — and compresses them into one figure you can put in front of an executive, track over time, and act on. This post explains what moves that number up or down, what each finding means for your quantum-migration exposure, and the concrete steps to improve it.
Why a single number matters
Cryptography is hard to discuss with people who don't live in it. A board member does not want a 40-row spreadsheet of cipher suites; they want to know whether the organization is improving or sliding backward. A readiness score gives you that shared language.
The context makes the case for paying attention. DigiCert's 2025 research found that while roughly 69% of enterprises recognize the quantum risk, only about 5% have deployed quantum-safe encryption. ISACA's 2025 findings are starker still: only about 5% of organizations have a defined quantum strategy, and roughly 91% have no formal migration plan. A score is the lightweight instrument that turns that abstract gap into something you can measure for your own domains.
The CipherReady Readiness Score is derived entirely from a safe, external, metadata-only scan. It inventories your public TLS certificates, the TLS versions your endpoints negotiate, DNS exposure, public-key algorithms (RSA or ECC), and HTTP security headers. It does not log in, test for exploits, or touch anything intrusive. That scope is a deliberate strength — but it's also the first thing to be honest about, which we'll come back to.
What drives the score down
Some findings are unambiguous negatives because they reflect cryptography that the standards bodies have already moved on from.
| Finding | Why it hurts the score | |---|---| | TLS 1.0 / TLS 1.1 negotiated | Formally deprecated by RFC 8996 (2021). Their presence signals stale configuration and weak transport security. | | SHA-1 certificate signatures | A deprecated signature algorithm; modern certificates should sign with SHA-256 or stronger. | | Expired or near-expiry certificates | Poor expiry hygiene is both an availability risk and a sign that nobody is actively managing the certificate estate. | | Missing security headers | Absent HSTS and related HTTP security headers leave transport and content protections weaker than they should be. |
These items lower the number because they represent posture that is measurably behind the current baseline. They are also the easiest wins — fixing deprecated protocols and renewing certificates is routine operational work, not a multi-year program.
What pushes the score up
The flip side is straightforward. Endpoints that negotiate TLS 1.2 or TLS 1.3 — the current protocol versions — score better than those still offering deprecated ones. Certificates signed with modern algorithms, with clean expiry and a managed renewal cadence, score better than a neglected estate, and present, correctly configured security headers add to the picture.
In other words, much of the score rewards basic cryptographic hygiene that good operations teams already handle. You don't need a quantum-migration budget to move the number in the first pass; you need to clean up what's deprecated and keep your certificates tidy.
Where RSA and ECC fit — your quantum-migration exposure
Here's the part that separates a post-quantum readiness score from an ordinary TLS hygiene check. Essentially all public TLS certificates in use today rely on RSA or ECC public keys, and both are broken by Shor's algorithm running on a cryptographically relevant quantum computer (CRQC). So the score doesn't penalize RSA and ECC as misconfigurations — they're the correct, current choice — but it surfaces them as your quantum-vulnerable exposure: the inventory of public-key cryptography that will eventually need to migrate.
That matters because of "harvest now, decrypt later" (HNDL): adversaries can capture encrypted long-lived data today and decrypt it once a CRQC exists — a threat model that underpins guidance from DHS, NCSC, ENISA, and ACSC. The Global Risk Institute's 2025 work (led by Michele Mosca) puts the median CRQC estimate around 2029–2032, with roughly a 34% probability by 2030. Mosca's theorem frames the urgency cleanly: if your migration time (X) plus your data's shelf-life (Y) exceeds the time until a CRQC arrives (Z), you are already at risk. Google's 2025 Willow result — reaching below-threshold error correction — was a genuine milestone, but it is not a break of RSA or ECC. The honest posture is "not yet, but prepare now."
So a high RSA/ECC count isn't a failing grade today; it sizes the migration work ahead. The standards to migrate toward already exist: on August 13, 2024, NIST finalized FIPS 203 (ML-KEM/Kyber for key establishment), FIPS 204 (ML-DSA/Dilithium for signatures), and FIPS 205 (SLH-DSA/SPHINCS+ for hash-based signatures), with FIPS 206 (FN-DSA/Falcon) in progress in 2026. PQC in TLS is already live — Chrome 131, Firefox 135, OpenSSL 3.5.0, and Apple OS v26 support the hybrid X25519MLKEM768 key exchange, and Cloudflare measured roughly 38% of human HTTPS traffic using hybrid PQC by March 2025.
See where your organization stands — run a free CipherReady readiness scan and get a cryptographic inventory of your public TLS, certificates, and algorithms in about 3 minutes.
How to improve your score — a practical order of operations
- Retire deprecated protocols. Disable TLS 1.0 and TLS 1.1 across your endpoints. This is the single most reliable way to lift the number and it removes posture that RFC 8996 already deprecated.
- Modernize signatures and fix expiry. Reissue any SHA-1-signed certificates, and bring near-expiry or expired certificates onto a managed renewal schedule.
- Add the missing headers. Configure HSTS and the other HTTP security headers your scan flags as absent.
- Inventory your RSA/ECC footprint deliberately. Treat the public-key inventory as your migration backlog, not a bug list. Knowing the size and location of your quantum-vulnerable certificates is the prerequisite for any roadmap. Our quantum risk assessment of cryptographic exposure walks through how to read that exposure, and the PQC readiness checklist turns it into steps.
- Plan for crypto-agility. The end goal isn't a one-time swap; it's the ability to change algorithms when you need to. Compliance frameworks already point this way — PCI DSS 4.0 Req 12.3.3 mandates a documented cryptographic inventory plus a migration plan for deprecated algorithms (future-dated controls effective March 31, 2025), and DORA (in effect January 17, 2025) requires crypto-agility for financial entities.
Why the score is most useful over time
A single scan is a snapshot. The real value comes from watching the number move. Certificates expire and get reissued, new subdomains appear, configurations drift — a clean result in June can degrade by December without anyone noticing.
That's where scheduled monitoring earns its place. Tracking the score on a recurring basis turns it from a one-off audit into a trend line — proof that posture is improving, an early warning when it regresses, and a steady artifact for leadership. If you need to present cryptographic risk to your board of directors, a trend line is far more persuasive than a single reading. Scheduled, repeated scanning is a paid capability in CipherReady precisely because crypto-agility is a continuous discipline, not a project with an end date.
Be honest about what the score is — and isn't
The readiness score reflects your externally visible cryptographic posture: what an outside observer can see about your public TLS endpoints, certificates, algorithms, DNS exposure, and headers. That is genuinely the right first step — you cannot manage what you have never measured, and most organizations have never measured even this much.
But it is not a full internal cryptographic bill of materials (CBOM). It does not see the cryptography embedded in your internal applications, databases, firmware, code-signing pipelines, or backend services. CipherReady is not a vulnerability scanner or a pentest, and the score is not a clean bill of health for everything you run. Think of it as the visibility layer: the fast, low-friction starting point that tells you where your public exposure stands and where to dig deeper. Treating it as the first step — not the finish line — is the only honest way to use it, and it's exactly the framing in our guide to the post-quantum readiness gap and your first step.
Frequently Asked Questions
What's a "good" post-quantum readiness score?
There's no universal pass mark, because the score is most meaningful relative to your own starting point and tracked over time. A higher number reflects modern TLS (1.2/1.3), clean and current certificates, modern signatures, and present security headers; a lower number reflects deprecated protocols, SHA-1, expiry problems, or missing headers. The most useful question isn't "what's a good score?" but "is my score improving with each scheduled scan?"
Does a high RSA or ECC count mean I'm failing?
No. RSA and ECC are the correct, current public-key algorithms for public TLS today — essentially every public certificate uses one or the other. The score surfaces them as your quantum-migration exposure, not as misconfigurations, because both are vulnerable to Shor's algorithm on a future CRQC. A high count sizes the migration work ahead; it doesn't mean anything is broken right now.
Will improving my score make my organization quantum-safe?
Improving the score strengthens your externally visible posture and shrinks the easy-to-fix gaps, but no external scan can make a sweeping safety claim. The score covers public TLS, certificates, algorithms, and headers — not your full internal cryptographic estate. It's the first step in a longer migration toward the NIST PQC standards (FIPS 203/204/205), built on crypto-agility, not a one-time fix.
How often should I rescan?
On a free plan you get 3 scans per month, which is enough to spot-check after you make changes. But because configurations drift and certificates change, the score is far more valuable tracked continuously. Scheduled monitoring — a paid capability — keeps the trend line current and flags regressions automatically, so you're not relying on someone remembering to run a manual scan.
See where your organization stands
You can't improve a number you've never measured. Start with a baseline: run a free CipherReady readiness scan to inventory your public TLS, certificates, public-key algorithms, and security headers, and get your readiness score plus an executive PDF report in about 3 minutes. When you're ready to track that score over time with scheduled monitoring and deeper reporting, compare CipherReady plans on the pricing page. The score is the start of the conversation — and the first step toward a defensible post-quantum migration.