PKI and Key Management

PKI and PQC: Preparing Certificate Authorities for the Quantum Transition

Learn how the PQC transition affects PKI: hybrid certificates, quantum-safe certificate chains, CA migration timelines, and what enterprise certificate management teams should prepare now.

PKI and PQC: Preparing Certificate Authorities for the Quantum Transition

Public Key Infrastructure is the trust backbone of the internet. Every HTTPS connection, every code signature, every email encrypted with S/MIME depends on certificate authorities issuing and validating X.509 certificates built on RSA and ECC.

When post-quantum cryptography replaces RSA and ECC, every certificate in every chain must eventually be reissued. This is not a simple algorithm swap — it affects certificate issuance, validation, revocation, and trust anchor management across the entire PKI ecosystem. For related context, see TLS certificate inventory work.

This article explains what the PQC transition means for PKI, what hybrid certificates are, and what enterprise certificate management teams should do now. For related context, see PQC compliance planning.

How PKI Works Today (and Why PQC Changes It)

A typical X.509 certificate chain works like this:

A root CA self-signs its certificate using RSA-4096 or ECC P-384
An intermediate CA certificate is signed by the root, also using RSA or ECC
An end-entity (leaf) certificate is signed by the intermediate CA, using RSA-2048 or ECDSA P-256

Every signature operation in this chain uses an algorithm that Shor's algorithm will break. When CRQCs arrive, every certificate signed with RSA or ECDSA is forgeable — meaning an attacker could create a fraudulent certificate that appears valid under the existing PKI.

The fix is to migrate the entire chain to post-quantum signature algorithms: ML-DSA (FIPS 204) or SLH-DSA (FIPS 205). But this migration cannot happen overnight — especially not at the root CA level, where certificate updates affect millions of relying parties. For related context, see crypto agility planning.

Hybrid Certificates: The Bridge Strategy

During the transition period, the proposed solution is hybrid certificates — X.509 certificates that contain both a classical signature (RSA or ECDSA) and a post-quantum signature (ML-DSA or SLH-DSA) from the same issuer.

A hybrid certificate chain works like this:

The root CA signs with RSA-4096 and ML-DSA-65
The intermediate CA certificate carries both signatures
The leaf certificate carries both signatures
A hybrid-aware client validates both signatures before trusting the chain
A legacy client validates only the RSA signature and trusts the chain as before

This provides backward compatibility — legacy clients see a normal RSA certificate — while giving PQC-aware clients the additional security of a lattice-based signature. If ML-DSA is broken, the RSA signature still provides defense-in-depth.

What Enterprise Certificate Teams Should Do Now

Audit Your Internal PKI

If you operate an internal CA — Microsoft AD CS, EJBCA, HashiCorp Vault PKI, AWS Private CA — audit every certificate template, every issuance policy, and every root and intermediate certificate. Record:

Which algorithms are used for each CA certificate (root, intermediate, issuing)
Which signature algorithms are configured in certificate templates
Which clients and services trust these certificates
Renewal timelines for root and intermediate CAs

Test Hybrid Certificates

Major CA software vendors are adding hybrid certificate support:

EJBCA (Keyfactor) has experimental PQC certificate issuance
Let's Encrypt is tracking PQC and has published hybrid certificate test plans
DigiCert and Sectigo have announced PQC roadmap commitments
OpenSSL 3.5+ includes ML-KEM and ML-DSA for testing

Set up a test intermediate CA that issues hybrid certificates. Test with a subset of internal services. Document the process, the performance impact, and any compatibility issues.

Prepare for Larger Certificates

ML-DSA-65 signatures are approximately 3,300 bytes — about 13x larger than a 256-byte RSA-2048 signature. Certificate chains will become larger. TLS handshakes will transmit more data. This has implications for:

Network bandwidth (especially for IoT and constrained devices)
Certificate transparency logs (larger entries = more storage)
OCSP responses and CRLs (larger signatures = larger revocation data)

Measure the impact in your environment before production deployment.

Plan Your Internal CA Migration Timeline

Do not wait for the root CA renewal cycle. Plan a phased migration:

2025-2026: Test hybrid certificates in non-production environments
2027-2028: Issue hybrid certificates for new internal services
2028-2030: Reissue all end-entity certificates with hybrid signatures
2030+: Reissue intermediate and root CA certificates with PQC-only (or hybrid) signatures

FAQ

Q: Will public CAs offer PQC certificates? A: Yes. DigiCert, Sectigo, Let's Encrypt, and others have PQC roadmaps. Hybrid certificates are expected to be available for public trust before 2028. Monitor your CA's announcements.

Q: What happens to existing RSA certificates during the transition? A: They continue to work for legacy clients. The hybrid approach means you issue a new certificate with both signatures rather than revoking the old one immediately. This is a migration, not a flag day.

Q: Does CipherReady help with PKI PQC migration? A: CipherReady's external TLS certificate inventory identifies every certificate, its algorithm, its issuer, and its quantum vulnerability. This is the discovery step PKI teams need before they can plan CA migration.

Start Free Readiness Scan →