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