Why do organisations need a crypto bill of materials before planning post-quantum migration?

Why This Matters for Security Teams

Post-quantum migration is not just a cryptography refresh. It is an inventory problem, a dependency problem, and a risk-prioritisation problem. Without a crypto bill of materials, teams cannot see where algorithms are embedded in applications, certificates, libraries, firmware, or third-party services, so they end up planning from assumptions instead of evidence. That creates a false sense of readiness and usually leaves legacy cryptography hidden in places that matter most.

For security leaders, this is especially important because cryptography often supports non-human identities, not just data in transit. Secrets, service accounts, signing keys, and automation workflows can all depend on algorithms that will age poorly under quantum pressure. NHI Management Group’s Ultimate Guide to NHIs notes that 96% of organisations store secrets outside of secrets managers in vulnerable locations, which is exactly the kind of sprawl that makes cryptographic discovery difficult. NIST’s NIST SP 800-63 Digital Identity Guidelines also underscores that identity assurance depends on knowing how credentials are issued, protected, and validated. In practice, many security teams discover their cryptographic exposure only after an application owner, certificate authority, or vendor outage forces the issue.

How It Works in Practice

A crypto bill of materials is the practical record of where cryptography is used, what algorithms are in play, which assets depend on them, and how those dependencies connect to business services. The goal is not only to list certificates or key stores. It is to map cryptographic usage across code, runtime infrastructure, CI/CD pipelines, APIs, device firmware, and identity systems so that migration planning can be risk-based.

In mature environments, teams build the inventory in layers:

• Application discovery to identify libraries, protocols, and hard-coded crypto dependencies.
• Infrastructure discovery to find TLS termination points, PKI services, HSMs, and signing workflows.
• Identity discovery to connect certificates, API keys, service accounts, and workload identities to the systems they protect.
• Data classification to separate low-value traffic from long-retention or regulated data that may need earlier migration.

That visibility changes the migration sequence. Teams can prioritise systems that handle sensitive data with long retention periods, external trust relationships, or embedded devices that are hard to patch. It also helps distinguish standard crypto upgrades from algorithm agility work, where the real task is replacing brittle assumptions in software and tooling. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls supports this kind of control mapping because cryptography is only manageable when assets, protections, and accountability are tied together.

For NHI governance, this matters because service identities often inherit cryptographic risk through certificates, token signing, and automation trust chains. The Ultimate Guide to NHIs is clear that hidden secrets and poor visibility are recurring failure points. These controls tend to break down when legacy applications embed crypto deep in vendor-managed components or disconnected operational technology, because ownership and dependency mapping become incomplete.

Common Variations and Edge Cases

Tighter cryptographic inventory often increases operational overhead, requiring organisations to balance migration speed against discovery accuracy. That tradeoff is real: a fast PQC roadmap can stall if the inventory is shallow, but a perfect inventory can delay action long enough to leave exposed assets untouched.

Best practice is evolving on how detailed the bill of materials should be. Some teams start with a coarse register of algorithms, certificates, and dependent services, then enrich it over time. Others aim for full cryptographic dependency graphs from the outset. There is no universal standard for this yet, but the principle is consistent: track enough detail to make migration decisions defensible. That usually includes algorithm type, key length, certificate lifetime, owning team, dependency chain, and data sensitivity.

Edge cases matter. Third-party SaaS, managed platforms, and embedded devices may not expose enough detail for complete inventory, so teams need contract clauses, vendor attestations, and compensating controls. In high-churn environments, the bill of materials must also be treated as a living control, not a one-time project artifact. Where identities, certificates, and secrets are created automatically, the inventory must be updated at the same pace or it will drift out of trust quickly.

For organisations with heavy automation, the biggest gap is usually not the algorithm itself but the hidden dependency chain behind service identities and machine-issued credentials. That is where Ultimate Guide to NHIs and identity guidance from NIST SP 800-63 Digital Identity Guidelines become operationally useful, because they force teams to treat cryptography as part of identity lifecycle management, not a separate exercise.

Related resources from NHI Mgmt Group

• When should organisations prioritise post-quantum planning for machine identities?
• When should organisations start planning for post-quantum identity controls?
• Which frameworks should guide post-quantum certificate migration planning?
• What breaks if organisations treat post-quantum migration as a one-time upgrade?