Quantum Readiness Is a Software Supply Chain Problem. Your SBOM Won't Show the Full Risk

Quantum readiness is becoming a software supply-chain problem. Organizations need to find cryptography across applications, build systems, infrastructure and suppliers before they can prioritize a post-quantum migration. A software bill of materials (SBOM) helps identify components, but it does not automatically reveal every algorithm in use, how a service negotiates cryptography at runtime, or whether a supplier can support a change.

On October 14, 2026, Singapore’s Cyber Security Agency (CSA) published more specific quantum-safe migration milestones. CSA’s publicly available CII guidance requires CII operators to submit their migration plan to CSA by March 31, 2027, and sets December 31, 2031 as the target to complete migration. It also states that new CII-system procurement must factor in quantum-safe considerations from 2028 onwards. For other organizations exposed to quantum risk, CSA recommends establishing a plan by the end of 2027 and aiming to complete migration by 2035. The dates apply to the Singapore guidance and its stated audiences; they are not universal deadlines for every company. Singapore CSA announcement · CSA advisory · Public CII guidance and Quantum-Safe Kickstarter Grant

The planning signal is clear: teams need an evidence-based view of their cryptographic dependencies, owners and constraints. The first step is discovery—not a claim that today’s encryption has already been broken.

Why quantum readiness starts with an inventory

The precise arrival date of a cryptographically relevant quantum computer is unknown. Public-key cryptography based on RSA and conventional elliptic curves is considered vulnerable to a sufficiently capable quantum computer, but this does not mean such a machine is currently breaking deployed systems. Organizations still need time to discover, test and coordinate changes across long-lived products and suppliers. Sensitive data captured today may also need protection for years, which can make the expected confidentiality lifetime relevant to prioritization.

An SBOM is an important foundation. It records software components and their relationships. It does not, by itself, prove which cryptographic algorithms are selected in production, what certificates and keys are active, how a vendor-managed gateway is configured, or how quickly a device’s firmware can be replaced.

Cryptography may sit in places that are easy to miss:

• A library used to validate JWT signatures or establish TLS sessions.
• A cloud service or SDK that delegates key management or signing to a managed provider.
• A payment, identity or messaging supplier with its own certificates and transition schedule.
• A build pipeline that signs packages, containers or software updates with classical public-key cryptography.
• VPNs, firmware, long-lived devices and hardware security modules that cannot be upgraded on an application release cycle.
• Databases and service-to-service connections with independently managed protocols and configurations.

That makes quantum preparation a joint security, engineering, procurement and vendor-management effort. A component inventory can point to where to investigate; runtime and supplier evidence are needed to understand the complete exposure.

Which cryptography needs a closer look?

“Quantum-safe” should describe a defined algorithm and use, not an unverified label or score. Increasing a conventional public-key key size does not change the underlying algorithm family’s quantum risk. RSA-4096 remains RSA; stronger classical elliptic curves remain classical elliptic curves.

NIST finalized FIPS 203, 204 and 205 on August 13, 2024. These are established standards, not new October 2026 releases. Choosing a standard does not, by itself, establish that an implementation, protocol or system has been migrated safely. NIST post-quantum cryptography publications

A Cryptography Bill of Materials (CBOM) can make cryptographic assets and their relationships easier to document. Depending on its discovery sources and format, it may represent algorithms, cryptographic components, key-related metadata and usage context. CycloneDX publishes a CBOM capability and specification guidance. A CBOM is an inventory artifact—not proof that its coverage is complete or that a system is quantum-safe. CycloneDX CBOM capability

What the 2027–2035 milestones mean

The 2027 marker in this graphic refers to the planning recommendation for other organizations exposed to quantum risk. CII operators have a separate milestone: they must submit their migration plan to CSA by March 31, 2027, as described below.

The Singapore CSA announcement and advisory distinguish between CII operators and other organizations exposed to quantum risk:

• CII migration plan submission by March 31, 2027: CII operators must submit their migration plan to CSA by this date, under CSA’s public CII guidance.
• From 2028 onwards: new CII-system procurement must factor in quantum-safe considerations. CSA’s public CII guidance and grant information
• CII migration by December 31, 2031: this is the stated target for completing migration of CII systems.
• Other exposed organizations: CSA recommends a migration plan by the end of 2027 and migration by 2035.

The United Kingdom’s National Cyber Security Centre (NCSC) separately publishes guidance targets: complete discovery and assessment and establish an initial plan by 2028; prioritize and progress migration by 2031; and aim to complete migration by 2035. The NCSC notes that a small set of rarely used technologies may be more difficult to migrate by 2035; organizations should still work toward the stated dates. These are UK guidance milestones, not global legislation. Organizations should assess which local requirements, sector rules and contractual commitments actually apply. UK NCSC PQC migration timelines

NIST’s IR 8547 transition plan is a draft as of October 16, 2026. It should not be described as a finalized blanket legal deadline for private companies. NIST IR 8547 draft

The useful lesson is to begin discovery early. A migration can involve application owners, protocol compatibility, hardware refresh cycles, suppliers and customer commitments; changing one library may be the smallest part of the work.

From component lists to connected inventories

CycloneDX already supports CBOMs. Version 1.6 introduced CBOM capability, and version 1.7 added identifiers for cryptographic algorithm families and elliptic curves. On August 5, 2026, the project announced plans for CycloneDX 2.0, describing proposed ways to associate cryptographic assets with migration risks, responses, owners, target dates and status.

As of October 16, 2026, CycloneDX 2.0 is announced as forthcoming and expected later in fall 2026; it has not yet been released or ratified. Do not build a current product or compliance claim around assumed 2.0 support. CycloneDX 2.0 announcement · CycloneDX CBOM

An extended inventory can connect three different questions:

1. SBOM: Which software components, versions, suppliers and dependencies are in the product?
2. CBOM: Which cryptographic algorithms and contexts need assessment or transition?
3. AIBOM: Which AI models, providers and related components are part of the product?

These inventories complement one another; they are not interchangeable guarantees. An Extended Bill of Materials (XBOM) is one way to organize and relate them so teams can investigate dependencies and maintain context. The actual contents and coverage still depend on what was scanned, how it was classified and which external evidence was added.

CISA and partner agencies published the 2026 Minimum Elements for a Software Bill of Materials on September 8, 2026. The publication updates recommended minimum elements and encourages SBOMs to be maintained as software changes; it does not create new requirements by itself. Teams should distinguish this guidance from obligations that come from applicable laws, regulations, contracts or sector rules. CISA and partner agencies: 2026 SBOM minimum elements

Other supply-chain data is useful context, not quantum evidence. Sonatype’s October 8, 2026 Q3 report recorded 149,329 total flagged packages across its malicious and unwanted categories; 27,618 had at least one overtly malicious behavior. The flagged total should not be read as 149,329 confirmed malware packages. These figures support the broader case for component tracking and impact analysis; they are not reports of quantum attacks or cryptographic migration failures. Sonatype Q3 2026 report

Sonatype reported 149,329 total flagged packages across categories; 27,618 had at least one overtly malicious behavior. The total includes flagged packages and should not be read as all confirmed malware.

Build an inventory that supports decisions

For each important cryptographic asset, record enough evidence to answer practical questions:

Crypto agility is the ability to change cryptographic mechanisms across applications, protocols, hardware and infrastructure with manageable operational risk. NIST’s crypto-agility white paper, CSWP 39 revision 1, was finalized on June 29, 2026; the original version was published in December 2025. It offers planning considerations, not a certification or proof that a particular organization is agile. NIST CSWP 39 revision 1

Avoid false precision. A “quantum readiness percentage” has little meaning without a defined scope, validated classification, coverage evidence, asset criticality and a clear account of what was not assessed. A code scan alone cannot establish the state of every runtime certificate, hardware security module, managed service or vendor environment. Validate algorithm classifications against NIST references and supplement inventories with runtime, configuration and supplier evidence.

A practical 90-day starting plan

Days 1–15: Assign ownership and choose scope

Name a program owner and select one representative, business-critical service or product. Map its data lifetime, signing and key-exchange use cases, network interfaces, release process and major suppliers. Make the boundary explicit so the first inventory can be reviewed.

Days 16–30: Collect initial evidence

Gather software inventories and available cryptographic information from source code, build systems, configurations and infrastructure records. Record algorithms and versions, certificate and key references where safe, system context, trust boundaries and supplier dependencies. Mark unknown or unobserved areas clearly rather than treating them as clean.

Days 31–45: Prioritize by consequence

Consider sensitive data that must remain confidential for years, externally exposed services, signing infrastructure, critical dependencies, and devices or firmware that are difficult to update. Treat RSA and conventional ECC as quantum-vulnerable public-key cryptography even where they remain suitable for classical security today.

Days 46–60: Engage suppliers

Ask suppliers which products and services rely on public-key cryptography, how they plan to support post-quantum or hybrid transitions where appropriate, what customer changes are required, and how they will test interoperability and communicate milestones. Record answers and evidence; do not infer readiness from a marketing statement alone.

Days 61–75: Test in controlled environments

Pilot selected key-establishment or signature changes in non-production systems. Check interoperability, latency, certificate and signature sizes, performance, fallback behavior, monitoring and rollback. Have relevant engineering and security owners review the test results.

Days 76–90: Publish a roadmap

Turn findings into owners, evidence gaps, dependencies, confidence levels and sequenced milestones. Link each milestone to a system and a verification method. Update inventories when software, cryptographic configuration or suppliers change.

Do not wait for perfect coverage before addressing the highest-consequence risks. Use an iterative, risk-based process and label its limits.

Where Plexicus XBOM fits

Plexicus’s public XBOM page presents SBOM, CBOM and AIBOM in one workflow and offers a way to request a product walkthrough. That can be a starting point for teams exploring connected inventories. It should not be read as evidence of complete cryptographic discovery, correct quantum classification, runtime or hardware coverage, supplier verification, PQC migration assurance, or regulatory compliance.

Before relying on any inventory tool for migration decisions, validate its actual coverage and classification against NIST references. Supplement code-derived results with runtime and configuration checks, supplier evidence, and tests in the systems in scope.

Start with a clear view of what you have—and what remains unknown.

Explore Plexicus XBOM and request a walkthrough →

The quantum question is a planning question today

No evidence establishes that a cryptographically relevant quantum computer is currently breaking ordinary public-key deployments. The near-term task is to determine which systems depend on quantum-vulnerable cryptography, where that information is incomplete, and how long assessment and migration will take.

An SBOM provides a valuable component foundation. A CBOM can describe cryptographic assets when it is based on suitable discovery and classification. An XBOM can help relate software, cryptography and AI inventories. None replaces runtime testing, supplier engagement, engineering ownership or a migration plan.

Quantum readiness begins as an inventory and governance program. The plan should make its scope, evidence, uncertainty, owners and locally applicable milestones visible.

Request a Plexicus XBOM walkthrough →

Frequently asked questions

Is RSA-4096 quantum-safe?

No. A larger key does not change RSA’s algorithm family. RSA, including RSA-4096, and conventional elliptic-curve public-key cryptography are considered vulnerable to a sufficiently capable quantum computer.

Is a CBOM legally required for post-quantum migration?

There is no single global rule requiring every organization to produce a CBOM in a specific format. Requirements depend on jurisdiction, sector, contracts and applicable regulation. A structured cryptographic inventory is a practical planning aid, but organizations should assess the rules that apply to them.

Can an SBOM or CBOM alone prove quantum readiness?

No. The inventory must have suitable scope and accurate classifications, then be checked against runtime configuration, hardware and supplier evidence. Testing, prioritization and a migration roadmap are also needed.

Has CycloneDX 2.0 been released?

As of October 16, 2026, CycloneDX describes version 2.0 as forthcoming. Do not assume it is generally released or supported by a particular product. CycloneDX 1.7 is the latest released 1.x version referenced by the project’s public materials.

Which NIST post-quantum standards have been finalized?

NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) on August 13, 2024. Selecting and deploying a standard still requires system-specific design, implementation and testing.

Are Singapore’s 2031 and 2035 milestones global deadlines?

No. They are Singapore CSA milestones for CII and recommendations for other organizations exposed to quantum risk. The UK NCSC publishes separate guidance targets. Applicability depends on the relevant jurisdiction, sector, contracts and organization.

Does Plexicus XBOM guarantee PQC migration or compliance?

No. The public page presents SBOM, CBOM and AIBOM in one workflow and invites teams to request a walkthrough. That does not establish complete discovery, correct algorithm classification, runtime or supplier coverage, successful migration or compliance.

Sources

• Singapore CSA, quantum-safe migration timeline announcement and grant, October 14, 2026.
• Singapore CSA, Advisory on Quantum-Safe Migration for Organisations, October 14, 2026.
• Singapore CSA, Quantum-Safe Kickstarter Grant and procurement information.
• UK NCSC, PQC migration timelines.
• NIST, post-quantum cryptography publications and standards.
• NIST, CSWP 39 revision 1: Considerations for Achieving Crypto Agility, finalized June 29, 2026.
• NIST, IR 8547 initial public draft.
• Canadian Centre for Cyber Security and G7 partners, Preparing for the Post-Quantum Era, September 2026.
• CycloneDX, CBOM capability and CycloneDX 2.0 announcement.
• CISA and partner agencies, 2026 Minimum Elements for an SBOM, September 8, 2026.
• Sonatype, Q3 2026 Open Source Malware Index, October 8, 2026.
• Plexicus, XBOM.