Using a CBOM to plan post-quantum migration

The question a migration plan has to answer

For every interface that uses cryptography, an operator eventually needs one answer: can this become quantum-safe, and what does it take? The PKI Consortium’s PQC migration use case starts from exactly that question and derives, in twelve steps, the attributes a CBOM must carry to answer it at the product boundary, where a vendor can disclose and an operator can act.

The framing matters. An operator running hundreds of instances of a product it cannot inspect internally does not need the product’s source code. It needs the vendor’s declaration, per interface, of what runs today and what can change.

What the profile asks a supplier to declare

Per interface, the profile calls for:

• Protocol versions and supported key exchange algorithms, and the current cryptographic practice: what actually runs today.
• The enablement pathway. Whether quantum-safe operation needs a configuration change, a software update or a hardware replacement.
• Coexistence. Whether classical and post-quantum peers can operate at the same time during transition.
• Implementation location. Software, HSM or trusted execution environment, and which library implements the interface. The profile mandates implementation identifiers, because migration planning depends on knowing which library is behind an interface.
• Constraints and performance impact that are known.
• Capability status with blockers. Enumerated values such as available, committed, planned and not planned, with the obstacle named: a provider dependency, a certification requirement, a hardware constraint.

Status values instead of dates is a deliberate choice. A capability often waits for a shared provider update that unlocks many interfaces at once; a date would be a guess, a status is a commitment a supplier can stand behind.

Where the observed inventory fits

A supplier’s declaration describes the product. Your environment is the product plus its configuration, its certificates, the libraries it was built with and the peers it talks to. That is what a cryptographic asset discovery and inventory tool observes.

Put the two side by side and the plan writes itself in three columns:

1. Configuration. Interfaces where the deployed version already supports a quantum-safe option and only the setting is classical. These are the first changes to make.
2. Update. Interfaces where the supplier has committed a capability in a later version. These become upgrade work with a version target.
3. Blocked. Interfaces where the status is not planned or a blocker is named. These become supplier conversations, replacement decisions or compensating controls, and they are the ones that decide your timeline.

The observed side also catches what a declaration cannot: an interface the supplier did not think of, a certificate issued outside the product’s control, a library version that differs from what was shipped.

How Cryptoramic supports this

Cryptoramic observes the cryptography in your scope, connects it to identified products and versions, and imports supplier readiness evidence, including PQC Maturity Model reports, to sit beside the observations. Its policy evaluation records the rule, source reference and migration dates behind each finding, and the action plan separates configuration changes from software upgrades and supplier dependencies. Findings and inventory can be exported as CycloneDX CBOMs for a selected scope.

What it does not do is invent a supplier’s answer. Where no declaration exists, the finding says so, and the next step is a request for one. See supplier readiness or read CBOM versus SBOM for the background.

Back to perspectives