Why do post-quantum cryptography programmes often stall after strategy and planning?

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 This Matters for Security Teams

Post-quantum cryptography programmes often stall because they begin as an algorithm-selection exercise instead of an operational change programme. The real work is inventorying where cryptography is used, identifying owners, and proving that upgrades can be deployed without breaking production systems. Current guidance suggests that PQC readiness depends on governance and control enforcement as much as on cryptographic strength, which is why a programme can look credible in a steering committee and still fail to move beyond planning.

That failure mode is familiar across identity and secrets-heavy environments. The same visibility gaps that affect non-human identities show up in cryptographic estates: keys in code, certificates embedded in services, and ownership spread across teams with no shared lifecycle process. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, a useful proxy for how often invisible assets derail otherwise sound security plans. For broader control expectations, teams can map early programme assumptions against PCI DSS v4.0 and ISO/IEC 27001:2022 Information Security Management, both of which reinforce governance, ownership, and demonstrable control operation. In practice, many security teams encounter PQC delay only after inventory gaps and change-control friction have already turned a strategy into shelfware.

How It Works in Practice

A working PQC programme starts with discovery, not migration. Security teams need to identify where RSA, ECC, TLS, certificate chains, code signing, VPNs, HSMs, PKI, and secrets management workflows depend on vulnerable primitives. That inventory has to be specific enough to answer three questions: what cryptographic mechanism is in use, who owns the system, and how quickly can it be changed. Without that, there is no trustworthy migration path.

From there, the programme should separate exposure from upgradeability. Some systems can be made crypto-agile through configuration, while others require code changes, vendor remediation, or hardware refresh cycles. A practical approach is to classify systems by business criticality and replacement complexity, then pilot the least disruptive migrations first. This is where policy and process matter more than slogans. NHIMG’s Ultimate Guide to NHIs is relevant because cryptographic control often fails for the same reason secrets governance fails: no one can prove where the asset lives, who can use it, or how it gets retired. The operating model should therefore include:

• cryptographic inventory tied to service ownership
• migration tiers based on risk and engineering effort
• test environments that validate interoperability before production change
• change windows and rollback plans for certificates, libraries, and protocols
• exception handling for legacy systems that cannot move immediately

Programme leads should also establish crypto-agility requirements for procurement and architecture reviews so new systems do not hard-code today’s algorithms into tomorrow’s risk. Current guidance suggests treating this as a lifecycle control, not a one-time transformation project. These controls tend to break down when legacy applications, vendor-managed appliances, and embedded systems cannot be patched or recompiled without unacceptable downtime.

Common Variations and Edge Cases

Tighter crypto governance often increases delivery overhead, requiring organisations to balance migration speed against operational stability. That tradeoff becomes more visible in mixed estates where some services are cloud-native, some are packaged, and some are deeply embedded in industrial or regulated environments. Best practice is evolving, but there is no universal standard for sequencing every PQC migration yet, especially where third-party dependencies dominate the stack.

One common edge case is vendor lock-in. If a vendor controls the crypto implementation, the internal programme may be reduced to contract management, assurance testing, and waiting for roadmap delivery. Another is certificate-heavy environments, where the first bottleneck is not the future algorithm but the present-day renewal process, trust store sprawl, and inconsistent expiration handling. Teams should also expect parallel workstreams: building inventory, updating standards, training engineers, and revising procurement language. NHIMG’s research on Ultimate Guide to NHIs shows how hidden assets and weak offboarding processes create persistent exposure, and the same pattern applies to cryptographic artefacts that are never fully retired. In practice, PQC programmes stall when ownership is split across infrastructure, application, and risk teams, because no single group can safely make the production change happen.

Related resources from NHI Mgmt Group

• Why do crypto agility requirements matter when planning post-quantum cryptography migration?
• Who is accountable for planning post-quantum cryptography adoption across PKI, signing, and key management?
• Why do machine identities matter in post-quantum cryptography planning?
• Why do Zero Trust programmes often stall after the first few wins?