DigiCert’s 2029 PQC Infrastructure Plan: Lessons for Enterprise PKI Teams

Quick answer: DigiCert published its 2029 post-quantum infrastructure migration plan in May 2026, targeting completion across both confidentiality (TLS) and authentication (certificate) systems, spanning internal infrastructure and customer-facing services. The plan’s most transferable lessons are not about DigiCert specifically: treating PQC as infrastructure modernization rather than a research project, treating hybrid cryptography as a transition mechanism rather than a permanent destination, and building crypto-agility as an operational capability through a bounded, observable pilot before wider rollout. This guide extracts those lessons for any enterprise PKI team building an independent migration plan, using DigiCert’s public roadmap as a benchmark, not a template to copy.

Several major internet infrastructure operators, including Google, Microsoft, Cloudflare, and DigiCert, have now converged on 2029 as a target completion date for post-quantum migration, a convergence that itself signals something: the underlying math driving urgency (lower-than-previously-estimated qubit counts needed to threaten RSA and ECC) is shared across the industry, not company-specific. DigiCert’s plan is worth studying specifically because DigiCert occupies a distinct position in that group: as a certificate authority, its migration is not just about securing its own infrastructure, it is about the trust infrastructure it issues to everyone else.

Key Takeaways

• DigiCert’s 2029 target, published May 2026, covers both TLS confidentiality and certificate-based authentication across internal and customer-facing infrastructure, driven by 2030 NIST and EU member state deadlines.
• DigiCert cites a reduced estimate of roughly 10,000 physical qubits needed to threaten RSA and ECC, down from earlier estimates, as a driver for treating this as infrastructure modernization rather than a distant research concern.
• DigiCert explicitly frames hybrid deployments as a transition mechanism, not a long-term replacement strategy, since classical algorithms remain a temporary bridge rather than an end state.
• Algorithm support includes ML-DSA-65 and ML-DSA-87 as defaults for most customers, with SLH-DSA variants available for those wanting a more conservative, hash-based alternative.
• DigiCert’s own operational guidance emphasizes keeping algorithm choices out of application code, automating certificate issuance and rotation, and treating rollback planning as a standard part of any infrastructure change, not a PQC-specific afterthought.

Why 2029, and Why the Estimate Changed

DigiCert’s stated reasoning for the 2029 target is specific: it is primarily driven by 2030 migration deadlines from NIST and EU member states, and completing the work a year ahead of those deadlines is meant to give the organization time to work through operational challenges before customers need to rely on the migration being solid. The underlying urgency driver has shifted too. Researchers now estimate an attack against RSA and ECC would require roughly 10,000 physical qubits, a meaningfully lower bar than earlier estimates, which is part of why DigiCert frames PQC migration as infrastructure modernization rather than a speculative research exercise: if scalable fault tolerance in quantum hardware becomes practical, classical public-key cryptography becomes vulnerable quickly, not gradually.

Algorithm Choices: Defaults and Alternatives

DigiCert’s plan supports ML-DSA-65 and ML-DSA-87 as its primary signature defaults, aligned with the same civilian-versus-CNSA-2.0 parameter split covered in our FIPS 203, 204, and 205 standards guide, and also supports SLH-DSA variants for customers who specifically want a more conservative, hash-based alternative rather than a lattice-based default. The lesson here generalizes well beyond DigiCert specifically: a credible PQC infrastructure plan needs a default recommendation for the majority of use cases plus an explicit, narrower path for customers or systems with a different risk tolerance, not a single mandated algorithm for everyone.

Hybrid as a Transition Mechanism, Not a Destination

DigiCert is explicit that it does not treat hybrid deployments as a long-term replacement strategy for pure post-quantum algorithms. That framing matters for how enterprise PKI teams should think about their own hybrid rollout: hybrid certificates and hybrid key exchange exist to manage the transition period safely, providing a fallback while trust in post-quantum algorithms accumulates, not as a permanent architecture to settle into indefinitely. Teams building a migration plan around hybrid as a forever-state, rather than a bridge with its own eventual sunset, are solving a different, more complex problem than the one hybrid cryptography was designed to solve.

Operational Lessons for Any PKI Team

DigiCert’s own published operational guidance for organizations starting PQC pilots translates directly to any enterprise PKI team, independent of which vendor or infrastructure they run on:

• Keep algorithm choices out of application code: hardcoding a specific algorithm into application logic is exactly what makes a future algorithm change expensive; abstracting algorithm selection into policy or configuration is what makes it a configuration change instead.
• Automate certificate issuance and rotation: a PQC migration that still depends on manual certificate handling multiplies operational risk at exactly the point where certificate formats and sizes are changing underneath the process.
• Make negotiation and policy enforcement observable: if you cannot see which algorithm a given connection or certificate actually negotiated in production, you cannot tell the difference between a successful rollout and a silent fallback to classical algorithms.
• Plan rollbacks and staged deployment like any other infrastructure change: PQC migration does not get a pass on the change-management discipline that would apply to any other infrastructure-wide rollout.
• Start with a bounded, observable pilot: pick an environment you fully control, where you can observe failures and iterate quickly, and be explicit about what the pilot is actually measuring before declaring it successful.

Building Your Own Plan, Not a Copy

DigiCert’s plan is a useful benchmark precisely because it is public, detailed, and comes from an organization with a distinct incentive structure, both securing its own infrastructure and issuing the trust infrastructure other organizations depend on. It is not a template to copy directly, since your own environment carries different legacy dependencies, different regulatory obligations, and a different tolerance for the operational risk of an aggressive timeline. Use published plans like this one the way you would use any competitor benchmark: to calibrate whether your own timeline and scope are reasonable against what capable, resourced organizations are actually committing to, not as a substitute for your own cryptographic inventory and risk assessment.

What We’d Actually Recommend

Treat 2029 as a useful industry reference point for calibrating your own timeline, not a deadline that applies to your organization by default; your actual deadline should come from your regulatory exposure and risk profile. Adopt the operational discipline DigiCert and other major operators are converging on, algorithm abstraction, issuance automation, negotiation observability, staged rollback planning, regardless of which specific vendor or CA platform you run. Start your own pilot in a genuinely bounded environment, and be explicit up front about what success looks like before expanding scope.

How Encryption Consulting Can Help

Turning published plans like DigiCert’s into a calibrated, independent migration plan starts with an accurate picture of your own environment, not a borrowed timeline. Our PQC Advisory Services build that plan against your actual cryptographic footprint, regulatory obligations, and risk tolerance, benchmarked against what the industry’s largest operators are committing to without simply inheriting their scope or timeline.

CBOM Secure builds the cryptographic inventory that any credible plan starts from, mapping algorithms, certificates, and keys across your environment before timeline and scope decisions are made. Where certificate issuance and rotation automation is the operational gap DigiCert’s own guidance flags, CertSecure Manager handles issuance, rotation, and algorithm policy enforcement from a single platform, giving you the observability and automation DigiCert’s field guidance identifies as prerequisites, on your own infrastructure rather than a hyperscale CA’s.

A Benchmark, Not a Blueprint

DigiCert’s 2029 plan is genuinely useful as a public reference point: a detailed, dated commitment from an organization with real operational stakes in getting this right, since it issues trust infrastructure for others as well as securing its own. The specific lessons worth taking, treating hybrid as a bridge rather than a destination, keeping algorithms out of application code, automating issuance, making negotiation observable, and piloting in a bounded environment first, are transferable regardless of your own vendor stack. The 2029 date itself is not; your own timeline should come from your own regulatory exposure and inventory, calibrated against what capable peers are committing to, not copied from it.

Frequently Asked Questions

Why did DigiCert choose 2029 specifically as its migration target?

Primarily to complete ahead of 2030 migration deadlines from NIST and EU member states, giving the organization a year of operational experience before those regulatory deadlines apply, rather than reaching readiness at the same moment the deadline arrives.

Does DigiCert treat hybrid cryptography as a permanent solution?

No. DigiCert is explicit that it views hybrid deployments as a transition mechanism rather than a long-term replacement strategy, since classical algorithms are expected to be phased out entirely rather than run alongside post-quantum algorithms indefinitely.

Should my organization adopt DigiCert’s exact 2029 timeline?

Not necessarily. DigiCert’s timeline reflects its own regulatory exposure, scale, and role as a certificate authority. Use it as a calibration benchmark for whether your own plan is reasonably paced, but derive your actual deadline from your own regulatory obligations and cryptographic inventory.

Which post-quantum signature algorithms does DigiCert’s plan support?

ML-DSA-65 and ML-DSA-87 as the default recommendations for most customers, with SLH-DSA variants available for those who want a more conservative, hash-based alternative to lattice-based signatures.

What is the most transferable operational lesson from DigiCert’s public guidance?

Keeping algorithm choices out of application code and making certificate negotiation observable in production. Both practices make a future algorithm change a configuration update rather than a redevelopment project, and both apply regardless of which specific vendor or CA platform an organization runs.