MITRE Rated Eight Enterprise Technologies on Post-Quantum Readiness. Key Exchange Is in General Release in Five, Signatures in Two.

October 15, 2026 – The Post-Quantum Cryptography Coalition published MITRE’s PQC Capability Development Report, in which MITRE rated the post-quantum readiness of eight categories of enterprise technology. The report is dated September 2026. MITRE built every rating from public evidence collected in July 2026.

MITRE found post-quantum key establishment in general release in five of the six categories where it applies: web browsers, web servers, VPN and network encryption, PKI and certificate authority (CA) management, and cloud service connectivity. It placed no category on the top rung of its scale, which requires a FIPS 140-3 validated module. It also found no evidence of a commercially available post-quantum hardware TPM.

Under Executive Order 14412, US federal agencies have until 31 December 2030 to move high-value assets and high-impact systems outside national security systems to post-quantum key establishment, and until 31 December 2031 to move them to post-quantum signatures. In July, MITRE found post-quantum signatures in general release in two of its eight categories, code signing and PKI/CA management, and validated in none.

MITRE is a US not-for-profit that operates federally funded research and development centers for the US government. It launched the coalition in 2023 with founding members including IBM Quantum, Microsoft, PQShield and SandboxAQ. Participation is free. The coalition said the report was developed with MITRE’s internal PQC research team to inform migration planning, technology refresh cycles and long-term investment decisions.

How MITRE Rated the Eight Technologies

MITRE rated each technology on two separate tracks and marked a track N/A where the technology does not rely on that guarantee. Under confidentiality development, MITRE tracked post-quantum mechanisms that keep data secret, chiefly key establishment. Under authentication development, it tracked post-quantum digital signatures, which verify identity and integrity. MITRE wrote that it kept the two apart because some technologies rely on only one, and because a technology can progress faster on one than on the other.

Its scale has six development levels, plus N/A:

• N/A: the technology does not rely significantly on that type of security guarantee.
• Blocked: no standards exist to support PQC for it.
• Enabled: the necessary standards exist to support PQC for that technology and guarantee.
• Components Available: standards-based PQC support exists in specialized, technology-specific components.
• Preliminary Integration: a limited, experimental or preliminary release supports PQC.
• Integration: a general release, fully available to the public, supports PQC.
• Validated Integration: a general release supports PQC through a FIPS 140-3 validated module certified for those post-quantum functions.

NIST had already validated software modules covering ML-KEM before MITRE’s July cut-off, among them the Go Cryptographic Module (certificate #5247, 27 April 2026) and AWS-LC 3 (certificate #5298, 3 June 2026). To award the top rung, MITRE needed evidence that a general-release product in the category performs its post-quantum functions through such a module.

For each technology, MITRE recorded the highest level it observed in its sources. MITRE wrote that it searched vendor blogs, product documentation, press releases, release notes and standards documents without starting from a pre-selected list of vendors or products. It did not separately track hybrid against pure post-quantum deployments, or specific key sizes.

MITRE stated that the report is not an independent evaluation of product security and that it relied on claims made by vendors and other technology sources. It also cautioned against reading the report as a list of the most significant products or vendors in any area. The peer review and commentary period took place in August and September 2026.

Ratings for Key Establishment and Signatures

Source: MITRE, PQC Capability Development Report, September 2026. Evidence collected July 2026.

Post-Quantum Key Establishment in General Release

In browsers, MITRE found hybrid key establishment widely available, mainly X25519MLKEM768, which combines classical X25519 with ML-KEM. Several major browsers enable it by default. MITRE found no mainstream browser support for the ML-KEM-1024 parameter set, or for pure post-quantum TLS key establishment.

Several major web servers support the same hybrid exchange, according to MITRE, which cited NGINX, F5, Microsoft and IBM. For VPNs, it found ML-KEM or hybrid ML-KEM in IKEv2/IPsec and TLS-based products from vendors including Palo Alto Networks, Fortinet, Cisco and OpenVPN. MITRE cited RFC 9242 and RFC 9370 as the standards behind quantum-resistant IKEv2 VPNs. Both extend IKEv2 so that a handshake can include additional key exchanges.

In cloud service connectivity, MITRE found hybrid TLS with ML-KEM at Cloudflare, AWS, Istio and IBM Cloud. It described cloud providers as among the furthest along. MITRE rated key establishment below general release in one category, volume encryption. It assessed only volume-encryption products that rely on asymmetric cryptography. In those products, MITRE found post-quantum support only in components. Some of them depend on TPMs whose post-quantum versions are planned but not yet commercially available.

Post-Quantum Signature Support by Category

In code signing, MITRE found ML-DSA support on several platforms, some of which also offer hybrid signing. Its sources included Cisco, Red Hat Enterprise Linux 10.1, Android 17, AWS Private CA and Microsoft Active Directory Certificate Services. MITRE described these products as deployable now and progressing toward validation, without naming the products it meant.

In the same section, MITRE cautioned that hybrid signatures do not by themselves establish secure hybrid authentication. It cited the stripping and downgrade risks discussed in RFC 9955, the IETF’s July 2026 informational document on hybrid signatures.

In PKI/CA management, MITRE found ML-DSA certificate issuance in private and enterprise CA products from Keyfactor, Microsoft and DigiCert, SLH-DSA issuance at Keyfactor and DigiCert, and support for ML-KEM keys in some certificate lifecycle operations. MITRE rated no other category at general release for both key establishment and signatures. Public certificate authorities do not yet issue these certificates; DigiCert states in its documentation that its CertCentral service does not issue public CA certificates with post-quantum algorithms.

MITRE rated the software that verifies those certificates lower. It found no browser support for validating X.509 certificates signed with post-quantum algorithms. Browser vendors had published designs and run limited experiments, including with Merkle Tree Certificates. For web servers, MITRE found post-quantum authentication only through custom builds, often based on Open Quantum Safe. In VPNs, it found no integrated post-quantum endpoint authentication.

MITRE rated cloud service connectivity at Preliminary Integration for signatures because the most advanced deployment it found was experimental: ML-DSA signatures on long-lived TLS connections.

Platform Assurance and Hardware TPMs

MITRE rated platform assurance, the hardware roots of trust behind trusted computing, at Components Available for signatures. It found standardized support for all ML-DSA parameter sets in firmware-based TPMs, implemented in software. One source MITRE cited was wolfSSL’s firmware TPM. In March 2026, the Trusted Computing Group announced version 1.85 of its TPM 2.0 Library Specification, which adds ML-KEM and ML-DSA.

As of July 2026, MITRE found no evidence of commercially available post-quantum hardware TPMs, nor of PQC integrated into mainstream trusted boot, measured boot or remote attestation workflows. Some hardware TPMs already protect their own firmware updates with post-quantum cryptography; MITRE cited Infineon’s version, which the company introduced in 2022. MITRE also found post-quantum support for firmware authentication, device identity and attestation in other hardware roots of trust.

My Analysis

In Executive Order 14412, the White House set separate deadlines for key establishment and signatures, a year apart. MITRE also rated the two separately. For key establishment, US agencies can already buy general-release products in five of the six categories where it applies. For signatures, MITRE found general releases in only two of eight categories, none of them backed by a validated module. I expect agency plans to slip first on signatures and on validated modules. Key establishment still takes upgrades, configuration and testing across every system an agency runs, but in most categories MITRE found at least one product to deploy.

Why Vendors Shipped Key Exchange First

Encrypted traffic recorded today becomes readable once a cryptographically relevant quantum computer exists, unless post-quantum key establishment protected it when it was sent. Every month an organization delays, adversaries can record more of its traffic for harvest now, decrypt later attacks, and the organization cannot protect copies they already hold by migrating afterwards. A forger, by contrast, needs a quantum computer to recover a signing key before forging with it. Because nobody can attack an authentication completed today after the fact, vendors put signatures second. The exceptions are signatures that must stay trusted for years, on firmware, code and root certificates, which is the Trust Now, Forge Later problem.

A browser vendor and a website operator can also adopt hybrid ML-KEM without anyone else’s cooperation. A browser offers X25519MLKEM768, and a server with ML-KEM support accepts it. Servers without that support fall back to a classical exchange. Moving signatures takes the whole chain: certificate authorities, the hardware security modules that store CA keys, browser root programs and every client that checks a signature.

On my reading of MITRE’s ratings, certificate issuance is ahead of certificate verification. Private CA products from Keyfactor, Microsoft and DigiCert issue ML-DSA certificates in general release, while MITRE rated browsers, web servers and VPNs at Components Available for signatures. Some vendors already ship the verification building blocks in general release. In a February 2026 note on RHEL 10.1, one of MITRE’s code-signing sources, Red Hat describes ML-DSA signatures and TLS certificates as generally available and fully supported in the release’s OpenSSL, GnuTLS and NSS libraries. Red Hat also notes that no public CA offers post-quantum certificates yet, so organizations can use that support only inside private PKI, between systems they control.

Browser vendors face a size problem as well. An ML-DSA-44 signature is 2,420 bytes (FIPS 204) against roughly 70 bytes for an ECDSA P-256 signature as TLS encodes it, and a handshake includes several signatures and public keys. Chrome’s engineers are testing Merkle Tree Certificates to reduce the number of signatures a handshake needs.

MITRE Rated Each Category by Its Most Advanced Vendor

MITRE gave each technology the highest level it observed in any source. From the ratings, a CISO learns whether a capability is on the market at all. The CISO still has to check the products in the estate, because MITRE could rate a whole category at Integration on the evidence of one vendor’s general release.

A buyer also learns from a general release only that a version with the feature exists. An organization learns whether it runs that version, with the feature switched on, only from its own cryptographic inventory. In the public version of its audit of 24 agencies (GAO-27-108740), released on 6 October from work completed in September 2025, the US Government Accountability Office found that one agency had fully addressed GAO’s criterion for a complete inventory of priority systems.

MITRE also did not track hybrid against pure deployments or parameter sets. Operators of US national security systems need ML-KEM-1024 under CNSA 2.0, but MITRE found no mainstream browser support for it. Those operators cannot treat the browsers’ Integration rating as evidence of CNSA 2.0 readiness.

Limits of Rating Vendors From Public Evidence

MITRE worked outside-in, from public evidence only. At Applied Quantum we are automating the same approach for a government client: the system scores a vendor’s products and services on more than 100 public signals before anyone looks inside a product. At that first stage, the system uses only public sources. We use its score to decide which products to examine first. To sign off a product against a federal deadline, an assessor needs answers that vendors have not published.

A vendor that ships ML-KEM without announcing it looks the same, from outside, as a vendor that has not started. MITRE could rate only what it observed, so it would miss an undocumented implementation above a category’s rating, including one at the top rung. An assessor should record missing public evidence as unknown, not as absent. An agency checking its own products has to ask each silent vendor directly.

From outside, I also cannot tell how a vendor built what it announced. A vendor can accurately announce hybrid signing while shipping a construction exposed to the stripping attacks RFC 9955 describes. An outside reader cannot tell from the announcement which construction shipped.

To place a product on MITRE’s top rung, an assessor needs a chain of linked facts: a general-release product; the cryptographic module inside it, with its version number; the FIPS 140-3 certificate issued for that version; the post-quantum functions the certificate covers; and the configuration its security policy requires. NIST publishes the certificate side of that chain. Certificates #5247 and #5298 list each module, its vendor and its approved algorithms, including ML-KEM key generation, encapsulation and decapsulation. NIST’s certificate for AWS-LC 3 applies only when the module is installed, initialized and configured as its security policy specifies. Unless a vendor publishes which module version performs its post-quantum exchange, and in which configuration, an outside assessor cannot complete the chain. When a product page says “FIPS 140-3 validated”, I read it as “a cryptographic module associated with this product has a certificate” until the vendor names the module, the certificate number and the configuration in which its post-quantum functions run.

FIPS 140-3 Validation for Post-Quantum Modules

MITRE set its top rung at FIPS 140-3 validation because it wanted evidence that an algorithm was implemented in a controlled way, beyond evidence that the algorithm is strong. It also noted that some organizations will not adopt a capability without validation. US federal agencies are among those organizations: in FIPS 140-3, NIST states that the standard applies to federal agencies that use cryptography-based security systems to protect sensitive information.

In its post-quantum cryptography FAQ, NIST says it will accept two hybrid cases in FIPS 140 validation: key establishment that combines a post-quantum scheme with a NIST-approved one, and dual signatures in which at least one component is NIST-approved. An agency can therefore run a hybrid deployment in approved mode on the strength of an approved classical component, before the post-quantum half is validated. MITRE asked for more at its top rung: post-quantum functions performed inside a module validated for them.

In Executive Order 14412, the White House gave NIST 180 days, to 19 December 2026, to revise the Cryptographic Module Validation Program’s processes to accelerate validations. It also directed rulemaking to amend the Federal Acquisition Regulation so that covered contractors must comply with NIST’s FIPS, including those that incorporate PQC, by 31 December 2030. OMB did not mention FIPS 140-3 or the validation program in M-26-15, its implementing memorandum, a gap I pointed out when OMB issued it in June.

MITRE described post-quantum code-signing products as progressing toward validation. A federal buyer needs both a suitable product release and an applicable validated module. Vendors can work on the two in parallel, so a buyer cannot infer one from the other. For signatures on the web, in VPNs and in hardware roots of trust, MITRE found no general release in July. When those releases arrive, I expect federal buyers’ 31 December 2031 dates to depend on validation as much as on the releases themselves.

Hardware TPMs and the 2026–2027 Refresh

In M-26-15, OMB tells agencies to build PQC upgrades into hardware refresh schedules and to move device attestation, “often rooted in a Trusted Platform Module (TPM),” to post-quantum algorithms. MITRE found no commercially available post-quantum hardware TPM in July. On 14 October, SEALSQ said it will demonstrate its QVault TPM, which generates and keeps ML-DSA and ML-KEM keys on-chip, at electronica in November. The company described FIPS 140-3 and TCG certification as a path its product line is on.

Until a post-quantum hardware TPM ships, an agency refreshing laptops or servers buys TPMs whose keys, signing and attestation run on classical algorithms, even where post-quantum cryptography already protects the TPM’s own firmware updates. On a five-year refresh cycle, machines bought this year will still be in service on 31 December 2030 and into 2031, the year the signature migration is due. Before signing, I would ask the TPM and platform vendors whether the exact TPM and firmware in the contract can gain ML-DSA attestation through an update, and what the replacement path is if not. MITRE found the same TPM dependency in volume encryption.

What to Ask Vendors Before the Signature Deadline

Agencies owe their M-26-15 migration plans to OMB and the Office of the National Cyber Director by 22 October, 120 days after the memorandum. I would plan key establishment and signatures as two workstreams, each with its own supplier list. Key establishment is mostly deployment work on products that already support hybrid ML-KEM: upgrades, configuration, interoperability testing and fallback policy. For signatures, agencies depend more on releases vendors have not shipped, so more of the work is procurement, alongside trust distribution and verification policy.

For every product on the signature path, from CAs, HSMs and code-signing systems to VPN gateways, web servers and TPM-based attestation, I would get four answers in writing:

• the general-availability releases that will generate and verify ML-DSA or SLH-DSA signatures, with their dates;
• which cryptographic module, in which version and configuration, will perform those operations;
• that module’s FIPS 140-3 certificate number, or its status in NIST’s validation queue;
• what the product does when post-quantum verification fails, or when it receives a hybrid signature with one component removed.

I would build the signature timeline from the vendors’ committed dates and treat any product without one as a risk to the 2031 deadline. Buyers outside the US federal government face the same suppliers on similar dates. In their coordinated implementation roadmap, EU member states aim to migrate high-risk use cases by the end of 2030. The UK National Cyber Security Centre recommends completing the highest-priority migration activities by 2031. My global PQC deadlines tracker covers other jurisdictions. My guide to PQC vendor governance covers the wider vendor program.

MITRE wrote that it will assess other capability areas in future editions as relevance and evidence permit. I would also like MITRE to repeat these eight ratings with evidence from 2027, so agencies can see whether vendors are shipping post-quantum signatures and validated modules fast enough for 31 December 2031.

From the author