The padlock icon in your browser address bar has protected internet users for decades. It signals that the connection between a visitor’s browser and your server is encrypted using SSL/TLS, and that the certificate was issued by a trusted Certificate Authority. That system works because the mathematics underlying it, primarily RSA and elliptic curve cryptography, is too computationally expensive for any existing computer to crack in a useful timeframe.
Quantum computers will not respect that boundary.
A sufficiently powerful quantum computer running Shor’s algorithm could break RSA-2048 encryption in hours. Elliptic curve cryptography faces the same fate. The mathematical assumptions that have kept the internet secure since the 1990s were never designed to withstand quantum-scale computation, and that limitation is now a planning problem for every website owner alive today.
This guide explains what post-quantum cryptography means for SSL certificates, what is already happening in your browser without you noticing, what the regulatory and industry roadmap looks like through 2029, and what practical steps website owners should take now to stay ahead of one of the largest infrastructure transitions in internet history.
What Post-Quantum Cryptography Actually Means
What is Post-Quantum Cryptography?
Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to remain secure against attacks from both classical and quantum computers. Unlike quantum cryptography (which transmits keys using quantum physics), PQC runs on standard hardware using mathematical problems that quantum computers cannot efficiently solve. NIST finalized its first three PQC standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA).
The current SSL/TLS ecosystem uses two types of cryptographic operations that quantum computers directly threaten. The first is key exchange: when your browser connects to a website, both sides agree on a shared encryption key using algorithms like ECDH (Elliptic Curve Diffie-Hellman) or RSA key exchange. The second is digital signatures: when a Certificate Authority signs your SSL certificate, it uses RSA or ECDSA to prove the certificate is genuine and was issued by a trusted source.
Quantum computers threaten both operations through the same mechanism. Shor’s algorithm, developed by mathematician Peter Shor in 1994, demonstrates that a quantum computer with enough stable qubits can solve the mathematical problems underlying RSA and elliptic curve cryptography in polynomial time rather than exponential time. Problems that would take classical computers millions of years become tractable in hours or days. The entire certificate trust model breaks.
The Quantum Threat Timeline: Why 2026 Is Not Too Early
The question most website owners ask is: “How soon does this actually matter?” The answer has two parts, and both of them point to acting now.
The Q-Day Estimate
“Q-Day” refers to the moment when a quantum computer becomes powerful enough to break RSA-2048 or elliptic curve P-256 encryption within a practical timeframe. Expert consensus from government agencies, research institutions, and technology companies places Q-Day somewhere between 2030 and 2035, with uncertainty skewed toward the earlier end. IBM’s publicly available quantum computing roadmap projects fault-tolerant systems with hundreds of logical qubits by 2029. NSA has stated that Q-Day could arrive as early as 2030 if hardware development accelerates.
Three research papers published between May 2025 and March 2026 reduced the estimated quantum resources required to break RSA-2048 from approximately 20 million qubits to fewer than one million, with some architectures potentially achieving this with as few as 100,000 qubits. Recent research from Google’s Craig Gidney has estimated that breaking RSA-2048 might require only around one million physical qubits running for one week. Separately, research published in early 2026 showed that breaking elliptic curve P-256 might require only 10,000 qubits on a neutral atom architecture. The threshold is moving closer faster than the 2022 estimates suggested.
But the precise date of Q-Day is, in a critical sense, the wrong question to be asking.
The Harvest Now, Decrypt Later Problem
What is a Harvest Now, Decrypt Later Attack?
A “harvest now, decrypt later” (HNDL) attack is a data collection strategy in which adversaries record encrypted internet traffic today, store it at scale, and plan to decrypt it once quantum computers capable of breaking the underlying encryption become available. Since the collection happens now and decryption happens later, any data with long-term sensitivity, such as financial records, medical information, legal documents, or authentication credentials, is at risk from the moment it is transmitted under classical encryption.
NIST’s transition guidance states directly: “Encrypted data remains at risk because of the harvest now, decrypt later threat in which adversaries collect encrypted data now with the goal of decrypting it once quantum technology matures. Since sensitive data often retains its value for many years, starting the transition to post-quantum cryptography now is critical to preventing these future breaches.”
This means the relevant deadline is not Q-Day itself. It is the point at which the data your visitors are transmitting to your website today will still be sensitive. If you operate a healthcare platform, a financial services website, a legal services portal, or any site handling data that must remain confidential for more than five to ten years, those connections are already at risk under current encryption. Nation-state adversaries are believed to already be collecting encrypted traffic at scale. The U.S. government has directed all federal agencies to migrate to post-quantum cryptography by 2035. The NSA wants all national security systems migrated before that date. A migration that takes five to eight years to complete, which is the realistic estimate for large organizations, cannot begin in 2029.
What Has Already Changed in Your Browser
The transition to post-quantum TLS has been underway for longer than most website owners realize, and a significant portion of it is already happening invisibly on connections to major platforms.
In August 2024, NIST finalized its first three post-quantum cryptographic standards. Google Chrome shifted to the standardized ML-KEM naming shortly after. Cloudflare deployed hybrid post-quantum key exchange as the default for connections to its network and reported that by March 2025, approximately 38 percent of human HTTPS traffic on its network was already using hybrid post-quantum handshakes.
What this means in practice is that a visitor using Chrome or Firefox connecting to a Cloudflare-proxied website was already negotiating a hybrid TLS handshake using X25519MLKEM768 without any configuration from the website owner. The hybrid key exchange combines the classical X25519 elliptic curve algorithm with ML-KEM (formerly called CRYSTALS-Kyber) in parallel. If either algorithm is eventually broken, the other continues to protect the session.
Microsoft’s cryptographic library SymCrypt shipped ML-KEM and ML-DSA in production across Azure, Microsoft 365, Windows 11, and Windows Server 2025 following the November 2025 update. AWS measured the overhead of hybrid PQC TLS at roughly 1,600 additional bytes and 80 to 150 microseconds of compute per handshake, which most deployments absorb without perceptible impact. Squarespace, GitHub, and several CDN providers have also enabled PQC-capable TLS connections for hosted websites.
The TLS handshake layer itself shows negligible performance difference. Research published in early 2026 measured classical, hybrid, and pure PQC TLS 1.3 handshakes under realistic load conditions and found that all three configurations showed negligible effect sizes on handshake latency, consistent with earlier Cloudflare experiments that found PQC key exchanges adding only approximately one to two milliseconds under ideal conditions.
The Three NIST PQC Standards: What They Replace and Why It Matters for Certificates
Understanding the three finalized NIST standards helps clarify exactly which part of your SSL infrastructure is changing.
FIPS 203: ML-KEM (Key Encapsulation Mechanism)
ML-KEM, based on the CRYSTALS-Kyber algorithm, replaces the key exchange step in TLS. When a browser connects to your server, ML-KEM provides the quantum-resistant mechanism for establishing the shared session key that encrypts all subsequent communication. This is where the hybrid approach (X25519 + ML-KEM) is currently deployed across Chrome, Cloudflare, and major cloud providers.
ML-KEM operates on the hardness of the Module Learning With Errors (MLWE) problem, a lattice-based mathematical structure that quantum computers cannot efficiently solve. Key sizes are larger than classical ECDH: an ML-KEM-768 public key is 1,184 bytes compared to 32 bytes for X25519. The additional size adds bandwidth overhead but is manageable on modern connections.
FIPS 204: ML-DSA (Digital Signature Algorithm)
ML-DSA, based on the CRYSTALS-Dilithium algorithm, replaces the digital signature component of SSL certificates. When a Certificate Authority signs your certificate to vouch for its authenticity, that signature currently uses RSA or ECDSA. ML-DSA would replace those signatures with a lattice-based alternative resistant to quantum attack.
This is where the SSL certificate transition becomes more complex. ML-DSA certificates have significantly larger signatures than RSA or ECDSA certificates. An ML-DSA-65 certificate chain in a TLS handshake is approximately 12 kilobytes, compared to a few kilobytes for an RSA or ECDSA chain. When combined with an ML-KEM key exchange, the total server-to-client data in the TLS handshake reaches approximately 17 kilobytes, which in some cases requires a second TCP round trip. For high-traffic sites, this bandwidth increase is a real capacity planning consideration.
NIST’s guidance is that ML-DSA should be the default choice for post-quantum signatures in most situations. Google has tested ML-DSA in TLS and found it workable, and it is expected to become the primary digital signature standard, eventually replacing the RSA and ECDSA infrastructure that currently underlies every publicly trusted SSL certificate.
FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature)
SLH-DSA, based on SPHINCS+, is a hash-based signature scheme using a fundamentally different mathematical structure than ML-DSA. It is not lattice-based, which provides a security diversification advantage: if future cryptanalysis uncovers weaknesses in lattice-based schemes, SLH-DSA remains unaffected. SLH-DSA signatures are significantly larger than ML-DSA signatures and signing is slower, so it is recommended as a backup or alternative rather than the primary choice.
A fourth standard, FN-DSA (based on the Falcon algorithm), was submitted for draft review in August 2025. FN-DSA’s key advantage is smaller signatures than ML-DSA: approximately 666 bytes at NIST Level 1, compared to ML-DSA’s larger footprint. If standardized, FN-DSA could become preferable for certificate chains where size constraints are a priority.
Where Post-Quantum SSL Certificates Stand Right Now
This is the section where most blog posts on post-quantum cryptography create confusion by blurring the line between what is already deployed and what is still being finalized.
Here is the precise state as of 2026.
Post-quantum key exchange (ML-KEM) in TLS handshakes is already deployed at scale by Cloudflare, Chrome, Firefox, Microsoft, AWS, and major CDN providers. This protects the session encryption layer of HTTPS connections against harvest now, decrypt later attacks. Website owners using these platforms get this protection automatically, without changing their certificate.
Post-quantum digital signatures in publicly trusted SSL certificates are not yet available for general website owners. The CA/Browser Forum, the industry body that governs what Certificate Authorities are permitted to do, has not yet updated its Baseline Requirements to allow ML-DSA in publicly trusted certificates. Additionally, the IETF has not yet finalized the OID (Object Identifier) and X.509 encoding standards required to represent PQC algorithms in the certificate format that browsers recognize. Both the CA/Browser Forum update and the IETF finalization are expected between 2026 and 2027.
Post-quantum certificates are available for private PKI today. Organizations that manage their own internal certificate infrastructure (for internal servers, employee devices, APIs, or IoT systems) can issue ML-DSA certificates now using DigiCert Private CA, AWS Private CA (which reached general availability for PQC in November 2025), and open-source tools including OpenSSL 3.5 with the OQS provider. This lets teams test PQC certificate compatibility against their infrastructure before public PKI support arrives.
The practical implication for website owners is a two-layer transition: the session encryption layer (key exchange) is already transitioning on major platforms, while the certificate authentication layer (signatures) is 12 to 24 months behind. Both layers need to migrate for full post-quantum security.
The CA/Browser Forum Timeline and the 47-Day Certificate Shift
Something else is changing in 2026 that directly intersects with post-quantum readiness: certificate lifetimes.
In April 2025, the CA/Browser Forum passed Ballot SC-081v3 with 29 votes in favor and zero opposed. Every major browser vendor, including Apple, Google, Mozilla, and Microsoft, backed the measure. The ballot reduces maximum SSL/TLS certificate validity from 398 days to 47 days through a phased schedule.
The phased timeline is as follows. From March 15, 2026, maximum certificate validity drops to 200 days. This phase is already in effect. DigiCert moved to 199-day maximum validity on February 24, 2026. Sectigo followed on March 12, 2026. From March 15, 2027, validity drops to 100 days. From March 15, 2029, validity reaches its final limit of 47 days, requiring renewal approximately every six to seven weeks.
The connection between shorter certificate lifetimes and post-quantum readiness is direct. A 47-day renewal cycle forces every organization to build automated certificate lifecycle management infrastructure. Manual renewal processes that work for annual certificates collapse completely at 47-day cycles: an 8-fold increase in renewal frequency makes spreadsheets, calendar reminders, and manual reissuance impractical or impossible. DigiCert’s own assessment describes manual revalidation at the 47-day stage as “a recipe for failure.”
This automation infrastructure is also the operational foundation for post-quantum migration. When ML-DSA certificates become available for publicly trusted use, organizations with automated renewal pipelines can transition their entire certificate estate to post-quantum algorithms through normal renewal cycles, without a separate migration project. Organizations still managing certificates manually in 2029 face two simultaneous crises: the automation crisis from 47-day lifetimes and the cryptographic crisis from the post-quantum transition.
According to the Sectigo 2025 State of Crypto Agility Report, conducted in partnership with research firm Omdia, only 5 percent of organizations have fully automated certificate management. Only 28 percent have a complete inventory of their certificates. Only 13 percent are confident they can track shadow or rogue certificates. These gaps, already significant, become catastrophic at 47-day renewal cycles.
What the Term “Crypto Agility” Means and Why Website Owners Need It
What is Crypto Agility?
Crypto agility is the operational and architectural capability to swap cryptographic algorithms, update certificate configurations, and migrate encryption infrastructure without significant disruption to services or requiring application rewrites. An organization with crypto agility can respond to a newly discovered cryptographic vulnerability or a completed PQC standard by rotating its certificates and updating its TLS configurations within days rather than months.
Crypto agility matters because the post-quantum transition is not a one-time event. NIST’s standards represent the current best available algorithms based on years of cryptanalytic vetting. But cryptography evolves. SIKE, a candidate algorithm that appeared promising in NIST’s evaluation process, was broken by a classical attack in 2022 after years in contention. If a future cryptanalytic breakthrough weakened ML-KEM or ML-DSA, organizations with crypto agility could rotate to alternatives within days. Organizations without it would face a crisis.
For website owners, crypto agility translates into four specific capabilities: a complete and continuously updated inventory of all SSL/TLS certificates across all systems; automated renewal processes using ACME or equivalent protocols; the ability to issue certificates with different algorithms through the same infrastructure; and monitoring that alerts on certificate expirations, algorithm mismatches, and configuration drift.
What Website Owners Should Do Right Now
The steps available to website owners in 2026 fall into three categories: actions you can take immediately, preparations for the 12-to-24-month window before public PQC certificates arrive, and longer-term infrastructure decisions.
Actions to Take Now
Conduct a complete certificate inventory. You cannot prepare a migration you cannot see. Audit every domain, subdomain, API endpoint, load balancer, CDN configuration, and cloud service in your infrastructure to map all active certificates. Identify their expiration dates, issuing CAs, validation levels, and the algorithms they use. Tools like Shodan, Censys, or your CA’s management platform can help identify certificates that are not directly network-visible.
Move to automated certificate renewal. The March 2026 shift to 200-day maximum validity is already in effect. The 47-day endpoint in 2029 is not a future problem. Setting up ACME-based automation now, whether through Certbot for Let’s Encrypt certificates or your CA’s managed renewal service, builds the infrastructure you need for both the lifetime reduction and the eventual PQC migration. Let’s Encrypt, DigiCert, and Sectigo all support ACME-based automation.
Check whether your hosting environment already provides hybrid PQC. If your website runs behind Cloudflare, uses a major CDN, or is hosted on AWS, Azure, or Google Cloud, your TLS handshakes may already use hybrid post-quantum key exchange without any action required. Verify this by reviewing your provider’s PQC documentation. This protects your visitors’ session encryption against harvest now, decrypt later attacks, covering the most immediately actionable part of the quantum threat.
Ensure you are running TLS 1.3. TLS 1.3 is required for post-quantum hybrid key exchange. CISA mandates TLS 1.3 adoption by January 2, 2030, but migrating now ensures compatibility with the hybrid PQC configurations already deployed by major browsers and CDNs. Sites still on TLS 1.2 should treat this as an immediate priority.
Preparations for the Next 12 to 24 Months
Monitor the CA/Browser Forum and IETF for PQC certificate standards. The finalization of OID standards and Baseline Requirements updates that will enable publicly trusted ML-DSA certificates is expected between late 2026 and 2027. Subscribe to CA newsletters, the CA/Browser Forum public mailing list, and IETF working group updates. When these standards finalize, Certificate Authorities will move quickly to support PQC certificates, and you want to be positioned to adopt them in the first renewal cycle.
Test PQC certificates in private PKI if you run internal infrastructure. Organizations managing internal servers, employee devices, or API authentication can deploy ML-DSA certificates through DigiCert Private CA or AWS Private CA today. Internal testing builds familiarity with the operational changes before they become mandatory in your public-facing certificate estate.
Evaluate your certificate management platform for PQC readiness. Most enterprise certificate lifecycle management platforms are actively developing PQC support. If you manage more than a handful of certificates manually, now is the time to evaluate whether your current tooling will support algorithm migration when PQC certificates become available. Platforms that support Sectigo Certificate Manager, DigiCert CertCentral, or equivalent CLM solutions with roadmapped PQC support are the appropriate direction.
Prioritize automation for any domain that would cause an outage if its certificate expired. Under the 47-day regime, every manually managed certificate is a latent outage risk. Identify your highest-traffic, most revenue-critical, or most visibility-sensitive domains first and automate their renewal before the 2027 100-day milestone arrives.
Longer-Term Infrastructure Decisions
Plan your cryptographic bill of materials. Organizations preparing for a managed post-quantum transition should document a complete Cryptography Bill of Materials (CBOM): a map of every algorithm, key, and certificate in use, where it resides, and what it connects to. NIST’s National Cybersecurity Center of Excellence recommends this as the first step in any PQC migration. A CBOM makes algorithm migration systematic rather than reactive.
Consider the size implications of PQC certificates in performance planning. A complete ML-KEM + ML-DSA TLS handshake adds approximately 17 kilobytes to the server-to-client data compared to a classical handshake. For most websites, this is invisible. For CDNs, APIs processing millions of requests per second, or high-frequency trading platforms, it requires capacity planning. Review your server initial congestion window settings and CDN configurations if you fall into this category.
Engage your SSL certificate provider about their PQC roadmap. Certificate Authorities are actively participating in CA/Browser Forum working groups to support PQC. Ask your current provider directly: when do they expect to issue publicly trusted ML-DSA certificates? What testing environments are available? What migration support will they offer? The answers will inform your migration timeline.
What to Look for in an SSL Certificate Provider for PQC Readiness
As you plan the transition, the choice of Certificate Authority and certificate management platform matters more than it has for most of SSL’s history. Not all CAs are equally positioned for the post-quantum transition.
Providers with active participation in CA/Browser Forum PQC working groups, published PQC roadmaps, and existing private PKI support for ML-DSA certificates are demonstrably further along than those waiting for standards finalization to begin development. DigiCert and Sectigo are both publicly committed to PQC certificate support and have issued private PQC certificates already. Sectigo has announced Private PQC certificates built into its Certificate Manager platform.
For website owners who currently purchase individual DV or OV certificates from a reseller, the immediate priority is ensuring automated renewal is set up and working reliably before the 100-day milestone in March 2027. The PQC certificate question is a 2027-to-2028 decision for most single-site operators, but the automation infrastructure decision is a 2026 requirement.
A Plain-Language Summary: Where Everything Stands in 2026
Already protecting you: Hybrid post-quantum key exchange (ML-KEM + X25519) is deployed by default on Cloudflare, Google Chrome, Firefox, AWS, Azure, Microsoft 365, and several other major platforms. If your website uses any of these, your session encryption is already partially quantum-resistant.
Not yet available: ML-DSA certificates for public websites. The CA/Browser Forum and IETF are finalizing the standards that will enable this. Expected: 2026 to 2027 for standards finalization; 2027 to 2028 for widespread CA availability.
Already mandatory: 200-day maximum certificate validity as of March 15, 2026. Automated renewal is no longer optional for any serious web operation.
Coming: 100-day validity by March 2027 and 47-day validity by March 2029. Both require automated certificate lifecycle management.
The threat driving it all: Harvest now, decrypt later. Any data transmitted under classical encryption today that needs to remain confidential past approximately 2030 to 2035 is already at risk from collection by sophisticated adversaries.
Your action priority: Build certificate automation now. Confirm hybrid PQC key exchange with your hosting or CDN provider. Monitor CA/Browser Forum announcements for ML-DSA certificate availability. Conduct a certificate inventory if you have more than a handful of domains.
The padlock is not going away. It is being rebuilt, and the construction is well underway. Website owners who understand the timeline and take systematic steps through 2026 and 2027 will complete the transition as a managed upgrade. Those who wait for Q-Day will face it as an emergency.
CompareCheapSSL.com compares SSL certificate prices from leading Certificate Authorities including DigiCert, Sectigo, GlobalSign, and others. Browse our comparison tool to find the best-value SSL certificate for your site, and check our provider guides for the latest updates on PQC certificate availability as standards finalize.
