Hybrid Post-Quantum Certificates: Why Your First PQC Migration Isn't Really Post-Quantum

NIST's 2024 Standards in 2026 Production Reality

On 13 August 2024 NIST published three Federal Information Processing Standards that collapsed a decade of competition into a deployable cryptographic stack: FIPS 203 (ML-KEM) for key encapsulation, derived from CRYSTALS-Kyber; FIPS 204 (ML-DSA) for digital signatures, derived from CRYSTALS-Dilithium; and FIPS 205 (SLH-DSA), the stateless hash-based signature scheme formerly known as SPHINCS+. A fourth standard, FIPS 206 (FN-DSA, ex-Falcon), is still in draft as of Q2 2026.

The marketing claim heard at every vendor briefing since is that the post-quantum transition has begun. The technical reality is narrower and more interesting: what is deployed in production in 2026 is a hybrid post-quantum certificate and hybrid key exchange story, not a pure PQC story, and the two should not be confused.

The most measurable PQC deployment today lives in the TLS 1.3 key exchange. Chrome enabled X25519MLKEM768 (codepoint 0x11EC, defined in draft-kwiatkowski-tls-ecdhe-mlkem) by default for desktop clients starting with version 124 in April 2024 and now reaches over 30% of TLS 1.3 handshakes globally according to Cloudflare's Radar telemetry from early 2026. Firefox shipped the same group in version 132. Cloudflare's edge has supported hybrid KEMs since 2022, first with X25519Kyber768Draft00, then migrated to the standardised X25519MLKEM768 when AWS-LC and BoringSSL switched in the second half of 2024.

AWS-LC 1.30 ships ML-KEM behind the FIPS module boundary; BoringSSL exposes it as part of the default group list. OpenSSL 3.5, released in April 2025, added native ML-KEM and ML-DSA support without provider plug-ins; before 3.5, production teams relied on the oqs-provider from the Open Quantum Safe project, which is fine for experimentation and unsafe for FIPS-bound workloads.

What is not deployed is just as important. PQC signatures inside TLS handshakes remain rare. The IETF draft-ietf-tls-mldsa is still in working group last call as of May 2026, and no major browser negotiates ML-DSA for the server certificate by default. Public root CAs have issued exactly zero ML-DSA roots that chain into the Mozilla, Apple, Microsoft, or Chrome trust stores. The CA/Browser Forum's Server Certificate Working Group has a PQC ballot tracker but no merged baseline requirement permitting ML-DSA in publicly trusted certificates.

Concretely: when a Chrome user loads a website over X25519MLKEM768, the symmetric session key is post-quantum-secure, but the server certificate that authenticated the handshake is still signed with ECDSA P-256 or RSA-2048. That asymmetry is the defining feature of 2026 PQC deployment and the entire subject of this article. For the broader context, see our practical guide to post-quantum cryptography.

What "Hybrid" Actually Means

The word hybrid is used loosely in vendor decks and precisely in three IETF documents. The distinction matters because the three variants have different wire formats, different failure modes, and different paths to standardisation.

The first variant is the concatenated hybrid KEM defined for TLS 1.3 in RFC 9794 (published December 2024) and instantiated as X25519MLKEM768. The shared secret is the concatenation of the classical ECDH output and the ML-KEM ciphertext-derived secret, fed through HKDF-Extract. If either component is broken — quantum break of X25519 or classical cryptanalytic break of ML-KEM — the combined secret remains secure under the indifferentiability of the KDF.

The ClientHello carries a single 1216-byte key_share entry (32 bytes X25519 + 1184 bytes ML-KEM-768 public key); the ServerHello returns 1120 bytes (32 + 1088). This is the cheapest, most operationally mature hybrid: only the TLS stack needs to know about it, and certificate chains are untouched.

The second variant is the composite signature, specified in draft-ietf-lamps-pq-composite-sigs and draft-ietf-lamps-pq-composite-kem. A composite certificate carries a single subject public key whose AlgorithmIdentifier is a new OID (for example id-MLDSA65-ECDSA-P256-SHA512) and whose key value is the concatenation of an ML-DSA-65 public key and an ECDSA P-256 public key. The signature is also a concatenation: verifying party must verify both components, and either failing aborts the verification.

This preserves the existing X.509 structure described in our X.509 standard explainer, but it doubles signature size (an ML-DSA-65 signature is 3309 bytes; an ECDSA P-256 signature is 64-72 bytes; the composite is roughly 3380 bytes). LAMPS reached working group last call on composite signatures in March 2026 with a target RFC in Q4 2026.

The third variant is the chained certificate or parallel chain approach, exemplified by Cloudflare's Merkle-Tree-Ladder experiments and by the older draft-truskovsky-lamps-pq-hybrid-x509 from 2018. Here the relying party processes two full certificate chains in parallel — one classical, one PQC — either delivered as non-critical X.509 extensions inside a single certificate or as two distinct chains negotiated in the TLS handshake.

This is the least intrusive to roots but the heaviest on the wire, and it has the worst story for legacy verifiers that strictly parse unknown critical extensions per RFC 5280 Section 4.2. Understanding why a relying party would reject one and accept the other requires understanding how certificate chains and trust are built and verified.

• Concatenated KEM (RFC 9794): TLS-only, doubles key_share size, requires no PKI change. Already in production at Cloudflare, Google, Amazon, Apple iCloud Private Relay. Failure mode: TLS stack mismatch causing fallback to classical curve.
• Composite signatures (draft-ietf-lamps-pq-composite): new OIDs in the certificate itself, dual-verify mandatory. Cleanest semantics for certificate-bound PQC. Failure mode: any relying party that does not know the composite OID rejects the chain outright.
• Chained / parallel certificates: two full chains delivered together. Most backwards-compatible if extensions are marked non-critical, but largest wire footprint and ambiguous trust semantics. Used in private PKIs and experimental deployments.

The Three Places Hybrid Certs Break

Hybrid deployments fail in production for boring reasons. Three classes of failure dominate every PQC pilot's incident log, and none of them is about the lattice cryptography itself.

The first is library version skew. Until OpenSSL 3.5, ML-KEM and ML-DSA lived in the oqs-provider module from liboqs 0.10+, which in turn depended on the OQS fork of OpenSSL. BoringSSL implements ML-KEM in its core but exposes a different API surface, and its certificate parser rejects unknown signature OIDs that older versions of OpenSSL silently accept. AWS-LC, derived from BoringSSL, ships ML-KEM as a FIPS-validated primitive in the AWS-LC FIPS 2024 module but disables it outside the FIPS boundary unless explicitly enabled at build time. BouncyCastle Java added ML-KEM in 1.78 and ML-DSA in 1.79, but composite signature OIDs require 1.80 and a non-default JcaCompositeSignerInfoGeneratorBuilder.

A pilot that compiles fine on the developer laptop with OpenSSL 3.5 will silently downgrade in a container running an Ubuntu 22.04 base image with OpenSSL 3.0.2 and no provider configured.

There is no protocol-level error: the client offers the hybrid group, the server does not understand it, and TLS negotiates a classical group as if nothing happened. Detection requires either an enforcing client or active monitoring of the negotiated cipher suite per endpoint.

The second is HSM and FIPS 140-3 module lag. FIPS 203, 204, and 205 algorithms cannot be claimed in a FIPS-validated module unless that module has been re-validated by an accredited Cryptographic and Security Testing (CST) laboratory and entered the NIST CMVP queue. As of May 2026, the CMVP queue holds over 200 ML-KEM/ML-DSA module submissions with a documented backlog of 14 to 22 months.

A few vendors hold module-in-process certificates; only a handful (Utimaco SecurityServer Se Gen2 firmware 5.5, Thales Luna 7 firmware 7.8.0, Entrust nShield 13.6, AWS KMS internal HSM) have a fully validated module covering at least ML-DSA-65. For organisations that operate under CNSA 2.0, PCI DSS 4.0, eIDAS QSCD, or any FedRAMP High envelope, a non-FIPS PQC implementation is not deployable.

The implication is that the root and policy CAs in a high-assurance hardware security module cannot move to ML-DSA until the HSM firmware is on the CMVP validated list, and that constraint typically pushes the root-CA migration into 2027 or 2028 regardless of the rest of the stack.

The third is Certificate Transparency log size limits. RFC 6962-bis and RFC 9162 do not impose a hard size cap on logged certificates, but operational logs do: Google's Argon and Xenon shards reject pre-certificates over 16 KB; Cloudflare's Nimbus rejects over 8 KB; the Sabre log caps at 8 KB; the Wyvern log accepts up to 32 KB but with a documented rate-limit penalty.

An ML-DSA-87 certificate with two SANs, a CRL distribution point, and a SCT extension sits at roughly 5.5 KB; a composite ML-DSA-65 + ECDSA P-256 certificate with the same metadata is around 4.2 KB; an SLH-DSA-SHA2-128s certificate is around 8.8 KB.

Composite chains where every intermediate carries an ML-DSA signature can push the SCT-bearing leaf plus chain past most logs' practical inclusion thresholds. The Certificate Transparency ecosystem was designed for ECDSA-sized artefacts, and its size assumptions surface as silent inclusion failures rather than verifier errors, which is the worst possible failure mode for a transparency layer.

A defensible operational response to these three failure classes has five components, executed in parallel rather than in sequence.

• Pin library versions across the stack. Treat the cryptographic library as a controlled component. Record exact versions of OpenSSL, BoringSSL, AWS-LC, BouncyCastle, mbedTLS, and any provider module in your CBOM. Block builds that do not match the approved version manifest.
• Stage HSM firmware upgrades in parallel. Schedule HSM firmware upgrades on the path to a CMVP-validated ML-DSA build at least six months before any policy CA is expected to sign ML-DSA. Coordinate with vendor module-in-process status, not marketing claims.
• Pre-flight CT log inclusion. Submit synthetic ML-DSA and composite pre-certificates to every log you rely on before the first real issuance. Measure inclusion success per log and per signature algorithm, not just SCT count.
• Instrument TLS negotiation on every endpoint. Export the negotiated named_group and signature_scheme as a Prometheus metric per TLS session. Without this telemetry, silent fallback to classical groups will go unnoticed for quarters.
• Inventory composite-aware verifiers. Catalogue every relying party that parses your certificates: SIEM agents, log forwarders, mobile SDKs, embedded clients. Any verifier that does not recognise composite OIDs becomes a denial-of-service risk the moment composite leaves the lab.

Real-World Migration Order

A working PQC migration plan is sequenced. Hybrid TLS termination first, internal CAs second, code signing third, S/MIME fourth, public roots last. The sequence is not arbitrary; it follows where the cryptographic risk is highest, where the operational change is cheapest, and where the relying-party population is most controlled.

TLS termination moves first because the relying parties are browsers and modern HTTP clients with monthly release cadences, the key exchange is renegotiated every session, and the hybrid wire format is already standardised in RFC 9794.

An organisation can deploy X25519MLKEM768 behind a single load balancer configuration change and roll back without re-issuing any certificate. The 2025 deployments at Cloudflare, Google Frontend, and Apple iCloud Private Relay demonstrate that even at internet scale the additional handshake overhead is on the order of 1.5 ms median and 7 ms tail, with no measurable change in connection success rate.

Internal CAs move second because the relying-party population is finite, identifiable, and under the same operational control as the issuing CA. Internal services that consume cryptographic primitives via a known set of libraries can be inventoried, upgraded, and tested.

Composite ML-DSA-65 + ECDSA P-256 issuance from internal policy CAs is the cleanest way to introduce PQC signatures into production without breaking older microservices, provided the workload uses libraries that recognise composite OIDs. This is where most organisations will book their first quantifiable PQC win in 2026 and 2027.

Code signing comes third because the verifiers (Windows Authenticode, macOS Gatekeeper, Linux package managers, container registry attestations) are slow-moving, but the threat horizon is long: a signed binary distributed in 2026 may execute for 15 years. CNSA 2.0 mandates ML-DSA for software and firmware signing by 2025, with full enforcement by 2030.

Microsoft Authenticode added ML-DSA support in Windows 11 24H2 via the SignTool 10.0.26100 release; the corresponding code-signing CAs in the Microsoft Trusted Root Program will accept ML-DSA OIDs from CA/Browser Forum Code Signing WG ballot SC-77 onwards.

The relevant trade-off is signature size at scale — a typical Windows driver catalogue with 50,000 entries each carrying an ML-DSA-65 signature grows by roughly 160 MB compared to ECDSA. The deeper context lives in our reference on public and private key management.

S/MIME moves fourth because the relying-party population is the most fragmented and the slowest to upgrade: Outlook desktop, Outlook Mobile, Apple Mail, Thunderbird, mobile mail apps embedded in MDM containers, and 20-year-old enterprise mail gateways that strip unknown OIDs. The CA/Browser Forum's S/MIME Baseline Requirements 1.0.4 do not yet permit ML-DSA. Until they do, S/MIME will run dual chains in the few organisations that pilot it, and most will wait for the 2027 BR revision.

Public root CAs move last, and they should. The rotation of a publicly trusted root is a multi-year exercise constrained by the slowest device in the relying-party population — embedded systems with hard-coded trust stores from 2018, point-of-sale terminals, set-top boxes, industrial controllers.

Replacing the signature algorithm on a root before the trust store population can verify it is an exercise in self-inflicted outages.

The correct posture is crypto-agile root design: maintain classical RSA-4096 and ECDSA P-384 roots until the relying-party fleet supports ML-DSA verification, and stand up parallel ML-DSA roots in a cross-signed configuration to seed the next-generation trust store, rather than rotating the existing one. The full argument for this approach lives in our reference on crypto-agility and the post-quantum transition.

Measurement: How to Track Real PQC Progress

The phrase PQC-ready is meaningless without metrics attached. A defensible PQC programme reports four numbers, refreshed monthly, with the data pipelines that produce them under the same change-control as the production cryptographic stack.

The first is the percentage of TLS sessions negotiated with a PQC KEM. This is measured per endpoint and per relying-party population. Cloudflare's edge reports it natively; for self-operated load balancers it requires parsing the negotiated named_group from TLS access logs or from eBPF probes on the kernel TLS path.

A realistic 2026 target for a public-facing service is 25-40% PQC KEM coverage, driven by Chrome and Firefox client share. Below 10% indicates a stack-level problem, usually OpenSSL or BoringSSL version skew. Above 50% is currently only seen on services that actively prioritise hybrid groups in their server preference order.

The second is the percentage of issued certificates whose signature algorithm is ML-DSA or a composite that includes ML-DSA. This is measured from the issuing CA database, segmented by certificate template, business unit, and lifetime. A pilot that issues 5,000 composite certificates against a baseline of 2 million classical certificates is at 0.25%, not at PQC-ready. Useful internal targets follow the migration sequence above: internal mTLS at 50% composite by end of 2026, code-signing at 100% composite by mid-2027, public TLS leaf at 0% until the CA/Browser Forum baseline permits it.

The third is the library audit result: the number of distinct cryptographic library versions in production, the percentage that support ML-KEM, the percentage that support ML-DSA, and the percentage covered by FIPS 140-3 validation when that is a regulatory requirement. This is the metric that links directly to the cryptographic bill of materials. An organisation that cannot answer which build of OpenSSL is running on each of our 12,000 hosts is not in a position to claim PQC progress regardless of how many pilot certificates it has issued.

The fourth is the HSM and KMS PQC support inventory: model, firmware version, CMVP validation status, supported ML-DSA parameter sets, supported ML-KEM parameter sets, planned upgrade path, and expected end-of-support date.

The decisive question this metric answers is whether the highest-assurance keys in the organisation — root CA keys, policy CA keys, code-signing keys — can be issued as ML-DSA within the FIPS module boundary or whether the module has to be replaced first. Almost every large enterprise will find at least one HSM model on this list that requires hardware replacement, and the lead time on hardware replacement is the binding constraint on the PQC schedule for that organisation.

Five Common Myths

Five claims recur in vendor briefings, conference talks, and internal architecture reviews. Each contains a kernel of truth and each is dangerous to repeat without qualification.

• “PQC certs are 10x bigger.” Partly true. An ML-DSA-87 signature is 4627 bytes versus 64-72 bytes for ECDSA P-256, a 60-70x ratio. But certificate size depends on the signature and public key together, and most metadata is shared. A pure ML-DSA-65 leaf is around 5.5 KB versus 1.4 KB classical, closer to 4x. SLH-DSA signatures range from 7856 bytes (128s) to 49856 bytes (256f) and can hit 10x in the worst case.
• “We’re done because we use X25519MLKEM768.” False. The KEM is post-quantum-secure; the server certificate is still signed with ECDSA or RSA, both Shor-vulnerable. A harvest-now-decrypt-later adversary cannot decrypt the symmetric session traffic, but the long-term signing keys remain a target. Authentication PQC is a separate, harder migration.
• “Hybrid is fine forever.” False. Hybrid is a transitional construction that buys backwards compatibility and defence-in-depth during a phase where ML-KEM and ML-DSA have under a decade of public cryptanalysis. As confidence in the lattice constructions accumulates and as relying-party populations migrate, hybrid imposes a permanent size and performance penalty that the industry will not carry indefinitely. Expect a pure-PQC RFC track for TLS by 2030.
• “Roots need rotation now.” False, and dangerous. Rotating a root CA before the relying-party fleet can verify the new signature algorithm produces outages, not security. What roots need is crypto-agile design: defined succession plans, parallel ML-DSA roots cross-signed for trust-store seeding, and operational rehearsal of the rotation. The decisive control on root migration is trust-store distribution, not key generation.
• “PQC migration = library upgrade.” False. Library upgrade is the easiest 5% of the work. The hard 95% is the inventory (CBOM), the verifier-side compatibility matrix, the HSM and KMS roadmap, the policy CA reconfiguration, the certificate-template redesign, the monitoring pipeline, the relying-party communication, and the rollback plan for every step.

Where Evertrust Fits

The honest framing of 2026 PQC deployment is that hybrid certificates and hybrid key exchange are the right answer for the next three to five years, and they are not the same thing as post-quantum. Treating them as if they were produces two failure modes in equal measure: complacency, when teams declare victory after deploying X25519MLKEM768 on a single load balancer; and paralysis, when teams refuse to move on hybrid because it is not pure PQC.

The correct posture is operational: instrument the negotiation, sequence the migration, monitor the inventory, and design the roots for agility, not for rotation.

That posture requires a certificate management platform that issues composite ML-DSA + ECDSA leaves alongside classical leaves from the same policy CA, exports CycloneDX 1.6 cryptographic-asset records for every certificate and every key, integrates with HSMs across CMVP validation states, and surfaces the negotiated TLS group and signature algorithm as first-class telemetry.

Evertrust is built for exactly this transition: hybrid issuance from policy CAs that already understand composite OIDs, automated discovery of classical certificates eligible for hybrid re-issuance, HSM integrations across the current CMVP queue, and continuous reporting that maps to the four PQC metrics described above.

The PQC roadmap is not a future product feature; it is a current operational programme. To see how it plugs in, explore Evertrust PKI and certificate management.