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

At a glance

What this is: This is a practical 90-day approach to building a Cryptographic Bill of Materials, with the central finding that crypto inventory is the prerequisite for post-quantum migration.

Why it matters: It matters because identity and security teams cannot govern certificates, keys and trust anchors they cannot see, and that visibility now shapes both migration readiness and day-to-day outage risk.

👉 Read eMudhra's 90-day plan for building a cryptographic bill of materials

Context

Post-quantum migration starts with a visibility problem, not a tooling problem. Most enterprises cannot accurately locate where their cryptography lives across applications, firmware, containers, scripts and third-party services, which means planning begins with inventory, classification and ownership rather than algorithm replacement.

For IAM, NHI and PKI teams, the practical issue is that certificates, keys, protocols and trust anchors behave like unmanaged identities when they are not catalogued. A C-BOM turns that sprawl into a governed inventory, which is why the first 90 days matter more than the final migration wave.

Key questions

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. Public domains, certificates, SSH keys, and service accounts should be mapped to owners and replacement paths before standards deadlines force a rushed program. A quick scan is useful, but the real work is governance, sequencing, and lifecycle control.

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. If lifecycle data is missing, teams cannot tell which assets are safe to keep, which need redesign and which can be migrated without destabilising dependent systems.

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. It also makes prioritisation unreliable, because teams cannot confidently distinguish high-risk cryptography from lower-risk systems or verify whether a change will affect a hidden dependency.

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.

Technical breakdown

What a cryptographic bill of materials actually captures

A Cryptographic Bill of Materials is an inventory of the cryptographic assets and dependencies in use across an estate. That includes algorithms, key sizes, certificates, trust anchors, libraries, protocols, versions and the systems that depend on them. The value is not just countability. It is the ability to map cryptographic exposure to business context, data sensitivity and ownership. Without that structure, quantum-readiness remains a slogan because teams can see individual assets but not the dependency chain that makes them operationally relevant.

Practical implication: Build the first C-BOM as a structured asset register, not a document, so ownership and exposure can be queried and updated continuously.

Why certificate lifecycle and crypto-agility belong in the same inventory

Certificate lifecycle is part of cryptographic governance, not a separate housekeeping task. Expiry, weak key sizes, deprecated protocols and unmanaged trust anchors create operational risk today, while quantum-vulnerable algorithms create strategic risk over a longer horizon. Crypto-agility means the environment can change algorithms and key material without redesigning every dependent system. A C-BOM becomes the control plane that shows which assets are ready to move, which are transitional and which will require redesign before replacement is safe.

Practical implication: Use the inventory to classify assets by quantum-vulnerable, transitional and quantum-safe so migration work is prioritised by business risk, not technical convenience.

How discovery becomes a living control rather than a one-time project

The article correctly treats inventory as a lifecycle problem. A useful C-BOM cannot be built once and filed away because cryptographic usage changes through CI/CD, vendor updates, certificate renewal and infrastructure drift. The control has to ingest data from scanners, certificate authorities, endpoints, load balancers and application owners, then regenerate on a recurring basis. That is the difference between a snapshot and a governance system: one answers what was present last month, the other supports operational decisions today.

Practical implication: Automate C-BOM refreshes through CI/CD and asset-management integration so the inventory stays current enough to guide remediation and audit responses.

NHI Mgmt Group analysis

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.

Crypto-agility is the real control objective, not one-time algorithm replacement. The article’s strongest operational point is that algorithm change will be repeated over time, so the estate must absorb future cryptographic shifts without another full discovery project. That is the same governance logic behind lifecycle-managed NHI: if dependencies are not continuously knowable, change becomes brittle. The implication is that migration programmes should be designed around change tolerance, not just current compliance.

Certificate lifecycle and quantum readiness now sit on the same risk register. The report frames expired certificates, weak key sizes and deprecated protocols as immediate debt, and that is the right lens. Post-quantum planning does not replace everyday cryptographic hygiene; it exposes how much of it was already unmanaged. Practitioners should stop separating operational crypto issues from strategic transition work, because they are now part of the same control surface.

Named concept: cryptographic visibility debt. This is the accumulated inability to answer where cryptography lives, who owns it and how quickly it can be changed. That debt is tolerated when risks are distant, but it becomes a migration blocker when standards shift and renewal cycles shorten. The implication for security leaders is that inventory quality itself has become a measure of readiness.

The organisations best positioned for the quantum transition will govern cryptography like a living identity estate. Continuous discovery, ownership mapping and lifecycle management matter more than isolated engineering projects. That is the discipline shift this article points to, and it should shape how boards, CISOs and infrastructure teams fund the work.

From our research:

• 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.
• The NHI Lifecycle Management Guide shows how lifecycle controls reduce inventory drift across provisioning, renewal and offboarding.

What this signals

Cryptographic visibility debt is now a programme-level issue, not just an asset-management nuisance. Once cryptography is spread across binaries, third-party services and configuration layers, the difference between a migration plan and a compliance exercise is whether ownership and refresh cycles are built into the control model from the start.

For teams already carrying broad NHI governance gaps, the pattern is familiar: if the estate cannot enumerate what it runs, it cannot prove what it protects. That is why continuous discovery and lifecycle control belong together, and why the NHI Lifecycle Management Guide is a useful parallel when inventory quality is the real blocker.

For practitioners

• 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. That structure is what lets you prioritise quantum-vulnerable exposure instead of collecting disconnected findings.
• Separate discovery from classification. First find cryptography everywhere it hides, then tag each item as quantum-vulnerable, transitional or quantum-safe. That two-step approach avoids false confidence from partial scans and gives owners a workable remediation queue.
• 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. A static snapshot will age out before migration work is complete.
• Use the inventory to rank migration by business risk. Prioritise long-lived secrets protecting high-value data and systems with the hardest algorithm changes first, then sequence lower-exposure assets later. That keeps the roadmap anchored to impact instead of technical convenience.

Key takeaways

• Post-quantum readiness begins with finding and classifying cryptography, not replacing algorithms first.
• A C-BOM becomes useful when it is tied to ownership, lifecycle state and business risk, not when it is a static spreadsheet.
• The organisations that will migrate calmly are the ones that treat cryptographic inventory as a living control plane.

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.
• Cryptographic visibility: Cryptographic visibility is the ability to see where keys, certificates, and algorithms exist, who owns them, and which services depend on them. It turns hidden trust dependencies into governed assets. Without it, teams cannot reliably assess exposure, prioritise remediation, or prove control effectiveness across identity and workload systems.

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.

👉 The full eMudhra article covers discovery, classification and migration planning in sequence.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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.