Hybrid Signatures: The Migration Bridge

A hybrid signature is one message signed by two algorithms at once: a classical scheme like ECDSA or Ed25519, and a post-quantum scheme like ML-DSA. In the strict form most standards work targets, the two signatures travel together and both have to verify. The point is insurance. If a quantum computer eventually breaks the classical half, the post-quantum half still holds. If a flaw turns up in the young post-quantum scheme, the classical half still holds. With a properly designed combiner, you stay protected as long as at least one of the two survives, the guarantee you want during a migration that will take years and can’t afford a wrong bet.

That is why hybrids get called a bridge. They let systems that depend on classical signatures today start carrying post-quantum protection without ripping anything out, and without staking everything on cryptography that is only a few years old.

Why hybrid signatures exist

The case for going straight to a pure post-quantum signature is simple: it’s smaller, faster, and it’s the destination anyway. The case against doing it immediately is that these schemes are new. NIST finalized ML-DSA and SLH-DSA in August 2024; the Falcon-based standard, FN-DSA, is still in draft, with a final version expected around late 2026 or 2027. Classical schemes like RSA and elliptic-curve signatures have three decades of attempted breaks behind them and are still standing against classical computers. The post-quantum schemes have not had that scrutiny yet, and history is unkind to young cryptography.

A hybrid hedges the two failure modes against each other. A quantum computer capable of running Shor’s algorithm at scale would break the classical signature but not the lattice-based one. A surprise cryptanalytic result against the lattice scheme, or a bug in its implementation, would break the post-quantum signature but not the classical one. That protection has a condition: the flaw has to stay inside the post-quantum half. A bug in shared parsing, key handling, or the combiner that binds the two together can still sink the whole construction. Where those conditions hold, an attacker needs both halves to fall before your signature is worthless, and during a transition when nobody can name the year quantum attacks become practical, that double cover is worth the overhead.

How hybrid signatures are being deployed

The furthest-along specification is composite ML-DSA, defined in an IETF draft (draft-ietf-lamps-pq-composite-sigs) that reached its nineteenth revision in April 2026 and has moved into the RFC Editor queue, on track to become a Proposed Standard. It is not an RFC yet, so treat it as a draft to watch rather than a finished standard. It targets X.509 certificates and PKI. “Composite” means the two algorithms are bound into a single object that presents one public key, one signature value, and one algorithm identifier at the protocol level, though each of those carries two components inside. A verifier either accepts the whole thing or rejects it.

You can’t quietly strip the post-quantum half off and present only the classical part. The draft calls this weak non-separability: in X.509 use, the algorithm label and processing rules make a stripped component fail. That closes the obvious downgrade route inside the certificate. It doesn’t eliminate every downgrade path at the system level, in a deployment that still negotiates or accepts a separate classical-only credential elsewhere can remain downgradeable.

Pairings and backwards-compatibility

The draft specifies concrete pairings, ML-DSA with RSA, with ECDSA, with Ed25519, with Ed448, so implementers aren’t inventing their own combinations. It also aims for what the authors call “protocol backwards-compatibility”: it supplies conventions for X.509/PKIX, PKCS#10, and CMP so those formats can carry a composite algorithm in their existing signature fields with no special hybrid-awareness in the protocol layer (CMS is being handled in a separate specification). That fit is what lets a composite slot into existing message flows. It does not mean old software understands it. Only upgraded verifiers recognize the new identifiers, and a legacy verifier cannot validate a composite certificate. The compatibility is in the fields, not in the verifiers.

Not every hybrid is composite

Some designs run two signatures side by side, bound loosely or not at all, and those looser constructions are where the classic engineering risks live: larger messages, slower negotiation, and downgrade paths where an attacker pushes both sides to drop the post-quantum component. Binding the two into one atomic object, as composite ML-DSA does, avoids most of that and is generally the safer pattern for certificates. One caveat worth knowing: composite ML-DSA targets standard unforgeability (EUF-CMA), not strong unforgeability (SUF-CMA), so it isn’t the right choice for a protocol that specifically needs the stronger property.

What it means for crypto and wallets

For blockchains the appeal is similar, but the mechanics are harder, because a chain can’t force everyone to upgrade at once. Adding a post-quantum signature type is a consensus change, usually a soft fork: upgraded nodes enforce the new rules, while old nodes (which have no code for the new signature) don’t check the post-quantum part at all. They tend to treat the new output as spendable by anyone and lean on the upgraded majority to enforce it. Old and new can coexist, but only upgraded software actually verifies the quantum-resistant signature. That sequencing problem faces every chain planning a migration.

The proposals here are still early. Bitcoin work aimed at post-quantum signing, including hash-based approaches like WOTS+ and XMSS, and newer proposals for a dedicated quantum-resistant output type, has not converged on a finished scheme. Current numbered BIPs sketch migration paths and legacy-spend phases rather than standardize a specific post-quantum signature. Ethereum’s account abstraction gives it another route to swap in new validation logic. Across all of them the same problem applies: you need a period where old and new coexist, and a hybrid is one way to make that period a ramp rather than a cliff.

The size cost

The cost is size, and on a blockchain size is money. A Bitcoin signature runs about 64 to 73 bytes, depending on whether the spend uses Schnorr or ECDSA. An ML-DSA signature is 2,420 to 4,627 bytes — roughly 33 to 72 times larger. SLH-DSA is more extreme still, from 7,856 up to 49,856 bytes. A hybrid stacks the classical signature on top, though the elliptic-curve part is small beside the post-quantum one. On a system where every byte competes for block space and pays a fee, that overhead is a deliberate trade of efficiency for cryptographic redundancy, not a free upgrade.

National authorities differ on hybrids

Anyone treating hybrids as the obvious universal answer should know the national security agencies don’t line up behind them.

The NSA, through its CNSA 2.0 suite, has said it will not require national-security systems to use hybrid products, and treats hybrids as a permitted step rather than the target. It expects the selected post-quantum algorithms to stand on their own, though it allows that interoperability or product availability may lead to hybrids in practice. That guidance covers U.S. National Security Systems, not the whole U.S. market.

Germany’s BSI and France’s ANSSI put more weight on hybrids during the transition: BSI recommends hybrid use where possible, and ANSSI requires or recommends it in its earlier migration phases. But ANSSI’s later phase, not expected before around 2030, allows standalone post-quantum cryptography with hybridization optional. So this is less a permanent European preference for hybrids than a difference over how long to keep the classical layer.

Everyone accepts the algorithms and accepts that migration has to happen; the split is over risk appetite: how much you trust new cryptography versus how much complexity you’ll carry to hedge it, and for how long. A vendor selling into U.S. national-security programs and into products that need French or German certification can feel that tension in one codebase, though selectable deployment profiles often resolve it.

When a hybrid makes sense

Reach for a hybrid when the thing you’re protecting has to stay valid for a long time and you can’t afford to be wrong about the post-quantum scheme: long-lived certificates, root keys, firmware signing, anything where a signature made today must still be trusted in fifteen years. Reach for it when you can’t run a clean flag-day cutover, keeping in mind that with composite signatures a legacy verifier still can’t validate the new object; real coexistence needs an extra mechanism, which means separate credentials, multiple output types, or negotiated protocol with authenticated downgrade protection. Lean toward pure post-quantum when size and speed dominate, when you control the whole stack and can upgrade it cleanly, or when a regulator like the NSA is pointing you straight at the destination.

The honest summary is that a hybrid buys time and insurance at the price of bytes and complexity. For a migration nobody can schedule precisely, against a threat nobody can date exactly, that trade is often worth making. Under the NSA and NIST direction it’s a bridge rather than a home, the plan is to reach pure post-quantum on the far side, though some high-assurance and regulated deployments may keep the classical layer longer. Either way, the hybrid’s job is to keep you from falling in as you cross.