Post-Quantum Cryptography Vendor Support Matrix (2026)
This page is a living reference tracking post-quantum cryptography (PQC) support across major technology vendors, services, and products. It covers ML-KEM (key encapsulation), ML-DSA (digital signatures), hybrid mode availability, and production status.
For procurement due diligence, pair this status matrix with the open PQC vendor questionnaire. Record product-specific decisions, evidence, owners, and rollback requirements in the PQC migration plan template.
Last full matrix review: September 30, 2026; subsequent entries carry their own check dates. Ubuntu 26.10 and the MITRE maturity context were checked October 20, 2026. This is not a re-verification of every vendor row.
How to read this matrix
- ML-KEM: Support for NIST FIPS 203 Module-Lattice-Based Key Encapsulation Mechanism
- ML-DSA: Support for NIST FIPS 204 Module-Lattice-Based Digital Signature Algorithm
- Hybrid mode: Classical + post-quantum algorithms combined (typically X25519 + ML-KEM-768 for key exchange)
- Production status: Whether the PQC feature is generally available and recommended for production use
Status legend:
- GA = Generally Available (production-ready)
- Preview = Available but not recommended for production
- Planned = Publicly announced but not shipped
- None = No announced support
Category maturity is not product verification
MITRE’s PQC Capability Development Report, published through the PQC Coalition, separates key establishment from authentication. Its September report uses public evidence collected in July 2026. Key establishment is further along in several enterprise categories; that does not certify every vendor in a category. Ratings reflect the most advanced observed evidence, not independent product-security testing. Keep checking the exact release, algorithm, configuration and validation boundary in each row below.
Cloud providers
For implementation detail across the three largest platforms, use the AWS, Azure, and Google Cloud PQC comparison.
| Provider | ML-KEM support | ML-DSA support | Hybrid mode | Production status | Notes |
|---|---|---|---|---|---|
| AWS | Hybrid ML-KEM TLS on documented service endpoints; no customer KEM-key workflow in KMS documented | ML-DSA-44/65/87 in KMS and Private CA | Yes (including X25519MLKEM768) | Mixed | KMS signatures GA in validated HSMs; CloudHSM ML-DSA Preview; CloudFront PQ TLS default; ALB/NLB PQ policies opt-in. |
| Google Cloud | ML-KEM-768/1024 and X-Wing KEMs in Cloud KMS (Preview); ML-KEM on internal traffic | ML-DSA + SLH-DSA in Cloud KMS (GA) | Yes (X-Wing and X25519MLKEM768, context-dependent) | Mixed | PQ Insights and signatures are GA. KEM operations and quantum-safe HPKE import remain Preview; import is software-target only. |
| Microsoft Azure | ML-KEM in SymCrypt, Windows Server 2025, .NET 10 | ML-DSA in SymCrypt, .NET 10 CNG APIs | Yes (X25519MLKEM768 in Schannel) | Partial GA | Platform/IaaS ready. Key Vault has NO PQC key types. Managed services vary. 2033 full migration target. |
| Cloudflare | X25519MLKEM768 available on edge and origin paths; actual negotiation depends on the peer | ML-DSA for Authenticated Origin Pulls and Custom Origin Trust Store; ML-DSA-44 DNSSEC validation on 1.1.1.1; public MTC issuance planned | Yes | Mixed GA / planned | PQ TLS and origin authentication are GA. Domain-level negotiated-group telemetry is available. Public CA/MTC issuance and Chrome quantum-resistant root-store inclusion target early 2027 and are not GA. |
| Fastly | X25519MLKEM768 | None announced | Yes | GA | Enabled by default on edge. |
| Akamai | Testing/limited | None announced | Unknown | Preview | Limited public documentation. |
Browsers
| Browser | ML-KEM key exchange | ML-DSA signatures | Hybrid mode | Production status | Since version |
|---|---|---|---|---|---|
| Chrome | X25519MLKEM768 (default) | MTC experiment completed; separate quantum-resistant root program has draft policy | Yes | Key exchange GA; authentication planned | Chrome 131 key exchange; MTC public trust not generally available |
| Edge | X25519MLKEM768 (default) | Not yet | Yes | GA | Edge 131 (Nov 2024) |
| Firefox | X25519MLKEM768 (default) | Not yet | Yes | GA | Firefox 132 (desktop), 145 (Android) |
| Safari | X25519MLKEM768 (default) | Not yet | Yes | GA | Safari 26 / iOS 26 / macOS Tahoe |
| Brave | X25519MLKEM768 (default) | Not yet | Yes | GA | Brave 1.73.86 (Chromium 131) |
| Opera | X25519MLKEM768 (default) | Not yet | Yes | GA | Opera 116 (Chromium 131) |
| Tor Browser | X25519MLKEM768 (default) | Not yet | Yes | GA | Tor Browser 15.0 |
All major browsers now negotiate post-quantum key exchange by default for TLS 1.3 connections. Post-quantum signatures in TLS certificates are not yet supported in any major browser for the public web PKI. Chrome is pursuing Merkle Tree Certificates as an alternative to standard X.509 PQ certificates.
VPNs
| VPN solution | ML-KEM support | ML-DSA support | Hybrid mode | Production status | Notes |
|---|---|---|---|---|---|
| WireGuard + Rosenpass | ML-KEM (via liboqs) | Not directly | Yes (WireGuard PSK + Rosenpass PQ key exchange) | Experimental/beta | Rosenpass provides PQ key exchange as a layer on top of WireGuard using its PSK mechanism. Written in Rust. |
| Cloudflare WARP (Zero Trust) | X25519MLKEM768 | None | Yes | GA | PQ key exchange in Cloudflare One tunnels between client and Cloudflare edge. |
| Surfshark modified WireGuard | ML-KEM, per vendor | ML-DSA authentication, per vendor | Exact construction not established by announcement | Vendor-reported availability on macOS and iOS | October 7 announcement; other platforms’ ML-DSA rollout planned. Not upstream WireGuard or independently established complete PQ security. |
| OpenVPN | None (native) | None | None | None | No native PQC. Third-party patches exist using liboqs but are experimental. |
| IPsec/IKEv2 | ML-KEM proposed (RFC drafts) | ML-DSA proposed | Hybrid drafts in IETF | Drafts only | IETF drafts for PQ in IKEv2 exist. No major vendor implementation GA. |
| Tailscale | None announced | None | None | None | Uses WireGuard internally; no public PQ support announced. |
| NordVPN / ExpressVPN | None confirmed | None | None | None | Marketing mentions of “quantum-safe” but no confirmed ML-KEM/ML-DSA deployment. |
| NetBird | ML-KEM (via Rosenpass integration) | None | Yes (hybrid with WireGuard) | Beta | Claims “first quantum-resistant mesh VPN.” Uses Rosenpass for PQ key exchange. |
The VPN space is behind browsers and cloud providers. WireGuard’s simplicity means PQ can be layered on via the pre-shared key mechanism (Rosenpass approach), but native protocol changes are not yet standardized.
Surfshark entry checked October 12, 2026: its October 7 announcement separates existing ML-KEM key establishment from added ML-DSA authentication on macOS/iOS. The generic protocol page mentions earlier PQ protection on other platforms; that is not evidence that the newer authentication feature has shipped there. Parameter sets, standard-client interoperability and an independent audit of this exact implementation are UNKNOWN from the announcement. See the VPN comparison for the connection-level boundary.
Developer services: GitHub SSH
Checked October 15, 2026: GitHub’s official SSH change record gives the schedule below. The scheduled activation date has passed; the record still uses scheduled wording rather than a separate completion notice. A credential-free observation of github.com:22 on October 15 saw the server advertise and select mlkem768x25519-sha256; host authentication was deliberately not completed. That corroborates endpoint availability, not authenticated end-to-end testing, every region or every connection.
| Capability / change | State and scope | Limitation |
|---|---|---|
| ML-KEM-768 + X25519 hybrid KEX | mlkem768x25519-sha256; official activation date October 14, 2026; advertised/selected on the observed github.com endpoint | Client/server negotiation determines use; no fleet-wide completion notice verified |
| Earlier PQ KEX | SNTRUP761 + X25519 rollout began September 17, 2025 | Different construction, not ML-KEM; both were advertised by the observed endpoint |
| Region | github.com and GitHub Enterprise Cloud with data residency, except US region, per official notice | Do not extrapolate one endpoint observation to the excluded region |
| New RSA uploads | Minimum 3072 bits, signing/authentication keys; October 14 effective date in schedule | Existing shorter keys are not automatically deleted by this upload rule; enforcement not tested by uploading keys |
| Legacy brownouts | November 4 and December 9, 2026 | Planned interruptions for ssh-rsa / SHA-1, ssh-rsa-cert-v01@openssh.com using SHA-1, and diffie-hellman-group-exchange-sha256 |
| Permanent retirement | January 13, 2027 | Scheduled, not already removed on October 15 |
| Enterprise Server | ML-KEM addition in 3.24; other listed changes in 3.25, per notice | Product release support is distinct from an individual server’s upgrade/configuration |
RSA keys can use SHA-2 signatures; RSA itself is not synonymous with the ssh-rsa/SHA-1 signature type. Hybrid KEX does not make host/user authentication PQ. Record the actual negotiated method and client version using the RFC 10042 implementation guide. No inference is made that all GitHub SSH traffic now uses PQC.
Messaging apps
| App | ML-KEM / Kyber support | ML-DSA support | Hybrid mode | Production status | Notes |
|---|---|---|---|---|---|
| iMessage (PQ3) | Kyber-1024 (initial) + Kyber-768 (ratchet) | None (classical ECDSA auth) | Yes (Kyber + P-256 ECDH) | GA | Level 3: PQ in initial key exchange AND ongoing ratchet. Shipped iOS 17.4 (March 2024). |
| Signal | ML-KEM-768 (PQXDH initial + SPQR ratchet) | None (classical Ed25519 auth) | Yes (X25519 + ML-KEM-768) | GA | PQXDH since Sept 2023 (Level 2). SPQR ratchet since June 2025 (Level 3). |
| None confirmed | None | None | None | Uses Signal Protocol but has not announced PQXDH or PQ ratchet deployment. | |
| Telegram | None | None | None | None | Telegram’s MTProto does not include PQC. No announced plans. |
| Matrix/Element | Experimental (Vodozemac) | None | Planned | Experimental | PQ Olm/Megolm under development. Not production. |
| Wire | None confirmed | None | None | None | Uses Proteus (MLS-based). MLS PQ extensions are in IETF drafts. |
| Zoom | ML-KEM-768 (E2EE meetings) | None | Yes (hybrid) | GA | PQ E2EE for Zoom Meetings shipped May 2024. |
| Google Meet (ordinary meetings/calls) | UNKNOWN: announcement does not name algorithm | UNKNOWN: PQ authentication not specified | UNKNOWN | Rollout in progress from October 12, 2026 | Web/laptop clients and meeting-room hardware first; mobile planned. Automatic update, not evidence of CSE-equivalent end-to-end encryption. |
Only iMessage and Signal provide production post-quantum encryption with ongoing rekeying (Level 3). Zoom provides PQ key exchange for E2EE meetings but without a PQ ratchet for the session.
Google Meet rollout
| Field | Verified state on October 13, 2026 |
|---|---|
| Vendor / product / capability | Google / Google Meet / vendor-announced PQ-protected meeting traffic |
| Web/laptop clients | Rollout started October 12; completion not verified |
| Meeting-room hardware | Included in the same rollout; no model-by-model completion evidence |
| Mobile | Planned / coming soon; no shipping date specified |
| Pace and audience | Up to 15 days for Rapid and Scheduled Release domains; Workspace, Workspace Individual and personal Google accounts eligible |
| User/admin action | Automatic; no user setting or admin control |
| Algorithm / parameter set / hybrid construction | UNKNOWN: not specified in the announcement |
| Post-quantum authentication | UNKNOWN: not explicitly documented |
| Evidence / verification | Google Workspace announcement, October 12, checked October 13; desk verification, not traffic testing |
This expands beyond Meet’s previously documented client-side encrypted (CSE) calls. It does not establish that ordinary meetings adopt the same key-ownership or end-to-end architecture. Google’s encryption help distinguishes cloud-encrypted meetings from CSE and optional end-to-end call modes. Do not infer the unnamed algorithm from Chrome, Cloud KMS or Google’s internal network. This is a Workspace application rollout, not a new Cloud KMS capability; see the Google Cloud guide.
Blockchain protocols and testnets
Blockchain maturity needs more than an algorithm checkbox. Track whether a standardized algorithm is present in code, enabled in an integrated public testnet, or deployed on the production network.
| Protocol / network | Standardized algorithm support | Implementation stage | Integrated public testnet | Production / mainnet status | Evidence and limitations |
|---|---|---|---|---|---|
| Tezos Quantumnet | ML-DSA-44 for tz5 accounts; experimental PQ mechanisms also cover consensus and data-availability functions | Ushuaia introduced feature-flagged tz5 support; Quantumnet enables it and integrates broader protocol changes | Live experimental public testnet since September 24, 2026 | Tezos mainnet is not established as quantum-safe. tz5 remains disabled by default on mainnet, and Quantumnet is not intended for production use | Quantumnet replaces current mechanisms in several areas, including XMSS plus STARK aggregation for attestations and ZODA for the DAL. These are experimental testnet designs, not proof of production security, performance, or a scheduled mainnet migration. |
Quantumnet moves Tezos beyond isolated, feature-flagged account support into an integrated public test environment. It does not collapse the remaining stages: protocol analysis, implementation hardening, governance, mainnet activation, wallet and infrastructure support, and user migration are separate work.
| Cosmos release / capability | Software support | Network adoption / limitation |
|---|---|---|
| Ledger Security 2026.1 | Cosmos SDK v0.55.0, CometBFT v0.40.0, enterprise PoA v1.1.0 and cosmos/kms v0.1.0, per release announcement | Released artifacts are not evidence that every Cosmos chain upgraded or enabled PQ keys |
| Validator and native account signatures | ML-DSA-65 / FIPS 204; consensus key types explicitly enabled per chain | Existing chains remain classical unless operators opt in; production/mainnet adoption not verified here |
| Validator rotation | In-place consensus-key rotation preserves validator identity and voting power | Requires chain enablement, correct signing state and operator rollout; not automatic migration |
| IBC verification | Counterparty light clients must verify ML-DSA signatures | Current docs require CometBFT v0.40+ before the first ML-DSA validator; announcement also names v0.38.26 compatibility, so verify the exact client/backport rather than assuming every older version works |
| Cosmos EVM accounts | Validator signatures can use ML-DSA | Ordinary EVM user accounts still require eth_secp256k1; no automatic PQ account conversion |
| Remote signing | Current cosmos/kms README supports ML-DSA-65 consensus signing on the file backend; PKCS#11 and AWS KMS rows explicitly document Ed25519 | Do not extend file-backend ML-DSA support to every remote HSM/KMS path; release-announcement backend wording is broader than the repository’s capability table |
Cosmos entry checked October 12, 2026: release announcement, post-quantum key documentation, SDK upgrade notes, cosmos/kms capability table and TMKMS migration guide establish implementation support, not network-wide migration. The announcement’s two-thirds voting-power threshold concerns consensus, not every user account, IBC counterparty or application. Existing ledgers must enable the key type and rotate validators explicitly. For TMKMS cutover, stop the old signer completely, translate its last-signed state and verify resumed signing; never run both signers on the same validator key, including during rollback. Cosmos says TMKMS leaves its bug bounty program in Q1 2027; this is not evidence that every installation stops working then. Plan and record the change through the migration template.
Email and certificates
| Product/Service | ML-KEM support | ML-DSA support | Hybrid mode | Production status | Notes |
|---|---|---|---|---|---|
| Let’s Encrypt | None | None | None | None | No announced PQC certificate timeline. Watching IETF developments. |
| DigiCert | None (production) | ML-DSA test certificates | Testing/pilot | Pilot | Issuing PQ test certificates for interoperability testing. |
| Entrust | None (production) | ML-DSA/composite | Testing | Pilot | PQ-capable CA for testing. Composite certificate support. |
| Google Trust Services | None (production) | Planned (Merkle Tree Certificates) | None | Planned | Chrome+Google pursuing MTCs instead of standard X.509 PQ certs. |
| Cloudflare CA | Not applicable to certificate issuance | Merkle Tree Certificates planned | MTC/classical paths planned | Announced; not issuing yet | Cloudflare targets early 2027 for first MTCs and Chrome Quantum-resistant Root Store inclusion; standard MTC issuance is planned to be free. |
| AWS Private CA | None (production TLS) | ML-DSA | Yes | GA (signing) | Can issue certificates signed with ML-DSA for internal/private use. |
| S/MIME | Composite KEM drafts | Composite signatures drafts | Hybrid via composite | Drafts only | IETF composite certificate drafts in progress. No production support. |
Post-quantum certificates for the public WebPKI are not generally available. Cloudflare and Chrome completed a large MTC experiment, but MTC specifications, root-program policy and public issuance remain under development. Cloudflare is building a CA and targets early 2027; do not convert that target into GA status.
Operating systems
| OS | ML-KEM support | ML-DSA support | Hybrid TLS | Production status | Notes |
|---|---|---|---|---|---|
| Windows 11 (24H2+) | CNG APIs, Schannel TLS | CNG APIs | X25519MLKEM768 in Schannel | GA | Full platform PQC support via SymCrypt. |
| Windows Server 2025 | CNG APIs, Schannel TLS | CNG APIs | X25519MLKEM768 in Schannel | GA | Production server deployments ready. |
| macOS Tahoe (26) | Security framework | Limited | Safari PQ TLS | GA | System-wide PQ key agreement in Safari 26+. |
| iOS 26 | Security framework | Limited | Safari + system PQ TLS | GA | Follows macOS Tahoe. |
| Linux (kernel) | Via OpenSSL 3.5 / SymCrypt-OpenSSL | Via OpenSSL 3.5 | Application-level | GA | No kernel-level PQ, but userspace libraries support it. |
| Android 15+ | Via Conscrypt / BoringSSL | Limited | Chrome PQ TLS | GA (Chrome), partial (apps) | Chrome on Android uses PQ. Other apps depend on Conscrypt updates. |
| Ubuntu 26.10 | OpenSSL 4.0 ML-KEM | ML-DSA / SLH-DSA library support | Peer-dependent | Released; interim, not LTS | OpenSSH 10.5; ENGINE removed. Validate provider/HSM integration. Canonical release security notes, checked October 20. |
Validated software providers and container integration
Algorithm standards, implementation support, module validation, image integration and runtime enablement are separate evidence layers.
| Vendor / implementation | Module validation | PQC services | Product integration / rollout | Evidence and limitations |
|---|---|---|---|---|
| Chainguard FIPS Provider for OpenSSL, version 3.6.0, build 3.6.0-r4 | Active FIPS 140-3 Level 1, CMVP #5523, issued September 15, 2026; software provider, approved-mode conditions apply | ML-KEM (FIPS 203 KEM); ML-DSA (FIPS 204 signature); SLH-DSA (FIPS 205 stateless signature); policy documents X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024 hybrid services alongside classical services | Opt-in rollout from October 1, 2026, per Chainguard; eligible images expose NIST-CMVP-5523-optin, runtime selection via OPENSSL_CONF_INCLUDE=/etc/ssl-3.6.0 | Does not validate every Chainguard image, upstream OpenSSL or the whole application. Confirm image digest, exact provider build, approved service and operational environment; PQC is not universally enabled by default |
Entry checked October 1, 2026: NIST’s certificate establishes validation; the security policy defines its boundary and services. Chainguard’s September 24 announcement establishes the October 1 opt-in rollout schedule; current integration documentation establishes the image indicator and runtime selector. These are not evidence that all customer workloads have migrated. The X25519 hybrid service’s classical component is non-approved with no security claimed under the policy; do not describe every component as independently FIPS-approved. See the library comparison’s provider section for implementation context and use the vendor questionnaire to request deployment-specific evidence.
Hardware roots of trust and TPMs
Hardware support needs two separate status checks: whether software can use the post-quantum functions, and whether the target device is commercially available. A tested integration does not by itself make the hardware generally available or every feature production-ready.
| Product | Standards relationship | PQ algorithms | Software/integration status | Hardware availability | Evidence and limitations |
|---|---|---|---|---|---|
| SEALSQ QVault TPM | Implements the post-quantum algorithm identifiers and commands introduced in TPM 2.0 v1.85, according to SEALSQ and wolfSSL | ML-DSA-44/65/87; Hash-ML-DSA; ML-KEM-512/768/1024 | Supported and hardware-tested in wolfTPM. The integration includes QVault detection, device-specific SPI configuration, PQC examples, hardware benchmark support, build instructions, and the pqc_ctrl inspection/test utility. | Public pre-production / evaluation. Do not treat QVault as broadly shipping commercial hardware yet. | wolfSSL reports testing on physical QVault hardware and its firmware TPM environment. That establishes integration evidence, not universal feature maturity or comparative performance. |
| Lattice Semiconductor Mach-N2 MH21D — secure-control FPGA, 215K system logic cells | Lattice claims CNSA 2.0 compliance; this is a vendor claim, not independently verified certification or automatic system-level compliance | ML-KEM (KEM, FIPS 203); ML-DSA (signatures, FIPS 204); LMS / XMSS (stateful hash-based signatures, NIST SP 800-208) | Lattice announces field-updatable algorithms and anti-rollback protection. Parameter sets and integration workflows require implementation-level verification. | Orderable; samples shipped according to Lattice’s family announcement. MH21D-specific shipment volumes and high-volume/general production are not established by these sources. | The product table identifies PQC / crypto agility specifically for MH21D, not every Mach-N2 SKU. Independent interoperability and performance evidence is still missing. |
| Lattice Sentry 5.0 / MachXO5-55TDQ — FPGA PFR solution stack, not a TPM | Lattice states NIST SP 800-193 compliance and CNSA 2.0 alignment; not independent certification | ML-DSA signatures; LMS/XMSS stateful signature verification; ML-KEM key encapsulation | Reference design, firmware/IP tooling, SPDM/DICE attestation and AMI Tektagon integration, per Lattice | Demo boards/services available according to Lattice; production/shipping planned Q4 2026 | Evaluation evidence is not proven production deployment; do not transfer Mach-N2 MH21D specifications to this platform |
Lattice Sentry 5.0 capability and maturity split
Checked October 13, 2026: Lattice’s October 12 announcement describes classical/PQ firmware resilience and attestation. Its solution page separates available demos from planned Q4 production/shipping.
| Layer / function | Documented capability | Boundary |
|---|---|---|
| Silicon / platform | Sentry 5.0 targets MachXO5-NX MachXO5-55TDQ | Not every FPGA in the family or every older Sentry platform |
| Firmware authentication | Stack lists ML-DSA-44/65/87 signing/verification; demo uses ML-DSA-87 or ECDSA-384 for image authentication | Classical and PQ options coexist; no automatic fleet-wide replacement |
| Hash-based signatures | LMS/XMSS verification and bitstream boot authentication | Stateful schemes, not stateless SLH-DSA; provisioning and signer-state management still matter |
| Secure sessions / symmetric protection | Demo documents ML-KEM session setup; announcement lists AES-GCM | KEM establishes key material; AES-GCM is symmetric authenticated encryption. Exact session parameter set/handshake mapping not established here |
| Attestation / identity | SPDM-based attestation, DICE identity/measurement; AMI Tektagon PQC Resiliency integration | Protocol/identity capabilities do not independently prove every attestation signature is PQ or every deployment certified |
| Evaluation / reference design | Demo board, LFMXO5D-5P0-SENTRY-EVN, RTL/RISC-V firmware reference design; Radiant/Propel tools | Vendor says boards/services available; distributor stock/lead time not independently confirmed |
| Production / assurance | Solution page plans production/shipping for Q4 2026 | Actual production deployment and independent certification UNKNOWN; vendor-validated IP is not a regulatory certificate |
Lattice attributes protect/detect/recover firmware behavior to NIST SP 800-193 and describes CNSA 2.0 compliance/alignment. These remain vendor claims, not automatic system-level compliance. No independent “industry-first” claim is made here. Use the crypto-agility guide and vendor questionnaire to ask for exact configuration, update policy, revocation, anti-rollback and deployment evidence.
Mach-N2 evidence checked September 18, 2026: the product family table and public preliminary overview datasheet, Table 1.4 distinguish MH21D’s 215K cells from MH20’s 220K. The September 16 announcement supplies the algorithm, update, security and availability claims. The public LN2-MH-20-EVN evaluation board contains an MH20 device: it is not evidence of tested MH21D PQC support. Detailed configuration/security guides require support access.
An FPGA-based hardware root of trust is not a TPM; assess the actual interfaces, algorithm capabilities and deployment maturity separately. For procurement, use the PQC Vendor Questionnaire to request parameter sets, update/recovery procedures and test evidence, alongside an operational crypto-agility plan. LMS/XMSS require careful signing-state management to prevent one-time-key reuse (NIST SP 800-208); advertised anti-rollback does not by itself establish that an integration handles signing state safely. They are not stateless SLH-DSA, described in the PQC Algorithm Reference.
The TPM 2.0 v1.85 specification makes standardized identifiers and command interfaces available for these algorithms; it does not make existing TPMs post-quantum capable. Device firmware, hardware support, host-library integration, and deployment validation remain separate requirements.
Migration discovery and remediation tooling
These products help organizations find and organize cryptographic dependencies. They do not establish that an inventoried system is quantum safe, and vendor-described automation still requires scoped testing and rollback.
| Vendor / product | Inventory and CBOM | Application mapping | Remediation / orchestration | Maturity and evidence |
|---|---|---|---|---|
| DigiCert Quantum Central Essentials | Centralizes data from DigiCert ONE, scans, key vaults, uploaded data, SBOMs and CBOMs | Applies organization-defined policies and identifies violations across inventoried assets | Creates remediation tasks in Jira and tracks their progress; Trust Lifecycle Manager can initiate certificate lifecycle actions | GA since September 24, 2026. Essentials subscription available; licensing is asset-based and public dollar pricing is not published |
| QuintessenceLabs TSF Sentry | Vendor describes continuous network, file and host discovery plus third-party CBOM ingestion | Correlates cryptographic findings to applications and services, according to QuintessenceLabs | Vendor describes API-driven policy orchestration through existing automation such as Ansible, Puppet and CI/CD | Product preview material and September 23, 2026 launch announcement; no public list price or independent coverage/performance validation found |
| QuintessenceLabs PQC Readiness Assessment | Uses TSF Sentry discovery, inventory and risk analysis | Produces a scoped view of systems, applications, data and dependencies | Delivers a prioritized remediation roadmap and crypto-agility recommendations; it is an assessment service, not proof of completed remediation | Available as a vendor-led assessment; pricing is not public |
Quantum Central reached general availability after a July preview, but GA describes the product release—not the completeness of a customer’s inventory or migration. Its Jira workflow coordinates work; it does not prove that a cryptographic change was safely deployed. TSF Sentry is likewise best evaluated in three layers: discovery finds cryptographic assets, application mapping connects those findings to responsible systems and services, and remediation orchestration sends policy-driven actions through existing enterprise automation. QuintessenceLabs describes the third layer as automated remediation; treat that as a vendor claim until the exact supported changes, approvals, failure handling and rollback behavior are demonstrated in the buyer’s environment. Use the cryptographic inventory guide and CBOM template to define coverage and evidence before comparing automation claims.
Programming language runtimes
| Runtime | ML-KEM support | ML-DSA support | Hybrid TLS | Production status | Notes |
|---|---|---|---|---|---|
| Go 1.24+ | X25519MLKEM768 (default TLS) | Internal (Go 1.26), public API proposed Go 1.27 | Yes | GA (key exchange) | Default hybrid PQ in all Go TLS clients. |
| Java 27+ | ML-KEM (JEP 527, default TLS) | ML-DSA APIs (JEP 497, Java 24+) | Yes (Java 27+) | GA (Java 27) | Java 24 has ML-DSA APIs but no TLS integration. |
| .NET 10 | ML-KEM APIs + TLS | ML-DSA APIs | Yes | GA | Via SymCrypt on Windows, SymCrypt-OpenSSL on Linux. |
| Node.js 24.5+ | OpenSSL 3.5 TLS | ML-DSA via OpenSSL 3.5 | Yes | GA | Bundled OpenSSL 3.5. Also backported to Node 22.20+. |
| Cloudflare Workers Web Crypto | Native ML-KEM-768/1024; no ML-KEM-512 | Native ML-DSA-44/65/87 | Primitives do not configure TLS | Available behind flag / draft API | Requires webcrypto_modern_algorithms; not stable-default GA or complete application migration. |
| Python | Via OpenSSL bindings (cryptography lib) | Via OpenSSL bindings | Application-level | Partial | python-cryptography wraps OpenSSL but explicit PQC APIs are limited. |
| Rust | aws-lc-rs, ml-kem crate, rustls | aws-lc-rs (unstable), ml-dsa crate | rustls 0.23.27+ (default) | GA (key exchange) | Multiple options: RustCrypto (pure Rust) or aws-lc-rs (native). |
Workers entry checked October 6, 2026: Cloudflare’s runtime documentation and implementation announcement distinguish native primitives from draft API status and default enablement. Bundled JS/WASM is not required for the supported ML-KEM/ML-DSA operations, but protocol integration and other runtime support remain separate. See the Cloudflare setup guide.
Summary of PQC deployment status (August 2026)
What works today in production
- TLS key exchange is the most mature deployment. Major browsers and Cloudflare negotiate hybrid PQ key exchange by default. AWS supports it on documented service endpoints, while Google uses ML-KEM on internal network traffic and availability on customer-facing services varies.
- Messaging apps (iMessage, Signal) have full PQ protection including ratcheting.
- Cloud KMS capabilities vary by workflow. Google Cloud PQ signatures are GA, while its KEM operations and quantum-safe key import are Preview.
- Operating systems (Windows 11/Server 2025, macOS/iOS 26) have platform PQC APIs.
- Language runtimes (Go 1.24+, Java 27, .NET 10, Node.js 24.5+, Rust via rustls) support PQ TLS.
- Hardware roots of trust are emerging. wolfTPM can exercise ML-KEM and ML-DSA operations on pre-production QVault hardware, but QVault is not yet broadly shipping.
- Migration management tooling now includes GA workflow products such as DigiCert Quantum Central. Product GA does not make the inventoried systems quantum-safe.
What is still missing or incomplete
- Public Web PKI certificates: No generally available publicly trusted PQ issuance. Cloudflare’s MTC CA is announced for early 2027, not live.
- VPNs: Most VPN solutions lack native PQ support. WireGuard+Rosenpass is experimental.
- Email encryption (S/MIME, PGP): IETF composite certificate drafts not finalized.
- Azure Key Vault: No PQ key types.
- ML-DSA in TLS certificates: Browsers do not validate PQ signatures in certificates yet (except internal/private use).
- WhatsApp, Telegram: No PQ support announced.
Biggest gaps to watch
- Certificate ecosystem: Public visitor-facing TLS authentication remains classical today. Cloudflare’s MTC experiment and CA roadmap are material progress, but standards, root-program approval and issuance are still pending.
- VPN standards: IKEv2/IPsec PQ drafts need to reach RFC status for enterprise VPN deployments.
- Managed cloud services: Support must be tracked per capability. AWS documents production ML-KEM TLS on several services; Google Cloud has GA PQ signatures but Preview KEM and quantum-safe import; Azure Key Vault has no PQ key types.
Methodology
This matrix is compiled from:
- Official vendor documentation and release notes
- NIST FIPS standards (FIPS 203, 204, 205)
- Cloudflare’s PQC support documentation (updated June 2026)
- Vendor security blogs (Apple, Google, Microsoft, AWS, Signal)
- IETF draft tracker for in-progress standards
- Direct testing where possible (browser PQ verification via Cloudflare Radar)
Every entry requires a verifiable primary technical or service-release reference. When an official rollout announcement omits the algorithm, as with ordinary Google Meet, we retain UNKNOWN rather than infer it. Generic “quantum-safe” marketing alone does not establish a capability.
References
See the Sources section above for all primary references with direct links. Key documentation pages:
- Cloudflare PQC support documentation (updated June 2026)
- Apple Security Research: iMessage with PQ3 (February 2024)
- Signal: Signal Protocol and Post-Quantum Ratchets (SPQR) (June 2025)
- AWS: ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager (April 2025)
- Google Cloud: Future-proofing data integrity — Quantum-safe digital signatures in Cloud KMS (July 2026)
- Microsoft: Post-Quantum Cryptography APIs Now Generally Available on Microsoft Platforms (July 2025)
- NIST FIPS 203, FIPS 204, FIPS 205 (August 2024)
- Rosenpass — Post-quantum WireGuard key exchange
- Zoom: Post-quantum E2EE for Zoom Meetings (May 2024)
- wolfSSL: wolfTPM support for SEALSQ QVault (September 2026)
- Cloudflare Radar: Post-quantum tracker
Sources
Cloud providers
- AWS: ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager — AWS Security Blog (April 2025)
- AWS-LC FIPS 3.0: First cryptographic library to include ML-KEM in FIPS 140-3 validation — AWS Security Blog (December 2024)
- AWS Post-Quantum Cryptography migration plan — AWS Security Blog (December 2024)
- Google Cloud: Future-proofing data integrity — Quantum-safe digital signatures in Cloud KMS — Google Cloud Blog (July 2026)
- Google Cloud: Announcing quantum-safe digital signatures in Cloud KMS — Google Cloud Blog (February 2025)
- Google Cloud KMS release notes — Status history for PQ signatures, KEMs, and quantum-safe import
- Google Cloud: Quantum-safe key import — Preview import methods and software-only target restriction
- Microsoft: Post-Quantum Cryptography APIs Now Generally Available on Microsoft Platforms — Microsoft Tech Community (July 2025)
- Cloudflare: PQC support documentation — Cloudflare Developer Docs (updated June 2026)
- Cloudflare: Post-quantum authentication to origins is now supported — Cloudflare Blog (August 2026)
- Cloudflare: Post-quantum cryptography goes GA — Cloudflare Blog (2024)
- Cloudflare: Building a post-quantum CA with MTCs — experiment results and announced early-2027 MTC target
- Cloudflare: Post-quantum visibility for domains — negotiated-group telemetry and dated adoption measurements
Browsers
- Cloudflare PQC support docs — browser compatibility matrix — Chrome 131+, Firefox 132+, Safari 26+, Edge 131+
Messaging apps
- Apple Security Research: iMessage with PQ3 — PQ3 protocol announcement (February 2024)
- Signal: The PQXDH Key Agreement Protocol — Signal PQXDH specification (September 2023)
- Signal: Signal Protocol and Post-Quantum Ratchets (SPQR) — SPQR ratchet announcement (June 2025)
- Zoom: Post-quantum E2EE for Zoom Workplace — Zoom press release (May 2024)
Operating systems and runtimes
- Microsoft: Post-Quantum Cryptography APIs Now Generally Available — Windows 11/Server 2025 (July 2025)
- Go 1.24: X25519MLKEM768 enabled by default — Go issue tracker, shipped February 2025
- Microsoft: Post-Quantum Cryptography in .NET — .NET 10 ML-KEM/ML-DSA support
Standards
- NIST FIPS 203: ML-KEM — Module-Lattice-Based Key-Encapsulation Mechanism (August 2024)
- NIST FIPS 204: ML-DSA — Module-Lattice-Based Digital Signature Standard (August 2024)
- NIST FIPS 205: SLH-DSA — Stateless Hash-Based Digital Signature Standard (August 2024)
- Cloudflare Radar: Post-quantum encryption tracker — Live PQ adoption metrics
Hardware roots of trust
- wolfSSL and SEALSQ: wolfTPM support for QVault — Physical-device testing, QVault detection, SPI configuration, examples, benchmarks, and
pqc_ctrl(September 3, 2026) - wolfSSL: Post-quantum support for the SEALSQ QVault TPM — Algorithm parameter sets, build flags, and public pre-production/evaluation status (August 26, 2026)
Migration tooling
- QuintessenceLabs: TSF Sentry and PQC Readiness Assessment announcement — product positioning and September 2026 announcement
- QuintessenceLabs: TSF Sentry product preview — discovery, CBOM ingestion, application correlation and vendor-described automation integrations
- QuintessenceLabs: PQC Readiness Assessment — assessment scope and deliverables
- DigiCert Quantum Central release notes — September 24, 2026 GA status, Essentials plan and workflow capabilities
- DigiCert Quantum Central licensing — subscription and cryptographic-asset licensing model
- Tezos: Introducing Quantumnet — public experimental testnet status and protocol-level experiments
- Octez protocol U025 documentation — Ushuaia
tz5feature flag and mainnet-disabled status
FAQ
Which cloud provider has the best PQC support?
AWS leads with FIPS-validated PQC (AWS-LC) and production ML-KEM TLS across multiple services. Google Cloud has GA ML-DSA and SLH-DSA signing, plus Preview KEM and quantum-safe key import workflows in Cloud KMS. Azure has strong platform support but lags in managed key services. Compare specific workflows and maturity levels instead of assigning one status to an entire provider.
Is my browser already using post-quantum encryption?
If you are running Chrome 131+, Edge 131+, Firefox 132+, Safari 26+, Brave 1.73.86+, or Opera 116+, your browser negotiates hybrid post-quantum key exchange (X25519MLKEM768) with any server that supports it. You can verify this using Cloudflare Radar’s browser support check at radar.cloudflare.com/post-quantum.
Why do browsers support PQ key exchange but not PQ signatures?
Post-quantum key exchange adds about 1 KB to the TLS handshake, which is acceptable. Post-quantum signatures (ML-DSA) are 2.4 to 4.6 KB each, and TLS certificate chains require multiple signatures. This would add 10-20 KB to every TLS handshake, significantly impacting performance. Chrome is pursuing Merkle Tree Certificates as a more efficient alternative.
Is WhatsApp post-quantum safe?
No. WhatsApp uses the Signal Protocol for end-to-end encryption but has not deployed PQXDH or any post-quantum ratchet. Messages encrypted with WhatsApp today are vulnerable to Harvest Now, Decrypt Later attacks if a sufficiently powerful quantum computer is built in the future.
What about VPNs? Is my VPN traffic quantum-safe?
Most likely not. The only production PQ VPN solution is Cloudflare WARP (Zero Trust), which uses X25519MLKEM768. WireGuard with Rosenpass is available but experimental. Commercial VPN providers (NordVPN, ExpressVPN, etc.) have not confirmed ML-KEM deployment despite some “quantum-safe” marketing claims.
How often is this page updated?
We aim to update this matrix monthly or whenever a major vendor ships new PQC capabilities. The “verifiedDate” in the page metadata indicates the last full verification pass. If you notice outdated information, please reach out.
What is the difference between Level 2 and Level 3 for messaging?
Level 2 (Signal pre-SPQR) means post-quantum cryptography protects only the initial key exchange. If session keys are compromised later, there is no post-quantum recovery. Level 3 (iMessage PQ3, Signal with SPQR) means post-quantum cryptography also protects the ongoing ratchet, so the protocol can recover quantum security even after a key compromise.