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 verified: August 17, 2026. We update this page as vendors ship new PQC capabilities. If you spot an inaccuracy or a missing entry, contact us.
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
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 for all edge TLS | ML-DSA for Authenticated Origin Pulls and Custom Origin Trust Store; ML-DSA-44 DNSSEC validation on 1.1.1.1 | Yes (all edge connections) | Mixed GA / planned | PQ TLS and origin authentication are GA. Recursive ML-DSA-44 DNSSEC validation is in production; authoritative signing and Registrar DS support remain planned. |
| 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) | Planned (Merkle Tree Certificates) | Yes | GA | Chrome 131 (Nov 2024) |
| 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. |
| 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.
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. |
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.
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. |
| 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 web PKI are not production-ready. The key blocker is certificate size: ML-DSA signatures are 2.4-4.6 KB, which significantly increases TLS handshake sizes. Chrome’s Merkle Tree Certificates approach aims to solve this.
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. |
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. |
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.
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+. |
| 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). |
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.
What is still missing or incomplete
- Public Web PKI certificates: No production PQ certificates from public CAs.
- 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: Until CAs issue PQ certificates and browsers validate them, TLS authentication remains classical. Key exchange is hybrid-protected, authentication is not.
- 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)
We do not include vendors that only mention “quantum-safe” in marketing materials without documenting specific algorithm support. Every entry requires a verifiable technical reference.
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)
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)
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.