Why do organisations overestimate their readiness for post-quantum cryptography?

Why This Matters for Security Teams

Post-quantum cryptography readiness is often overestimated because organisations mistake policy intent for deployment reality. A strategy deck can name owners, but that does not mean certificates, embedded libraries, hardware modules, and third-party dependencies are inventory-complete or testable. The same gap appears across non-human identity governance: NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is a useful warning sign for cryptography programmes as well.

For PQC, the issue is less about knowing that quantum risk exists and more about proving that an enterprise can find every crypto dependency, change it without breaking production, and verify that the change actually holds under load. Leaders often see a cleaner architecture than the one operators maintain, especially where certificates are tied to application release cycles, legacy appliances, or managed services. Compliance language can reinforce false confidence, because a requirement to assess risk is not the same as a tested migration plan. Current guidance from ISO/IEC 27001:2022 Information Security Management and PCI DSS v4.0 supports control discipline, but neither one removes the need for operational evidence. In practice, many security teams discover their actual cryptographic exposure only after a platform upgrade, certificate outage, or vendor notice has already forced the question.

How It Works in Practice

Readiness for post-quantum cryptography depends on four practical capabilities: asset discovery, algorithm agility, change control, and validation. First, teams need a complete inventory of where cryptography exists, including applications, APIs, service accounts, secrets stores, CI/CD pipelines, and devices that use long-lived certificates or embedded libraries. Second, they need algorithm agility, meaning systems can replace one cryptographic primitive without a full redesign. Third, migration must be staged so that hybrid operation, rollback, and compatibility with external partners are all tested before enforcement. Fourth, teams need proof, not assumptions, that key exchange, signing, latency, and interoperability still work after the change.

This is where the analogy to NHI governance becomes useful. If an organisation cannot reliably track and rotate machine credentials, it is unlikely to track every place where cryptographic dependencies are hard-coded or inherited. The Ultimate Guide to NHIs highlights how common it is to store secrets in vulnerable locations and to leave them valid long after they should be retired. PQC programmes fail in the same way when they assume a central team can swap algorithms centrally, while the real dependency is buried in application code, device firmware, or a vendor-controlled integration.

• Map every cryptographic dependency to an owner, system, and lifecycle state.
• Test hybrid deployments before a production mandate is issued.
• Validate certificates, libraries, and firmware that may not support PQC at the same pace.
• Use change windows to measure performance impact, not just functional success.

Best practice is evolving toward repeatable crypto-agility exercises rather than one-time assessments. These controls tend to break down in distributed environments with inherited vendor components and undocumented embedded systems because the migration path is not fully under enterprise control.

Common Variations and Edge Cases

Tighter cryptographic governance often increases operational overhead, requiring organisations to balance migration speed against service stability and third-party readiness. That tradeoff is especially visible in hybrid estates, where some systems can support modern libraries quickly while others depend on appliances, embedded firmware, or regulatory-approved configurations that move slowly.

There is no universal standard for PQC cutover sequencing yet, so teams should avoid treating awareness campaigns as proof of readiness. A strong programme will separate three questions: what must be changed, what can be proxied or fronted, and what must remain in legacy mode until the dependency is replaced. This matters for certificates, code signing, VPNs, supply chain integrations, and machine-to-machine trust. It also matters for the broader non-human identity surface, because crypto migration usually touches service accounts, API keys, and automated workflows that are already under-governed. The same operational blind spots described in the Ultimate Guide to NHIs often reappear here: unclear ownership, incomplete visibility, and too much confidence in documents that have never been exercised in production.

Where organisations do better, they usually start with high-value trust paths and external dependencies, then build test evidence before expanding scope. A readiness claim is credible only when it survives dependency discovery, migration rehearsal, and rollback testing with real operators involved.

Related resources from NHI Mgmt Group

• How should organisations prepare IAM for post-quantum cryptography?
• How should organisations start migrating to post-quantum cryptography without replacing everything at once?
• Why do shorter certificate lifetimes matter for post-quantum cryptography readiness?
• Post-Quantum Cryptography Readiness