Why do post-quantum cryptography migrations stall even when the dependency inventory is complete?

Why This Matters for Security Teams

Post-quantum cryptography planning often looks straightforward on paper: find the dependencies, replace vulnerable algorithms, and validate the rollout. In practice, the hardest blocker is not discovery but governance. Even with a complete inventory, teams still need clear approval paths, change ownership, validation criteria, and residual risk acceptance. Without those decision rights, the migration becomes a queue of unresolved handoffs instead of an execution plan.

This is especially visible in environments where cryptography is embedded in service accounts, API keys, certificates, CI/CD pipelines, and third-party integrations. A full dependency list does not tell security teams who can safely change a library, who can approve a protocol downgrade exception, or who will own rollback if a release fails. That is why post-quantum work often resembles broader NHI failure patterns described in Ultimate Guide to NHIs, where visibility improves but operational control remains fragmented. The same pattern shows up in supply chain incidents such as the LiteLLM PyPI package breach, where dependency trust mattered as much as dependency knowledge.

Standards like ISO/IEC 27001:2022 Information Security Management and PCI DSS v4.0 reinforce the same operational truth: asset knowledge is necessary, but accountable control implementation is what moves risk. In practice, many security teams discover migration paralysis only after the inventory is finished and every team is waiting for another team to own the first change.

How It Works in Practice

A complete inventory should be treated as an input to governance, not a finish line. For post-quantum migration, teams need to translate each dependency into a decision tree: which cryptographic primitive is in use, whether it is customer-facing or internal, what breakage would occur if it changed, and which owner is empowered to approve the change. That requires explicit roles for architecture, application owners, security, platform engineering, and risk acceptance.

The practical sequence usually looks like this:

• Classify the dependency by business criticality and cryptographic exposure.
• Assign a named owner for implementation, testing, and rollback.
• Define the approval authority for exceptions and deferred remediation.
• Set validation criteria for interoperability, latency, and failure handling.
• Track temporary compensating controls while legacy algorithms remain in service.

That governance layer matters because post-quantum migration often touches identity and trust flows rather than isolated code. Certificates, authentication tokens, signing workflows, and third-party APIs can all create hidden coupling. A team may know every dependency, yet still be unable to move if no one can decide whether a hybrid-crypto transition is acceptable, whether a vendor update is mandatory, or whether a legacy endpoint can remain in place for one more release cycle. Guidance from the NHI domain is useful here because it emphasizes ownership, lifecycle control, and credential governance rather than inventory alone, as reflected in the Ultimate Guide to NHIs.

Current guidance suggests pairing the inventory with a decision register so each cryptographic dependency has a clear approver, implementer, tester, and risk owner. These controls tend to break down when dependencies sit inside vendor-managed services or shared platforms because no single team can safely change the implementation without coordination from upstream providers.

Common Variations and Edge Cases

Tighter governance often increases coordination cost, requiring organisations to balance migration speed against approval rigor. That tradeoff becomes most visible in regulated systems, high-availability services, and vendor-dependent stacks, where a rushed crypto replacement can create outages or compliance gaps.

One common edge case is a dependency that is inventory-complete but operationally opaque. For example, a library may be known, but the application team may not control the runtime, the vendor may not expose a PQ-ready roadmap, and the security team may not have authority to force a replacement. Another edge case is hybrid cryptography, where teams defer the final cutover because they want backward compatibility. That can be sensible, but only if there is a planned exit date and a named owner for the legacy path.

There is no universal standard for this yet, but current guidance increasingly treats post-quantum migration as a lifecycle governance problem rather than a one-time technology swap. The real stall point is usually decision latency, not technical difficulty. When organisations do not preassign authority for exceptions, validation, and rollback, inventory completeness can create the illusion of readiness while execution remains blocked.

Related resources from NHI Mgmt Group

• Why do post-quantum projects stall even when the risk is understood?
• Why do non-human identities create compliance risk even when policies exist?
• How should organisations prepare IAM for post-quantum cryptography?
• How should security teams prepare APIs for post-quantum cryptography?