The honest answer is uncomfortable: parts of the internet are already post-quantum ready, but most companies are not.

Cloudflare reported in 2025 that more than 50% of human traffic on its network was already protected against harvest-now/decrypt-later attacks with post-quantum key agreement. But origin support behind Cloudflare was still only 3.7%. That gap is the story: the edge is moving faster than the enterprise systems behind it.

Browsers, CDNs, messaging platforms, cloud providers, certificate authorities, and core open-source libraries have started deploying or planning hybrid post-quantum cryptography. The average enterprise, however, still cannot answer the basic migration question: where exactly do we use RSA, elliptic curve cryptography, long-lived certificates, SSH keys, VPN tunnels, code-signing keys, and embedded device trust anchors?

TL;DR

  • NIST finalized the first post-quantum standards in August 2024: ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures.
  • Cloudflare, Google Chrome, AWS, Apple iMessage, Signal, OpenSSH, Go, Kubernetes, and Let’s Encrypt are already moving in visible ways.
  • Key exchange is moving faster than digital signatures and public key infrastructure.
  • The biggest enterprise gap is not algorithm availability. It is cryptographic visibility, vendor dependency, and change control.
  • Every organization should start with a crypto inventory, data-retention risk model, vendor questionnaire, and test plan for hybrid TLS, SSH, VPN, PKI, and code-signing paths.

What “Ready” Actually Means

Post-quantum readiness does not mean every system has replaced RSA and elliptic curve cryptography overnight. That would be reckless and unrealistic.

For 2026, a practical readiness model has four levels:

LevelWhat it meansExample signal
DeployedPost-quantum protection is enabled in production for a defined use case.Hybrid ML-KEM in TLS or messaging key establishment.
DeployableThe platform supports PQC, but customers must enable, configure, or validate it.Cloud service endpoints, private PKI, VPN, or SSH options.
PlanningThe organization has inventory, priorities, and migration owners.Crypto inventory, vendor roadmap, high-risk data classification.
ExposedThe organization cannot identify where vulnerable public-key cryptography is used.Unknown certificate estate, unmanaged SSH keys, opaque appliances.

The strongest organizations are not the ones claiming to be “quantum-proof.” They are the ones that can change cryptography without rewriting their business.

The Standardization Baseline

NIST’s first finalized post-quantum standards are now the center of gravity:

  • FIPS 203: ML-KEM for key encapsulation and shared-secret establishment.
  • FIPS 204: ML-DSA for digital signatures.
  • FIPS 205: SLH-DSA for hash-based digital signatures and algorithm diversity.

This matters because vendor hesitation used to have a legitimate excuse: the standards were not final. That excuse is weaker now. There are still protocol, performance, certification, and interoperability problems to solve, but the migration target is no longer vague.

The UK NCSC’s public migration guidance is a useful benchmark even outside the UK: define migration goals and complete discovery by 2028, execute early high-priority migrations by 2031, and complete migration by 2035. That timeline sounds long until you compare it with enterprise certificate lifetimes, embedded device lifecycles, industrial control refresh cycles, and software supply-chain dependencies.

Who Is Moving First?

Cloudflare And The Web Edge

Cloudflare is one of the clearest examples of production post-quantum deployment. It enabled post-quantum key agreement on the server side for customers in 2022 and has continued moving toward standardized ML-KEM.

Its 2025 measurement is the important part. More than half of human traffic on Cloudflare’s network had post-quantum key agreement, while origin support still lagged far behind.

That split captures the whole industry. The edge is moving. The messy enterprise origin is slower.

Google Chrome And The Browser Ecosystem

Chrome has been a major accelerator because browser defaults move internet behavior at scale. Chrome Enterprise policy now describes post-quantum TLS key agreement using the NIST ML-KEM standard, and Cloudflare’s timeline notes that Chrome enabled post-quantum key agreement by default on desktop in March 2024.

Google is also looking beyond key exchange. In 2026, Google described work on Merkle Tree Certificates as a possible path for post-quantum HTTPS authentication without the bandwidth cost of simply stuffing large PQ signatures into traditional X.509 certificate chains.

That is the important distinction: TLS key exchange is becoming real now; post-quantum certificates and public PKI are still a harder ecosystem migration.

Let’s Encrypt And The Certificate Authority Layer

Let’s Encrypt is not production-ready for post-quantum certificates yet, but its roadmap matters. In June 2026, it announced Merkle Tree Certificates as its planned path for post-quantum Web PKI, targeting a staging environment in late 2026 and a production-ready environment in 2027.

That makes Let’s Encrypt a clear “planning with public milestones” case. It also reinforces the key distinction in this article: post-quantum key exchange protects confidentiality against harvest-now/decrypt-later collection, while post-quantum certificate authentication requires a slower Web PKI migration involving certificate authorities, browsers, ACME clients, transparency systems, and server operators.

AWS

AWS has moved from experiments into customer-facing services. AWS states that services such as AWS KMS, Amazon S3, and CloudFront have implemented hybrid post-quantum key establishment combining ECDH with ML-KEM. AWS KMS and AWS Private CA also support ML-DSA use cases for quantum-resistant signatures and roots of trust.

For defenders, this is a strong “deployable” signal. It does not mean every workload on AWS is automatically quantum-safe. It means cloud teams now have supported paths for specific high-value use cases: KMS access, private trust roots, code signing, mTLS, and service communication.

Apple And Signal

Messaging is ahead because the harvest-now/decrypt-later risk is obvious: encrypted conversations can be captured today and attacked later.

Apple introduced PQ3 for iMessage in 2024. The design uses a hybrid approach and adds post-quantum protections not only at the beginning of a conversation but also during ongoing rekeying.

Signal first added PQXDH for post-quantum session establishment, then announced SPQR and the Triple Ratchet in 2025 to extend post-quantum protection into ongoing conversations while preserving forward secrecy and post-compromise security.

These are not enterprise PKI migrations, but they show what serious readiness looks like: protocol redesign, hybrid deployment, staged rollout, and explicit damage limitation after key compromise.

OpenSSH, Go, And Kubernetes

The open-source infrastructure layer is also moving.

OpenSSH has offered post-quantum key agreement by default since 9.0, initially with sntrup761x25519-sha512, and made the standardized mlkem768x25519-sha256 hybrid exchange the default in OpenSSH 10.0. Go 1.24 enabled X25519MLKEM768 by default for TLS when applications use the standard configuration. Kubernetes v1.33 inherits this through Go 1.24, which means some Kubernetes API server connections can negotiate hybrid post-quantum TLS without a dedicated Kubernetes feature announcement.

This is good news, but it creates a detection problem: security teams may gain or lose PQC depending on runtime versions, TLS configuration, middleboxes, and downgrade behavior. “We use Kubernetes” is not a readiness answer. “These control-plane connections negotiated X25519MLKEM768 in testing” is closer.

Microsoft And Enterprise PKI

Microsoft’s AD CS documentation now describes post-quantum support arriving in phases. ML-DSA support is available as Phase 1, while ML-KEM and composite algorithms are planned for later phases. The platform requirements also matter: modern Windows Server and Windows 11 versions are required.

This is where many enterprises will feel the migration most. AD CS is tied to domain authentication, device enrollment, TLS, code signing, Wi-Fi, VPN, and internal service identity. Post-quantum migration is not only a browser problem; it is an identity and certificate governance problem.

Meta

Meta has publicly described a PQC workgroup and a TLS migration approach focused first on internal communications where it controls both endpoints. Its engineering write-up is useful because it is candid about the real migration pain: larger key shares, packet-size behavior, performance tradeoffs, dependency issues, and implementation bugs.

That is what serious enterprise readiness looks like in practice. Not a press release. A scoped use case, controlled endpoints, hybrid key exchange, measurement, and operational debugging.

What This Means For Common Software

For most defenders, the practical question is not “is Windows ready?” or “is Linux ready?” That is too broad to be useful. The better question is: which application, which TLS or crypto library, which version, and which peer on the other end of the connection?

Browsers are the clearest everyday win. Chrome, Chromium-based Edge, Firefox, Safari, and other major clients are moving post-quantum key agreement into normal web traffic when the server side supports it. That does not mean every HTTPS session is fully post-quantum. It usually means the session key exchange can be hybrid post-quantum while the certificate chain is still classical RSA or ECDSA.

On servers, the story is less magical and more familiar: check the library under the hood. curl, nginx, Apache httpd, HAProxy, Postfix, service agents, and internal APIs often inherit their PQC posture from OpenSSL, BoringSSL, Go TLS, Java, Schannel, NSS, or another backend. The command that matters is often something boring like “nginx -V” or “openssl version”, which is unfair, but security has never promised glamour.

SSH is one of the cleaner infrastructure wins. Modern OpenSSH has had hybrid post-quantum key exchange for years, with mlkem768x25519-sha256 becoming the default in OpenSSH 10.0. VPNs are more vendor-specific: some commercial providers have shipped post-quantum modes, but “uses WireGuard” or “uses OpenVPN” is not enough. You need to verify the actual protocol mode and handshake.

Email encryption, document signing, code signing, firmware signing, Java estates, .NET workloads, and private PKI are still the places to be careful. Some building blocks are arriving, but production readiness depends on interoperability, trust stores, certificate formats, client support, and rollback plans.

The takeaway: do not build a dashboard that only counts certificates and then declare victory. The first wave of PQC is often negotiated at the transport layer through hybrid key exchange. The certificate may still be classical while the session key agreement is already post-quantum. Annoying? Yes. Important? Also yes.

Who Is Not Ready?

Most organizations are not ready if readiness means operational control over their cryptography.

Common gaps include:

  • No complete inventory of certificates, SSH keys, VPN configurations, S/MIME, code-signing keys, HSM-backed keys, service meshes, databases, firmware signing, and embedded trust anchors.
  • No classification of data that must remain confidential for 5, 10, 20, or 30 years.
  • No vendor questionnaire asking when products will support ML-KEM, ML-DSA, hybrid modes, rollback controls, and logging.
  • No way to test whether TLS, VPN, proxy, DLP, WAF, EDR, and packet-inspection appliances tolerate larger ClientHello messages.
  • No plan for systems that cannot be upgraded: industrial equipment, medical devices, old mobile apps, legacy Java stacks, appliances, and offline firmware-signing processes.

The most exposed sectors are not necessarily the ones with the weakest cryptography today. They are the ones with the longest data secrecy requirements and slowest replacement cycles: government, defense, telecom, healthcare, finance, identity infrastructure, operational technology, and product vendors signing firmware for devices that will remain in the field for a decade.

What Everyone Should Do Now

1. Build A Cryptographic Inventory

Start with public-key cryptography. Find:

  • TLS certificates and issuing chains.
  • SSH host keys and user keys.
  • VPN, IPsec, mTLS, Wi-Fi, and service-mesh cryptography.
  • Code-signing, package-signing, firmware-signing, and update-signing keys.
  • HSM, KMS, TPM, smart card, and hardware token dependencies.
  • Embedded libraries: OpenSSL, BoringSSL, Go TLS, Java JSSE, Windows Schannel, NSS, wolfSSL, mbedTLS.

Do not limit this to internet-facing systems. Harvest-now/decrypt-later is about recorded traffic and long-lived secrets. Internal traffic, backups, archives, and partner links count.

2. Rank Data By Secrecy Lifetime

Ask a simple question: if this traffic or archive were decrypted in 2032, would it still matter?

Source code, M&A material, trade secrets, legal records, health data, government communications, customer identity documents, and authentication seeds often have a long risk tail. Those systems should move earlier than low-sensitivity telemetry or short-lived public web sessions.

3. Test Hybrid Key Exchange Before You Need It

Hybrid key exchange combines classical and post-quantum algorithms, commonly X25519 with ML-KEM-768. This gives a practical migration bridge: the connection remains protected if either component remains secure.

Test it in controlled places first:

  • External web edge and CDN configuration.
  • Internal APIs built with Go 1.24+ or OpenSSL 3.5+.
  • SSH administrative paths with modern OpenSSH.
  • Kubernetes control-plane and service communication.
  • Cloud KMS and private CA workflows.

Measure failures. Some middleboxes and older TLS stacks make brittle assumptions about packet sizes or ClientHello layout. Finding that in a lab is boring. Finding it during a forced migration is expensive.

4. Separate Key Exchange From Signatures

Do not treat “PQC support” as one checkbox.

Key exchange is moving faster because it can often be upgraded in TLS libraries, browsers, servers, and managed service endpoints. Signatures are harder because they touch certificate chains, trust stores, code-signing verification, firmware update flows, document signing, identity systems, and long-lived roots of trust.

Your roadmap should have separate tracks:

  • Confidentiality track: TLS, VPN, SSH, mTLS, messaging, service-to-service encryption.
  • Authenticity track: PKI, code signing, firmware signing, document signing, device identity, certificate transparency, root rotation.

5. Push Vendors Now

Every security questionnaire should include post-quantum questions:

  • Which NIST PQC algorithms do you support today?
  • Is support hybrid or post-quantum only?
  • Which protocols are covered: TLS, SSH, IPsec, S/MIME, code signing, private PKI?
  • Can customers enable, disable, log, and audit PQC negotiation?
  • What breaks when ClientHello or certificate sizes grow?
  • What is your timeline for ML-KEM and ML-DSA in supported releases?
  • How will long-lived devices receive cryptographic updates?

The right answer in 2026 is not always “fully deployed.” But “we have no roadmap” is a risk signal.

The Readiness Verdict

Ready now: selected browser-to-edge TLS paths, major CDN deployments, some cloud service endpoints, modern messaging protocols, OpenSSH, Go TLS, and parts of the Kubernetes ecosystem.

Partly ready: enterprise PKI, Let’s Encrypt’s planned Merkle Tree Certificate path, cloud private CA workflows, code-signing pilots, internal service communication, and organizations that already have crypto inventory and vendor pressure underway.

Not ready: unmanaged certificate estates, legacy VPNs, embedded appliances, long-lived OT and IoT devices, opaque vendor products, and organizations that cannot say where RSA and ECC are used.

The real post-quantum divide is not between companies that understand quantum computing and companies that do not. It is between organizations that can change cryptography deliberately and organizations that will discover their dependencies one outage at a time.

Start with visibility. Move the highest-risk confidentiality paths to hybrid key exchange. Build a signature migration plan separately. Make vendors show their roadmap. Treat crypto-agility as infrastructure, not a research project.

Sources