A 90-day C-BOM plan for post-quantum cryptography visibility

At a glance

What this is: eMudhra’s 90-day plan says the first post-quantum step is a Cryptographic Bill of Materials that inventories cryptographic assets across the estate and turns visibility into a migration plan.

Why it matters: IAM, PKI and workload-identity teams need this visibility because migration, certificate lifecycle, and crypto-agility all fail when cryptography is embedded in places the programme cannot see.

Context

Post-quantum migration is first and foremost a visibility problem: most enterprises do not have a reliable map of where cryptography exists across systems, vendors and runtime environments. A Cryptographic Bill of Materials, or C-BOM, is the inventory discipline that makes the migration problem concrete enough to govern.

For IAM and PKI teams, the practical issue is not just quantum readiness. The same inventory exposes expired certificates, weak key sizes, deprecated protocols and unmanaged trust anchors, so the work immediately connects to certificate lifecycle management and broader cryptographic governance.

Key questions

Q: How should teams prepare cryptographic inventories for post-quantum migration?

A: Teams should map every cryptographic asset to its owner, dependency, and replacement path before they start migrating algorithms. That lets them prioritise critical services, identify legacy exposure, and reduce downtime during change. Without a reliable inventory, PQC becomes a blind migration rather than a governed transition.

Q: Why does a C-BOM matter beyond quantum readiness?

A: A C-BOM also surfaces expired certificates, weak key sizes, deprecated protocols and unmanaged trust anchors, which are operational and audit risks today. That makes it a live cryptographic governance tool rather than a future-only migration artifact.

Q: What usually breaks when cryptographic inventory is incomplete?

A: Incomplete inventory breaks prioritisation. Teams cannot tell which systems use which algorithms, which suppliers depend on them, or which assets are too critical to migrate without testing. That creates blind spots in PQC planning and pushes organisations into reactive, high-risk transitions instead of sequenced change.

Q: How do you know a C-BOM is actually useful?

A: It is useful when it can be regenerated continuously, tied to owners and deployment context, and used to prioritise migration work by sensitivity and longevity. If the inventory cannot support those decisions, it is only a catalogue, not a control.

Technical breakdown

What a C-BOM inventories across the estate

A Cryptographic Bill of Materials is a structured inventory of the cryptographic elements in use across an environment, including algorithms, keys, certificates, libraries and protocols. The value is not just cataloguing what exists, but linking each item to where it runs, who owns it and what data it protects. That makes cryptography governable at scale, especially when assets are spread across applications, firmware, containers, scripts and third-party integrations. In practice, the C-BOM becomes the system of record for deciding what must be replaced, renewed or retired as post-quantum readiness matures.

Practical implication: inventory cryptographic assets by owner, usage and exposure before trying to plan migration.

Why discovery must include certificates, keys and trust anchors

Discovery has to reach beyond application code because much of enterprise cryptography lives in operational layers that scanners often miss. Certificates in CAs, load balancers, key stores and endpoints tell you where trust is actually anchored, while keys and secrets metadata show what is managed, where it is deployed and how long it persists. That is why the article treats certificate data and usage context as first-class inventory fields. Without those layers, a C-BOM records only surface evidence and misses the trust dependencies that drive real migration risk.

Practical implication: pull certificate and trust-anchor data from operational systems, not just source code and binaries.

How C-BOMs support crypto-agility and migration sequencing

A useful C-BOM does more than identify quantum-vulnerable assets. It classifies cryptographic usage as transitional, quantum-vulnerable or quantum-safe, then uses sensitivity and longevity to decide sequencing. That is the core of crypto-agility: the ability to change algorithms and trust models without starting discovery from scratch each time standards evolve. The article’s 90-day plan uses this logic to turn inventory into prioritised remediation, with long-lived, high-value exposures moved ahead of short-lived, lower-risk assets.

Practical implication: rank cryptographic dependencies by data longevity and exposure so migration starts with the highest-risk assets.

NHI Mgmt Group analysis

C-BOM visibility is the control prerequisite, not a documentation exercise: post-quantum migration fails when cryptography is treated as an attribute of applications rather than a governed estate-wide dependency. The important change is that security teams stop guessing where trust resides and start managing it as inventory. That is the point at which cryptographic governance becomes operational rather than aspirational.

Crypto inventory is a living lifecycle problem, not a one-time project: certificates, keys and protocols age, move and reappear as systems change, so a static spreadsheet quickly becomes false comfort. C-BOM thinking aligns naturally with lifecycle management because the question is not only what exists today, but what must be continuously rediscovered, classified and retired. Practitioners should treat inventory freshness as a control objective.

Cryptographic debt now matters before Q-Day: the same visibility that prepares an enterprise for post-quantum algorithms also exposes weak keys, deprecated protocols and unmanaged trust anchors that create immediate operational and audit risk. That means the business case does not depend on quantum timelines alone. The practitioner's conclusion is that C-BOM governance pays for itself in present-day resilience.

Crypto-agility is the named concept that matters here: it is the ability to change algorithms, certificates and trust dependencies without redoing discovery each time standards shift. The article’s phased plan shows why crypto-agility begins with an accurate C-BOM rather than with a migration sprint. Teams that cannot regenerate their inventory continuously will struggle to execute any future cryptographic transition.

Board reporting should shift from assurance claims to inventory completeness: leaders do not need another abstract quantum-readiness statement, they need evidence that cryptographic assets are discoverable, classified and owned. That is where C-BOM becomes a governance instrument, not just a technical artifact. The practical conclusion is that visibility metrics should sit alongside migration milestones.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Crypto inventory has become the prerequisite for any serious post-quantum programme: teams that cannot answer where cryptography lives will not be able to sequence migration, prove readiness or manage the operational fallout of algorithm change. The governance shift is from periodic assessment to continuous cryptographic ownership.

Living inventory is the real control objective: once a C-BOM is tied to certificate discovery, renewal and asset management, it becomes a mechanism for sustaining trust rather than a one-time discovery project. That is the shape of crypto-agility in practice, not in theory.

The scale of the visibility problem is stark: only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. The same pattern applies to cryptographic dependencies, which means inventory discipline is the difference between managed transition and blind migration.

For practitioners

• Build a discovery-first C-BOM Scan binaries, containers, firmware, infrastructure-as-code and certificate infrastructure so the initial inventory is deliberately over-inclusive rather than incomplete.
• Classify cryptographic assets by risk Tag each item as quantum-vulnerable, transitional or quantum-safe, and record algorithms, key sizes, protocol versions, ownership and exposure.
• Prioritise long-lived high-value exposures Use data sensitivity and longevity as the first ranking filter, then sequence remediation for vulnerable algorithms and high-exposure trust anchors.
• Keep the inventory continuously refreshed Integrate certificate discovery, issuance and renewal into CI/CD and asset-management workflows so the C-BOM remains a living control plane.

Key takeaways

• Post-quantum migration depends on knowing where cryptography lives, not just on selecting new algorithms.
• The immediate value of a C-BOM is broader than quantum readiness because it exposes weak and unmanaged cryptographic dependencies already causing risk.
• A usable inventory must stay current, classify assets by exposure and feed prioritised migration planning.

Key terms

• Cryptographic Bill of Materials: A cryptographic bill of materials lists the cryptographic capabilities built into software components, such as supported algorithms and libraries. It is useful for component visibility, but it does not show live configuration, deployment context or actual runtime usage. That makes it a partial input, not the full governance record.
• Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, certificates, and trust dependencies without redesigning production systems. It matters because cryptographic standards evolve, and organisations need accurate inventories and automated lifecycle controls before they can migrate safely.
• Quantum-Vulnerable Cryptography: Quantum-vulnerable cryptography refers to algorithms, especially RSA and ECC, that are expected to lose security against sufficiently capable quantum computers. These algorithms still protect many modern systems today, but they represent long horizon risk for cloud environments that need durable confidentiality and trustworthy digital signatures.
• Trust anchor: A trust anchor is the root authority that signs federation metadata and establishes the policies other participants inherit. In practice, it controls who can join, what cryptographic rules apply, and how trust is delegated across an ecosystem. The security posture of the whole federation depends heavily on this layer.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.