Post-quantum cryptography does not justify, in 2026, urgently replacing your public SSL certificates. The real effort is instead to enable or prepare hybrid post-quantum TLS encryption on the server, CDN, or load balancer side, then automate certificate management as validity periods keep shrinking fortement. For an SMB, it is mainly a matter of risk, compatibility, and timing.
Post-quantum cryptography: what really changes for SSL
Post-quantum cryptography refers to algorithms designed to resist future ordinateurs quantiques capable of breaking some current protections. The topic affects SSL/TLS, that is, the HTTPS padlock that protects exchanges between a browser and your site.
Two mechanisms are often mixed up. On one side, the TLS key exchange, which is used to create a secret session key at the beginning of the connection. On the other, the X.509 certificate signature, which proves that the server really belongs to the displayed domain. The first is moving quickly. The second remains much less mature in public production.
The NIST, the American organism for standardization, approved in August 2024 the first post-quantum standards: FIPS 203 for ML-KEM, FIPS 204 for ML-DSA and FIPS 205 for SLH-DSA. It encourages administrators to start the transition. That does not mean that all SSL certificates need to be replaced tomorrow morning.
For a showcase website, an e-commerce site, or a business application, the useful question is therefore simple: should you act now, and where should you place the effort without creating unnecessary outages?
Why SSL certificates are not the first lever
A public SSL certificate is issued by a certification autority such as DigiCert, Sectigo, GlobalSign, or Let’s Encrypt. Today, widely deployed public certificates still mainly rely on classical signatures, such as RSA or ECDSA. Post-quantum certificates remain rare at large scale.
Recent data points in that direction. A study published on arXiv in June 2026, portant on 32,011 domains, rapporte 0 % adoption of hybrid post-quantum certificates in its sample. In other words: the market has not encore shifted to massive replacement of public X.509 certificates.
The reason is pragmatic. Post-quantum certificate chains can be much more bulky. Academic work published in 2026 mentions a TLS handshake size increase of 5 times to more than 20 times depending on the choice of algorithms. For mobile sites, unstable connections, or heavily used APIs, this overhead can translate into latency and network costs.
Honestly, for the majority of SMBs, migrating today to a public post-quantum SSL certificate is not the right trade-off. It is better to strengthen the TLS configuration, monitor announcements from certification autorities, and prepare automation. The risk of a premature migration is more concrete than the immediate benefit.
The real 2026 issue: hybrid TLS and browser compatibility
The most realistic short-term path is hybrid TLS. The principle: the browser and the server combine a classical algorithm, for example X25519, with a post-quantum algorithm such as ML-KEM-768. If one of the two were compromised in the future, the other would remain a protection.
The X25519MLKEM768 group has become the practical reference for TLS 1.3. Cloudflare indicates that its TLS 1.3 edge supports hybrid post-quantum key accord, with support announced since October 2022 for sites and APIs served via Cloudflare. Chrome 124 enabled hybrid post-quantum TLS exchange by default in April 2024, with a documented transition to ML-KEM after the initial use of Kyber before Chrome 131.
Google Cloud also documents the use of X25519MLKEM768 for Cloud Load Balancing lorsque clients advertise TLS 1.3, with default enablement planned starting in October 2026. On the Internet standards side, the IETF draft draft-ietf-tls-ecdhe-mlkem-05 from June 2026 notably defines X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
In the projects we lead, we often see confusion between “my certificate is post-quantum” and “my TLS connection uses a hybrid exchange.” In practice, it is the second point that is the most accessible today, especially if your site goes through Cloudflare, a compatible CDN, or a modern load balancer.
If you also manage firewalls, VPNs, or administration access, the same transition logic applies: inventorier first, then change. Recent incidents on network equipment are a reminder that a configuration weakness can be more urgent than a distant quantum risk, as shown by our analysis of the concrete risk around Fortinet firewalls.
Budget, timelines, and trade-offs for an SMB
The cost depends mainly on your architecture. A simple WordPress site behind Cloudflare does not require the same work as a SaaS platforme with several APIs, internal certificates, mobile applications and confor compliance constraints. The classic trap is to budget only for the certificate, whorn the time is actually spent on inventory, testing, and automation.
| Situation | Realistic action in 2026 | Typical timeline | Estimated budget France |
|---|---|---|---|
| Showcase website or WordPress with CDN | Check TLS 1.3, enable hybrid support if available, monitor HTTPS headers | 0.5 to 2 days | 300 to 1 200 € excl. tax depending on the provider |
| SME e-commerce | TLS audit, cart/payment testing, CDN or hosting, renewal monitoring | 2 to 5 days | 1 000 to 3 500 € excl. tax |
| SaaS application with API | Mapping of domains, mobile clients, partner APIs, load balancers, and internal certificates | 1 to 3 weeks | 4 000 to 12 000 € excl. tax |
| Regulated IS or large enterprise clients | Documented transition plan, compatibility testing, cryptographic policy, NIST/IETF monitoring | 1 to 2 months | 10 000 € excl. tax and more |
These ordres of magnitude vary depending on the existing setup. A clean, documented infrastructure hosted on OVHcloud, Scaleway, AWS, Google Cloud, or Azure is handled more quickly than a historical stack of servers without a reliable inventory.
At this budget level, it is often better to fund robust certificate automation rather than an isolated post-quantum prototype. Let’s Encrypt, ACME (the automatic certificate issuance protocol), and deployment tools can prevent costly HTTPS outages. One hour of downtime on an appointment-booking or payment site can cost more than a well-executed TLS audit.
The shortening of certificate lifespans changes the game
The CA/Browser Forum, which sets the rules for public TLS certificates with browsers and certification authorities, approved ballot SC-081v3 in April 2025. The schedule gradually reduces the maximum duration of public certificates: 200 days since March 15, 2026, 100 days on March 15, 2027, then 47 days on March 15, 2029.
This change is not strictly speaking post-quantum, but it directly affects your operations. The faster certificates expire, the more dangerous manual renewals become. DigiCert indicates, for example, that all its public TLS/SSL certificates will move to a maximum validity of 199 days starting from the 200-day phase.
The risk for an SMB is therefore not just theoretical. It is the forgotten certificate on a payment subdomain, the mobile API that stops responding, or the client dashboard that displays a security warning on a Monday morning. Nothing spectacular. Very inconvenient.
Simple governance is often enough: list the domains, identify the issuer, note the renewal method, centralize alerts, and test dependencies. If your site was created by several providers over time, a broader architecture audit can also help; this is typically an issue to address during a site redesign or takeover with a local agency.
Reasonable action plan before migrating
A good transition does not begin with buying a new certificate. It begins with mapping. Without that, you risk securing the homepage while forgetting the API used by your mobile application.
- Inventory all domains, subdomains, APIs, internal certificates, and third-party services exposed over HTTPS.
- Check support for TLS 1.3, then the availability of a post-quantum hybrid key exchange via your CDN, host, or load balancer.
- Test the browsers, mobile applications, partner bots, and old devices that still connect to your services.
- Automate renewals with ACME or your provider’s tool, then configure alerts before expiration.
- Document a lightweight cryptographic policy: accepted algorithms, responsible parties, review schedule, critical dependencies.
From the agency side, the reflex is to separate reversible decisions from risky decisions. Enabling hybrid support via Cloudflare or a compatible load balancer, after testing, is generally reversible. Replacing an entire certificate chain with signatures that are still not widely supported is much less so.
Regulatory constraints must also be considered calmly. The RGPD, applicable since 2018, requires personal data to be protected by measures appropriate to the risk, but does not prescribe a specific post-quantum algorithm for HTTPS. The same logic applies to the European AI Act for AI uses: compliance is built through risk analysis, documentation, and oversight, as explained in our guide on the AI Act for SMBs using ChatGPT or Claude.
The case where the obvious solution is a bad one: a company that forces an experimental post-quantum option on all its endpoints without assessing clients. If an older mobile application, a logistics scanner, or a B2B partner cannot keep up, the security gain becomes a service interruption.
When should you actually migrate your SSL certificates?
For public SSL certificates, the reasonable approach in 2026 is active waiting. You are not standing still: you prepare the infrastructure, you automate, you monitor NIST, IETF, and CA/Browser Forum standards, but you avoid an isolated migration that the rest of the ecosystem still does not follow.
The priority changes if you handle data with very long confidentiality requirements: medical records, industrial secrets, sensitive contracts, legal archives. The risk called “harvest now, decrypt later” means that an attacker can record encrypted traffic today in order to try to decrypt it later with a quantum machine. In this case, hybrid TLS becomes more relevant right now.
Another exception concerns closed environments. For an internal PKI (private certificate infrastructure), a laboratory, a controlled business application, or server-to-server exchanges that you fully manage, testing hybrid certificates can make sense. Not to look good. To learn, measure chain size, identify incompatibilities, and train teams.
Scoping this type of project upfront avoids most unpleasant surprises: incomplete inventory, misunderstood browser compatibility, forgotten manual renewal, dependence on a vendor. This is often where an outside perspective saves time, especially when security, hosting, and application development intersect.
FAQ on post-quantum cryptography and SSL
Should I replace my SSL certificate with a post-quantum certificate?
In most cases, no in 2026. Public support for post-quantum certificates remains limited, while hybrid TLS on the key exchange side is already more realistic.
Does Cloudflare make my site post-quantum compatible?
Cloudflare indicates that its TLS 1.3 edge supports hybrid post-quantum key exchorge. This mainly concerns the key exchange between the browser and Cloudflare, not necessorily the origorin certificate of your server.
Does post-quantum cryptography slow down a website?
It can increase the size of TLS exchanges, especially for post-quantum certificate chains. In hybrid key exchange mode, the impact must be tested based on your traffic, your users, and your infrastructure.
What is the first security project to launch?
Start with the HTTPS inventory, TLS 1.3, renewal automation, and expiration alerts. It’s more cost-effective and safer than a rushed post-quantum migration.