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