Notifications
Clear all
Topic starter
12/07/2026 12:26 pm
TL;DR: Enterprises cannot plan post-quantum migration without first finding where cryptography lives across applications, firmware, containers and third-party services, and eMudhra argues a Cryptographic Bill of Materials is the first practical step. The real governance shift is that crypto inventory becomes a living control plane for certificate lifecycle, weak algorithms and crypto-agility, not a one-time project.
NHIMG editorial — based on content published by eMudhra: A 90-day plan for building a Cryptographic Bill of Materials
Questions worth separating out
Q: How should security teams start a post-quantum migration program?
A: Start by inventorying where cryptography is actually used, then measure external exposure first.
Q: Why do certificate lifecycle issues matter in post-quantum planning?
A: Because expired certificates, weak key sizes and unmanaged trust anchors are already operational risks, while quantum-vulnerable algorithms add a longer-term transition risk.
Q: What breaks when cryptography is only tracked in spreadsheets?
A: Manual tracking leaves ownership, dependency mapping and renewal state too incomplete for migration planning.
Practitioner guidance
- Map cryptography by dependency, not by system list. Inventory algorithms, key sizes, certificates, trust anchors, libraries and protocols together so each asset is tied to the application or service that depends on it.
- Separate discovery from classification. First find cryptography everywhere it hides, then tag each item as quantum-vulnerable, transitional or quantum-safe.
- Build continuous refresh into the inventory lifecycle. Pull data from scanners, certificate authorities, endpoints, load balancers and CI/CD pipelines so the C-BOM updates as certificates renew, code ships and infrastructure drifts.
What's in the full article
eMudhra's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step 90-day discovery sequence across applications, firmware, containers and infrastructure-as-code.
- Attribute set for each cryptographic asset, including key size, issuer, expiry, protocol version and usage context.
- Suggested classification approach for quantum-vulnerable, transitional and quantum-safe assets.
- Roadmap logic for turning the inventory into phased migration priorities and crypto-agility planning.
👉 Read eMudhra's 90-day plan for building a cryptographic bill of materials →
C-BOMs and crypto inventory: what IAM teams need to do next?
Explore further
12/07/2026 12:39 pm
C-BOMs are becoming the cryptographic equivalent of identity inventory. Enterprises cannot govern post-quantum migration from scattered certificates and tribal knowledge. The same visibility problem that weakens NHI governance now appears in cryptographic estates, where ownership, usage context and lifecycle state determine whether controls are enforceable. Practitioners should treat cryptographic inventory as a first-class governance layer, not as a documentation exercise.
A few things that frame the scale:
- 57% of organisations lack a complete inventory of their machine identities, according to The Critical Gaps in Machine Identity Management report.
- 66% report that managing machine identities requires significantly more manual intervention compared to human identity management.
A question worth separating out:
Q: Who should own a C-BOM and the resulting migration roadmap?
A: Ownership should sit with the teams that control both the cryptographic assets and the systems that depend on them, typically platform, PKI and security governance functions together. The practical test is whether the owner can update the inventory, validate changes and sequence migration work without relying on ad hoc coordination.
👉 Read our full editorial: A 90-day C-BOM plan for post-quantum cryptography visibility
