The term on this page
- PQCpost-quantum cryptography
- algorithms that run on ordinary computers and are believed to resist quantum attack
Also mentioned
ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry (new tab), ML-DSAML-DSAModule-Lattice-based Digital Signature AlgorithmModule-Lattice-Based Digital Signature Algorithm, the NIST-standardized post-quantum signature scheme derived from CRYSTALS-Dilithium and specified in FIPS 204.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab), PKIPKIpublic key infrastructurePublic Key Infrastructure, the framework of certificate authorities, certificates, and policies that binds public keys to identities and enables trust in TLS, code signing, and email.Read the full entry (new tab) are defined in the glossary.
Read this first
On 15 October 2026, the Post-Quantum Cryptography Coalition published MITRE's enterprise PQC capability assessment across eight technology areas. Five areas reach Integration for confidentiality, but only code signing and PKI or certificate authority management reach Integration for authentication. No area reaches Validated Integration, which requires a FIPS 140-3 validated module. The report is a planning baseline built from public evidence, not a product approval list or an independent security evaluation.
The PQC Capability Development Report changes an abstract migration question into a capability map. Instead of asking whether post-quantum cryptography exists somewhere in the market, MITRE separately scores confidentiality and authentication in web browsers, web servers, VPN and network encryption, platform assurance, code signing, PKI and certificate authority management, volume encryption, and cloud service connectivity.
That separation matters. Key establishment can move to ML-KEM while certificates, device identity, software signatures, trust anchors, recovery and validation remain classical. Calling the first successful hybrid handshake a completed migration hides the part of the system that decides whom to trust.
The maturity scale stops short of validated deployment
MITRE reviewed public evidence through July 2026 and used seven levels: Not Applicable, Blocked, Enabled, Components Available, Preliminary Integration, Integration and Validated Integration. Integration means production-ready or generally available capability was found. Validated Integration adds a harder condition: use of PQC in a FIPS 140-3 validated cryptographic module.
| Enterprise capability | Confidentiality | Authentication |
|---|---|---|
| Web browsers | Integration | Components Available |
| Web servers | Integration | Components Available |
| VPN and network encryption | Integration | Components Available |
| Platform assurance | Not Applicable | Components Available |
| Code signing | Not Applicable | Integration |
| PKI and CA management | Integration | Integration |
| Volume encryption | Components Available | Components Available |
| Cloud service connectivity | Integration | Preliminary Integration |
Five of the six areas where confidentiality applies reach Integration: browsers, servers, VPN and network encryption, PKI and CA management, and cloud connectivity. Volume encryption remains at Components Available. Authentication reaches Integration in only two of eight areas: code signing and PKI or CA management. Cloud authentication is at Preliminary Integration, while the other five applicable areas are at Components Available.
The asymmetry matches the migration sequence many teams see in practice. Hybrid key establishment is already available in important network paths, so recorded traffic can receive protection before a complete post-quantum identity stack exists. Signature profiles, certificate processing, hardware roots of trust, attestation and cross-vendor verification have more interfaces to align.
Authentication is the operational gap
The report found no commercially available hardware product with PQC support in the Trusted Platform Module capability it reviewed as of July 2026. That does not mean platform assurance is permanently blocked. Software implementations and specifications provide components, but the hardware trust boundary that many fleets depend on has not reached general integration in the evidence set.
Code signing and PKI show more progress, yet an Integration rating does not collapse their acceptance work. A signing system has to generate, protect, rotate, back up and recover keys; issue and validate artifacts; survive larger signatures; and work across build systems, HSMs, transparency services, bootloaders and rollback versions. A CA can issue a post-quantum certificate while one relying party still rejects its key format or algorithm identifier.
A category rating is not your vendor's rating
MITRE assigns each category the highest level supported by public evidence for any product it found. The report does not say that every browser, VPN, HSM, CA or cloud service has that capability. It also does not independently evaluate implementation security. Map the exact product, version, configuration and cryptographic module in your estate before converting a category finding into a deployment claim.
No category reached Validated Integration
None of the sixteen confidentiality and authentication tracks in the report reached Validated Integration. That is a useful procurement boundary. Standardized algorithms and a generally available feature can establish functional readiness, but they do not prove that the module carrying the operation has completed the validation expected by a regulated deployment.
FIPS 140-3 validation also has a precise scope. It applies to a named module version and its approved configurations, not to every product that embeds the library or advertises the same algorithm. Migration programmes should capture the certificate number, module version, operational environment and security policy when validation is required. A roadmap that records only ML-KEM or ML-DSA support cannot answer that question.
What migration teams should do now
- Split every inventory row into confidentiality and authentication paths. Record key establishment, signatures, certificates, attestation, trust anchors and recovery separately.
- Map the report's category-level signal to the exact product and version you operate. Ask vendors for release notes, supported configurations and interoperability evidence.
- For regulated workloads, require the FIPS 140-3 module certificate and security policy rather than accepting a claim that a product uses a standardized algorithm.
- Continue hybrid key-establishment work where it reduces harvest-now-decrypt-later exposure, but keep authentication as an explicit parallel workstream.
- Test certificate issuance, validation, key import, backup, restore, rotation, revocation, signing and rollback across every ownership boundary.
- Treat hardware roots of trust and constrained devices as schedule risks until the actual target hardware passes performance, memory and lifecycle tests.
The updated PQC migration roadmap now adds capability maturity as a second sequencing axis beside data lifetime and policy deadlines. The cryptographic inventory provides the product and version map needed to apply the report honestly. Teams that need evidence for a release gate should turn those rows into conformance tests and an implementation audit, not a vendor questionnaire alone.
The report is a baseline, not a finish line
The coalition says the assessment will be updated as the market changes. That is important because the evidence cutoff was July 2026, three months before publication, and product capabilities can move between releases. Public absence is not proof that a private beta or unpublished implementation does not exist, while a public announcement is not proof that the implementation is safe or interoperable.
The practical conclusion is narrower and more useful than a market-ready headline. Post-quantum key establishment has crossed into integration in several enterprise network categories. Authentication is less mature and validated modules remain the missing top tier. Plan with that gap visible, verify the exact build in front of you, and keep functional integration, interoperability, implementation assurance and formal validation as separate gates.
References
- Post-Quantum Cryptography Coalition, PQC Capability Development Report, published 15 October 2026.
- MITRE, PQC Capability Development Report PDF, September 2026 report with public-evidence findings through July 2026.
- NIST Cryptographic Module Validation Program, validated modules, the official module validation registry and scope guidance.
- PostQuantum.com analysis of the MITRE capability report, published 17 October 2026, a secondary summary of the capability gaps and limitations.
Where this goes next