Pure vs Composite Post-Quantum Certificates

Quick answer: A pure PQC certificate uses a single post-quantum algorithm, such as ML-DSA, and requires every relying party in the chain to understand that algorithm to validate it. A composite certificate carries both a classical algorithm and a post-quantum algorithm together, requiring both to validate, so an attacker must break both to forge a signature, but at the cost of a larger certificate and a relying-party requirement to understand the composite format itself, currently defined in IETF LAMPS drafts. Pure PQC is the simpler, smaller, and increasingly recommended path for environments you control end to end; composite remains the safer choice where interoperability with relying parties you do not control is uncertain.

Every PKI team migrating to post-quantum algorithms eventually hits the same fork: issue certificates on a single post-quantum algorithm, or issue certificates that carry a classical algorithm and a post-quantum algorithm together. Both formats exist, both are actively supported by current platforms, and the choice has real consequences for certificate size, validation logic, rollback safety, and how quickly the migration can actually finish.

Key Takeaways

• Pure PQC certificates use a single post-quantum algorithm; composite certificates combine a classical and a post-quantum algorithm, both of which must validate.
• Composite certificates require an attacker to break both component algorithms to forge a signature, but they are larger and require relying parties to understand the composite format itself.
• The composite format is defined in IETF LAMPS working group drafts and, while nearing stable status, is not yet a finalized RFC.
• Current guidance from CA and PKI vendors increasingly favors pure PQC where the ecosystem supports it, reserving composite for scenarios with real interoperability uncertainty.
• Microsoft’s AD CS platform has shipped pure ML-DSA support; composite certificate support is planned for a later phase alongside ML-KEM.

The Two Formats, Defined

Property	Pure PQC	Composite
Algorithms in the signature	One post-quantum algorithm (e.g., ML-DSA)	One classical and one post-quantum algorithm, combined (e.g., ECDSA + ML-DSA)
Security assumption	Depends entirely on the post-quantum algorithm holding up	Remains secure as long as either component algorithm remains unbroken
Relying party requirement	Must understand and support the specific post-quantum algorithm	Must understand the composite format and both component algorithms
Certificate size	Larger than classical, smaller than composite	Larger than both pure PQC and classical, carrying two full signatures
Standards status	Built on finalized standards (ML-DSA is FIPS 204)	Defined in IETF LAMPS drafts, nearing but not yet final RFC status

Security Assumptions: What Each Format Actually Protects Against

Pure PQC certificates put full trust in the post-quantum algorithm’s security. That is a reasonable position for finalized, well-vetted standards like ML-DSA, but it does mean that if a serious weakness were ever discovered in the algorithm, every certificate built on it would need to be reissued with nothing to fall back on in the interim.

Composite certificates exist specifically to avoid that single point of failure during the transition period, when post-quantum algorithms are newer and have not accumulated the decades of cryptanalytic scrutiny that RSA and ECDSA have. A composite signature remains valid as long as either the classical or the post-quantum component remains unbroken, so an attacker has to defeat both simultaneously to forge it. That is a meaningfully stronger security posture during a period when trust in post-quantum algorithms is still being established, at the direct cost of size and validation complexity.

Relying-Party Compatibility: The Real Deployment Constraint

This is where the choice usually gets decided in practice, not on security grounds. A pure ML-DSA certificate is the cleanest end state, but every system validating that certificate, browsers, load balancers, embedded devices, legacy middleware, must already understand ML-DSA. In a homogeneous, closed-loop environment where every validator is under your control, that requirement is easy to satisfy. In a heterogeneous estate full of third-party appliances and older software that will not be updated on your migration timeline, it is a real blocker.

Composite certificates do not avoid this problem so much as relocate it: a validator now needs to understand the composite format itself, on top of both component algorithms. That is a different, and currently less widely deployed, compatibility requirement than pure ML-DSA support.

Chain Size, Validation Overhead, and Rollback

Composite certificates are unambiguously larger than either pure classical or pure PQC certificates, since they carry two complete signatures rather than one. Across a full certificate chain, that compounds: a composite root, intermediate, and leaf chain carries roughly double the signature payload of a pure PQC chain at every level, with corresponding effects on handshake size and validation time, since a relying party has to verify two signatures per certificate rather than one.

Rollback safety favors composite for one specific reason: if a post-quantum algorithm needs to be revoked or replaced mid-transition, a composite certificate’s classical component keeps validating on its own in systems that fall back to classical-only trust, buying time that a pure PQC certificate does not offer. Pure PQC certificates have no equivalent safety net; a problem with the algorithm means reissuing the certificate, full stop.

Interoperability and Migration Timing

Current guidance from major CA and PKI platforms is trending toward pure PQC as the default recommendation where the surrounding ecosystem supports it, reserving composite for specific scenarios: environments with real interoperability uncertainty, systems where a rollback safety net justifies the size and complexity cost, or contractual and regulatory contexts that explicitly require dual-algorithm protection during the transition. The composite specification itself is nearing stable status inside the IETF LAMPS working group, but “nearing” is doing real work in that sentence: implementers should track its progress rather than treat it as settled, and should expect encoding details to still be capable of minor revision before final RFC publication.

Platform timing matters here too. Microsoft’s AD CS platform shipped pure ML-DSA signature support in its May 2026 update, with composite certificate support, alongside ML-KEM, slated for a later phase. That sequencing, pure PQC signatures first, composite and key establishment later, reflects where the broader ecosystem’s implementation effort has concentrated so far.

What We’d Actually Recommend

Default to pure PQC, specifically pure ML-DSA, wherever you control the full validation chain: internal code signing, infrastructure attestation, machine-to-machine trust inside a managed fleet. Reserve composite certificates for scenarios where relying-party compatibility is genuinely uncertain, where a specific regulatory or contractual requirement calls for dual-algorithm protection, or where the rollback safety net is worth the added size and validation cost. Track the LAMPS composite drafts and your CA platform’s composite support timeline rather than building a production plan around composite today if pure PQC already satisfies your compatibility requirements. For the dual-validation mechanics, failure scenarios, and a pre-deployment test checklist once you do choose composite, see our composite signatures deployment guide.

How Encryption Consulting Can Help

Whichever format fits a given system, CertSecure Manager issues and manages both pure PQC and composite certificates from a single policy plane, so supporting a mixed environment during the transition does not mean running two separate certificate platforms. For organizations issuing composite (hybrid) certificates specifically, PKI-as-a-Service provides the managed CA infrastructure built to support dual-algorithm issuance without standing up parallel hierarchies.

Our PQC Advisory Services make the pure-versus-composite call system by system, rather than as a single organization-wide policy, based on the actual relying-party compatibility in your environment, and build the migration sequencing to match.

A System-by-System Decision, Not a Single Policy

Pure and composite certificates are not competing philosophies so much as tools suited to different compatibility conditions. Pure PQC is smaller, simpler, and increasingly the recommended default wherever you control the validation chain end to end. Composite earns its size and complexity cost specifically where relying-party compatibility is uncertain or where a rollback safety net justifies the trade-off. Most organizations will end up running both during the transition, and the decision that matters is not picking one format for the whole PKI, but knowing which systems actually need which guarantee.

Frequently Asked Questions

Is composite certificate support finalized?

Not yet as a published RFC. The composite signature format is defined in IETF LAMPS working group drafts, which are nearing stable status but remain subject to revision until formal publication.

Why would anyone choose composite over pure PQC if it’s larger and more complex?

Composite certificates provide a security and rollback safety net: they remain valid as long as either the classical or post-quantum component is unbroken, and a compromised post-quantum algorithm does not immediately invalidate trust the way it would for a pure PQC certificate. That is worth the added size and complexity in environments where interoperability is uncertain or regulatory requirements call for dual-algorithm protection.

Does Microsoft AD CS support composite certificates today?

As of the May 2026 update, AD CS supports pure ML-DSA signatures. Composite certificate support, alongside ML-KEM key establishment, is planned for a later phase.

Can an organization use pure PQC for some certificates and composite for others?

Yes, and this is the recommended approach for most organizations during the transition. The choice should be made system by system based on relying-party compatibility and risk tolerance, not as a single blanket policy across the whole PKI.

How much larger is a composite certificate than a pure PQC certificate?

A composite certificate carries a complete classical signature in addition to a complete post-quantum signature, so it is meaningfully larger than either component alone. Across a full certificate chain, that overhead compounds at every level of the hierarchy.