The move to post-quantum public-key infrastructure is becoming more concrete. On October 14, the IETF LAMPS working group published revision 23 of Composite ML-KEM for use in X.509 Public Key Infrastructure. The document defines composite key-encapsulation mechanisms that combine ML-KEM with established algorithms such as RSA-OAEP, ECDH, X25519, and X448.
The draft is in the RFC Editor queue, but it is not yet a published RFC. That distinction matters. It is mature enough to inform architecture, lab work, and inventory design, while implementers should continue to track changes and avoid presenting the draft as a final standard.
Composite cryptography creates a compound dependency
A composite construction is intended to preserve security if at least one component remains secure, subject to the construction’s assumptions and correct implementation. Operationally, however, two algorithms do not create two isolated controls. They create one compound object whose security and availability depend on encoding, key generation, certificate profiles, private-key protection, implementation behavior, and relying-party support.
An inventory should therefore capture more than “ML-KEM supported.” For each affected certificate or service, teams need to know:
- the composite algorithm identifier and exact parameter combination;
- certificate profile, issuer, subject, purpose, validity, and renewal process;
- where each private-key component is generated, stored, backed up, and used;
- the libraries, appliances, HSMs, agents, and services that parse or operate on it;
- the relying parties and trust stores that must accept the certificate;
- protocol and message formats that transport the composite public key or ciphertext;
- observed interoperability results and failure behavior; and
- the source, date, confidence, owner, and next review for every claim.
Without those relationships, “supports composite ML-KEM” is a product statement rather than migration evidence.
Certificate issuance is only the beginning
A certificate authority may be able to issue a new profile before applications can consume it safely. Parsers may reject unfamiliar identifiers. Middleboxes may impose size limits. Hardware modules may protect one component but not the other. Monitoring and certificate-lifecycle systems may display incomplete metadata. Recovery procedures may assume a single key object.
That makes PKI migration a population problem. Teams should identify every issuer, enrollment path, template, certificate class, key-protection boundary, relying application, and renewal workflow. They should then test representative paths rather than extrapolating from one successful certificate.
A useful readiness statement names the tested population: for example, a specific issuing hierarchy, client and server versions, trust configuration, composite profile, and transaction type. It should not imply universal compatibility.
Hybrid assurance needs explicit evidence
Composite designs can help organizations introduce post-quantum protection while retaining a traditional component. They can also complicate assurance. Validation status, approved modes, key-generation procedures, and operational boundaries may differ between components. A traditional algorithm’s certificate or module validation does not automatically validate the complete composite implementation.
Teams should attach validation and assurance evidence to the exact module, version, operating environment, algorithm, and function it covers. Any gap between a validated primitive and an unvalidated composite integration should remain visible. Procurement language should distinguish implemented support, enabled configuration, successful interoperability testing, and independently validated operation.
What organizations should do next
First, add composite and hybrid structures to the cryptographic data model now. A single free-text algorithm field cannot represent the components, combiner, parameters, and dependencies accurately.
Second, map X.509 populations to business services and relying parties. Migration priority should reflect data lifetime, service criticality, renewal cadence, external dependencies, and recovery difficulty.
Third, build bounded interoperability tests. Include issuance, parsing, negotiation, key use, revocation, renewal, rollback, monitoring, and failure cases. Record exact versions and configurations.
Fourth, keep standards maturity explicit. Track this Internet-Draft as a proposed standard in the RFC Editor queue, not as a finished RFC, and define a review trigger for publication or material revision.
Finally, preserve evidence from pilots in the production inventory. Test results that remain in a lab notebook cannot support later risk decisions or audit questions.
How Vista Platform helps
Vista Platform is a self-hosted infrastructure inventory and DCIM platform with cryptographic posture built in. It serves as a cryptographic system of record through the operating loop of discovery, canonical inventory, evaluation, action, and proof. Teams can connect certificates, algorithms, assets, owners, relying services, evidence, exceptions, and remediation rather than treating each finding as an isolated list item.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted rather than indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Explore Vista’s cryptographic inventory, post-quantum migration, and CBOM and compliance resources.
Where uncertainty remains
The draft may still change before RFC publication, and implementations will mature at different speeds. Composite constructions also do not eliminate implementation defects, key compromise, weak operational controls, or availability failures. The immediate value is architectural: it gives organizations a concrete reason to model compound cryptographic objects and their dependencies before deployment pressure arrives.
Source
- Composite ML-KEM for use in X.509 Public Key Infrastructure, revision 23, IETF LAMPS Working Group, October 14, 2026.