Use cases for profiles

The purpose of a profile has to be settled before the profile can be written. This section sets out the purposes a CBOM profile is asked to serve. Each purpose makes a different set of attributes mandatory, which is why the methodology produces profiles rather than a single schema.

Why the use case comes first

A profile answers the question "what must be disclosed so that a particular decision can be made", which is a different question from "what cryptography does this contain". The first question cannot be answered in the abstract. An attribute that is indispensable for one purpose is irrelevant to another: a vulnerability responder needs the implementing library and can ignore endpoint roles, while a procurement team checking an interface baseline needs the reverse.

Starting from the use case also bounds the disclosure. Without a stated purpose there is no principled way to decide where a profile stops, and the result drifts either towards demanding everything, which vendors reasonably resist, or towards a lowest common denominator that supports no decision at all. A profile with a named consumer and a named decision can be assessed on its merits.

One CBOM can serve several of these purposes at once, within a limit worth stating plainly. Different consumers apply different profiles to the same unchanged document, and a vendor generating a single high-fidelity CBOM may find it evaluated against a procurement profile by one customer and a vulnerability profile internally, with no republication in between. That holds for any profile whose attributes the document already carries.

It does not hold across a profile that introduces new attributes. A baseline-conforming document cannot be evaluated against the PQC migration profile at all, because the capability and roadmap attributes are absent. The practical consequence is that "supply a CBOM" is not one request: a buyer has to name the profile, and a vendor generating documents against the baseline alone has not met a migration request by producing more of them.

The use cases below are described briefly. One of them, PQC migration, is worked through in full under Use Cases, the section that holds worked use cases, where the consumer's decision is turned into a complete profile definition. That page is the template for how the others would be developed, and the section overview states the shape each one follows and which of the nine below have been developed. A blank in that shape is kept there as a template, so starting the next one is a matter of copying a file rather than deciding on a structure.

The use cases

1 · PQC migration readiness and planning

An operator has to decide which systems to migrate, in what order, and what each will cost. That means separating the systems needing only a configuration change from those requiring a software update, and both from those tied to hardware that must be replaced. The consumers are migration programme leads and, increasingly, the regulators they report to.

A profile for this purpose requires the algorithms an interface currently uses and those it is able to use, so that capability and actuality can be compared, together with the lifecycle stage that says which is being reported. It does not ask for a readiness verdict, because that judgement depends on criteria which change over time and belongs in an external policy. This use case is developed in detail on the PQC Migration tab.

2 · Procurement and tender conformance

An operator states cryptographic requirements in a tender and needs to check what comes back without reading it by hand. Today this is done with security questionnaires, whose answers are prose and cannot be compared between vendors. A profile expresses the requirement in a form a machine can evaluate, and the vendor's CBOM is the response to it.

The requirements here are structural as much as attribute-level. Beyond describing each interface, a procurement profile typically insists that certain kinds of interface are present at all, which is how it catches a vendor that has described its service interface and said nothing about how the product is administered.

3 · Vulnerability management and incident response

An advisory is published against a cryptographic library. The question is which services are affected, and it has to be answered in hours rather than weeks. This use case has the least tolerance for manual work.

Almost everything depends on one attribute: the identifier of the implementing library, expressed in a form that can be matched against a vulnerability feed. Endpoint roles, interface types and lifecycle stages contribute little here. A profile written for this purpose is deliberately narrow.

It is also the one use case in this list that the baseline actively obstructs, because that attribute is the one rule the baseline permits a producer to withhold. Vulnerabilities sets out what a CBOM contributes when an advisory lands, which kinds of weakness it is the only evidence for, and why no profile for this purpose has been written yet.

4 · Regulatory and compliance reporting

An organization must demonstrate its cryptographic position against a framework such as the EU Cyber Resilience Act, NIS2, the BSI technical guidelines, or a national directive. The consumer is an auditor or regulator who did not generate the data and cannot ask follow-up questions of the system.

A profile encodes what a given framework expects, so that conformance can be evidenced by a dated artifact that an auditor can re-check. Because the reader is external, provenance and lifecycle stage carry unusual weight: a reported position is only meaningful if it says when and from what it was derived. A jurisdiction-specific profile also lets a global vendor satisfy the requirement once and report against it in several places.

5 · Continuous integration quality gate

The aim is to stop non-conforming cryptography reaching production, by checking a CBOM at a pipeline stage and failing the build when a mandatory rule is violated. The consumer is the pipeline itself, which is the only case here where no human reads the result unless the check fails.

Any profile can be used this way, so the requirement falls on the validator: it must return a usable exit status and a machine-readable report. Which attributes are mandatory is a question for whichever profile the pipeline applies. The Demo section shows the same behaviour interactively.

6 · Crypto-agility assessment

Before an algorithm needs replacing, an architecture or risk function wants to know how hard replacing it would be. The answer is rarely uniform across an estate, and the interfaces that will cause trouble are usually identifiable in advance where an assessment has been carried out.

The determining factor is whether cryptography is reachable through a replaceable provider or fixed in place, which makes the implementing library and its location the central attributes. Keeping key exchange, encryption and authentication as separate attributes rather than a single cipher-suite string also matters, because agility usually differs between them.

7 · Supply-chain transparency

A supplier at any tier needs to tell its customers what cryptography its product uses, and would prefer to do so once rather than in a different format for each customer. Downstream, an integrator needs disclosures it can compare across suppliers.

A disclosure baseline meets this need. The binding constraint here is the upper bound on what may be asked, which is unusual: the profile has to be satisfiable without exposing information a supplier has a legitimate reason to protect. The ability to mark an attribute as withheld, rather than omitting it silently, is therefore of particular importance in this use case.

8 · Mergers and third-party risk due diligence

An acquiring organization, or one onboarding a significant partner, needs a view of cryptographic exposure across an estate it does not operate and cannot inspect directly. The work is usually done under time pressure and with limited cooperation.

Coverage matters more than depth. A broad disclosure across the estate, with the absence of data recorded explicitly rather than left blank, tells the assessor where the risk concentrates: deprecated algorithms still in use, and cryptography bound to hardware that will not be upgraded.

9 · IoT device estates

An operator of a large deployed estate of constrained devices decides, per device model, whether the cryptography can be changed in place, whether the device has to be replaced, whether something in front of it can carry the cryptography instead, or whether the exposure is accepted and documented. Scale is what changes the problem: each action costs the unit price multiplied by the number deployed, plus the cost of physically reaching each one.

Three things make this more than a sector flavour of the first entry. A capability answer of no can be permanent, because the limit is available flash or a frame size fixed by a radio standard rather than a decision somebody could take differently. The party able to install new firmware is often neither the manufacturer nor the operator. And the document describes a device model while the decision is made about deployed instances of it, so the producer cannot state the things that vary per instance and the operator has to join them in from its own records. A profile for this purpose therefore needs attributes none of the others do: whether an update mechanism exists, who can trigger it, and whether key material fixed at manufacture can be replaced at all. This use case is drafted on the IoT Device Estate tab, where the choice of consumer is still open.

Attributes emphasised by each use case

Profiles differ from one another in two ways, and the distinction decides whether one document can serve several of them.

Some purposes draw on the same set of attributes and differ only in which of them are mandatory. Procurement, vulnerability response and supply-chain transparency are largely of this kind, and the table below shows the emphasis each places. A document rich enough for one is usually evaluable against another without being reissued.

Others need attributes that do not exist in the baseline at all. PQC migration is the clearest case: knowing which algorithms an interface uses today answers none of the three questions a migration planner has, so that profile adds fourteen attributes rather than selecting among the nine. A document produced against the baseline cannot be evaluated against it — not because it fails, but because the attributes were never collected. The producer has to generate a richer document, which is what makes the choice of profile a procurement decision rather than a reporting preference. The two cases are the depth and coverage axes described under composition in Profile: a profile may ask for more detail about the same subject matter, or bring more subject matter into scope at the same detail, and which one is being asked for decides whether an existing document can answer.

● emphasised by a profile for this use case · ○ relevant but not the focus

Two rows are worth explaining. PQC readiness emphasises implementationPurl because the migration profile is the one place in the worked example that tightens an inherited rule, removing the baseline's permission to withhold it: migration sequencing depends on knowing which library implements an interface. It emphasises interfaceType because product rule P2 turns on it, and an undeclared management interface is the omission a migration plan can least afford. Supply-chain transparency, by contrast, does not emphasise implementationPurl: that use case is bounded by an upper limit on what may be asked, and the library version is the attribute a supplier is most likely to withhold, which is why the baseline marks it withholdable.

The IoT row is the one this table serves least well, and that is worth noticing rather than smoothing over. Its marks are accurate as far as they go, but most of what that use case turns on — whether an update mechanism exists, who can trigger it, whether keys fixed at manufacture can be replaced — is not in any column here, because no existing profile asks for it. A table of emphasis can only compare profiles across the attributes they share.