PQC Implementation: Where PQC Support Has Already Shipped

Which platforms already support post-quantum algorithms

Post-quantum key agreement has shipped broadly and is enabled by default in mainstream libraries, browsers and cloud services. Post-quantum authentication has not. Private certificate authorities can issue ML-DSA certificates today; public certificate authorities cannot, because browser root programmes have not yet accepted post-quantum roots.

Key agreement has shipped, signatures have not

The single most useful thing to understand about current availability is that the two halves of the migration are years apart.

Key agreement moved quickly because it required no ecosystem coordination. A client and a server negotiate a hybrid group, and if both support it the connection uses it. Nothing else in the internet's trust model needs to change, and the harvest now, decrypt later benefit is immediate. Cloudflare reported in 2026 that over 65 per cent of human traffic reaching its network was post-quantum encrypted.

Signatures moved slowly because they depend on certificates, and certificates depend on root programmes, baseline requirements and X.509 encoding standards that are still in progress. The result is the defining asymmetry of current deployment: a browser can negotiate a post-quantum session key against a server whose certificate is still signed with ECDSA P-256.

Cryptographic libraries and OpenSSL PQC support

OpenSSL 3.5 is the practical centre of gravity for most estates, because so much infrastructure depends on it. Two details matter operationally. It is a long term support release with support to April 2030, which covers the period in which most migration deadlines fall. And it changes default TLS behaviour, preferring hybrid key encapsulation, which means upgrading the library enables post-quantum key agreement without an explicit configuration change.

Browsers and clients

Hybrid ML-KEM key agreement is enabled by default in Chrome from version 124, Firefox from version 132 and Safari from 17.7. In practice this means most user web traffic to a post-quantum capable server is already protected against harvest now, decrypt later without any enterprise action.

Messaging clients moved earlier still. Signal deployed post-quantum key agreement in 2023 and Apple introduced PQ3 for iMessage in 2024, both ahead of the general web.

The limitation is scope. Browser support covers browser-originated TLS. It does not cover VPN clients, email signing, 802.1X or line-of-business applications, which is the endpoint blind spot discussed in why endpoints are missing from most PQC programmes.

Cloud and key management platforms

AWS supports hybrid post-quantum TLS across service endpoints and has added ML-DSA key specifications to KMS, so post-quantum signing keys can be created and used through the standard sign and verify interface. Google Cloud KMS has shipped quantum-safe digital signatures, quantum-safe key encapsulation and quantum-safe key import. Microsoft has made post-quantum APIs generally available across its platforms and has accelerated its programme target to 2029.

For most organisations this means the cloud layer is ahead of the internal estate, and the constraint on using it is application support rather than platform availability.

PKI, certificate authorities and code signing

This is where the position changed materially in 2026.

Microsoft added ML-DSA support to Active Directory Certificate Services on Windows Server 2025 through the May 2026 security update, KB5087539, allowing certification authorities, certificate templates and online responders to sign with post-quantum keys. Two qualifications matter. ML-DSA is signature only, so it does not make TLS sessions or stored data quantum-safe; ML-KEM and composite certificates are slated for a later phase. And there is no in-place migration path, so an existing certification authority cannot be converted. A parallel hierarchy must be stood up alongside it.

That second point is significant for anyone already weighing AD CS in a modern estate, because standing up a parallel hierarchy is the same exercise as a platform migration, and it is a reasonable moment to evaluate whether AD CS remains the right issuing platform.

Commercial and open-source certificate authority platforms including EJBCA Enterprise, and certificate lifecycle platforms from vendors we partner with including Keyfactor, DigiCert and Entrust, have shipped post-quantum issuance for private hierarchies. Code signing is progressing separately: Microsoft Authenticode added ML-DSA support in Windows 11 24H2, and CNSA 2.0 requires post-quantum software and firmware signing for national security systems well ahead of the general timeline.

Hardware security modules

HSM support has arrived across the major vendors, generally through firmware releases rather than hardware replacement. Thales released post-quantum capability in Luna 7.9 in July 2025. Utimaco, Entrust and Futurex have shipped comparable firmware, and Crypto4A designs its platforms as quantum-safe from the outset.

Three checks matter more than the headline claim. Whether the firmware version deployed in your estate is the one with support, rather than the latest available. Whether the implementation is FIPS validated, since validation lags general availability. And whether the algorithms you need are supported, particularly LMS and XMSS for firmware signing, which are approved under NIST SP 800-208 and are not always included alongside ML-KEM and ML-DSA.

What has not shipped: public trust certificates

No post-quantum roots have been accepted into the Mozilla, Apple, Microsoft or Chrome trust stores. The CA/Browser Forum Baseline Requirements have not been amended to permit ML-DSA in publicly trusted certificates, and the X.509 encoding work continues in the IETF's LAMPS working group.

Progress is visible. Microsoft has announced a pilot programme for ML-DSA roots in its trusted root programme, for test purposes only rather than production use, and DigiCert has been drafting a ballot to permit ML-DSA in the Baseline Requirements. Chrome has been working on ML-DSA trust anchor support for private PKI in TLS 1.3. Separately, Google proposed Merkle Tree Certificates in February 2026 as an alternative architecture, reducing post-quantum authentication data from roughly 14,700 bytes to as little as 736 by signing batches rather than individual certificates.

The practical conclusion for 2026 is that public post-quantum TLS certificates are not something to plan around yet. Private hierarchies are a different matter and can migrate now, precisely because they do not depend on browser trust stores.

How to verify an OpenSSL PQC or vendor claim

Vendor statements about post-quantum support describe availability far more often than they describe default behaviour, and the difference determines whether anything is actually protected.

Four questions separate the two. Which specific product version contains the support, since claims are frequently made against a release the customer has not deployed. Whether the capability is enabled by default or requires configuration, since an available algorithm that is never negotiated protects nothing. Whether the implementation is FIPS validated, which matters for regulated environments and lags general availability by some margin. And which algorithms and parameter sets are supported, since ML-KEM without ML-DSA, or ML-DSA without LMS, may not cover the use case.

For OpenSSL specifically, verification is direct. Checking the reported version, listing the available key encapsulation and signature algorithms in the default provider, and inspecting the negotiated group in a test handshake will establish the position in minutes. That is a more reliable input to planning than any datasheet. Further guidance on assessing claims is covered in why PQC vendor claims need scrutiny.

What to do with what has shipped

Three actions are available now and none of them waits on further standards.

Enable hybrid key agreement wherever both ends support it. In many estates this requires only upgrading to OpenSSL 3.5 or an equivalent runtime, and it addresses the harvest now, decrypt later exposure that cannot be remediated later.

Begin private hierarchy work. Private certificate authorities can issue ML-DSA certificates today, and standing up a parallel post-quantum hierarchy is the long-lead activity that determines whether the 2031 milestone is achievable.

Establish version baselines. Record which libraries, HSM firmware and platform versions are deployed against those that carry post-quantum support, since the gap between the two is the real migration backlog and it is usually larger than expected.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services, nuclear and transport. We hold partnerships across the HSM, certificate authority and certificate lifecycle vendor landscape, which gives us visibility of shipped capability rather than roadmap statements.

We establish which versions are actually deployed across an estate through our PKI health check and cryptographic bill of materials services, then design and deliver parallel post-quantum hierarchies through our PKI design and build practice, including the hardware security module configuration required to support them.

For the algorithms themselves, see our comparison of the NIST post-quantum algorithms.