Post-quantum cryptography readiness depends on crypto-agility

At a glance

What this is: This is an analysis of NIST’s latest post-quantum signature evaluation and the operational burden it places on cryptography teams.

Why it matters: It matters because IAM, PKI, and machine identity programmes will have to support long-lived hybrid cryptography without breaking issuance, renewal, revocation, or trust chains.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read DigiCert's analysis of NIST’s post-quantum signature evaluation

Context

Post-quantum cryptography is the move from today’s public-key algorithms to newer schemes designed to resist future quantum attacks. The hard part is not only choosing algorithms, but keeping certificates, protocols, policies, and inventories adaptable as standards evolve and implementations change.

For identity, this is a machine identity and certificate lifecycle problem as much as a cryptography problem. Enterprises will have to manage hybrid trust for years, which means visibility, renewal discipline, revocation, and crypto-agility become core controls rather than back-office plumbing.

Key questions

Q: How should security teams prepare certificate estates for post-quantum migration?

A: Start with inventory, dependency mapping, and lifecycle automation. Teams need to know which applications, devices, and machine identities depend on each trust chain before they can safely introduce post-quantum algorithms. Without that visibility, migration becomes reactive, with outages and policy drift happening after the change instead of before it.

Q: When does crypto-agility matter more than selecting a specific PQC algorithm?

A: Crypto-agility matters most when standards, vendor support, and deployment maturity will change over time. In that situation, the deciding factor is whether the organisation can update algorithms, certificates, and protocols quickly without breaking service. The more distributed the environment, the more important the operating model becomes.

Q: What breaks when certificate lifecycle management is still manual during PQC migration?

A: Manual lifecycle management breaks scale, consistency, and response speed. Expired certificates, delayed revocation, and mismatched trust settings become more likely as hybrid cryptography expands across the estate. The result is a migration process that depends on coordination rather than control, which is rarely sustainable.

Q: How do machine identities change the risk profile of post-quantum transition?

A: Machine identities multiply the number of trust relationships that must remain valid while cryptographic standards evolve. That turns PQC from a narrow cryptography project into a broad identity governance problem. Teams must account for service accounts, devices, APIs, and certificates together, not as separate workstreams.

Technical breakdown

Why crypto-agility matters in post-quantum migration

Crypto-agility is the ability to change cryptographic algorithms, certificates, and policies without rebuilding the surrounding platform. That matters because PQC migration will not happen in one cutover. Organisations will run classical and post-quantum trust in parallel while vendors update libraries, hardware, and protocols. The operational challenge is less about picking a winning algorithm and more about making every trust dependency visible enough to change safely. If certificate inventories are incomplete, renewal logic is manual, or trust assumptions are embedded in code, the migration path becomes brittle fast.

Practical implication: inventory every certificate, trust anchor, and dependent application before planning PQC rollout.

Hybrid cryptographic environments will last for years

Hybrid cryptography means supporting both classical and post-quantum schemes during a transition period. NIST’s continued evaluation of backup algorithms reflects that the ecosystem still needs flexibility while standards settle. For enterprises, this creates a mixed estate across applications, devices, and authentication systems, where some components can move quickly and others cannot. The main risk is operational inconsistency: one team updates a service while another depends on a legacy trust path that no longer matches policy or tooling maturity.

Practical implication: treat PQC migration as a portfolio problem, not a single certificate replacement project.

Certificate lifecycle automation is now a resilience control

Certificate lifecycle management covers issuance, renewal, revocation, and policy enforcement across the estate. In a PQC transition, that lifecycle becomes the control plane for change because algorithms will evolve while trust relationships stay live. Manual approval chains and disconnected tooling increase the chance of expired certificates, failed revocations, and drift between intended and actual trust state. Automation is not just about efficiency. It is how organisations keep pace with cryptographic change while preserving availability and accountability across machine identities.

Practical implication: automate certificate lifecycle events so cryptographic changes do not depend on manual coordination.

Threat narrative

Attacker objective: The objective is to preserve access to trust relationships and weaken the organisation’s ability to adapt before cryptographic change forces disruption.

1. Entry occurs through legacy cryptographic trust that remains valid after standards begin to change, creating a slow-moving exposure window rather than a single exploit event.
2. Escalation comes from operational lag, where incomplete inventories, manual renewals, or outdated protocols allow weak trust paths to persist across applications and machine identities.
3. Impact is sustained exposure to future quantum risk and avoidable outages when cryptographic transitions are rushed or inconsistently applied.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Salt Typhoon US telecoms breach — Salt Typhoon APT used stolen credentials and Cisco CVE to breach US telecoms.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Crypto-agility is the real control objective, not algorithm selection. The article’s central point is that PQC migration fails if organisations treat it as a one-time cryptographic swap. Standards will keep moving, products will update at different speeds, and trust paths will remain live across long-lived machine identities. The practical conclusion is that certificate and protocol adaptability is now the governing capability, not an implementation detail.

Certificate lifecycle blind spots will become PQC failure points. Hybrid cryptography increases the number of certificates, trust anchors, and policy dependencies that must stay aligned. In that environment, manual approvals and fragmented tooling create the same failure mode seen in other identity programmes: the estate is too distributed to govern consistently. The practitioner lesson is that visibility and lifecycle automation determine whether cryptographic change is controllable.

Post-quantum readiness is a machine identity issue as much as a cryptography issue. The systems most exposed are not just user-facing applications, but the service-to-service and device trust relationships that depend on certificates and signed assertions. That means PQC planning must sit alongside workload identity, renewal governance, and revocation discipline rather than in a separate cryptography silo. The implication is that machine identity governance becomes a prerequisite for safe migration.

PQC migration exposes the identity assumption that trust infrastructure changes slowly. That assumption was designed for environments where certificates and protocols evolved on a long, predictable cycle. It fails when standards, implementation guidance, and vendor support all shift while hybrid trust remains active. The implication is that identity programmes must stop treating cryptographic change as exceptional and start treating it as a routine governance capability.

Named concept, cryptographic transition debt: the longer organisations delay lifecycle automation and inventory discipline, the more change accumulates in the trust layer. That debt shows up as brittle renewals, inconsistent revocation, and rushed migration work later. Practitioners should treat every unmanaged certificate and manual trust dependency as deferred PQC risk.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• The lifecycle angle is developed further in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, which is the natural next step for teams modernising certificate and credential operations.

What this signals

Cryptographic transition debt: PQC is exposing a problem many identity programmes already carry. If certificates, secrets, and trust anchors are not centrally inventoried, every standard change becomes a manual rescue operation instead of a governed migration.

The next phase of readiness is less about watching NIST’s algorithm lists and more about proving that certificate and machine identity workflows can absorb change without service disruption. Teams that cannot rotate, revoke, or reissue at speed will discover that crypto-agility is an operating model, not a feature.

For identity leaders, the signal is clear: certificate lifecycle automation now belongs in the same conversation as workload identity and zero trust. The programmes that align those controls early will have the most room to absorb future cryptographic change without emergency remediation.

For practitioners

• Build a full cryptographic inventory Map certificates, trust anchors, protocols, and systems that depend on them before planning any PQC change. Include machine identities, embedded libraries, and policy dependencies so hybrid migration does not expose hidden trust paths.
• Automate certificate lifecycle controls Move issuance, renewal, revocation, and policy enforcement into central workflows so crypto changes do not depend on manual coordination. Prioritise systems with high renewal frequency or business-critical trust relationships.
• Classify hybrid dependencies by migration risk Rank applications and services by how difficult they will be to move from classical to post-quantum trust. Use that view to sequence changes for the most exposed machine identities first.
• Test rollback and exception handling now Validate how teams will respond if a new PQC scheme, certificate policy, or vendor update breaks a trust chain. Build exception paths that preserve availability without creating permanent non-compliant shortcuts.

Key takeaways

• PQC migration is a lifecycle and operations problem, not only a standards problem.
• Incomplete inventories and manual certificate processes are the main blockers to crypto-agility at enterprise scale.
• Machine identity governance has to absorb cryptographic change continuously, or hybrid trust will become brittle.

Key terms

• Crypto-agility: The ability to change cryptographic algorithms, certificates, and related policies without redesigning the surrounding system. In practice, it means an organisation can absorb standards changes, vendor updates, and new trust requirements while keeping services available and governed.
• Hybrid cryptography: A transition state where classical and post-quantum cryptographic schemes operate in parallel. It is common during standards migration and increases operational complexity because different applications, devices, and trust chains may move at different speeds.
• Certificate lifecycle management: The governance process that covers issuance, renewal, revocation, policy enforcement, and inventory control for certificates. Strong lifecycle management is what makes cryptographic transitions manageable because it keeps trust relationships visible and changeable across the estate.
• Machine identity: A non-human identity used by software, devices, or workloads to authenticate and establish trust. Machine identities often rely on certificates, keys, and signed assertions, which makes them central to PQC migration and especially sensitive to lifecycle and inventory gaps.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 governance maturity, it is worth exploring.

This post draws on content published by DigiCert: NIST advances post-quantum signature algorithms. Read the original.