Building the product inventory needed for post-quantum migration

A product roadmap for post-quantum migration needs more than a list of cryptographic algorithms. It needs a record of where cryptography supports the offered product, which services depend on it and who has the authority to change each dependency. Without those relationships, a supplier can announce an ambition while leaving its commercial team unable to answer a customer's practical planning question.

The inventory is a product-management asset. It connects technical discovery to support periods, supplier commitments and customer integrations. A useful record helps decide whether a change belongs in an ordinary release, requires coordination with an upstream vendor or depends on replacing a longer-lived part of the offer.

Separate discovery from evidence that products work together

NIST's NCCoE migration project has distinct discovery and interoperability workstreams. The first examines where and how cryptography is used and how inventories can support prioritisation. The second examines compatibility of implementations within an agreed scope and a controlled environment. The project concerns hardware, software and services, rather than only application source code.

That separation is helpful for evaluating a commercial roadmap. Identifying a dependency is one accomplishment. Demonstrating that a changed product works with the required surrounding services is another. A supplier should be able to say which stage its evidence supports without turning a planned compatibility exercise into a completed result.

The NCSC's July 2026 workshop report, describing a December 2025 event with Vodafone and the National Cyber Advisory Board, emphasises early supplier engagement and clear requirements. Participants also highlighted the opportunity to coordinate migration with normal technology refreshes and the importance of dependencies on long-lived hardware. These are planning considerations, not proof that a particular vendor's product is ready.

Start with the customer-facing service

An inventory organised only around libraries may be difficult for a product owner to use. The record should also identify the service the cryptographic dependency supports. For example, an application may rely on separate arrangements for customer sign-in, communication with a hosted service and verification of software releases. Knowing that the same underlying technology appears in several places does not establish that those uses have the same owner or change schedule.

The commercial question is what would need to change for a customer to continue using the offered product under the intended future requirements. That requires a view of the product boundary and the interfaces crossing it. An externally supplied identity service may be outside the application code while remaining central to the customer's experience.

A component inventory is still useful input. Our guide to SBOM coverage explains why release identity and dependency coverage matter. A general SBOM should not automatically be described as a complete cryptographic inventory, however. The product team needs to establish what relevant usage information it contains and what additional evidence is required.

Record evidence and uncertainty separately

Each inventory entry should have a source of information. It might come from reviewed product documentation, an internal engineering assessment or a dated supplier response. Those sources have different scopes. A generic company statement about future capability is weaker evidence for a specific supported product than a release-level commitment.

The record should distinguish confirmed information from an assumption awaiting review. An unresolved dependency is not necessarily a reason to halt all planning, but it needs an owner and a visible effect on the roadmap. Treating blank fields as implicit confirmation can make an incomplete inventory look more mature than it is.

A useful entry connects the product release, the relevant service or interface, the source of the dependency information, the responsible party and the expected change route. It can also record the support horizon and any customer coordination required. These fields help a product manager reason about sequencing without turning the inventory into a repository of sensitive secrets.

The inventory should not contain private keys or other credentials. Its purpose is to describe dependencies and responsibility at an appropriate level, with access suited to the information it contains. The customer-facing version can be a bounded summary while the supplier maintains more detailed internal evidence.

Distinguish who supplies from who decides

The vendor selling the finished product may not control every dependency. An upstream software provider can determine when a supported update becomes available. A hardware manufacturer can determine whether a product can support a future change. The customer may control an external service or approve changes to a shared integration.

Those relationships should be visible in the roadmap. A statement that a dependency is “supplier managed” is incomplete if it does not identify which supplier and how its plans have been established. Product teams need an accountable contact and a dated evidence record, rather than a general expectation that the market will provide an answer.

Consider a hypothetical document-processing application delivered both as a hosted service and as an on-premises package. The hosted edition uses services selected by the vendor. The installed edition relies on customer-managed infrastructure. A single migration date for the whole product family could obscure different dependencies and approval routes. The inventory should support separate, intelligible plans for those editions.

This distinction can improve the sales conversation. A supplier can explain what it controls, what it has verified with partners and what it needs from the customer. That is more credible than a broad readiness label whose scope becomes narrower only after contract signature.

Use the inventory to sequence investment

Product dependencies should be considered alongside the intended commercial lifetime. A supported product due for replacement soon may have a different change route from hardware expected to remain in service for many years. The decision belongs in the product roadmap, with its assumptions recorded, rather than being made from an algorithm name alone.

The buyer can ask how the proposed route aligns with contract renewals, planned upgrades and integration work already budgeted. A supplier should distinguish an available capability from a funded development item and from an aspiration dependent on another organisation. These categories have different implications for procurement timing and customer confidence.

Our coverage of the NCSC migration roadmap provides the broader timing context. This inventory work supplies the product-specific evidence needed to turn that context into a defensible plan. It should not be used to imply that one public timetable overrides every contractual or sector-specific requirement.

A roadmap also needs a way to revisit priorities. New supplier information, a changed product lifetime or a revised customer integration can alter the preferred sequence. An inventory maintained through ordinary release and supplier-management work gives the team a more reliable basis for those decisions than a one-off workshop spreadsheet.

Ask for a bounded readiness demonstration

A customer evaluating a supplier can request one representative dependency traced through the inventory to its planned change and supporting evidence. The discussion should establish the current release, the responsible party, the proposed future state and the remaining work. It can stay at a commercial assurance level without exposing sensitive implementation details.

If the supplier has compatibility evidence, the customer should understand its scope: the products and versions considered, the environment used and the result actually observed. A successful exercise involving one integration should not be generalized to every customer configuration. Where evidence is still planned, the offer should say so and identify the relevant milestone.

The deliverable from this work is a maintained map between product functions, cryptographic dependencies and change responsibility. It gives founders and product leaders a basis for allocating investment, and gives commercial teams a precise answer when customers ask how an offer will evolve. The inventory earns its value by improving those decisions and remaining connected to the product that customers actually buy.