Hybrid Composite Certificates

Choosing between hybrid and composite certificates

Hybrid means running a post-quantum algorithm alongside a classical one so that the connection remains secure if either fails. It applies separately to key exchange, where it is already deployed by default, and to certificates, where several competing approaches exist and none has yet been standardised for public trust.

Hybrid key exchange and hybrid certificates are different things

The word hybrid is used for two unrelated mechanisms, and vendor material rarely distinguishes them.

Hybrid key exchange combines a post-quantum key encapsulation mechanism with a classical key agreement, producing a shared secret derived from both. The X25519MLKEM768 group is the deployed example, enabled by default in mainstream browsers and in OpenSSL 3.5. It is settled, widely supported and requires no ecosystem coordination.

Hybrid certificates concern how a certificate carries more than one algorithm for authentication. This is unsettled. Several approaches are in circulation, standards work continues in the IETF, and no post-quantum roots have been accepted into browser trust stores.

An organisation can therefore have fully deployed hybrid key exchange while having made no decision at all about certificates, which is the position most are in.

Why hybrid rather than post-quantum alone

Three arguments support running both algorithms during transition.

The post-quantum algorithms are newer than the classical ones and have less accumulated cryptanalysis. Candidates were broken during the standardisation process, Rainbow and SIKE both in 2022, and NIST selected HQC as a backup key encapsulation mechanism specifically because structured lattice assumptions could conceivably fail. Hybrid means a break in either algorithm does not compromise the connection.

Compliance frameworks may require the classical algorithm. Some regimes have not yet approved post-quantum algorithms in isolation, and hybrid satisfies both requirements simultaneously.

Interoperability is preserved. A hybrid construction can fall back where the far end does not support the post-quantum component, which matters in estates with mixed capability.

National positions differ on whether this is a requirement or a preference. France's ANSSI and Germany's BSI treat hybrid deployment as the required approach during transition, and the EU roadmap emphasises standardised hybrid solutions. US guidance permits hybrid without mandating it. The NCSC recommends ML-KEM-768 and ML-DSA-65 for most typical use cases.

The certificate approaches compared

The trade-off is consistent across the table. Approaches that guarantee post-quantum protection break legacy verifiers, and approaches that preserve legacy compatibility cannot guarantee post-quantum protection.

Size is the constraint that decides most cases

Post-quantum authentication is expensive in bytes, and hybrid approaches pay for both algorithms.

An ML-DSA-65 signature is 3,309 bytes against 64 for ECDSA P-256, with a public key of 1,952 bytes against 64. A certificate chain carries several of each, and a composite certificate carries the classical values in addition. In practice this can grow a chain by an order of magnitude, which affects TLS handshake size, embedded device storage, smartcard capacity and any protocol with a fixed message limit.

This is why the industry sequence has been key exchange first and authentication later, and why alternative architectures are being explored. Google proposed Merkle Tree Certificates in February 2026, reducing post-quantum authentication data from roughly 14,700 bytes to as little as 736 by signing batches of certificates rather than individual ones and distributing trust through compact inclusion proofs. The cryptographic primitives are unchanged; what differs is how signatures are applied and delivered.

Where each approach fits today

For internal and private hierarchies, where the organisation controls every verifier, composite or post-quantum-only certificates are viable now. Private certificate authorities can issue ML-DSA certificates today precisely because they do not depend on browser trust stores, and the constraint is whether the relying applications can validate them.

For estates with mixed verifier capability, dual or chameleon approaches keep legacy systems working. The cost is management overhead in the dual case, and weaker assurance in the chameleon case, since protection applies only where the verifier looks for the alternative signature.

For public TLS, no approach is available. The CA/Browser Forum Baseline Requirements have not been amended to permit ML-DSA, no post-quantum roots have been accepted into the Mozilla, Apple, Microsoft or Chrome trust stores, and the X.509 encoding work continues in the IETF's LAMPS working group. Pilot programmes exist, including Microsoft's for ML-DSA roots, but they are explicitly not for production use.

For firmware and code signing, the question is different again. LMS and XMSS under NIST SP 800-208 are approved, supported in hardware and appropriate where verification must be cheap, which is covered in our comparison of the NIST post-quantum algorithms.

What to decide now and what to defer

Enable hybrid key exchange wherever both ends support it. This is settled, widely deployed, and addresses harvest now, decrypt later exposure that cannot be remediated afterwards. In many estates it requires only upgrading to OpenSSL 3.5 or an equivalent runtime.

Begin private hierarchy work. Standing up a parallel post-quantum hierarchy is the long-lead activity, and the approach chosen for internal certificates does not depend on the public trust decision. Where AD CS is the issuing platform, note that ML-DSA support offers no in-place migration, so a parallel hierarchy is required regardless.

Defer the public certificate decision. Planning a public TLS approach now means designing against standards that have not settled, and the architecture may change materially if Merkle Tree Certificates or a similar approach gains adoption.

Test with real chain sizes. The failures encountered are interoperability failures rather than cryptographic ones: fixed buffer sizes, fragmentation behaviour, appliances rejecting oversized chains and credential storage limits. These are discoverable cheaply in a test environment and expensively in production.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services, nuclear and transport.

We design certificate hierarchies against the constraints that actually bind, including chain size, verifier capability and credential storage, through our PKI design and build practice, and establish the current position through our PKI health check. Where a parallel post-quantum hierarchy is required, we deliver it alongside the certificate lifecycle management capability needed to move endpoints onto it at scale.

For what this costs in handshake size and latency, see what post-quantum algorithms cost in size and latency.

‍