Bills of Materials for Quantum Readiness: SBOM, CBOM, and Beyond

Introduction

Quantum computing threat is forcing organizations to inventory their digital assets like never before. With powerful quantum attacks on the horizon, businesses must identify what they have – software, cryptography, sensitive data, hardware – before they can secure it.

Security standards and government directives now urge a comprehensive cryptographic inventory as the first step toward quantum readiness. In practice, compiling these inventories is daunting. Modern IT environments are sprawling and cryptography lurks everywhere – from web servers and databases to IoT devices and vendor libraries. No single tool finds 100% of cryptographic instances; some are hardcoded or undocumented. Moreover, a full enterprise inventory could take years, involving code updates, vendor coordination, and significant expense. The last thing we want is to get stuck in analysis-paralysis, spending endless time on inventories while the quantum clock ticks.

Enter the “BOMs” – Bills of Materials – as practical tools for quantum readiness. Just as manufacturing has bills of materials listing all components of a product, in cybersecurity we use BOMs to enumerate the ingredients of our digital systems. A Software Bill of Materials (SBOM) lists software components and dependencies; a Cryptographic Bill of Materials (CBOM) details cryptographic items like algorithms and keys; we can extend the concept to data inventories and hardware BOMs as well.

Each of these BOMs shines a light on a different facet of your technology stack, helping answer crucial questions: What software do we rely on (and which might need quantum-safe updates)? Where are we using vulnerable encryption (RSA, ECC, etc.)? Which sensitive data might adversaries target to “harvest now and decrypt later”? What devices or hardware could be weak links? For CISOs, these inventories provide a strategic map of quantum risk, compliance gaps, and migration priorities. For technical teams, they offer actionable detail – pinpointing exactly where to focus crypto-agility efforts and software upgrades.

Software Bill of Materials (SBOM) for Quantum Readiness

An SBOM is essentially a nested inventory or “list of ingredients” that make up a software product. It enumerates all components, libraries, modules, and their versions that are packaged into an application. SBOMs have emerged as a key building block for software supply chain security and transparency. Standards like NTIA’s guidance, SPDX, and CycloneDX provide formats to exchange SBOM data, and initiatives like the U.S. Executive Order 14028 (2021) now require software suppliers to provide SBOMs to federal agencies. In short, SBOMs answer the question: “What’s in our software?”

How does this help with quantum readiness?

Knowing your software components is fundamental when planning a post-quantum cryptography (PQC) migration. Many applications rely on third-party libraries or open-source modules that implement cryptography. An SBOM lets you identify where those libraries are and which versions are in use. For example, if a widely used library (say OpenSSL or a JWT library) uses RSA or ECC, an SBOM helps locate every product or system in your organization that includes that library. When quantum-resistant updates or patches become available, you’ll know exactly which software packages need updating. Conversely, if certain critical systems use custom or uncommon cryptographic code, an SBOM ensures it isn’t overlooked.

In essence, SBOMs provide visibility: you can’t fix or upgrade what you don’t know you have. As one industry study noted, more than 20 billion digital devices will need to be upgraded or replaced in the next 10-20 years to implement quantum-safe encryption. SBOMs (and the related hardware BOMs discussed later) help scope this massive upgrade effort by mapping out the software landscape and its dependencies.

Standards and practices

Today, SBOMs are typically produced in machine-readable formats like CycloneDX or SPDX, and they often integrate into CI/CD pipelines so that each software release comes with an updated BOM. Regulators have highlighted SBOMs in the context of PQC as well. For instance, U.S. federal guidance (OMB Memo M-23-02) not only calls for a prioritized cryptographic inventory but also for establishing a “secure software supply chain” – effectively mandating SBOM practices for visibility into software components.

While SBOMs alone don’t detail cryptography (that’s where CBOM comes in), they set the foundation. Think of SBOM as the broad map of your software ecosystem, upon which other inventories can add layers (like a “crypto layer”). By implementing SBOM processes now, you create an asset register that will greatly streamline quantum-era upgrades.

Recommendation

Ensure your organization has an SBOM for each critical application – whether developed in-house or procured. Leverage available tools to generate SBOMs (many package managers and build tools can auto-generate them). Use the SBOM data to cross-reference known cryptographic libraries and modules. This will likely reveal hotspots (e.g. multiple systems depending on the same vulnerable crypto library) that should be prioritized in your quantum-safe roadmap. SBOMs also help engage vendors: you can ask suppliers for SBOMs of their products and scrutinize if they include any cryptography that isn’t quantum-safe, prompting early dialogue on their upgrade plans.

Cryptographic Bill of Materials (CBOM)

If SBOMs give you the “ingredients list” of software, a Cryptographic Bill of Materials (CBOM) gives you the ingredients of your security – it is a structured inventory of all cryptographic assets in a system. In essence, a CBOM is to cryptography what an SBOM is to software components. It catalogs all the algorithms, encryption libraries, protocols, digital certificates, keys, and related cryptographic elements used by an application or device.

The CBOM concept has been spearheaded by OWASP’s CycloneDX project as an extension of the SBOM standard. For example, CycloneDX defines a CBOM schema that includes algorithm names (and parameters like key lengths or modes), locations in the software where they’re used, certificates (with details like issuer and expiration), and even the relationship between crypto components and the software modules that invoke them.

Why is CBOM invaluable for quantum readiness?

Because you cannot transition to quantum-safe algorithms if you don’t know what algorithms you’re using today. Quantum computing primarily threatens specific cryptographic algorithms – notably RSA and ECC in the public-key realm (also finite-field DH and DSA), and potentially shortens the effective security of symmetric keys (think AES-128) and hashes. A CBOM shines a light on where those vulnerable algorithms lurk in your environment. It helps answer questions like: Which applications are using RSA-2048 for digital signatures or key exchange? Do we rely on ECC (P-256 curves) in our mobile apps or IoT devices? Where are our TLS connections using non-PQC ciphersuites? Do we have hardcoded cryptography in legacy systems? By enumerating this, a CBOM allows security teams and engineers to prioritize what to fix or replace. For instance, if a CBOM reveals that a critical payment system uses 2048-bit RSA certificates that expire in 2028, you know that system is a high priority for implementing quantum-safe crypto before 2030. Or if an IoT device uses an embedded ECC library, you might plan to update its firmware or replace the device in the field by a certain date.

CBOMs are increasingly recognized as must-have due to the quantum threat. Governments have explicitly called for cryptographic inventories: a U.S. White House memorandum (OMB M-23-02) in late 2022 mandated federal agencies to inventory their cryptographic systems as part of the transition to PQC. The National Security Memorandum 10 (NSM-10) and related guidance similarly emphasize identifying all current cryptographic usage, especially in high-impact systems and where data needs long-term protection. The CBOM is designed to facilitate exactly this. In fact, CycloneDX positions the CBOM as a tool to help catalog crypto assets and flag those that are not quantum-safe, supporting compliance with standards like NSM-10 on PQC. CBOM provides the knowledge you need for quantum migration – it makes cryptography transparent across your portfolio.

Beyond quantum-specific concerns, CBOMs deliver immediate security value as well. They expose weak or non-compliant crypto lurking in systems (e.g. usage of deprecated algorithms like SHA-1, or short 1024-bit keys). This means you can improve your cryptographic hygiene now, ahead of quantum – for example, phasing out old TLS 1.0 or replacing an MD5-based hash, which reduces today’s risks too.

CBOMs also enhance crypto-agility. If a new vulnerability is discovered in a cipher or library (say a flaw in a popular cryptographic library), you can quickly search your CBOM repository to find all software using that component and assess impact. For instance, during the 2022 OpenSSL v3 vulnerability scare, organizations with CBOMs could rapidly determine which applications actually used OpenSSL 3.x and needed patching. This ability to map crypto to applications accelerates both quantum migration and general incident response.

Standards and tools

The CBOM concept is being baked into emerging standards. OWASP’s CycloneDX 1.4 specification includes CBOM elements, and NIST is also working on guidelines for cryptographic inventories. The NIST National Cybersecurity Center of Excellence (NCCoE) has a draft SP 1800-38B “Migration to PQC: Cryptographic Discovery” guide, highlighting methods to discover and document crypto in applications.

Tooling is growing as well – for example, IBM has released an open-source CBOM tool and object model, and other vendors offer scanners that can generate CBOMs from source code or binaries. Importantly, a CBOM can either be packaged with an SBOM or kept as a separate linked document. Some organizations embed crypto info inside their SBOM (using CycloneDX extension fields), while others maintain a dedicated CBOM per system. Either approach works as long as the data is accessible. The key is maintaining the CBOM as your systems evolve – e.g. updating it when a software release changes a library or when certificates get renewed. Automation is your friend here: integrate CBOM generation into CI/CD and into asset management processes.

Recommendation

Start by identifying a handful of critical applications and build their CBOMs. This could be done manually by code review and configuration inspection, or semi-automatically with tools. Use the findings to drive action – for each vulnerable algorithm uncovered, decide if you will isolate, upgrade, or replace it in the near term. Also, consider enterprise-wide patterns: a CBOM effort might reveal that many systems rely on a particular cryptography library (say BouncyCastle or OpenSSL). This insight allows a centralized approach (perhaps preparing a quantum-safe version of that library and deploying it across multiple systems).

In planning your broader PQC migration, use the CBOM to sequence upgrades: e.g., address items that have earlier “crypto expiration” dates (like expiring certificates or algorithms reaching end-of-life) first. And remember, perfection is not required on day one – even a partial CBOM that covers, say, your top 10 mission-critical systems is a huge leap forward in risk management compared to having no visibility at all.

Sensitive Data Inventory (“Data BOM”)

Not all data is equally threatened by quantum advances. The concept of a “Data Bill of Materials (Data BOM)” can be thought of as an inventory of your data assets, with a focus on identifying which data needs long-term confidentiality.

In the context of quantum readiness, organizations should catalog sensitive data that must remain secure for extended periods. This is because adversaries may be stealing encrypted data today to decrypt in the future when quantum decryption is available – the so-called “harvest now, decrypt later” tactic. Any data that will still be sensitive 5, 10, or 20 years from now (by which time quantum computers may be capable of breaking present encryption) is at risk. Classic examples include: personal identifying information (PII) with long retention (e.g. health records, social security numbers), intellectual property and trade secrets, confidential government or military records, financial records that must be kept for years, and so on. Even communications (emails, messages) that might seem transient could be sensitive if they involve strategic plans or personal privacy and could be incriminating or harmful if revealed in the future.

How a data inventory aids quantum readiness?

By identifying which data sets are high-value and long-lived, you can prioritize protecting those with quantum-resistant measures sooner rather than later. U.S. guidance under NSM-10 explicitly calls out data “that must remain sensitive through 2035” as top priority for migration to PQC. In practice, this means if you know certain databases or information stores contain such data, you might migrate them to quantum-safe encryption (or add extra protections) first. For example, a healthcare provider might decide to re-encrypt its archived patient records using a hybrid classical+post-quantum algorithm, or a bank might enforce quantum-safe TLS tunnels for backing up financial data. But you can only do this if you’ve identified those datasets in the first place.

A structured data inventory (our “Data BOM”) would list major data repositories, the types of data they hold, classification of sensitivity, and importantly the required secrecy duration. A practical approach is to work with your data governance or compliance teams – many organizations already classify data (confidential, secret, public, etc.) and have retention policies. Extend those practices by flagging any data that needs confidentiality beyond the near term. It is equally important to note how that data is currently protected: Is it encrypted? If so, with what algorithms? Is it being transmitted over networks using TLS, and what ciphersuites? This overlaps with the CBOM, but from a data-centric view.

It’s worth noting that some forward-leaning experts predict a formalized “Data BOM” will become as standard as SBOM in certain domains (for instance, AI training datasets are now so critical that proposals for Data BOMs to track data lineage and usage are emerging). For quantum security, the concept is what matters: maintain an inventory or at least a list of your critical data and map it to crypto. Think of it like, “which crown jewels need a quantum-safe vault?”. This will guide your investments – you might decide to implement PQC encryption first for those crown jewels, even if it’s not yet feasible enterprise-wide.

Recommendation

Conduct a workshop with data owners and security teams to identify data that has a long shelf life of sensitivity. Use criteria from standards or regulations (for example, GDPR requires protecting personal data, and if that data must remain confidential for decades, it implies a need for PQC). Document these datasets, their locations (databases, file servers, cloud storage, backups), and note what cryptography currently protects them (e.g., “Database X: contains customer PII, encrypted with AES-256, accessed via TLS 1.2 RSA/ECDHE”). This combined with the CBOM will highlight gaps – e.g., if backups of a sensitive database are encrypted with RSA-based tools, that’s a gap to close. Then, integrate this into your quantum readiness roadmap: those data sets likely merit early adoption of quantum-resistant encryption or network security (such as using TLS with a quantum-safe key exchange like CRYSTALS-Kyber once available, or using symmetric encryption with sufficiently large keys that resist Grover’s algorithm).

Also consider policy and key management: you might enforce shorter re-key intervals or dual encryption (encrypt data with both classical and PQC algorithms) for highest-value data during the transition period. The outcome of a good data inventory is focus – it helps you allocate effort where a future quantum attacker would find the biggest payoff.

Hardware and Device BOM (HBOM)

Software and data often steal the spotlight, but hardware devices are a critical part of the quantum readiness puzzle. Many devices in use today – from IoT sensors and smart appliances to industrial control systems and even hardware security modules – have cryptographic functions embedded at the firmware or chip level. Updating or replacing these devices to support quantum-safe crypto can be a massive challenge.

A Hardware Bill of Materials (HBOM) is an inventory of the physical devices and hardware components in your environment, often including details about their firmware, chipsets, and cryptographic capabilities. Knowing your hardware estate is important because if a device only supports (for example) RSA/ECC and cannot be upgraded, it may become a security liability in the quantum era.

Why a hardware/device inventory matters?

First, the scale of the hardware replacement effort is huge – the World Economic Forum estimated over 20 billion digital devices will need upgrade or replacement in the next 10-20 years to deploy quantum-safe encryption. Your organization owns a (tiny) slice of those 20 billion, but you need to know which ones they are.

An HBOM helps identify all the places where quantum-vulnerable cryptography is baked into hardware. For instance, consider: company laptops that use TPM chips (are those TPMs quantum-safe? likely not yet), IoT devices like security cameras or smart printers using RSA-based TLS, network appliances (VPN gateways, firewalls) that run on embedded OS and might have hardcoded crypto, PLCs in factories with firmware that uses ECC for authentication, or even customer-issued hardware tokens/smart cards. By listing out hardware models and firmware versions, you can work with vendors to find out what crypto each supports and whether upgrades are planned. Some devices might just need a firmware update to add PQC algorithms (e.g., a software-defined radio or a router might get a patch), but others might never support PQC, implying they’ll need replacement. Without an HBOM, such devices can be forgotten until they break. With an HBOM, you can proactively plan tech refresh or mitigations (like isolating a device on a network until it’s replaced).

Standards bodies are acknowledging this aspect too. CycloneDX, for example, defines a Hardware BOM format (HBOM) in its schema, allowing hardware components and their details to be catalogued similar to software. Some regulators, particularly in critical infrastructure sectors, have started asking for hardware inventories for cybersecurity. While not explicitly about quantum, this dovetails with PQC readiness – e.g., U.S. power grid security standards (NERC CIP) require asset inventories which could be extended to note crypto details of devices.

Also, the U.S. Cybersecurity Strategy (2023) has initiatives around IoT security labeling, hinting that future device certifications might include disclosing cryptographic info (which is effectively an HBOM element). In sum, hardware transparency is part of overall supply chain security.

Integrating hardware into your quantum-safe plan

Augment your existing IT asset management with crypto-relevant info. For each critical device type, record what cryptography it uses. If you have an inventory of network gear, add a column for “crypto algorithms supported” (your network team or vendor can often provide this).

Pay special attention to any end-of-life devices – older hardware might never get updates and could harbor outdated cryptography that will be broken by quantum computers. Those should be high on the list for replacement.

Additionally, include embedded systems in products your company makes (if you’re a manufacturer of electronics or IoT products, you need to assess your own products’ crypto agility). Planning for quantum-safe hardware might involve working with manufacturers for new models or firmware, budgeting for device replacements, and possibly deploying compensating controls (e.g., if an IoT sensor can’t be upgraded, maybe you tunnel its communications over a quantum-safe VPN as an interim shield). An HBOM gives the grounding to make these decisions systematically.

Recommendation

Leverage any existing CMDB (Configuration Management Database) or asset inventory you maintain. Enrich it with columns/tags about cryptographic components. Some organizations perform “firmware SBOM” analysis on devices – if you can get the firmware binary, you might generate an SBOM/CBOM for the firmware to see what libraries and algorithms are inside. This is advanced, but even without that, you can often obtain from vendor documentation the cryptographic capabilities (e.g., “Device X’s firmware supports TLS 1.2 with RSA-2048, SHA-256”). Maintain a list of such devices and engage vendors for roadmaps: will there be a software update for PQC? Do we need to buy a new model? By mapping this out, you avoid nasty surprises down the line. And similar to data, prioritize – focus on devices that secure critical systems or sensitive data flows. For example, an HSM (hardware security module) that manages your certificate authority might only support RSA/ECDSA; since that’s a linchpin of your security, plan to procure a quantum-ready HSM or update its firmware as soon as available. On the other hand, an IoT coffee machine on your guest network, while still something to eventually upgrade, is lower priority.

Bringing It All Together – Practical Steps and Avoiding Paralysis

It’s clear that comprehensive BOMs (SBOM, CBOM, data, hardware) provide the visibility needed for a smooth quantum transition. They each address a slice of the puzzle – software, cryptography, data, devices – and together give a 360° view of where you stand.

However, assembling all these BOMs to 100% completeness is hard. It can be easy to fall into the trap of “we can’t start migrating to PQC because we’re still compiling inventories”. To avoid this analysis-paralysis, adopt a risk-informed, phased approach:

• Prioritize High-Risk Assets: Not everything carries equal risk. Identify the critical systems (those supporting essential services or protecting highly sensitive data) and focus your BOM efforts there first. This aligns with guidance from standards bodies – for example, U.S. federal guidelines explicitly direct agencies to inventory high-impact systems, high-value assets, and long-sensitive data first. If you concentrate on, say, the top 10 or 20 most critical applications for CBOM/SBOM analysis, you’ll cover a large risk surface early. Likewise, start with the most sensitive data stores for your data inventory, and key operational tech for hardware inventory.
• Leverage Existing Data and Automation: You might already have partial inventories. Many organizations have vulnerability management lists, certificate management systems (which are essentially a partial CBOM of certificates), or open-source component scanning from AppSec programs. Build on those. Use automated tools where possible – for instance, run an SBOM generator on major applications, use network scanning to find TLS endpoints and record their cipher suites (a quick way to map crypto usage). Perfect accuracy is not the immediate goal; coverage is. Even a rough inventory is better than none when making decisions.
• Iterate and Improve: Treat BOMs as living documents, not one-off projects. Initial versions might be incomplete – that’s okay. As you execute migrations or new info comes in, update the BOMs. Over time, the gaps will fill in. For example, you might discover during testing that a legacy system uses an unexpected cryptographic function; update the CBOM then. Regularly scheduled reviews (quarterly, annually) can checkpoint progress. Many organizations tie this into their governance: e.g., requiring that any new system deployment comes with an SBOM and CBOM, so the inventory grows organically.
• Drive Action, Don’t Just Document: The purpose of these BOMs is to inform action. So define triggers and use cases. For instance, if your CBOM shows System A using RSA 2048, the “action” is to plan a PQC replacement by 2025. If your data inventory flags a database of secrets, the action might be to implement hybrid encryption this year. Set specific goals such as “By next year, eliminate all use of algorithm X” or “upgrade library Y in all applications” and use the BOM to track completion. This keeps the momentum on mitigation rather than endless inventory work.
• Communicate and Educate: For CISOs and program leaders, BOMs are fantastic communication tools. They can help explain to business leadership why budget or time is needed for certain upgrades (“We discovered 40% of our applications use libraries that will be broken by quantum; we have a plan to update them over 3 years”). They also demonstrate compliance effort: showing auditors or regulators that “we have an SBOM/CBOM for these systems” evidences proactive risk management. Internally, socialize the concept that everyone has a role in maintaining these inventories – developers should know to list their dependencies, architects should document crypto choices, etc. This way, the burden is shared and the culture shifts to one of transparency.

Avoiding analysis paralysis is crucial. It’s worth reiterating that while a full, enterprise-wide cryptographic inventory is the ideal end-state, you need not (and probably cannot) achieve it overnight. The goal is to balance long-term completeness with short-term risk reduction. In practice, this means you might begin quantum remediation on critical systems in parallel with continuing inventory on less critical ones. For example, you might already start testing a PQC algorithm in a critical VPN product now (with the knowledge from a CBOM that it uses ECC today), rather than waiting until you’ve inventoried every single internal app. By the time quantum computers mature, you want your most important assets safe – even if some less critical ones still need work, that’s an acceptable trade-off initially. As one strategy paper put it, address the “most critical quantum risks first, while laying the groundwork for eventual enterprise-wide PQC adoption.”.

Standards and Frameworks Shaping BOM Practices

It’s helpful to know that you’re not doing this alone or in a vacuum – a number of standards, frameworks, and industry initiatives are emerging around these types of inventories and quantum readiness:

• Government Directives: Multiple countries have issued mandates related to cryptographic inventories. We discussed the U.S. OMB Memo M-23-02, which required federal agencies to produce a prioritized inventory of cryptographic systems and begin quantum-proofing them. National Security Memorandum-10 (2022) sets timelines for U.S. agencies to mitigate quantum risks by 2035, starting with inventorying systems that handle sensitive data beyond 2035. Financial regulators and critical infrastructure bodies are also raising the issue – for instance, the U.S. healthcare sector coordinating council recommended healthcare providers identify crypto in medical devices and electronic health record systems as part of quantum preparedness.
• Standards for SBOM and CBOM: The cybersecurity community has rallied to standardize how we share these inventories. For SBOM, formats like SPDX (an ISO standard) and CycloneDX (an OWASP standard now also an international standard ECMA-TR/ISO) are widely used. For CBOM, CycloneDX 1.4 includes a formal model for cryptographic elements, and efforts are underway to potentially integrate aspects of CBOM into SPDX as well. NIST’s Cybersecurity Framework (CSF) 2.0 draft now references asset inventory and crypto agility. NIST’s Secure Software Development Framework (SSDF) calls for maintaining provenance data (which SBOMs provide) and by extension knowing your crypto usage. There’s also work on VEX (Vulnerability Exploitability Exchange) documents which complement SBOMs by indicating whether known vulnerabilities in components are actually exploitable – this can be relevant when a vulnerability is cryptographic (e.g., if an algorithm is broken, a CBOM+VEX could tell you which apps are affected).
• Industry Collaborations: Sectors such as telecommunications have formed task forces (e.g., the GSMA Post-Quantum Telco Network Taskforce) to develop migration guidelines  – these often include sharing SBOM/CBOM information between operators and vendors to manage risk. In IoT, groups like NIST’s IoT Cybersecurity Initiative and global forums are discussing “ingredient lists” for devices (essentially SBOM/HBOM) as part of certification. Additionally, companies like IBM, Microsoft, AWS, and various cybersecurity firms are releasing tools and whitepapers on cryptographic discovery and inventory best practices. Even open-source communities (OpenSSL, for instance) are engaging with the PQC transition by providing technical guidance; aligning your BOMs with such guidance (e.g., knowing where OpenSSL is used via SBOM so you can apply their PQC-enabled versions in future) will keep you ahead.

Staying aware of these external drivers is useful because they can help justify internal efforts. If a particular standard maps well to your needs (for example, using CycloneDX for both SBOM and CBOM so they interlink), adopt it to benefit from community tools.

And keep an eye on upcoming regulations – for instance, if you’re in the financial services sector, regulators might soon ask for evidence of quantum risk management, and having these inventories will put you in a strong position to answer confidently. In highly regulated industries like finance and healthcare, aligning with standards early is often advantageous. But even if you’re in a less regulated space, following best practices like SBOM/CBOM will improve your security posture immediately (supply chain attacks and classical crypto vulnerabilities are present dangers) and set you up for a smoother PQC transition.

Conclusion

Being quantum-ready ultimately comes down to preparation and agility. The various “BOMs” we’ve discussed – SBOMs for software, CBOMs for cryptography, data inventories, and hardware BOMs – are not just bureaucratic paperwork; they are foundational maps that illuminate where and how to act. Each BOM offers a different lens on the problem of quantum risk, from the software you run, to the encryption that safeguards it, to the data you protect, to the devices you rely on.

Together, they inform a holistic strategy so that when quantum-busting algorithms arrive, your organization isn’t scrambling in the dark. Instead, you’ll have a clear inventory of what needs fixing, replacing, or shielding.

However, remember that the goal is not the inventory itself, but what it enables. A fancy cryptographic inventory spreadsheet means little unless it leads to upgrading those cryptographic components. A detailed SBOM is only as good as the actions you take to patch or replace vulnerable components identified. So use these BOMs as a means to an end: stronger security and smooth migration. Also, be pragmatic and time-conscious. We likely have a limited window (perhaps this decade) to get quantum-ready before major deadlines and threats hit. Focus on the big wins – the critical assets – and don’t let the perfect be the enemy of the good.