BACKGROUND

Data collected across development and deployment phases

The significance of a cryptographic fact depends on the phase at which, and the party by which, it was captured. The lifecycleStage attribute of a CBOM records that phase, which allows the statement that a product uses a given algorithm to be interpreted precisely.

The four lifecycle stages

The lifecycle model (version 1) uses a flat enumeration — intended, implemented, configured, observed — attached to each interface. Each value corresponds to a phase of the software lifecycle, a distinct producer, and a distinct data source.

Each stage answers a distinct question from a distinct source. Read from left to right, the sequence is a progression from architects to operators.

Information available at each phase

Stage	Phase	Establishes	Does not establish
`intended`	Design	What the architecture is specified to use.	What was actually built.
`implemented`	Build	What the shipped code or binary is capable of (the vendor build CBOM).	What a deployment enables; capability is not actuality.
`configured`	Deploy	What the deployed configuration permits.	Whether configuration matches live sessions; configuration may drift.
`observed`	Runtime	What was negotiated on the wire.	Durability; a later configuration change can invalidate the observation.

Relationship to SBOM Generation Context

The 2026 minimum elements guidance adds an element called SBOM Generation Context, defined as the relative software lifecycle phase and the data available when the author generated the SBOM. The reasoning given there matches the reasoning here: component data differs according to the phase at which it was captured, and a consumer assessing risk needs to know which phase that was.

The guidance gives "before build", "build", and "after build" as acceptable values and permits more specific identifiers. Our four stages map onto those references and subdivide the last one, because the difference between what a deployment permits and what it actually negotiates is the distinction PQC migration turns on.

Lifecycle stage used here	Corresponding generation context
`intended`	before build
`implemented`	build
`configured`	after build, as a more specific identifier
`observed`	after build, as a more specific identifier

A producer that follows the minimum elements therefore already records what a profile needs, though possibly at a coarser granularity. Where only the coarse value is available, a consumer can place the CBOM in the right region of the lifecycle but cannot separate configured capability from observed use, which is a limitation worth recording rather than inferring. See References.

False positives and false negatives across the lifecycle

No single stage gives a complete or perfectly accurate picture. Each is prone to two kinds of error: a false positive, where cryptography is reported but is not actually in effect, and a false negative, where cryptography is in effect but is not reported. The balance between the two shifts as a subject moves from design to runtime.

Stage	Typical false positive (reported, not in effect)	Typical false negative (in effect, not reported)
`intended`	An algorithm specified in the design but never implemented.	Cryptography introduced during implementation, such as that inside libraries and dependencies, which the design did not foresee.
`implemented`	Compiled-in capability, such as cipher suites or providers, that no deployment ever uses.	Cryptography loaded dynamically at runtime, provided by hardware (an HSM or TEE), or reached through dependencies the scanner does not cover.
`configured`	An algorithm permitted by the configuration but never negotiated in practice.	Cryptography outside the inspected configuration, such as built-in defaults or out-of-band channels.
`observed`	Cryptography seen only in a scan probe or a transient session, not representative of normal use.	Cryptography on paths not exercised during the observation window, such as failover, administrative, or rarely used interfaces.

False positives are highest early, where a design or a build reports what is possible rather than what runs, and lowest at runtime, where what is seen has genuinely occurred. False negatives do not simply fall; they change character. A design misses implementation detail, a static scan misses dynamic and hardware cryptography, a configuration misses what it does not govern, and a runtime scan misses whatever was not exercised while it watched.

This is why a product CBOM and a service CBOM are combined rather than used in isolation. A product CBOM, from the implemented stage, tends to over-report capability and under-report runtime and hardware cryptography; a service CBOM, from the observed stage, under-reports paths it did not see. Reading them together reduces both kinds of error.

The readiness gap

PQC-capable software and hardware do not, in themselves, guarantee that post-quantum cryptography is configured and active, nor that it remains active across configuration changes. A product may be implemented with support for a given algorithm that is never configured and therefore never observed. Large migrations regularly reveal interoperability and performance effects between these stages.

For this reason a CBOM should record the lifecycle stage rather than an unqualified fact. A vendor's implemented CBOM and an operator's observed scan may both be correct and yet differ; the discrepancy is itself a significant result. A CBOM that supports both perspectives represents the discrepancy explicitly.

Product CBOM and service CBOM

Two kinds of CBOM are separated here, because they answer different questions and are produced by different parties.

A product CBOM describes the cryptography a product contains or is able to use. It is usually produced by the vendor at build time and ships with a release, so it reflects the implemented stage: what the product can do. A service CBOM describes the cryptography a running service actually uses. It is produced by the operator from the deployed configuration and from what is observed on the wire, so it reflects the configured and observed stages: what a particular deployment does.

A service is usually built from several products, so a service CBOM draws on the product CBOMs of its components and adds the configuration and runtime picture that exists only once the service is deployed. The cryptographic relationships between endpoints exist at the service level, not within any single product.

Why the distinction matters for PQC migration

PQC migration turns on the difference between capability and use. A product CBOM tells you whether a product can be made quantum-safe, and whether that requires a software update or a hardware change. A service CBOM tells you whether a given deployment is quantum-safe today. The two are not interchangeable:

A product CBOM on its own can overstate readiness. A product may support ML-KEM, but that says nothing about whether any deployment has enabled it.
A service CBOM on its own cannot show the upgrade path. Knowing that a service still negotiates a classical group does not tell you whether the underlying products can be reconfigured or must be replaced.

Migration planning needs both. Product CBOMs identify which products can reach a quantum-safe target and how; service CBOMs identify which deployments have actually reached it, and which have not. Comparing the two, interface by interface, distinguishes a software update from a hardware refresh, and a planned state from a running one.

Multiple producers of a single interface's data

In the worked example the two lifecycle stages arise from the two producers:

The HTTPS service interface is recorded as observed, captured by scanning the running server (a runtime, operator view).
The SSH management interface is recorded as configured, captured from the deployment configuration (an integrator view).

A profile may require the stage to be declared, as the baseline profile does, or may require a specific stage. A runtime-assurance profile might require every interface to be observed, whereas a procurement profile might accept implemented from a vendor build.

Stakeholders at each stage

Each stage has a different producer, and in most cases the party that produces the data is not the party that needs it. That separation is why the lifecycle stage has to be recorded rather than assumed: a consumer receiving a CBOM usually did not generate it and cannot tell from the content alone which phase it describes.

The table sets out who produces a CBOM at each stage, who typically consumes it, and which use cases the data at that stage can support. A use case appears against more than one stage where it draws on both, which is common: several of them depend on comparing one stage against another rather than reading a single one.

Stage	Produced by	Consumed by	Use cases it supports
`intended` design	Architects and security architects, from design documents and threat models.	Architecture review boards; procurement teams writing requirements; the working group or sector body defining a profile.	Crypto-agility assessment Procurement, for stating the requirement rather than checking it
`implemented` build	Development and build teams, from source and dependency analysis in the pipeline.	The vendor's own product security function; downstream integrators; operator procurement; security operations holding a component inventory.	Procurement and tender conformance CI quality gate Vulnerability management Supply-chain transparency Crypto-agility assessment
`configured` deploy	Integrators, platform and infrastructure teams, from deployment configuration and policy bundles.	Deployment gates; internal risk and assurance; migration programme leads.	PQC migration readiness CI quality gate, at the admission step Compliance reporting
`observed` runtime	Operations and monitoring teams, from scanning and telemetry against the running service.	Assurance and audit; incident responders; regulators receiving a reported position; customers asking what a service actually uses.	PQC migration readiness, for actual rather than declared state Incident response Compliance reporting Due diligence

Consumers who never produce

Several stakeholders appear only on the consuming side, and their needs shape what a profile has to require. Regulators and auditors read a position they had no part in generating, so provenance and lifecycle stage matter more to them than to anyone else. Customers and partners issuing a supply-chain request are in the same position, and are usually the reason a CBOM has to be scoped and redacted before release, as described in the Inventory section. Acquiring organizations performing due diligence read across an entire estate they do not operate, where the absence of data is as significant as its content.

Where the hand-offs fail

The stages are separated by organizational boundaries as often as by time, and the data degrades at those boundaries.

Between implemented and configured the producer changes organization, from vendor to operator. A vendor cannot state what a deployment will enable, and an operator cannot see inside the binary. Neither party can produce a complete picture alone, which is the argument for combining a product CBOM with a service CBOM rather than choosing between them.
Between configured and observed the producer usually stays within one organization but changes team. This is where drift appears, because configuration is authored once and running systems change afterwards.
Between intended and implemented the data is frequently lost entirely. Design intent is rarely carried into a machine-readable form, so a consumer cannot tell whether cryptography present in a build was deliberate or incidental.

A profile can require the stage to be declared, which makes these gaps visible. It cannot close them; doing so would require a different party to produce data it does not currently produce. That is an adoption question rather than a specification one.

Progress tracking over time

Successive CBOM revisions (the content-revision axis described in the Versioning section) constitute an audit trail. An interface progressing from implemented to configured to observed with post-quantum cryptography enabled provides a verifiable migration record for internal governance and for regulators.

← Inventory Next: Model →

PKIC CBOM Profiles Working Group · illustrative documentation.