Post-Quantum Readiness
Why TLS Certificates, RSA, and ECC Create Hidden Quantum Risk
RSA and ECC power most TLS certificates today. When quantum computers break these algorithms, every certificate becomes a risk. Learn where the risk hides and how to start your crypto inventory.
Why TLS Certificates, RSA, and ECC Create Hidden Quantum Risk
Every HTTPS connection your organization makes — every web portal, every API endpoint, every VPN gateway — relies on TLS certificates that use either RSA or Elliptic Curve Cryptography (ECC). These two algorithm families have protected internet traffic for decades. They are also the algorithms that cryptographically relevant quantum computers will break first.
This article explains where the quantum risk hides in your TLS infrastructure, why it is not always visible to security teams, and how to start finding and prioritizing quantum-vulnerable TLS certificates before they become an incident.
The Pervasive Reach of RSA and ECC in TLS
TLS (Transport Layer Security) is the cryptographic protocol that secures HTTPS, email (SMTP/IMAP with STARTTLS), VPN tunnels, database connections, and virtually every encrypted client-server communication on the internet. Every TLS handshake uses asymmetric cryptography — RSA or ECDSA — to authenticate the server (and sometimes the client) and establish a shared session key.
Recent scans of the top million websites show that RSA still accounts for roughly 70% of all TLS certificates in active use. ECC (primarily P-256) accounts for most of the remaining 30%. Post-quantum certificate deployments remain under 1%.
This means that essentially every TLS certificate in your organization — from your main website to your internal admin portals to your third-party SaaS integrations — relies on an algorithm that a sufficiently powerful quantum computer can break using Shor's algorithm.
Where the Hidden Risk Lives
The obvious risk is your public-facing websites. If an attacker can factor the RSA public key in your TLS certificate, they can impersonate your site, decrypt captured traffic, and forge digital signatures. That is well-understood.
The hidden risk is everywhere else:
Internal services behind VPNs: Just because a service is not internet-facing does not mean its traffic is safe from collection. An adversary who can intercept network traffic at any point between the client and server — through a compromised router, a malicious ISP, or physical tap — can record the encrypted TLS handshake and store it for future quantum decryption.
Third-party SaaS integrations: When your organization uses a SaaS platform, that platform typically terminates TLS on its own infrastructure using its own certificates. You inherit their cryptographic posture. If a vendor's TLS endpoints use RSA-1024 or RSA-2048, your data flowing through those integrations is exposed to the same quantum risk — and you may not even know which algorithms they use.
API gateways and microservices: Service-to-service communication inside modern architectures often uses mutual TLS (mTLS) with internally managed certificates. These certificates are rarely part of an organization's central certificate inventory and are often issued with longer validity periods — sometimes 5+ years — directly increasing their exposure to the quantum transition window.
Cloud load balancers and CDNs: AWS ALB, CloudFront, Azure Front Door, and Cloudflare all terminate TLS on your behalf. Their certificate configurations — algorithm selection, key size, TLS version — are controlled through cloud console settings that may not be reviewed during a traditional certificate audit.
Email servers with STARTTLS: Opportunistic TLS on SMTP connections often uses older certificates and weaker configurations than web-facing services. These certificates are frequently overlooked during inventory efforts.
The Certificate Lifecycle Problem
TLS certificates already have a lifecycle management problem — the CA/Browser Forum is pushing toward 47-day maximum validity periods. Certificate expiration is a known operational risk. Now add quantum vulnerability to that picture: a certificate that expires in 45 days still protects data whose confidentiality lifetime may be 10+ years. Expiration fixes the "this certificate will be trusted forever" problem. It does not fix the "data encrypted under this certificate can be stored and decrypted later" problem.
This is why certificate inventory — knowing every certificate, its algorithm, its key size, its issuer, and its host coverage — is the prerequisite for PQC readiness. You need to know which certificates exist before you can prioritize which ones to migrate.
How to Start Finding Quantum-Vulnerable TLS
Run an External Cryptographic Posture Assessment
The fastest starting point is an external assessment. Tools like CipherReady connect to your domains the same way a browser does — performing TLS handshakes, inspecting certificate chains, and recording algorithms, key sizes, and TLS versions. This surfaces every publicly visible TLS endpoint and its cryptographic configuration.
Key data points to collect for each endpoint:
- Certificate subject and issuer
- Public key algorithm (RSA, ECDSA, EdDSA, etc.)
- Key size (2048, 4096, P-256, P-384)
- Signature algorithm (SHA-256 with RSA, ECDSA with SHA-256)
- TLS version negotiated (1.2, 1.3)
- Cipher suite
- Certificate expiry date
- SAN entries (all domains covered by this certificate)
Classify by Quantum Risk
Map each certificate to a risk tier:
- Critical: Long-lived data protected by RSA-2048 or ECC P-256; certificate issued for 1+ years; covers domains handling regulated data (financial, healthcare, PII)
- High: RSA-2048 on public-facing endpoints; key size below 3072 bits; SHA-256 with RSA signatures
- Medium: RSA-4096 or ECC P-384 (larger classical parameters offer some additional margin but are not quantum-safe); internal endpoints with limited blast radius
- Low: Modern algorithms (Ed25519) with short-lived certificates on ephemeral services
Build a Migration Priority List
Prioritize by:
- Data sensitivity and confidentiality lifetime (regulated data, long-lived secrets, IP)
- Certificate visibility (public-facing vs internal)
- Replacement difficulty (can the certificate be reissued? does it require application changes?)
- Vendor dependency (can you update it yourself, or does a vendor control the timeline?)
Why External-First Assessment Is the Logical Starting Point
External cryptographic posture assessment has three advantages as a starting point:
- Zero infrastructure changes: No agents, no network taps, no credentials. You can start in minutes.
- Auditor's-eye view: External assessment shows what regulators, auditors, and attackers can see from outside your perimeter — exactly the view that matters for compliance and risk assessment.
- Fastest ROI: You will discover certificates you did not know existed, often within the first scan. Expired test certificates, forgotten subdomains, and misconfigured SAN entries are common.
External assessment does not replace internal discovery for high-priority regulated systems, but it is the fastest and safest way to establish a baseline inventory and start your PQC migration planning.
FAQ
Q: If my data is encrypted with AES-256 and RSA is only used for key exchange, am I still at risk? A: Yes. In a typical TLS handshake, RSA is used either for key exchange or for server authentication. If an attacker can break the RSA key, they can either recover the session key (if RSA key exchange was used) or impersonate the server to intercept traffic (if RSA signatures were used). The AES symmetric encryption is quantum-resistant for practical purposes, but only if the key was established securely.
Q: Should I stop using RSA certificates immediately? A: No. RSA certificates remain secure against classical attacks today. The quantum risk is a future risk for data whose confidentiality must extend beyond the next 10–15 years. The appropriate action now is inventory, risk classification, and migration planning — not panic.
Q: Are there any TLS configurations that are already quantum-safe? A: NIST's ML-KEM (FIPS 203) and ML-DSA (FIPS 204) are designed for TLS integration. Experimental support exists in OpenSSL 3.5+ and various TLS libraries. Hybrid key exchange (ECDHE + ML-KEM) is being standardized. Full production PQC TLS is still emerging, but the building blocks exist and testing is underway.
Start Your TLS Certificate Inventory
Run a free external cryptographic posture assessment on a domain you own with CipherReady. You will receive a TLS certificate inventory, algorithm and key-size analysis, readiness score, and AI-assisted executive summary in under 3 minutes.
Start Free Readiness Scan →
View Pricing →