Standards, support, and what you observed
A published algorithm standard, a protocol specification, a vendor feature, and a successful connection are four different facts. Keep them separate when evaluating a product or describing readiness.
Reference checked 25 September 2026. Publication dates and status below are from the linked primary sources. Follow their errata and later revisions before implementing or procuring a system.
Algorithm standards
| Standard | Role | Published status | Scope |
|---|---|---|---|
| FIPS 203 · ML-KEM | Key encapsulation / shared-secret establishment | Final, 13 August 2024 | Defines ML-KEM-512, -768, and -1024. It does not independently define an HTTPS deployment. |
| FIPS 204 · ML-DSA | Digital signatures | Final, 13 August 2024 | Defines a lattice-based signature scheme; it is not a TLS key exchange. |
| FIPS 205 · SLH-DSA | Digital signatures | Final, 13 August 2024 | Defines stateless hash-based signatures with different size/performance tradeoffs. |
| SP 800-208 · LMS / XMSS families | Stateful hash-based signatures | Final, October 2020 | Requires careful signing-state management; cloning or restoring signer state needs specialist controls. |
Names from pre-standard experiments, such as Kyber draft groups, are not interchangeable evidence for final ML-KEM deployments. Record the exact identifier and version rather than relabeling an old result.
Protocol integration
RFC 10024, published August 2026 as an IETF Proposed Standard, defines three hybrid TLS 1.3 groups. It is the published successor to the earlier ECDHE/ML-KEM draft. An RFC's existence does not tell you which products or configurations have shipped it.
| TLS group | Composition | Identifier |
|---|---|---|
X25519MLKEM768 | X25519 + ML-KEM-768 | 0x11ec |
SecP256r1MLKEM768 | P-256 + ML-KEM-768 | 0x11eb |
SecP384r1MLKEM1024 | P-384 + ML-KEM-1024 | 0x11ed |
CheckPQC recognizes these names and identifiers when they are reported as the selected group on a valid TLS 1.3 connection. Unknown identifiers remain unknown. The methodology explains what is measured and why a TLS cipher suite or client offer is insufficient.
SSH and other protocols use their own mechanisms and identifiers. Follow the OpenSSH guide for SSH; do not apply a TLS group name to a VPN, messaging protocol, or file format without its product's documentation.
Four levels of evidence
- Algorithm standardized: there is a published cryptographic construction and parameter set.
- Protocol specified: a protocol defines how peers use that construction and identify it.
- Product documented: a vendor identifies a supported release, configuration, and constraints.
- Deployment observed: your tested connection or verified artifact provides dated evidence for that exact scope.
Record each independently in the worksheet. “Uses a NIST-standard algorithm” is also distinct from a claim that a particular cryptographic module is validated. For a validation requirement, check the exact module certificate, version, operating environment, and approved mode in the NIST CMVP record.
Migration guidance and timelines
NIST IR 8547 is an Initial Public Draft published 12 November 2024 on the cited page. It discusses NIST's expected transition approach. Do not present a draft target as a universal legal deadline or a prediction of when a quantum computer will exist.
The UK NCSC guidance, published 20 March 2025, gives planning milestones for UK migration: discovery and an initial plan by 2028, priority migrations by 2031, and completion by 2035. These are that guidance's milestones, with its stated audience and exceptions; other jurisdictions, regulators, and contracts can have different requirements.
Use the applicable policy for your organization and record its source, scope, owner, and review date. Prioritize sensitive long-lived data and difficult-to-replace dependencies while supported products become available. The NCCoE migration project provides discovery and interoperability resources.
Use the reference in a real assessment
Start with a concrete check, retain its exact algorithm and limits, then investigate authentication, storage and keys, and vendor dependencies. A single green test is valuable evidence for one component; a readiness plan connects the rest.
Documentation reviewed 25 September 2026. This reference summarizes technical standards and guidance, not a legal or compliance determination.