PQC (Post-Quantum Cryptography) 05-28-2026

DigiCert’s 2029 post-quantum infrastructure migration plan

Shane Kelly
PQC Migration Plan Blog Hero

At DigiCert, our goal is to complete our core post-quantum infrastructure migration by 2029. That work includes confidentiality (TLS) and authentication (certificates) systems across both internal infrastructure and customer-facing services.

This post outlines the technologies we plan to use, what we already support today, and the major milestones we expect to complete over the next several years.

Why DigiCert is targeting 2029

Our decision to target 2029 is primarily driven by the 2030 migration deadlines from NIST and the EU member states. Reaching post-quantum readiness before those deadlines gives us time to identify operational challenges and help customers transition from a position of experience.

Recent reductions in the estimated quantum processing power required to break current encryption algorithms have coalesced many in the industry around a 2029 migration date. Researchers now estimate that attacks against RSA and elliptic curve cryptography (ECC) will require around ten thousand physical qubits, down from hundreds of millions a decade ago. 

These improvements are theoretical but coupled with advancements with neutral atoms and improved error corrections; a cryptographically relevant quantum computer (CRQC) seems possible soon.

Putting on a tin foil hat for a moment, it’s fair to wonder whether we may be closer to a CRQC than public disclosures suggest. For organizations responsible for very high-security systems that require a paranoid worldview, transitioning to PQC now is a necessity.

DigiCert’s view on quantum risk

DigiCert believes the remaining barriers to a CRQC are primarily engineering challenges.

If scalable fault tolerance becomes practical, classical public-key cryptography will become vulnerable very quickly. That's why we view PQC migration as an infrastructure modernization effort, not a speculative research project.

What quantum security means at DigiCert

For internal systems, DigiCert is using:

  • x25519mlkem768 for confidentiality
  • ML-DSA-44 for authentication

While we believe these are good defaults for a lot of our customers, some will have different requirements. In addition to these algorithms and key strengths, our solutions support ML-DSA-65 and ML-DSA-87, as well as SLH-DSA variants for customers who want a more conservative post-quantum solution.

DigiCert has confidence in the standardized PQC algorithms, particularly the NIST-selected schemes. We’re not treating hybrid deployments as a long-term replacement for PQC because, for all intents and purposes, classical asymmetric cryptography has already been broken*.

That said, although DigiCert doesn’t plan to use hybrid authentication internally, we'll support customers who require hybrid deployments during migration periods. Customers evaluating hybrid approaches can contact us at pqc.labs@digicert.com.

* By “broken,” we mean there exists an algorithm that substantially reduces the security of RSA and ECC. Shor’s algorithm satisfies that condition, regardless of the engineering hurdles associated with building large-scale quantum computers.

What DigiCert supports today

DigiCert already supports several production PQC capabilities across both internal (aka private) PKI and public-facing infrastructure.

DigiCert Private CA allows customers to issue ML-DSA certificates today. Additional information is available in the DigiCert documentation for post-quantum solutions. 

Major public-facing DigiCert TLS endpoints, including www.digicert.com and one.digicert.com, already support x25519mlkem768 key exchange.

2029 migration plan

Confidentiality (TLS)

One of the primary areas of DigiCert’s 2029 migration effort is confidentiality. That work centers on TLS modernization and post-quantum key exchange across both internal infrastructure and customer-facing services.

PQC TLS migration requires balancing quantum readiness with the compatibility realities of existing customer connections. An immediate switch to PQC-only TLS configurations would break compatibility with most existing systems. Because of this, migration needs to happen in stages.

Phase 1: Universal TLS 1.3 support

Get every TLS connection across DigiCert infrastructure to support TLS 1.3 with x25519mlkem768 key exchange. This requires a full inventory of internal and external TLS connections, as well as coordination with vendors providing TLS termination services.

Phase 2: Customer TLS migration

DigiCert aims to help customers transition fully to TLS 1.3 before 2028. Up-to-date browsers and libraries already support much of this transition path. Older enterprise software, custom SDKs, embedded systems, and long-lived infrastructure platforms pose a challenge.

This phase is the most operationally difficult portion of the migration effort. Some customers will require a significant amount of coordination to accomplish the task.

Phase 3: Classical key exchange removal

Once compatibility requirements no longer require legacy support, DigiCert plans to disable non-PQC key exchange options. At that point, confidentiality protections become resistant to harvest-now, decrypt-later (HNDL) threats.

Authentication (certificates)

Authentication is the second major focus area of DigiCert’s 2029 migration effort. This portion of the transition centers on post-quantum certificates and PKI automation.

Broad deployment of PQC certificates requires support from:

  • Browser vendors 
  • The IETF 
  • The CA/B Forum 
  • TLS libraries 

DigiCert will continue its work with standards organizations and ecosystem partners to help accelerate adoption.

Internal PKI automation

DigiCert already supports ML-DSA certificates within DigiCert® Private CA.

The next major milestone is complete PQC automation across certificate issuance and lifecycle workflows.

DigiCert already maintains X9 PKI root certificates for all three ML-DSA variants.

Internal PKI migration

DigiCert plans to migrate internal PKI systems to ML-DSA-44.

Software support remains the primary gating factor. Systems built on OpenSSL 3.5+ generally support ML-DSA successfully, but many browsers, platforms, and cryptographic libraries still require additional work.

Public ML-DSA certificate support

Public PQC certificates ultimately depend on CA/B Forum and browser acceptance. DigiCert plans to offer public ML-DSA certificates as soon as standards permit deployment.

Merkle Tree Certificates

The industry is also evaluating Merkle Tree Certificates (MTCs) as a potential alternative for PQC Web PKI.

MTCs could improve certificate transparency scalability and reduce certificate sizes. Those benefits become increasingly important in post-quantum environments where certificate sizes grow substantially.

DigiCert is actively developing MTC prototypes and intends to support MTC issuance alongside traditional public CA services.

The final step

After confidentiality and authentication systems transition successfully, DigiCert will rotate credentials, tokens, and other secrets.

Factors that could change the timeline

Every large-scale cryptographic transition depends on variables outside any single organization’s control.

Here are some of the factors that could accelerate or delay PQC adoption timelines.

  • Earlier-than-expected CRQC development: If a cryptographically relevant quantum computer emerges sooner than expected, migration timelines across the industry will compress dramatically.
  • Vendor readiness: Vendor support remains one of the largest issues for PQC migration. Organizations with critical vendors lacking PQC support will experience slower transitions.
  • Organizational scale: Larger organizations typically require more time to complete cryptographic migrations.

The quantum transition is already underway

Organizations that begin modernizing early will be in a significantly stronger position as post-quantum requirements become part of basic security mandates.

The good news is that the technology exists. We just have to start using it.

Subscribe to the blog