Start by scoping the systems most exposed to long-lived or sensitive data, then combine automated discovery across network services, certificate stores, application dependencies, cloud services, and hardware security modules. Enrich each finding with algorithm, key length, business owner, data sensitivity, and lifespan. The result is a living inventory that supports prioritisation, not just documentation.
Why This Matters for Security Teams
A crypto bill of materials is the only practical way to answer a simple but hard question: where is cryptography used, which algorithms are in play, and what will break when those algorithms are no longer acceptable? That matters because post-quantum migration is not just a library upgrade. It affects certificates, TLS endpoints, code dependencies, firmware, HSMs, backups, and any system that depends on long-lived trust chains.
Security teams also need a structured inventory because the risk is uneven. Data with long retention periods, regulated records, and machine-to-machine trust paths face the earliest exposure. Without a bill of materials, organisations tend to discover crypto exposure during incident response, audit, or vendor review rather than during planned migration. The same visibility gap seen in NHI programmes applies here: NHI Mgmt Group notes in the Ultimate Guide to NHIs that only 5.7% of organisations have full visibility into their service accounts, which is a useful warning sign for any cryptography inventory effort.
Current guidance suggests treating the crypto bill of materials as an operational control, not a one-time spreadsheet. NIST’s NIST SP 800-63 Digital Identity Guidelines and NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce the broader principle that identity and cryptographic trust require continuous governance. In practice, many teams discover their highest-risk crypto dependencies only after a platform or certificate renewal has already failed.
How It Works in Practice
A useful crypto bill of materials starts with discovery, then moves into classification and ownership. The inventory should cover network services, application code and containers, cloud-managed certificates, secrets stores, endpoint configurations, identity providers, and HSM-backed keys. Each item needs enough context to drive prioritisation: algorithm, key size, protocol, expiration, business owner, system dependency, data classification, and whether the asset protects data that must remain confidential for years.
The best practice is to normalise findings into a single record format so teams can compare risk across environments. For example:
- Discover TLS certificates and inspect negotiated protocols, ciphers, and certificate lifetimes.
- Scan source repositories and build artefacts for embedded crypto libraries and deprecated primitives.
- Query cloud APIs for managed keys, certificate services, and encryption settings.
- Inventory HSMs and key vaults to determine key purpose, rotation cadence, and algorithm support.
- Map each asset to a workload, service account, or business process so ownership is explicit.
That ownership step matters because a cryptographic dependency is only actionable when someone can approve replacement, testing, and cutover. The NHI experience documented in The State of Non-Human Identity Security shows why visibility breaks down when inventories are fragmented: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. The same problem appears in crypto inventories when application teams, infrastructure teams, and third parties each maintain partial records.
From there, teams should rank findings by exposure horizon. Systems handling archival data, digital signatures, long-lived tokens, or regulated records deserve earlier review because they may need crypto-agility well before quantum-safe standards are universally deployed. The inventory should be refreshed automatically from configuration sources and certificate telemetry so it stays current as systems change. These controls tend to break down when cryptography is embedded in legacy applications, appliances, or vendor-managed platforms because the algorithm is hidden behind interfaces that discovery tools cannot inspect.
Common Variations and Edge Cases
Tighter crypto inventory controls often increase operational overhead, requiring organisations to balance migration speed against the effort of validating every dependency. That tradeoff becomes sharper in hybrid estates, where some systems support modern telemetry while others expose almost nothing about their cryptographic posture.
One common edge case is indirect crypto use. Teams may only catalogue obvious TLS or certificate assets and miss message queues, service meshes, signed software updates, database encryption, or authentication flows that rely on older algorithms. Another is third-party software and managed services, where the vendor owns the implementation but the enterprise still owns the risk. Current guidance suggests recording these as externally controlled dependencies with explicit reassessment dates, because there is no universal standard for vendor transparency yet.
A second edge case is overlapping cryptographic roles. The same key may protect data at rest, authenticate a service, and support code signing. Those assets should be tracked separately in the bill of materials if their replacement timelines differ. A third is post-quantum transition planning itself: some environments will need hybrid deployments, while others can move service by service. Teams should therefore avoid assuming a single migration date applies everywhere. The right answer is a living inventory that can show what is exposed now, what is difficult to replace, and what must be prioritised first.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | AI RMF supports structured risk inventory and prioritization for cryptographic dependency exposure. | |
| NIST CSF 2.0 | ID.AM-1 | Asset inventory is foundational to finding cryptographic dependencies across the environment. |
| NIST SP 800-63 | Digital identity guidance reinforces strong lifecycle control for trust material and authentication. | |
| NIST Zero Trust (SP 800-207) | PR.AC-1 | Zero trust depends on knowing and validating the cryptographic basis of each trust path. |
Extend asset management to include crypto assets, owners, lifecycles, and exposed algorithms.
Related resources from NHI Mgmt Group
- How should security teams start a post-quantum migration program?
- How should security teams prepare certificate estates for post-quantum migration?
- How should security teams assign ownership for post-quantum cryptography migration in multi-team environments?
- How should security teams build cryptographic agility for post-quantum PKI migrations?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
