What breaks when organisations treat cryptography inventory as enough for PQC readiness?

A raw list of certificates or keys does not show which systems depend on them, who owns them, or what business services would be affected by replacement. Without that context, teams can mis-rank priorities, miss hidden dependencies, and stall migration planning. PQC readiness needs context-rich visibility, not spreadsheet counting alone.

Why This Matters for Security Teams

Cryptography inventory is a useful starting point, but it is not a readiness plan. A list of certificates, keys, and algorithms does not reveal where those assets are embedded, which applications depend on them, or what happens if a certificate authority, device trust chain, or signing workflow changes. PQC migration is therefore a dependency and service-risk problem, not just a crypto catalog problem.

Security teams that stop at inventory often misclassify the hardest systems: legacy appliances, embedded platforms, internal APIs, code-signing pipelines, and third-party integrations that are easy to miss until replacement work starts. That gap matters because PQC adoption will touch operational controls, change windows, vendor contracts, and rollback planning. Guidance from ISO/IEC 27001:2022 Information Security Management reinforces that asset awareness must support risk treatment, not sit apart from it, and the Ultimate Guide to NHIs shows why ownership and lifecycle context are essential when identities and secrets drive service dependencies. In practice, many security teams encounter PQC exposure only after a renewal event, vendor constraint, or outage has already turned “inventory complete” into “migration blocked.”

How It Works in Practice

Effective pqc readiness starts by mapping cryptographic assets to the systems and business services they protect. That means identifying where certificates, keys, and trust anchors are used for TLS, signing, code distribution, device identity, service-to-service authentication, and administrative access. The inventory must then be enriched with ownership, environment, expiration, algorithm, dependency, and replacement path data so teams can rank migration effort by business impact rather than by count.

A practical approach is to treat the inventory as one layer in a wider dependency model:

• Classify each cryptographic asset by use case, lifecycle stage, and criticality.
• Map each asset to its consuming applications, hosts, services, and external partners.
• Record the control plane that issues, stores, rotates, or revokes it.
• Link each item to an owner who can approve change, test replacement, and accept risk.
• Separate near-term migration blockers from longer-term modernization work.

This is consistent with the control logic in PCI DSS v4.0, which expects cryptographic protections to be governed as part of a broader security program, not as isolated artifacts. The same lesson appears in NHIMG’s Ultimate Guide to NHIs: visibility is only useful when it connects to lifecycle control, ownership, and revocation. For PQC, that context determines whether a system can swap algorithms, dual-stack for transition, or remain on legacy cryptography until the application itself is rebuilt. These controls tend to break down when cryptography is embedded in unmanaged firmware, hard-coded libraries, or third-party services because the team cannot change the dependency without vendor coordination.

Common Variations and Edge Cases

Tighter crypto inventory often increases operational overhead, requiring organisations to balance faster discovery against the cost of maintaining accurate dependency data. That tradeoff becomes more visible in mixed estates where modern PKI tooling, legacy appliances, and cloud-managed services all use different renewal and replacement processes.

Current guidance suggests that not every asset should be remediated in the same order. High-risk internet-facing services, code-signing systems, and long-lived trust anchors usually deserve earlier attention than low-impact internal certificates. There is no universal standard for PQC sequencing yet, so teams should use business criticality, exposure, and replacement complexity to set priorities. That is especially important when secrets are embedded in CI/CD pipelines, because a cryptographic change can disrupt build integrity long before a production service fails.

Another edge case is vendor dependency. Some platforms will not support PQC algorithms on your timeline, which means readiness may require contract management, compensating controls, or phased coexistence rather than immediate replacement. The Ultimate Guide to NHIs is useful here because it frames identities and secrets as operational assets that must be owned and rotated, not merely counted. The core failure is assuming a complete list equals a complete plan. It does not, especially when the migration path crosses embedded systems, external dependencies, or regulated environments with fixed change windows.

Related resources from NHI Mgmt Group

• What breaks when organisations treat a business continuity plan as enough for breach readiness?
• When should organisations treat an NHI as a high-priority risk?
• What breaks if organisations treat cryptography as static infrastructure?
• What breaks when teams treat a PQC scan as full readiness?