Post-quantum certificate migration is now an identity governance issue

At a glance

What this is: DigiCert’s plan frames post-quantum migration as a staged shift in TLS, certificates, and secrets handling across internal and customer-facing systems.

Why it matters: For IAM, PKI, and NHI teams, the key issue is that quantum readiness depends on inventory, lifecycle control, and coordination across every identity boundary that relies on certificates and tokens.

👉 Read DigiCert's post-quantum infrastructure migration plan for 2029

Context

Post-quantum cryptography is the effort to replace public-key algorithms that could be weakened by future quantum computers. In identity programmes, that is not just a cryptography problem. It affects TLS, certificate issuance, key exchange, secrets rotation, and every system that depends on long-lived machine trust.

DigiCert’s migration plan shows why this matters operationally. A PQC transition cannot be handled as a one-time platform swap because legacy browsers, embedded systems, vendor termination services, and long-lived infrastructure all create compatibility constraints. That makes crypto agility part of identity governance, especially where machine identities and certificates underpin access and trust decisions.

Key questions

Q: How should security teams plan a post-quantum migration for TLS and certificates?

A: Start with a dependency inventory that covers every TLS endpoint, certificate issuing path, and vendor-managed termination point. Then separate the work into staged transitions for confidentiality, authentication, and secrets cleanup so you can preserve compatibility while reducing long-term quantum exposure.

Q: When does PQC migration become a governance issue rather than a crypto project?

A: It becomes a governance issue as soon as multiple teams, vendors, and certificate lifecycles must change in sequence. At that point, success depends on ownership, approvals, and coordination, not just on choosing a post-quantum algorithm.

Q: What usually slows down certificate migration to post-quantum algorithms?

A: Legacy browsers, embedded systems, custom SDKs, and unsupported libraries are the usual blockers. Organisations also slow themselves down when certificate automation is weak and trust changes are managed manually across too many environments.

Q: How do IAM teams prepare for harvest-now, decrypt-later risk?

A: Focus on the identities and certificates that will remain valid for the longest time, then shorten exposure by improving lifecycle control, renewal discipline, and migration sequencing. The goal is to reduce the value of captured traffic before quantum capability matures.

Technical breakdown

Why PQC migration has to start with TLS inventory

Post-quantum TLS migration begins with knowing every place where key exchange happens, including internal services, external endpoints, and vendor-managed termination points. The important distinction is between confidentiality and authentication: one protects session traffic, the other proves system identity. DigiCert’s plan uses hybrid or staged TLS 1.3 adoption because a sudden switch would break interoperability for older software and embedded platforms. That is a classic cryptographic migration problem, but in identity terms it is also a trust inventory problem. If you do not know which workloads rely on which cipher suites, you cannot plan the cutover safely.

Practical implication: inventory every TLS dependency before setting any PQC timeline.

How post-quantum certificates change PKI lifecycle management

Certificate migration is not only about new algorithms, but about issuance, renewal, trust anchor management, and automation across the certificate lifecycle. DigiCert’s focus on ML-DSA certificates and PKI automation reflects the reality that public acceptance, browser support, and standards alignment all gate deployment. For identity teams, this means certificate governance has to track algorithm choice, expiry, replacement path, and where automation can reduce manual intervention. Post-quantum certs also raise operational questions about certificate size, compatibility, and policy enforcement across internal and public PKI. Lifecycle control becomes the mechanism that determines whether PQC stays experimental or becomes normal practice.

Practical implication: map PQC certificate issuance, renewal, and retirement into a governed lifecycle workflow.

Why secrets rotation becomes the final migration step

DigiCert places rotation of credentials, tokens, and other secrets at the end of the migration sequence, which is a useful signal for practitioners. Once TLS and certificate trust are modernised, the remaining identity artefacts still need cleanup because quantum readiness is not complete until every dependent secret is reviewed. In NHI terms, secrets are not isolated objects. They are part of a wider trust chain that includes certificates, keys, and service-to-service authentication. If rotation is delayed until the end, it usually means the programme has already accepted that identity and cryptographic dependencies must be modernised in order, not by one-off remediation.

Practical implication: treat secrets rotation as a dependent workstream, not a standalone cleanup task.

NHI Mgmt Group analysis

PQC migration is now an identity governance problem, not just a cryptography project. DigiCert’s roadmap shows that the hardest work is not algorithm selection but lifecycle coordination across TLS, certificates, vendors, and legacy systems. That is exactly the kind of dependency chain identity teams already manage in NHI governance, except the trust boundary is cryptographic rather than purely administrative. Practitioners should treat PQC readiness as a governed identity transition, not a lab exercise.

Certificate agility is the named concept this market keeps underestimating. The article makes clear that support for ML-DSA, standards bodies, browser vendors, and CA ecosystems all have to line up before migration can complete. That means the operational constraint is not whether PQC exists, but whether organisations can swap trust anchors, algorithms, and issuance paths without breaking service continuity. Certificate agility should now be measured as a lifecycle capability, not a crypto feature.

Harvest-now, decrypt-later changes the value of long-lived machine trust. DigiCert explicitly links legacy key exchange removal to resistance against HNDL threats, which means any certificate or token that remains valid for years carries more strategic exposure than it did in a classical-only world. This is especially relevant for machine identities, where long renewal cycles and incomplete inventory are common. The implication is that long-lived trust artefacts now create future exposure, even if they look harmless today.

Crypto modernization will expose weak ownership in NHI and PKI estates. The migration path depends on full inventories, vendor coordination, and disciplined workflow control, which are the same weak points that cause machine identity sprawl in other programmes. Where ownership is unclear, migration stalls. Where automation is missing, lifecycle tasks pile up. Practitioners should expect PQC work to reveal whether identity governance is actually operational or only documented.

Post-quantum readiness will converge IAM, PKI, and workload identity governance. The article’s sequencing from TLS to certificates to secrets shows that these disciplines can no longer be managed in separate silos. A certificate problem can become a workload trust problem, and a workload trust problem can become an operational continuity issue. The practical conclusion is that identity architecture teams need a single migration view across human, NHI, and infrastructure trust assets.

From our research:

• 69% of organisations now have more machine identities than human ones, according to the Critical Gaps in Machine Identity Management report.
• Only 38% have automated certificate lifecycle management in place, which helps explain why large-scale cryptographic change is so operationally difficult.
• For a broader governance lens, the Ultimate Guide to NHIs , What are Non-Human Identities shows how machine trust assets fit into identity programmes.

What this signals

Post-quantum work will force identity teams to unify certificate management, workload trust, and secrets rotation under one programme view. The organisations that already know where their machine identities live will move faster because they can sequence migration by dependency instead of by guesswork.

Certificate agility: the ability to change algorithms, trust anchors, and issuance paths without service disruption. As PQC adoption accelerates, this becomes a programme capability in its own right, not a cryptography footnote.

With 57% of organisations lacking a complete inventory of their machine identities, according to our Critical Gaps in Machine Identity Management report, the first blocker to PQC readiness is often visibility rather than code support.

For practitioners

• Build a complete TLS dependency inventory Map every internal and external endpoint that uses TLS 1.3, including vendor termination services, legacy applications, embedded systems, and customer-facing properties. Record which systems can already support x25519mlkem768 and which require staged compatibility handling.
• Classify certificate lifecycle readiness by system family Separate internal PKI, public PKI, and customer-issued certificates into distinct migration tracks so you can see where ML-DSA support, renewal automation, and trust anchor changes are actually blocked.
• Plan for legacy software constraints early Identify browsers, custom SDKs, and long-lived platforms that cannot move quickly to PQC-safe configurations, then tie them to a remediation sequence instead of assuming a single cutover date will work.
• Treat secrets rotation as a downstream dependency Schedule credentials, token, and other secrets rotation after the certificate and key exchange migration path is defined, so you do not create a cleanup effort that conflicts with ongoing trust transitions.

Key takeaways

• PQC migration is really a staged identity and trust transition across TLS, certificates, and secrets.
• The limiting factor is usually inventory, ownership, and compatibility, not the existence of post-quantum algorithms.
• IAM and NHI teams should treat certificate agility and lifecycle control as core readiness work for the quantum era.

Key terms

• Post-Quantum Cryptography: Post-quantum cryptography is a set of algorithms designed to resist attacks from quantum computers. In identity and PKI programmes, it mainly affects key exchange, certificate signatures, and the systems that depend on those trust anchors for authentication and encrypted transport.
• Certificate Lifecycle: Certificate lifecycle is the full path from issuance through renewal, replacement, revocation, and retirement. For NHIs and infrastructure trust, it is the control surface that determines whether cryptographic change can happen safely and at scale.
• Cryptographic Agility: Cryptographic agility is the ability to change algorithms, key lengths, and trust mechanisms without major service disruption. In practice, it is a governance and engineering capability that lets identity programmes adapt before legacy cryptography becomes a liability.
• Harvest-Now, Decrypt-Later: Harvest-now, decrypt-later is the threat model where attackers capture encrypted traffic today and wait to break it once stronger computing becomes available. For long-lived machine and service communications, it turns current confidentiality decisions into future exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: DigiCert’s 2029 post-quantum infrastructure migration plan. Read the original.