Quantum readiness gaps expose identity and cryptography governance

At a glance

What this is: This is a survey-based view of post-quantum cryptography readiness, finding that many organisations still lack a plan for the cryptographic transition that quantum computing will force.

Why it matters: It matters because PQC readiness affects certificate lifecycle management, trust architecture, and identity programmes that depend on public-key cryptography across human, machine, and workload access.

By the numbers:

• Nearly half of organisations (48%) are not prepared to confront the urgent challenges posed by quantum computing.
• Mid-sized organizations are particularly vulnerable, with 56% saying they are not ready.
• Companies that view PQC as a significant undertaking are more than twice as likely to be taking steps now (49%) compared to those that consider the risks to be minor or overstated (24%).

👉 Read Keyfactor's findings on PQC readiness and digital trust

Context

Post-quantum cryptography is the shift away from public-key cryptographic algorithms that quantum computers are expected to weaken or break. For identity teams, that is not a distant cryptography issue. It affects certificates, signing, federation, workload identity, and every trust decision built on keys that must survive long-lived systems.

Keyfactor's survey shows a familiar governance pattern: organisations recognise the risk unevenly, but action lags when the problem is treated as abstract or remote. That gap creates a planning problem for IAM, PKI, and platform teams, because cryptographic dependencies are embedded across human identity, NHI, and machine-to-machine trust paths.

The organisations least ready are often the ones with the least room for error. Mid-sized firms, in particular, tend to have less specialised cryptography capacity, fewer spare engineering cycles, and more legacy dependencies, which makes the PQC transition an operational programme rather than a narrow technical upgrade.

Key questions

Q: How should security teams prepare for post-quantum cryptography in identity systems?

A: Start by mapping every place public-key cryptography supports authentication, signing, federation, and workload trust. Then prioritise the longest-lived and most business-critical dependencies, because those are the systems most likely to fail during a rushed transition. PQC preparation succeeds when it is tied to ownership, lifecycle processes, and testable migration paths, not just a technology refresh.

Q: Why do certificate and trust dependencies make PQC hard to deliver?

A: Because cryptographic algorithms are embedded in many different control points, and those dependencies are often hidden inside applications, appliances, and identity workflows. Once a library, certificate profile, or signing method is fixed in place, changing it can break authentication or trust chains. The harder the dependency is to see, the harder it is to migrate safely.

Q: What should organisations measure to know if PQC planning is working?

A: Measure discovery completeness, asset ownership, algorithm flexibility, and the number of long-lived trust paths still tied to current public-key schemes. A PQC programme is moving in the right direction when teams can explain where cryptography is used, who owns it, and which systems can be switched without redesigning the whole environment.

Q: Who should own post-quantum cryptography readiness across the enterprise?

A: PQC readiness should be owned jointly by security, identity, PKI, platform, and application teams, with clear executive sponsorship. If ownership sits only with security, the migration stalls at inventory and risk assessment. The organisations that move fastest treat PQC as an enterprise trust programme with named operational owners, not a specialist side project.

Technical breakdown

Why post-quantum cryptography changes identity trust models

PQC matters because identity systems depend on cryptography for authentication, signature validation, federation, and device or workload trust. When current public-key algorithms become unsafe, the issue is not only encrypted data at rest. It is the entire chain of trust that allows certificates, tokens, signed artefacts, and federated sessions to remain credible over time. That makes PQC a lifecycle problem as much as a crypto problem, because certificates and keys are issued, renewed, replaced, and retired across multiple control planes.

Practical implication: map where public-key trust underpins identity and prioritise the longest-lived dependencies first.

Cryptographic agility is the control that decides transition speed

Cryptographic agility means being able to swap algorithms, certificate profiles, and trust dependencies without redesigning every system. In practice, many enterprises lack that flexibility because cryptographic choices are hardcoded into applications, appliances, and identity workflows. When the algorithm changes, the surrounding operational assumptions often do not. That is why PQC readiness is less about announcing support and more about whether a platform can migrate without breaking authentication, signing, or device trust at scale.

Practical implication: inventory where algorithm choices are fixed in code, policy, or hardware before you set any transition timeline.

Certificate lifecycle management is where PQC work becomes real

Most of the work lands in certificate lifecycle management, where issuance, renewal, rotation, revocation, and discovery have to be coordinated across many environments. PQC increases the number of things that can go wrong because longer key sizes, new algorithms, and mixed-mode deployments all add operational friction. If teams do not already know where certificates exist and who owns them, they will struggle to sequence the migration. The transition is therefore a governance programme with cryptographic consequences, not a cryptography project with governance as an afterthought.

Practical implication: tie PQC planning to certificate discovery, ownership, and renewal workflows rather than treating it as a one-time migration.

Threat narrative

Attacker objective: The attacker aims to undermine cryptographic trust at scale by breaking the algorithms that protect identity, data, and system integrity.

1. Entry occurs through the organisation's existing dependence on public-key cryptography for authentication, signing, and secure communications.
2. Escalation follows when quantum-capable adversaries can exploit weak or obsolete algorithms across identity, certificate, and trust workflows.
3. Impact is the collapse of trust in encrypted sessions, signed artefacts, and long-lived data that depended on those algorithms remaining secure.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

PQC readiness is an identity governance problem before it is a cryptography upgrade. Public-key algorithms sit underneath certificates, federation, workload trust, and signed software flows, which means the transition reaches into IAM, PKI, and NHI governance at the same time. Teams that treat it as a security lab exercise will miss the ownership, lifecycle, and dependency questions that actually determine delivery. Practitioners need to plan the cryptographic transition as part of identity operating model change.

Cryptographic agility is becoming the real control point. The survey's split between organisations that are acting now and those waiting for urgency shows that policy intent is not the limiting factor. The limiting factor is whether systems can change algorithms without brittle rebuilds, certificate outages, or trust chain failures. That makes agility the practical determinant of whether a PQC programme can move from roadmap to execution.

Certificate lifecycle debt will define which organisations move first. Organisations with poor discovery, weak ownership, and inconsistent renewal discipline will find PQC harder because they cannot see where the old algorithms live. That is not a technology gap alone. It is a lifecycle and accountability gap that magnifies every migration step. Practitioners should assume the hardest part of PQC is the inventory they have never fully completed.

Mid-market readiness gaps are a governance signal, not just a resourcing symptom. When 56% of mid-sized organisations say they are not ready, the pattern points to structural underinvestment in cryptographic ownership, not simply a lack of awareness. Smaller teams often carry more legacy debt and fewer specialised roles, which means PQC will expose where identity and trust responsibilities were never clearly assigned. The implication is that governance structures will need to mature before technical migration can keep pace.

Strong security teams are already reframing PQC as business continuity. The survey shows that organisations responding now are more likely to act when they see the transition as material rather than theoretical. That is the right signal for identity leaders, because cryptography failure would not stay within the security team. It would affect customer trust, service continuity, and regulatory defensibility across the whole digital trust stack. Practitioners should elevate PQC from roadmap item to enterprise resilience agenda.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That confidence gap is exactly why teams should review Ultimate Guide to NHIs , Key Challenges and Risks before they build their next trust and lifecycle roadmap.

What this signals

Cryptographic transition planning will increasingly sit inside identity governance rather than pure infrastructure work. That shift matters because the failure mode is not a single broken algorithm but a portfolio of trust dependencies spread across certificates, federation, and workload identity. Teams that already manage lifecycle, ownership, and discovery well will have a clearer path to PQC than teams still relying on undocumented trust chains.

Certificate visibility will become a board-level readiness indicator. If you cannot explain where certificates live, who owns them, and which systems depend on them, you do not yet have a credible quantum-readiness programme. The organisations that can map trust dependencies early will be able to sequence the migration with less operational risk and stronger defensibility.

PQC readiness should be treated as part of identity resilience, not as a stand-alone cryptography project. The practical task is to connect discovery, ownership, and lifecycle management to the systems that carry trust today. That is where the real programme acceleration happens, and it is why identity teams should engage now rather than waiting for a crisis signal.

For practitioners

• Inventory cryptographic dependencies across identity systems Map where certificates, signatures, federation, and workload trust depend on current public-key algorithms. Include external identities, internal applications, and device trust paths so the migration scope reflects real exposure rather than only obvious infrastructure.
• Assign ownership for PQC migration by control domain Name accountable owners for PKI, IAM, application teams, platform teams, and risk management. The work fails when cryptography is treated as nobody's job, so build an explicit ownership model before you set deadlines.
• Test algorithm replacement in long-lived trust flows Pilot replacement in the systems that cannot fail closed, such as certificate validation, signing pipelines, and federation dependencies. Focus on where legacy algorithms are hardcoded so you can measure the operational blast radius early.
• Use certificate lifecycle management as the execution backbone Link PQC planning to discovery, renewal, revocation, and rotation workflows. That lets teams move from abstract readiness to operational control, and it exposes where hidden certificates or orphaned trust chains could delay migration.

Key takeaways

• The report shows a readiness gap, but the deeper issue is governance maturity across cryptographic trust dependencies.
• Nearly half of respondents said they are not ready for the quantum transition, and mid-sized organisations lag even further behind.
• Teams that can inventory, own, and migrate certificate and trust dependencies will be better placed to handle the PQC transition without destabilising identity services.

Key terms

• Post-Quantum Cryptography: Post-quantum cryptography is a set of cryptographic algorithms designed to remain secure against attacks from quantum computers. For identity teams, it affects certificates, signing, federation, and other trust services that depend on public-key cryptography today.
• Cryptographic Agility: Cryptographic agility is the ability to replace one algorithm, key type, or certificate profile with another without redesigning the entire system. In practice, it depends on flexible code, policy, and lifecycle controls that can absorb change without breaking identity services.
• Certificate Lifecycle Management: Certificate lifecycle management is the process of discovering, issuing, renewing, rotating, revoking, and retiring certificates across an environment. It becomes critical in PQC planning because migration success depends on knowing where trust exists and who owns it.

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 Keyfactor: Keyfactor finds nearly half of enterprises unprepared for quantum cybersecurity threats. Read the original.