From Inventory to Action: Making Cryptography Governable

Post-quantum migration becomes manageable when an organization can connect a cryptographic use to the data and service it protects, the people and suppliers who control it, and the change path that can replace it. The subject here is the operating program behind crypto agility: how discovery, prioritization, policy, implementation, and measurement turn a scattered set of cryptographic dependencies into decisions that can be owned and repeated. The goal is not a perfect list; it is enough reliable context to act without treating an algorithm name as a risk assessment.

Inventory the use, not just the algorithm names

A static list of algorithms answers only one question: which mathematical choices appear somewhere in the environment? It does not say what those choices protect, whether they are negotiated or fixed, who depends on them, how long the data must remain secure, or whether the component can be updated. NIST's proposed strategic plan therefore starts with an assets-centric inventory informed by data criticality. The object being inventoried is the protected use and its dependencies, not an isolated string in a configuration file.

For an Internet-facing service, that use may span a client connection, an edge proxy, a server library, a certificate and trust path, a key store, and the application that receives the resulting session. For an enterprise device, it may include firmware authentication, secure boot, stored data, and links to a management service. The earlier architecture distinctions matter here because the inventory needs to record where the cryptographic state lives and which boundary can change it. A library, a kernel, a hardware module, and a supplier-controlled service may all participate in one protected operation while having different owners and refresh cycles.

Data criticality gives the inventory a reason to exist. A cryptographic dependency protecting long-lived confidential records may deserve earlier attention than one protecting a short-lived, low-value session. A device identity or signed update that must remain trustworthy for the device's lifetime creates a different priority from a credential that can be reissued during a controlled service deployment. The sources do not provide a universal scoring formula, and an organization should not pretend that one ranking works for every mission. They do support a disciplined connection between what matters, how exposed it is, and how difficult it will be to change.

The inventory should also capture dependencies that are easy to miss when teams document only their own systems. A service can inherit PQC behavior from an underlying TLS library. A cloud workload can depend on provider hardware or an HSM service. A certificate can remain valid in many relying parties after the server team has changed its software. A legacy application can contain cryptographic code that its current maintainers no longer understand. A supplier may control firmware, validation, or a hardware refresh that the organization cannot accelerate through its own release process. These are not peripheral details; they determine whether a migration action will propagate.

Automated discovery can make this work more repeatable. NIST points to gaps in asset, configuration, vulnerability, and log-management tools and recommends enhancing them where necessary to identify cryptographic algorithms and key lengths across code, libraries, applications, hardware, and protocols.