Hybrid post-quantum cryptography is often summarized as “use the old algorithm and the new algorithm together.” The September 23 revision of the X-Wing Internet-Draft shows why that shorthand is not enough for engineering or governance. X-Wing defines a concrete key encapsulation mechanism that combines X25519 with ML-KEM-768 and specifies how their results are combined.
The document is an individual Internet-Draft with no formal IETF standing, not a finalized standard. That caveat matters. So does the draft’s central design goal: reduce the ecosystem burden created by too many similar hybrid choices. For security leaders, the operational lesson is that “hybrid” is not a complete inventory value. A hybrid construction is a distinct cryptographic dependency with an exact specification, revision, component set, combiner, implementation, and protocol context.
Two components do not automatically make one safe construction
X-Wing pairs the traditional X25519 key exchange with the NIST-standardized ML-KEM-768 post-quantum KEM and derives a fixed-length shared secret. The draft makes specific choices about hashing, encoding, component behavior, and validation. Those details are the construction. A product that happens to run X25519 and ML-KEM-768 somewhere in the same handshake is not necessarily implementing X-Wing.
This distinction matters during procurement and assurance. A questionnaire that asks only whether a product “supports hybrid PQC” may group together incompatible or differently analyzed mechanisms. A software bill of materials that lists two algorithm names but omits the combiner and consuming protocol leaves reviewers unable to tell what protection is actually delivered.
It also matters during remediation. If a weakness, implementation bug, or interoperability change affects the composition rather than either primitive in isolation, teams need to find the X-Wing dependency itself. Searching separately for X25519 and ML-KEM-768 may produce a large, misleading set of assets and still miss the relationship that requires action.
Version is part of the security record
The latest document is revision 11. It incorporates the final ML-KEM-768 rather than the earlier Kyber draft lineage discussed in comparisons, and it includes implementation guidance and test material. The draft can still change or be replaced before any later standardization outcome.
That makes revision tracking essential. An inventory should distinguish an experimental implementation tied to a particular draft from a future standardized identifier, and it should distinguish both from vendor-specific hybrids with similar component names. Useful fields include:
- construction name and specification revision;
- component algorithms and parameter sets;
- library, package, provider, and exact version;
- protocol and application using the construction;
- where keys are generated, stored, and consumed;
- interoperability peers and negotiated identifiers;
- test-vector or conformance evidence; and
- owner, approval status, exception, and replacement plan.
These fields turn an algorithm claim into an actionable dependency record. They also prevent an easy audit error: reporting that an asset has moved to a recognized construction when it actually uses an earlier draft or an unreviewed local combination.
Do not confuse key establishment with authentication
The draft explicitly says X-Wing is not an authenticated KEM and is not a universal replacement for every Diffie-Hellman use. It is intended as a general-purpose building block, including potential use with Hybrid Public Key Encryption, but the surrounding protocol still has to supply the properties the application needs.
For migration planning, that means teams should record the security purpose separately from the algorithm. Key establishment, entity authentication, document signing, code signing, and data-at-rest protection have different dependencies and transition paths. Deploying a hybrid KEM can improve the confidentiality story while leaving certificate signatures or other authentication mechanisms quantum-vulnerable.
What organizations should do next
Start by tightening terminology in architecture standards and supplier questions. Ask for the named construction, specification revision, negotiated code point or identifier, implementation version, supported protocols, and evidence of interoperability. Avoid accepting “PQC-ready” or “hybrid” as sufficient detail.
Next, model composition in the cryptographic inventory. The record should show that a service uses X-Wing, that X-Wing comprises X25519 and ML-KEM-768 in a specified construction, and that a particular library implements it for a particular protocol. This is exactly the kind of relationship a useful cryptographic bill of materials must preserve.
Then establish lifecycle gates for experimental cryptography. Decide where draft-based implementations are permitted, who watches revision changes, what tests must be repeated after an update, and how a deployment will move to a stable profile. Keep production rollout proportional to the maturity of both the construction and the surrounding protocol specification.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Through discovery, canonical inventory, evaluation, action, and proof, it helps teams link observed cryptography to assets, software, policies, owners, and remediation work.
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. It can help organizations preserve the component and dependency context needed to govern hybrid constructions and produce evidence over time. Vista tracks and governs post-quantum migration; it does not generate PQC keys or execute every migration. It is not a vulnerability scanner, selected-asset Active Scan is not indiscriminate network scanning, and an undiscovered dependency is not proof of absence.
See Vista’s post-quantum transition overview for a broader migration perspective.
Where uncertainty remains
X-Wing revision 11 is current work, not a final standard or a blanket recommendation. Its future identifiers, adoption, and protocol integrations may evolve. The defensible action today is not to label every X25519-plus-ML-KEM deployment “X-Wing.” It is to record precisely what is implemented, where it is used, which evidence supports the claim, and which event will trigger reassessment.
Source
- X-Wing: general-purpose hybrid post-quantum KEM, draft-connolly-cfrg-xwing-kem-11, Internet-Draft by Deirdre Connolly, Peter Schwabe, and Bas Westerbaan, September 23, 2026.