They stall when organisations cannot see their cryptographic estate clearly, assign ownership, or change controls safely at scale. PQC readiness is less about picking an algorithm early and more about fixing operational gaps in visibility, governance, and enforceability. Without those basics, teams end up with plans that look sound on paper but never become repeatable change in production.
Why PQC programmes get stuck after the slide deck
Post-quantum cryptography programmes often fail at the point where strategy must become engineering. The hard part is not writing a migration vision, but discovering where cryptography actually lives, which systems depend on it, and who can change it without breaking service. That makes PQC a governance and operationalisation problem as much as a technical one. The planning phase can look complete while the organisation still lacks inventory quality, change authority, testing pathways, and rollout sequencing. PCI DSS v4.0 reinforces how cryptographic controls only help when the supporting process is enforceable, not merely documented. In practice, many security teams encounter PQC resistance only after they try to turn a roadmap into platform changes, certificate replacement, or application updates.
How programme plans turn into production friction
PQC stalls because the work is cross-cutting and the dependencies are easy to underestimate. A single cryptographic algorithm change can touch libraries, certificate authorities, hardware security modules, API integrations, device firmware, vendor-managed services, and application release cycles. If the estate is not mapped well enough to show where algorithms, key lengths, protocols, and trust chains are used, teams cannot rank migration order or estimate blast radius. That is why “PQC ready” is usually a misleading label before operational discovery is complete.
The practical sequence is usually more constrained than leaders expect:
- First, identify where cryptography is embedded in business-critical paths, not just in published standards.
- Then, determine which controls are owned internally and which are inherited from vendors, platforms, or outsourced operations.
- Next, test whether candidate replacements can be deployed without breaking interoperability, latency targets, or device support.
- Finally, prove that change can be repeated through normal release and exception processes, rather than as a one-off project.
That last step is where many programmes slow down. If a team can only migrate a small subset of services by hand, the programme is not yet a programme. It is a series of isolated repairs. ISO/IEC 27001:2022 Information Security Management is relevant here because PQC succeeds only when cryptographic change is governed as a managed system, with clear responsibility, evidence, and repeatable control operation. The guidance breaks down when organisations treat cryptography as a central security team task instead of an estate-wide change that must be absorbed by engineering, infrastructure, procurement, and risk owners.
Where migration complexity and ownership gaps create the real blockage
Tighter cryptographic assurance often increases coordination overhead, requiring organisations to balance stronger future security against present-day operational change capacity.
The main edge cases are not about algorithm choice. They are about where the estate is inconsistent or partially outsourced. Hybrid environments, legacy appliances, embedded devices, and third-party integrations often create pockets where PQC cannot be introduced on the same timeline as modern applications. In those cases, the right answer is usually not to force uniform rollout. It is to classify systems by migration difficulty, exposure, and dependency depth, then accept that some areas need compensating controls or staged coexistence.
A second common variation is policy drift between strategy and enforcement. Teams may agree that cryptography must be upgraded, but no one can compel changes across application teams, business units, or suppliers. That is not a cryptography problem alone. It is an ownership and control-enforcement problem. The industry still lacks full consensus on the best migration pattern for every estate, especially where long-lived devices or external dependencies are involved, so practitioners should avoid assuming that one migration model fits all systems.
Another edge case is false confidence from lab success. A pilot that works in a controlled environment can fail in production because of certificate chains, performance overhead, unsupported clients, or fragile dependencies. The programme stalls when those failures are discovered too late. In practice, the migration path becomes viable only when teams can prove repeatable change across the messiest parts of the estate, not just the cleanest ones.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | PQC planning stalls when the cryptographic estate and business context are not visible. |
| GV.RM-01 — Risk Management Strategy | PQC needs explicit risk-based prioritisation across systems and timelines. | |
| GV.RR-03 — Roles, Responsibilities, and Authorities | Ownership gaps commonly block execution of cryptographic changes. | |
| Recommendation — Map cryptographic dependencies to business services before setting the migration sequence. Use risk-based prioritisation to stage migration by exposure and operational criticality. Assign clear authority for cryptographic changes across platform, app, and supplier owners. | ||
| CIS Controls v8 | 5 — Account Management | PQC migration depends on knowing which teams and suppliers can enforce change. |
| 12 — Network Infrastructure Management | Protocol, certificate, and trust-path changes often surface in infrastructure dependencies. | |
| Recommendation — Centralise ownership and approval paths so cryptographic updates can be executed consistently. Review infrastructure dependencies before changing protocols or trust chains in production. | ||
| ISO/IEC 42001:2023 | 6.1 — Actions to Address Risks and Opportunities | PQC programmes need governed treatment of migration risk and operational constraints. |
| Recommendation — Convert PQC risk assessments into governed actions, owners, and tracked delivery milestones. | ||
Practitioner Guidance
What to prioritise: Treat cryptographic inventory quality and ownership mapping as the first deliverables, not supporting tasks. If the programme cannot answer where cryptography is used and who can change it, every later milestone is provisional.
Decision rule: If a system cannot be updated without breaking availability, interoperability, or supplier commitments, classify it as a controlled migration problem rather than a standard upgrade. That distinction changes sequencing, testing, and exception handling.
What to verify: Confirm that the organisation can make the same cryptographic change more than once through normal release processes. One successful pilot is not evidence of readiness; repeatability is.
Common mistake: Teams often overinvest in policy statements and underinvest in control ownership, testing scope, and operational rollback. That produces a roadmap that is technically credible but procedurally non-executable.
Practitioner takeaway: PQC programmes stall when leaders confuse strategic intent with deployable control change; progress depends on proving that cryptographic updates can be discovered, governed, tested, and rolled out repeatedly across the real estate.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
