The demand driving most Cryptographic Bill of Materials programs is post-quantum migration, and the first question everyone asks is which of their assets are vulnerable. It is the right question to start with and the wrong question to stop with. Knowing that an asset relies on RSA tells you it is quantum-vulnerable. It tells you nothing about whether replacing it is a configuration change you can make this afternoon or a hardware refresh that is gated by a vendor’s roadmap three years out. Readiness is the product of both: what is vulnerable, and how hard each vulnerable thing is to change.
A platform that reports only vulnerability produces a list of everything that needs to migrate eventually, which is useful for scoping and useless for sequencing. A platform that also reports changeability produces a plan, because it can rank the estate by the combination of urgency and effort that determines what you should touch first. Crypto-agility readiness is that second capability, and it is what turns a post-quantum inventory into a post-quantum program.
This post explains how a CBOM platform identifies quantum-vulnerable assets at ingestion, the attributes it uses to prioritize migration, how it detects the post-quantum algorithms that are starting to appear, and the substitutability analysis that estimates how hard each change will actually be.
PQC Migration Trajectory (CNSA 2.0 Timeline)
Projected algorithm distribution across enterprise infrastructure
⚠️ Organizations that haven't started inventory by 2026 will miss CNSA 2.0 network equipment deadline (2030) — migration typically takes 3-5 years.
Identifying What Is Vulnerable
The quantum threat to public-key cryptography comes from Shor’s algorithm, which breaks the mathematical problems that the common asymmetric algorithms rely on. A readiness capability begins by flagging every asset built on one of those problems at the moment it is ingested, rather than waiting for an operator to ask.
The Shor-vulnerable families are well defined, and a mature platform recognizes all of them rather than just the headline cases:
| Algorithm Family | Hard Problem Shor Breaks | Common Uses |
|---|---|---|
| RSA | Integer factorization | Signatures, key transport, TLS, code signing |
| ECDSA | Elliptic-curve discrete log | Signatures, TLS, device identity |
| ECDH | Elliptic-curve discrete log | Key agreement, TLS key exchange |
| Finite-field Diffie-Hellman | Discrete log in a finite field | Key agreement, legacy TLS, IPsec |
| DSA | Discrete log in a finite field | Legacy signatures |
Flagging vulnerability at ingestion matters because it makes the vulnerable set a first-class, queryable property of the inventory rather than an analysis someone runs later and forgets to re-run. Every asset arrives already tagged with whether it is Shor-vulnerable, which family it belongs to, and the parameters that affect its exposure. Symmetric algorithms and hash functions are handled separately, since their quantum exposure is the far milder Grover speedup that larger parameters address, and conflating the two is a common way immature tooling overstates the problem.
Prioritizing Migration: Vulnerability Is Not Urgency
Once the vulnerable set is known, the question becomes order. Not everything vulnerable is equally urgent, and treating the vulnerable list as a flat to-do queue wastes the scarce effort of a migration on low-impact assets while high-impact ones wait. Prioritization is a scoring capability that combines several attributes, each of which independently shifts an asset up or down the queue.
The attributes that drive migration priority:
- Certificate or key lifetime. A long-lived credential carries quantum-vulnerable trust further into the future than a short-lived one, which raises its urgency.
- Exposure. An externally reachable asset is a bigger target than an internal-only one, and exposure often decides the order between two otherwise similar assets.
- Business criticality. An asset protecting a revenue system or a safety function outranks one protecting a low-stakes internal tool.
- Algorithm replaceability. How hard the specific algorithm is to swap out, which the substitutability analysis below quantifies.
- Data-confidentiality lifetime. For anything protecting data that must stay confidential for years, the harvest-now-decrypt-later window makes migration urgent even if the asset itself is short-lived, because the data it protects is not.
- Regulatory relevance. An asset in scope for a standard or mandate with a deadline inherits that deadline regardless of its other properties.
The harvest-now-decrypt-later dimension deserves particular weight, because it inverts intuition. A session key that lives for minutes looks low-urgency on lifetime alone, but if the traffic it protects carries data that must remain secret for a decade, an adversary who records that traffic today can decrypt it once a quantum computer exists. Readiness scoring that ignores data-confidentiality lifetime systematically under-prioritizes exactly these assets. A platform that weighs it correctly moves them up the queue even though their own keys are ephemeral.
Detecting Post-Quantum Algorithms Already in the Estate
Readiness is not only about what is vulnerable. As migration proceeds, post-quantum algorithms begin appearing in the estate, and the platform has to recognize them accurately to measure progress and to avoid flagging an already-migrated asset as still vulnerable. Detection has to work by both algorithm name and object identifier, because configurations and certificates may express the same algorithm either way, and it has to recognize the hybrid and composite forms that dominate the transition period.
The post-quantum and transitional forms a mature platform recognizes:
| Algorithm / Form | Standard or Role | Detection Basis |
|---|---|---|
| ML-KEM | FIPS 203, key encapsulation | Name and OID |
| ML-DSA | FIPS 204, signatures | Name and OID |
| SLH-DSA | FIPS 205, hash-based signatures | Name and OID |
| Composite keys | Classical plus PQC in one credential | Composite OID and structure |
| Hybrid key exchange | Classical plus PQC in one handshake | Negotiated group markers |
Hybrid and composite detection is the part that trips up shallow tooling. During the transition, the strongest deployments do not swap classical for post-quantum outright; they run both together, so that security holds if either algorithm survives. A composite certificate carries both a classical and a post-quantum key, and a hybrid handshake negotiates a group that combines a classical and a post-quantum exchange. A platform that only looks for pure post-quantum algorithms misreads these as classical and reports no migration progress where real progress has been made. Recognizing the hybrid markers is what lets readiness reporting reflect reality during the years the transition actually takes.
Substitutability: How Hard Is This Change?
The attribute that separates a readiness capability from a vulnerability scanner is substitutability analysis: estimating, for each vulnerable asset, how difficult the change actually is. This is the difficulty half of the readiness equation, and it is what makes the output a plan rather than a list. The difficulty of replacing a cryptographic asset is not uniform; it depends entirely on where the algorithm is bound and what has to change to swap it.
A useful substitutability model distinguishes levels of effort:
| Change Required | Relative Difficulty | Example |
|---|---|---|
| Configuration change | Lowest | Switching a server’s negotiated TLS groups to prefer a PQC exchange |
| Certificate-profile change | Low | Reissuing a certificate under a profile that uses a PQC signature algorithm |
| Library upgrade | Moderate | Updating an application’s crypto library to a version that implements the new algorithm |
| Protocol upgrade | High | Moving to a protocol version that supports the new algorithm at all |
| Hardware replacement | Highest | Replacing an HSM or device whose crypto is fixed in hardware |
An asset that can migrate with a configuration change is cheap to fix and can go early; an asset whose crypto is baked into hardware may be the most urgent by vulnerability and yet impossible to touch until a refresh cycle, which changes how you plan around it entirely. Substitutability is also what makes the “algorithm replaceability” input to prioritization meaningful: a high-urgency asset that is trivial to change is the obvious first move, while a high-urgency asset that requires hardware replacement is a long-lead project you must start now precisely because it cannot be done quickly.
The honest version of this analysis acknowledges uncertainty. Substitutability for a cleanly configured TLS endpoint is easy to estimate; substitutability for an algorithm embedded deep in a legacy application is a harder call, and a mature platform records the estimate with the confidence behind it rather than presenting every difficulty score as equally certain.
Readiness Is Vulnerability Times Difficulty
The reason to build both halves is that neither alone produces a plan. Vulnerability alone gives you a list of everything to do and no order. Difficulty alone tells you what is easy to change without telling you what is worth changing. Readiness is the combination: the ability to rank the estate by the intersection of how urgently an asset needs to migrate and how hard that migration will be.
That intersection is what lets a program sequence intelligently. The easy, urgent changes go first, to build momentum and reduce exposure quickly. The hard, urgent changes start in parallel, because their long lead times mean a late start is a missed deadline. The easy, low-urgency changes ride along opportunistically. The hard, low-urgency changes wait. A CBOM platform that scores both axes makes that sequencing a query over the inventory rather than a workshop exercise repeated every quarter, and that is what crypto-agility readiness delivers: not a warning that the estate is vulnerable, which everyone already knows, but an ordered, effort-aware path through the migration.
FAQ
Q: Isn’t identifying vulnerable algorithms enough to plan a migration? No. Identifying vulnerability gives you a complete list of what must eventually change but no basis for ordering it. Two assets can both rely on RSA and be worlds apart in effort, one a config change, the other a hardware refresh. Readiness requires pairing vulnerability with substitutability so the estate can be ranked by urgency and difficulty together, which is what produces a workable sequence.
Q: Which algorithms does a readiness capability flag as quantum-vulnerable? The Shor-vulnerable asymmetric families: RSA, ECDSA, ECDH, finite-field Diffie-Hellman, and DSA. These rely on integer factorization or discrete logarithms, which Shor’s algorithm breaks. Symmetric algorithms and hash functions are treated separately because their quantum exposure is the much milder Grover speedup, and conflating the two overstates the problem.
Q: Why does data-confidentiality lifetime affect migration priority? Because of harvest-now-decrypt-later. An asset’s own key may be short-lived, but if the data it protects must stay confidential for years, an adversary can record the traffic today and decrypt it once a quantum computer exists. Scoring that ignores how long the protected data must remain secret systematically under-prioritizes short-lived keys that guard long-lived secrets.
Q: What are hybrid and composite forms, and why detect them? During the transition, strong deployments run a classical and a post-quantum algorithm together so security holds if either survives. A composite credential carries both key types; a hybrid handshake negotiates a combined exchange. A platform that only looks for pure post-quantum algorithms misreads these as classical and reports no progress where real progress was made, so detecting the hybrid and composite markers is essential to accurate readiness reporting.
Q: What does substitutability analysis actually estimate? How hard it is to replace a given asset’s cryptography, ranging from a configuration change, through certificate-profile changes, library upgrades, and protocol upgrades, up to hardware replacement. This difficulty estimate is the input that turns a vulnerability list into a sequenced plan, and a mature platform records the confidence behind each estimate rather than treating every difficulty score as equally certain.
About QCecuring
QCecuring flags Shor-vulnerable assets at ingestion, scores migration priority across certificate lifetime, exposure, business criticality, data-confidentiality lifetime, and regulatory relevance, detects post-quantum and hybrid forms by name and OID, and analyzes substitutability from configuration changes through hardware replacement. The result is crypto-agility readiness that sequences the migration by vulnerability and difficulty together, not a flat list of everything that is vulnerable.
See your estate ranked by post-quantum urgency and effort
Tags: Post-Quantum Cryptography, PQC, CBOM, Crypto-Agility, Quantum Risk, ML-KEM, ML-DSA, SLH-DSA, Harvest Now Decrypt Later, Hybrid Cryptography, Migration Planning, Cryptographic Inventory