How should organisations start PQC migration when they do not know where cryptography is used?

Start with a cryptographic inventory that maps algorithms, keys, certificates, and the identities that depend on them. Without that dependency map, migration planning becomes guesswork, and teams cannot estimate blast radius, prioritise vulnerable systems, or sequence changes safely. Inventory is the control that turns PQC from a theoretical deadline into an executable programme.

Why This Matters for Security Teams

Post-quantum migration cannot start at the algorithm layer if the organisation does not know where cryptography is used. The first real task is discovering which applications, services, certificates, keys, and identities depend on each cryptographic primitive, because those dependencies define business impact and rollback risk. That is especially true for NHI-driven systems, where service accounts, API keys, and automation paths often hide the longest-lived trust relationships. NHI Mgmt Group’s Ultimate Guide to NHIs notes that 68% of organisations do not know how to fully address NHI risks, which is a useful signal for how often hidden identity dependencies are missed.

Security teams also need a dependency map because a cryptographic control rarely sits in one place. It spans TLS, code signing, secure boot, secrets storage, identity federation, and third-party integrations. If that map does not exist, migration plans become speculative instead of executable. For context on how credential exposure turns into real damage, the Schneider Electric credentials breach is a reminder that identity and secret exposure can move faster than governance processes can react. In practice, many security teams encounter cryptography dependencies only after a certificate outage, a supplier issue, or a renewal failure has already forced emergency work.

How It Works in Practice

Start with inventory, but make it a dependency inventory rather than a simple list of algorithms. The goal is to identify where cryptography exists, what it protects, who or what relies on it, and how quickly it can be replaced. That means mapping certificates to workloads, keys to applications, secrets to pipelines, and identities to the trust chains they use. Current guidance from standards bodies such as PCI DSS v4.0 reinforces that control evidence should be traceable, but PQC planning goes further by asking what breaks when one primitive changes.

A practical sequence is:

• Discover cryptography in code, configuration, infrastructure, endpoints, and third-party integrations.
• Classify each dependency by algorithm, key length, certificate type, expiry, and business criticality.
• Identify identities that consume the cryptography, including workload identities, service accounts, and automation keys.
• Record replaceability: whether the component can support hybrid modes, dual-stack negotiation, or only a full cutover.
• Prioritise externally exposed, long-lived, or hard-to-patch systems first.

This is where the NHI lens matters. If an API key, certificate, or workload credential is embedded in a CI/CD path, that path may need redesign before PQC can be adopted safely. The Ultimate Guide to NHIs highlights how widespread non-human identity sprawl is, and that sprawl often mirrors cryptographic sprawl. For teams building a phased plan, that means pairing discovery with ownership, rotation, and offboarding data so the migration backlog is aligned to real operational risk. These controls tend to break down in highly distributed environments with unmanaged third-party dependencies and undocumented embedded devices because the cryptography cannot be enumerated reliably.

Common Variations and Edge Cases

Tighter cryptographic governance often increases discovery overhead, requiring organisations to balance migration speed against operational disruption. That tradeoff is especially sharp when systems are legacy, vendor-managed, or embedded, because the team may not control the code paths that use the cryptography. In those cases, current guidance suggests a parallel track: inventory first, then segment systems into those that can adopt hybrid PQC quickly and those that need compensating controls until replacement is feasible.

There is no universal standard for this yet on every platform, so teams should avoid treating “PQC ready” as a single badge. A certificate authority, a device fleet, and an internal API gateway can each fail for different reasons. Secrets management also matters because cryptographic migration often exposes hidden static credentials, and those credentials may be more urgent to fix than the algorithm itself. NHI Mgmt Group’s research also shows that only 5.7% of organisations have full visibility into their service accounts, which helps explain why cryptographic dependency maps so often omit the identities that will actually break first.

For regulated environments, the practical answer is to treat inventory quality as part of the migration control set, not a pre-task. That is the only way to sequence remediation, validate readiness, and prove progress to auditors and leadership at the same time.

Related resources from NHI Mgmt Group

• How can organisations know whether Linux IoT security controls are actually working?
• How do organisations know whether a replacement will preserve governance quality?
• How do organisations know if privileged access governance is keeping up with hybrid cloud change?
• How do organisations know whether service desk access handling is actually working?