Composite Signatures in PQC Migration: Benefits, Risks, and Deployment Patterns

Quick answer: A composite signature bundles a classical algorithm and a post-quantum algorithm, typically ML-DSA with ECDSA, RSA, or Ed25519, into a single ASN.1-encoded value using “AND” validation logic: both component signatures must independently verify, or the whole composite fails. That gives composite signatures a real security benefit, an attacker needs to break both algorithms, but it comes with concrete costs: legacy clients that do not understand the composite OID cannot parse the certificate at all, certificate size grows to carry two full signatures, and the underlying IETF LAMPS specification, while nearing stable status, is not yet a finalized RFC. This guide covers how composite validation actually works, what breaks when one component fails, and how to test a composite deployment before relying on it in production.

Composite signatures get discussed constantly at a conceptual level, “combine classical and post-quantum for defense in depth”, without much attention to the mechanics: what exactly gets validated, what happens when one algorithm fails, and what actually breaks in an application that was not built to expect a composite value. This guide covers those mechanics directly, building on our pure vs composite certificate comparison with the operational detail specific to deploying composite signatures.

Key Takeaways

• Composite signatures use “AND” validation: both the classical and post-quantum component signatures must independently verify for the composite to be valid.
• The IETF LAMPS working group defines composite signatures as a single ASN.1 structure, CompositeSignatureValue, containing each component signature as a separate BIT STRING.
• Legacy clients that do not recognize the composite algorithm OID cannot parse the certificate at all, a stricter failure mode than extension-based hybrid approaches that degrade gracefully for older clients.
• Certificate size grows meaningfully: a composite signature carries a complete classical signature and a complete post-quantum signature, not a combined or compressed value.
• The composite signatures draft is nearing stable status in IETF LAMPS but remains subject to revision until formal RFC publication.

How Dual Validation Actually Works

A composite signature is not a single cryptographic operation over combined key material. It is two complete, independent signatures, each computed with its own algorithm over the same message, packaged together and validated according to explicit logic. The IETF LAMPS composite signatures draft defines the structure as a sequence: an algorithm identifier for each component, a composite public key containing both component public keys, and a composite signature value containing both component signatures, each encoded as its own BIT STRING.

Validation follows straightforward “AND” logic: the verifier checks the classical signature against the classical public key, checks the post-quantum signature against the post-quantum public key, and the composite is valid only if both checks pass. Early drafts of the specification considered an “OR” mode, where either component validating would be sufficient, but the direction the working group settled on requires both, since an “OR” composite provides no additional security over the weaker of its two components.

Algorithm Failure Scenarios: What Actually Happens

The entire point of composite signatures is how they behave when one component algorithm fails, and it is worth walking through explicitly.

• Classical algorithm compromised (for example, a cryptanalytically relevant quantum computer breaks ECDSA): the post-quantum component still requires an unbroken ML-DSA signature to forge, so the composite remains secure. This is the primary threat the composite format defends against.
• Post-quantum algorithm compromised (a future cryptanalytic weakness is found in ML-DSA): the classical component still requires breaking ECDSA or RSA to forge, so the composite remains secure. This is the scenario composite signatures exist to hedge against during a period when post-quantum algorithms have not accumulated decades of scrutiny.
• Both components compromised simultaneously: the composite fails, the same outcome a pure single-algorithm signature would have under a single break, but requiring an attacker to defeat two independent, mathematically unrelated problems rather than one.
• One component signature is simply malformed or corrupted, not cryptographically broken: the composite fails validation entirely, by design. There is no partial-credit validation path.

Standards Maturity: Close, Not Final

The composite signatures specification has moved through multiple IETF LAMPS working group revisions and defines explicit algorithm combinations, ML-DSA paired with RSA, ECDSA, Ed25519, or Ed448, covering the combinations most X.509, PKIX, and CMS use cases need. Reference implementations already exist, including support in Bouncy Castle, and proof-of-concept deployments are running against those implementations today. That is meaningfully further along than a purely theoretical draft, but it is still short of a published RFC, and encoding details, algorithm identifier assignments, and edge-case handling can still change before that publication. Organizations building against the current draft should expect to track revisions rather than treat the current encoding as permanently fixed.

Certificate Size: The Concrete Cost

A composite signature is not a compressed or shared-material combination; it is a full classical signature and a full post-quantum signature carried side by side. An ML-DSA-65 composite signature paired with ECDSA-P256, for example, carries roughly 3,309 bytes for the ML-DSA component plus 64 bytes for the ECDSA component, versus 3,309 bytes for a pure ML-DSA-65 signature alone. Public keys stack similarly. Across a full certificate chain, that overhead compounds at every level, root, intermediate, and leaf, with direct consequences for TLS handshake size, OCSP response size, and the storage footprint of certificate stores that hold large volumes of composite certificates.

Application Compatibility: Why Legacy Clients Fail Hard

This is the compatibility distinction that matters most in practice. Composite signatures are identified by a dedicated algorithm OID that bundles both components into what the protocol treats as a single, atomic algorithm. A client or library that does not recognize that OID cannot parse the certificate at all, it is not a case of ignoring an unfamiliar extension and falling back to what it does understand. This differs from extension-based hybrid approaches, where the post-quantum material rides in a non-critical X.509 extension that legacy clients can simply skip, validating the classical signature alone and continuing to function.

The practical implication: composite certificates require every relying party in the chain to be updated with composite-aware validation logic before deployment, not gradually as a bonus feature. There is no compatibility bridge for older systems the way there is with a pure classical certificate that simply ignores post-quantum material it does not need.

Test Criteria Before Production Deployment

Before relying on composite signatures in production, verify each of the following:

1. Every relying party in the chain correctly parses the composite OID and does not silently fail, hang, or fall back to an insecure default when it encounters one.
2. Validation genuinely enforces “AND” logic, confirmed by testing with a deliberately corrupted classical component and a deliberately corrupted post-quantum component separately, verifying both cause validation failure.
3. Handshake and certificate chain size stay within the limits of your infrastructure, including any TLS inspection appliances, load balancers, or embedded devices that may not handle the larger payload gracefully.
4. HSM and signing infrastructure can generate both component signatures within acceptable latency, since composite signing is two full cryptographic operations, not one.
5. A rollback path exists in case a compatibility issue surfaces after deployment, since composite certificates cannot be gracefully degraded to classical-only for a client that cannot parse them.

What We’d Actually Recommend

Treat composite signatures as a deliberate choice for closed-loop environments where you control every relying party, not a general-purpose default. Run the full test criteria above in a staging environment before any production rollout, with particular attention to the “AND” enforcement test, since a validation implementation that silently accepts a single valid component defeats the entire purpose of the format. Track the LAMPS working group’s progress toward final RFC status rather than treating the current draft encoding as permanent, and build your certificate issuance pipeline to accommodate an encoding revision if one comes before finalization.

How Encryption Consulting Can Help

CertSecure Manager issues and manages composite certificates alongside pure PQC and classical formats from a single policy plane, so a mixed environment during the transition does not require separate tooling per format. Where composite signing applies to code and firmware artifacts rather than certificates, CodeSign Secure generates and manages both component signatures with HSM-backed key storage and policy-enforced signing workflows.

Our PQC Advisory Services run the compatibility and validation testing this guide covers as part of a structured composite signature rollout, including the “AND” enforcement verification and rollback planning described above.

A Real Security Benefit With a Real Compatibility Cost

Composite signatures deliver exactly what they promise: an attacker needs to break two independent algorithms, not one, to forge a signature. That benefit is genuine and well worth having in the right context. What it is not is a free upgrade. Legacy clients fail hard rather than gracefully, certificates carry real size overhead, and the specification behind the format is close to finalized but not there yet. Testing the “AND” validation logic explicitly, verifying every relying party’s compatibility before rollout, and tracking the LAMPS draft’s progress are the difference between composite signatures as a genuine security improvement and composite signatures as an outage waiting to happen.

Frequently Asked Questions

Does a composite signature validate if only the post-quantum component is valid?

No. The standardized direction requires “AND” logic: both the classical and post-quantum components must independently validate. A composite signature with only one valid component fails validation entirely.

What happens if a client doesn’t recognize the composite algorithm?

It cannot parse the certificate at all. Composite signatures use a dedicated algorithm OID treated as a single atomic algorithm, so an unrecognized OID causes outright parsing failure rather than a graceful fallback to the classical component.

How much larger is a composite signature than a single-algorithm signature?

It carries the full size of both component signatures. An ML-DSA-65 plus ECDSA-P256 composite adds roughly 64 bytes on top of the ML-DSA-65 signature’s own 3,309 bytes, and that overhead repeats at every level of a certificate chain.

Is the composite signatures format an official IETF standard yet?

Not yet. It is defined in IETF LAMPS working group drafts that are nearing stable status, with reference implementations already available, but formal RFC publication has not yet occurred, and encoding details remain subject to revision until then.

What is the single most important thing to test before deploying composite signatures?

That “AND” validation logic is genuinely enforced. Test with a deliberately corrupted classical component and a deliberately corrupted post-quantum component separately, and confirm both cause validation failure. A validator that accepts a composite with only one valid component defeats the format’s entire security purpose.