Migrating a PKI to post-quantum without breaking a single existing client: that is the real problem. Two families of solutions compete for the job — the hybrid certificate (two certificates in parallel) and the composite certificate (two algorithms in a single certificate). They look alike, they get confused everywhere, and yet they do not answer the same need. This guide settles the question.
The problem: two cryptographic worlds that must coexist
Post-quantum cryptography is not arriving in a greenfield. It is arriving in information systems full of servers, network equipment, business applications, IoT devices and middleware — some of it a decade old — all of which, today, understand only RSA and ECDSA.
Switching overnight to a post-quantum algorithm like ML-DSA (the signature standard that came out of the NIST process) would sever trust with that entire installed base: a client that does not know the algorithm can neither validate the certificate's signature nor build the chain of trust. Conversely, staying on classical cryptography means accepting the "harvest now, decrypt later" risk and falling behind a regulatory deadline that keeps getting closer.
Hence the question most CIOs and CISOs preparing their roadmap are asking today: how do you make the two worlds coexist during the transition? Two broad families of answers exist, and the fuzzy vocabulary surrounding them ("hybrid", "dual", "composite", "parallel") keeps the confusion alive. Let's pin down the definitions.
Family 1 — The hybrid certificate (a.k.a. "parallel" or "dual")
Definition
In the hybrid approach — also called parallel or dual — you issue two independent certificates (or two separate key pairs) for the same identity:
- a classical certificate, signed with RSA or ECDSA, exactly as today;
- a post-quantum certificate, carrying for instance an ML-DSA key and signature.
The mental model is simple: picture a server holding two access badges for the same door. The first badge is in the format every current reader can process; the second is in the new format, which only upgraded readers recognize. Each client uses the certificate it understands and ignores the other. The two chains of trust live side by side without ever touching.
The advantages
The headline benefit is full backward compatibility. A classical client is not even aware the post-quantum certificate exists: nothing changes for it, and no update is required on its side. That is the property that makes hybrid deployable right now, across a heterogeneous estate, without a coordinated client migration campaign. The transition can be gradual: you modernize clients one at a time, and each one switches to the post-quantum chain when it is ready.
The cost — and it is operational, not cryptographic
The flip side fits in one sentence: twice as many certificates to manage. Two issuances, two renewals, two inventory entries, two expiry dates to watch, two potential revocations — for every identity.
That doubling would be almost anecdotal in yesterday's world of one- or two-year certificates. It is anything but in the era of short lifecycles: with validity periods dropping to 100 days, then 47 days, every additional certificate multiplies the renewal operations per year. An estate of 5,000 identities running dual means 10,000 live certificates, each renewed several times a year. Without lifecycle automation (discovery, inventory, renewal, deployment), the operational strain becomes very real — and it is that strain, far more than the cryptography, that makes hybrid projects fail.
Family 2 — The composite certificate
Definition
The composite approach tackles the problem from the other end: instead of two certificates, you issue a single X.509 certificate that carries:
- a composite public key: both public keys (classical + post-quantum) encapsulated together in a single field;
- a composite signature: both signatures, produced by both algorithms, cryptographically bound together.
The verification rule is strict: the verifier must validate both signatures to accept the certificate. That conjunction is precisely what gives composite its security value: the construction remains secure as long as at least one of the two algorithms holds. If ML-DSA were broken tomorrow, the ECDSA component still stands; if a quantum computer breaks ECDSA the day after, the ML-DSA component still stands. You are not betting on one algorithm — you are betting that they will not both fall at the same time.
This mechanism is being standardized at the IETF, in the LAMPS working group, through two documents: draft-ietf-lamps-pq-composite-sigs (composite signatures, revision -19 of April 2026, on the standards track) and draft-ietf-lamps-pq-composite-kem (composite key encapsulation, revision -17).
The dealbreaker today: backward compatibility
The composite certificate introduces new OIDs (algorithm identifiers) that existing cryptographic stacks do not know. The direct consequence: a classical-only client cannot understand a composite certificate. Where hybrid left the installed base untouched, composite requires that every verifier in the chain be updated to recognize the composite algorithms — otherwise validation simply fails.
Composite is therefore elegant cryptographically (a single object to manage, a strong binding between the two algorithms, no inventory doubling), but it shifts the burden onto the ecosystem: it is only viable within a perimeter where you control every last client.
The cross-cutting constraint: size
Whichever path you choose, one physical parameter weighs on the entire discussion: post-quantum signatures are big.
An ML-DSA signature weighs roughly 2.4 to 4.6 KB depending on the parameter set. By comparison, an ECDSA signature fits in ~64 bytes. That is a factor of several dozen, and it propagates everywhere certificates travel:
- TLS: the handshake carries the server certificate and its chain; every added ML-DSA signature inflates the connection's first round trips, with a measurable impact on establishment latency, especially over constrained links;
- IoT and embedded: limited memory, metered bandwidth, sometimes hard caps on frame sizes — the overhead can be a plain dealbreaker;
- composite specifically: the certificate stacks both public keys and both signatures into a single object, which mechanically becomes the heaviest of the three options.
Size is therefore not an implementation detail: it is a selection criterion in its own right between hybrid, composite and pure post-quantum, and it explains why the answer cannot be uniform across the entire IT estate.
The decision table: which choice in which context?
There is no absolute winner. The right choice depends on the degree of control you have over the verifiers, the size constraints of the channel, and the applicable regulatory framework.
| Context | Recommendation | Why |
|---|---|---|
| Internal PKI (you control all clients) | Composite is viable | Every verifier can be updated to recognize the new OIDs; a single certificate to manage per identity, with a strong cryptographic binding between the two algorithms. |
| eIDAS / qualified signatures | Hybrid, following the compliance doctrine (see ANSSI) | The regulatory framework comes first: align with the doctrine published by ANSSI rather than with a technical preference. See our dedicated article on ANSSI's positions. |
| Constrained IoT / embedded | Watch the size: sometimes a single well-sized algorithm, or a lightweight hybrid | The overhead of ML-DSA signatures (2.4–4.6 KB versus ~64 bytes for ECDSA) can blow past memory and bandwidth budgets; size for exactly what you need. |
| Public web / browsers | Neither is ready at scale — track the CA/Browser Forum and the IETF TLS working group | On the browser side, post-quantum key exchange (ML-KEM, via X25519MLKEM768) has been enabled by default in Chrome and Firefox since 2024-2025; but ML-DSA signatures in public certificates are not — updates to the CA/Browser Forum's Baseline Requirements are expected in late 2026 or 2027, and Chrome is exploring an alternative path (Merkle Tree Certificates) rather than classic post-quantum X.509. Any unilateral move would be premature. |
One cross-cutting reading of this table: the more closed and controlled your perimeter, the more attractive composite becomes; the more open and heterogeneous it is, the more hybrid imposes itself — all the way to the public web, where the only sound move is to wait for standardization and root programs to converge.
The pragmatic recommendation: start hybrid, aim for composite
For most organizations, the sensible trajectory in 2026 looks like this:
1. Start with hybrid/dual wherever the transition must begin now. It is the only approach that guarantees full backward compatibility with the existing estate, and therefore the only one that lets you move forward without coordinating a simultaneous update of every client. It also delivers a less visible but precious benefit: it forces the organization to industrialize its certificate management (exhaustive inventory, automated renewal, expiry monitoring) — a prerequisite that is unavoidable anyway with 47-day validity periods.
2. Handle the doubled workload with tooling, not headcount. The real risk of hybrid is not cryptographic, it is operational. If every additional certificate translates into additional manual work, dual will not scale. If the lifecycle is automated end to end, doubling the estate becomes a configuration parameter rather than a staffing problem.
3. Aim for composite as the ecosystem matures, starting with closed perimeters (internal PKI, controlled machine-to-machine) where every verifier can be updated. The signals to watch are the stabilization of the LAMPS drafts and the arrival of support in mainstream cryptographic libraries. A well-architected PKI must be able to absorb this evolution without a redesign: make that a criterion in your tooling choices starting today.
4. Keep size in mind at every step. Before generalizing anything on a constrained channel (high-volume TLS, IoT, low-bandwidth links), measure the real impact of post-quantum signatures on your handshakes and memory budgets. Some segments will justify different choices from the rest of the IT estate — and that is normal.
Product note
At ZetaCert, these two families structure our roadmap. ZetaCA issues in hybrid/dual mode — parallel classical + ML-DSA issuance has been validated. PKIFactor, our certificate lifecycle management (CLM) platform, addresses precisely the Achilles' heel of hybrid: the inventory and renewal of both certificates for each identity are handled without doubling the human workload, which keeps dual sustainable even with short validity periods. ZetaCA also issues in composite mode (a single certificate combining both mechanisms, following the IETF LAMPS pq-composite-sigs drafts), tracking their evolution: you thus cover both strategies, dual and composite, under a single authority — without having to pick a side too early.
If you want to assess where your estate stands and where to start: audit.zetacert.com.
📋 What to do today
- Inventory your certificate estate and your verifiers. You cannot choose between hybrid and composite without knowing which clients will have to validate what — it is the starting point of the entire decision.
- Test dual issuance on a pilot perimeter (an internal application, a machine-to-machine segment) to measure the concrete operational impact of the doubling, with your current tooling.
- Measure the size impact on your sensitive channels: time TLS handshakes with chains weighed down by ML-DSA signatures, and check the memory budgets of your embedded devices before committing to anything.
- Put standardization on watch: the composite LAMPS drafts, the IETF TLS working group, the CA/Browser Forum and ANSSI publications. The right moment to switch to composite will be dictated by the ecosystem, not by your internal calendar.
