What gets organisations stuck in PQC planning?

Why This Matters for Security Teams

PQC planning stalls when organisations try to treat cryptography as a simple algorithm swap instead of a dependency discovery problem. The real exposure is hidden in certificates, code signing, API clients, cloud services, backups, vendor integrations, and embedded systems, where crypto is often inherited rather than explicitly owned. That makes inventory, prioritisation, and change impact analysis the hard part, not the mathematics of post-quantum algorithms.

This is why current guidance in the NIST Cybersecurity Framework 2.0 emphasises asset visibility, governance, and risk prioritisation before control changes. NHI Management Group research shows the same pattern in adjacent identity domains: only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is a strong indicator of how often unseen machine dependencies block security programmes.

In practice, many security teams encounter PQC deadlock only after migration deadlines have been announced, rather than through intentional cryptographic discovery and dependency mapping.

How It Works in Practice

Effective PQC planning starts with cryptographic inventory, not procurement. Security teams need to find where asymmetric cryptography is used, which systems depend on it, how long assets must remain trusted, and which third parties will be affected by any change. That includes TLS termination, private CAs, device firmware, authentication flows, document signing, container pipelines, and application libraries that may be several layers removed from the business owner.

A practical approach is to build a system-by-system map of cryptographic use and then classify each dependency by business criticality, data sensitivity, and replacement complexity. The goal is to identify where hybrid deployment is needed, where algorithm agility already exists, and where legacy constraints will force redesign. NIST guidance and transition planning principles support this sequence, because cryptographic replacement without dependency discovery tends to create outages, failed handshakes, and broken trust chains.

In environments with mature NHI governance, that inventory should also include machine identities and secret stores, because certificates and API keys are often the operational glue that ties services together. The NHI Mgmt Group Ultimate Guide to NHIs highlights why this matters: if organisations cannot see service accounts, they also struggle to see the crypto attached to them. A useful planning sequence is:

• discover cryptographic dependencies across applications, devices, and supplier services;
• identify owner, expiry, and replacement path for each dependency;
• rank by business impact, not by technical novelty;
• pilot high-risk workloads where algorithm agility is already possible;
• test rollback, interoperability, and certificate renewal paths before broad rollout.

These controls tend to break down in hybrid estates with legacy appliances, unmanaged SaaS integrations, and outsourced software components because the cryptography is embedded too deeply for standard asset tools to see.

Common Variations and Edge Cases

Tighter cryptographic governance often increases operational overhead, requiring organisations to balance migration urgency against service stability and supplier constraints. That tradeoff is especially visible when long-lived certificates, regulated infrastructure, or embedded devices cannot be patched on a normal software cycle.

There is no universal standard for pqc readiness scoring yet, so current guidance suggests using practical tiers: immediate exposure, medium-term migration, and long-horizon remediation. Some teams focus first on internet-facing systems, while others prioritise data with long confidentiality lifetimes, such as health, financial, or intellectual property records. Both approaches are valid if the rationale is explicit and repeatable.

Another common edge case is vendor dependency. If a critical service provider has not published a PQC roadmap, the customer may still need contract language, inventory evidence, and fallback plans. This is also where broader identity governance helps, because machine credentials, certificates, and service accounts often fail together. The NHI Mgmt Group notes in the Ultimate Guide to NHIs that 92% of organisations expose NHIs to third parties, which makes supplier coordination a material part of PQC planning rather than an afterthought.

For teams trying to avoid stalling, the key question is not "which PQC algorithm should be chosen first?" but "which cryptographic dependencies would fail business services if changed tomorrow?"

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?