REFERENCE

Terms and definitions

The vocabulary this methodology uses, collected in one place. Definitions here are summaries; the section named against each term is where it is developed and is authoritative if the two differ.

How to read this section

Terms are grouped by what they describe. Where a term is borrowed from elsewhere, the source is named, because a methodology that quietly redefines an established term causes more difficulty than one that invents a new word. Attribute names follow the conventions recorded in Method: a bare name denotes present state and a Supported suffix denotes declared capability.

The last table lists terms deliberately not used, with the reason. Those entries exist because each was considered and set aside, and without a record the discussion tends to recur.

The model

Term	Definition	Developed in
Cryptographic relationship also: edge	The location at which cryptography is applied between parties. It is not itself a cryptographic asset. The methodology's own term.	Model
Endpoint also: node	A party to a cryptographic relationship. An endpoint need not be a running host, and the parties to a relationship need not exist at the same time.	Model
Cryptographic asset	An algorithm, protocol, certificate, or key used by a relationship. Corresponds to the CycloneDX component type of the same name.	Model
Interface	A cryptographic relationship that is a communication interface between two parties. A subset of relationships, retained because the profile's rules are written about interfaces.	Model
Node fact / edge fact	A property of a thing, against a property of a use. "The product supports AES-256-GCM" is a node fact; "this connection negotiated AES-256-GCM" is an edge fact.	Model

Profiles and conformance

Term	Definition	Developed in
Profile	A defined subset of mandatory attributes for a stated objective, expressed independently of any format. A minimum reporting requirement, not exhaustive coverage.	Profile
Profile scope	The boundary a profile declares: the subject type it describes, the relationship types its rules constrain, and the lifecycle stages of reported data it accepts. Decided together in Method step 2 and carried as one object, because the three are one boundary.	Conformance
Identifier scheme	The form a profile requires for identifying a class of asset — a Package URL for a library and for the subject, a named registry for algorithms and protocols. Declared by the profile rather than negotiated per document, so that two disclosures about the same thing can be correlated. C14 checks that the declaration and the rules agree.	Conformance
Stated absence	A structural rule is satisfied by presence or by an explicit statement that the thing is absent, and silence is neither. A subject with no administrative surface says so and conforms; one that simply omits its management interface does not. The disclosure model applied to structure rather than to an attribute.	Profile
Cryptographic purpose	The job cryptography does at a relationship — establishing a key, encrypting, proving identity, protecting a message, signing for the long term, protecting keys, deriving keys. A purpose is not an operation: `sign`/`verify` is one operation covering both a certificate signature and a firmware signature, which migrate a decade apart. Only a purpose carries a timetable, which is why capability is stated per purpose. An entry qualifies for the vocabulary under a four-part test: declarable at the boundary, independently migratable, actionable, and not an ingredient of another purpose. A purpose is not a partition of algorithms — AES-GCM serves encryption and data integrity at once.	PQC Migration
Group rule	A rule constraining a repeated group keyed by a controlled vocabulary, so an interface answers once per key. Member rules are evaluated inside an entry, so a conditional guard refers to that entry rather than to the interface. `coverage` says whether an entry is required for every value in the vocabulary or only for those the scope declares — the difference between a profile that stages a problem and one that drops the part it defers.	Conformance
Orientation	Whether a profile reports present state (`inventory`), forward-looking capability (`migration`), or both. Declared in the scope and enforced against the rules by C12, so that a capability attribute never arrives in place of the present state it is a capability for.	Conformance
Forward-looking attribute	An attribute describing what an interface could do or will do rather than what it does: any name with a `Supported` suffix, and `capabilityStatus`, `blockedBy` and `roadmapRef`, which describe a future state with no present-state counterpart.	PQC Migration
Subject type	What a profile describes: a `product`, a `service`, a `component`, or an `estate-subset`. It determines what a producer can reasonably be asked for, since a consumer operating a service can be asked for more than one holding a product it cannot inspect.	Method
Accepted lifecycle stages	The subset of lifecycle stages a profile will evaluate. An interface reporting a stage outside the set fails the rule constraining the stage, in the same way a carrier version outside `appliesTo` is refused. A derived profile may narrow the set and may not widen it.	Conformance
Decision options	The actions a profile's consumer chooses between, stated explicitly. Their presence is what makes the action-choice test checkable: a decision answerable in only one way is not a decision, and a profile written from one has no principled place to stop.	Method
Product-level rule also: structural rule	A rule constraining the set of interfaces a product declares, such as a required count or a required kind. Catches omission, which per-attribute rules cannot.	Profile
Per-interface rule	A rule applied uniformly to every declared interface.	Profile
Conformance level also: obligation level	MUST, SHOULD or MAY, following BCP 14 (RFC 2119 and RFC 8174). Only MUST determines a verdict.	Conformance
Withholdable	A property of a rule. A withholdable attribute is satisfied by a `withheld` marker; otherwise withholding fails the rule.	Profile
Audience	Who may hold a document, and therefore what it may contain. A profile reflects it only through which rules are `withholdable`: a profile permitting no withholding on the contested rules can be cleared only by a restricted variant, and is therefore a derived profile of the public one. Not yet declarable in a rules file, which is Q54.	Confidentiality
Verdict	The result of evaluating one document revision against one profile version: conforms, does not conform, or refused.	Conformance
Refused	An outcome, distinct from non-conformance, where the carrier version falls below the profile's declared minimum and no assessment is performed. A refusal says nothing about the document's content.	Conformance
Well-formed profile	A profile satisfying the methodology's own requirements C1 to C17. A verdict issued against a profile that is not well-formed establishes nothing.	Conformance
Conformance claim	A statement by an identified party that a named document revision was assessed against a named profile version and produced a stated verdict, citing the profile version, the carrier format version and the content revision.	Conformance
Self-declared claim	A claim in which the evaluating party is the producer of the document. Permitted, and labelled as such.	Conformance
Attested claim	A claim in which the evaluating party is other than the producer.	Conformance
Dual use	The property that one profile is both a specification for the producer and a checklist for the consumer.	Profile
Independent evaluation	Evaluating one CBOM against several profiles, each producing its own verdict. The profiles need not know of each other and are not combined.	Profile
Extension	A profile declaring that it inherits every rule of another and states only additions and tightenings.	Profile
Base and derived profile	The profile named in `extends`, and the one naming it. A derived profile inherits every rule and may add to or tighten them. For a public and a restricted variant, the public profile is the base.	Profile
Profile tag	A short handle such as `interface-disclosure`. The half of a rule citation that says which profile the rule belongs to, and the one identifier that has to be unique along an inheritance chain.	Objects
Rule identifier	Local to the profile that declares it, cited as `tag#id`. The letter says how often the rule is evaluated: `P` per product, `I` per interface, `G` per group entry. A tightened rule keeps the identifier of the profile that introduced it.	Objects
Key coverage	A group rule's `keyCoverage`: whether an entry is required for every key in its vocabulary (`all-purposes`) or only for the keys the profile's scope declares (`in-scope`). Distinct from the product attribute `coverage`, which says how complete a document's interface list is. Both were called coverage until decision 0021.	Profile
Claim verification	Re-running the evaluation a claim records, against the document its digest names, to establish that the claim still holds. It does not establish that the disclosed values are true.	Conformance
Monotonic extension	The rule that a derived profile may add and tighten but never relax. It guarantees that conforming to the derived profile means conforming to the base.	Profile
Profile family	A set of profiles related by extension. A family ordered by depth asks progressively more about the same consumer decision; its shallowest member is the entry profile. Conformance at a depth carries conformance at every depth below it, which is monotonic extension doing the work.	Maturity
Depth	How much a profile asks about the same subject matter and the same decision. A deeper profile adds rules; it does not change what the family is about. Contrast coverage, which brings more subject matter into scope at the same depth, and a branch, which changes the decision.	Maturity
Entry profile	The shallowest profile in a family: the least a producer can disclose and still be checked against something. Set above untargeted scanner output and below a full disclosure bar, so that a producer beginning today has a verdict to show for it.	Maturity
Branch	A derived profile serving a different consumer decision, recognised by a different `objective` or a different `scope.orientation`. Monotonic like any extension, but not a greater depth: the PQC migration profile is a branch of the interface family, not a rung of it.	Maturity
Deferral	Something a profile does not require at this depth, as distinct from something excluded on principle at every depth. A rules file carries both in one `exclusions` list and does not distinguish them mechanically, which is recorded as Q52.	Maturity
Tightening	Raising a conformance level, narrowing a constraint, or removing withholdability. Permitted in an extension.	Profile
Relaxing	Lowering a level, widening a constraint, removing a rule, or adding withholdability. Not permitted in an extension; a profile needing it is independent.	Profile

Disclosure states

Four outcomes are possible for any attribute. The distinction between the last three is required by the 2026 SBOM minimum elements guidance and is not expressible in either format natively.

State	Meaning	Effect on a MUST rule
`value`	A value was supplied and checked against the constraint.	Passes if valid.
`withheld`	The producer holds the information and declines to publish it.	Passes only where the rule is withholdable.
`unknown`	The producer does not have the information.	Fails, reported separately from an absent attribute.
`undeclared`	Neither a value nor a marker was supplied.	Fails.

Attributes

Attributes shared across profiles, followed by those introduced by the PQC migration profile.

Attribute	Definition	Introduced in
`interfaceId`	The producer's own label for an interface. Profiles do not constrain its value, and consumers should not treat it as a stable cross-organization identifier.	Profile
`interfaceType`	The role of an interface, from a controlled vocabulary. What makes a rule such as "declare a management interface" evaluable.	Profile
`protocol`	The protocol securing the interface, such as TLS, SSH or IPsec.	Profile
`protocolVersion` / `protocolVersionsSupported`	The version in use, and the set of versions the interface can negotiate.	Profile / PQC Migration
`keyExchange` / `keyExchangeSupported`	The key-agreement or key-encapsulation algorithm in use, and the set the interface is able to use.	Profile / PQC Migration
`encryption`	The bulk or AEAD algorithm protecting data on the interface.	Profile
`authentication` / `authenticationSupported`	The signature algorithm authenticating the server or host: a certificate signature for TLS, a host key for SSH.	Profile / PQC Migration
`endpointRoles`	The roles of the parties to the interface, such as client and server.	Profile
`lifecycleStage`	The phase at which the data was captured. See the lifecycle table below.	Lifecycle Data
`implementationPurl`	The Package URL of the library implementing the interface's cryptography. The value cross-referenced against vulnerability feeds.	Profile
`coverage`	A product-level statement of how complete the declared interface set is.	PQC Migration
`capabilityStatus`	A commitment class for a capability the interface does not yet have, expressed without a date.	PQC Migration
`blockedBy`	What must change before a capability becomes available, and therefore who is able to change it.	PQC Migration
`roadmapRef`	A reference to a roadmap entry carrying a target release and, where offered, a date. Kept outside the interface so that a slipping date does not force a CBOM revision.	PQC Migration
`enablementMethod`	What a consumer must do to turn a capability on.	PQC Migration
`minimumProductVersion`	The product version at which a capability becomes available. Required where enablement is by software update.	PQC Migration
`providerLocation`	Where key operations execute, which determines whether adopting an algorithm is a software matter at all.	PQC Migration
`coexistence`	Whether the interface can serve classical and post-quantum peers at the same time. Determines whether migration requires a coordinated cutover.	PQC Migration
`negotiationControl`	Whether the interface can be configured to require post-quantum key exchange and refuse a classical fallback.	PQC Migration
`integrationConstraints`	Known effects of enabling a capability, such as handshake size limits or intermediary incompatibilities.	PQC Migration

Controlled vocabularies

Attribute	Permitted values
`interfaceType`	`management` · `service` · `interconnect` · `peer` · `storage`
`lifecycleStage`	`intended` · `implemented` · `configured` · `observed` a profile accepts a subset of these; see profile scope
`subjectType`	`product` · `service` · `component` · `estate-subset`
`orientation`	`inventory` · `migration` · `both`
`cryptographicPurpose`	`key-establishment` · `encryption` · `entity-authentication` · `data-integrity` · `non-repudiation` · `key-protection` · `key-derivation` a sector profile may add to this; whether it may is the mirror of Q35 and is unresolved
`coverage`	`all-external` · `all` · `partial`
`capabilityStatus`	`available` · `committed` · `planned` · `under-evaluation` · `not-planned`
`blockedBy`	`provider` · `product` · `hardware` · `standard` · `certification`
`enablementMethod`	`already-enabled` · `configuration` · `software-update` · `hardware-change` · `licence` · `not-available`
`providerLocation`	`software` · `hsm` · `tee` · `unspecified`
`coexistence`	`simultaneous` · `exclusive` · `unknown`

Lifecycle and provenance

Term	Definition	Developed in
Capture phase	What `lifecycleStage` records: whether a value was intended, implemented, configured or observed. A property of one fact, so two attributes in the same document can differ. Not a revision state.	Lifecycle Data
Revision state	Created, signed, published, superseded. A property of a whole document, and what governance controls. Validation is not one of them: it happens to a published revision repeatedly and changes nothing.	Governance
`intended`	Cryptography specified at design time. Says nothing about what was built.	Lifecycle Data
`implemented`	Cryptography present in the shipped binary. Indicates capability rather than use.	Lifecycle Data
`configured`	Cryptography the deployed configuration permits.	Lifecycle Data
`observed`	Cryptography negotiated on the wire. A snapshot, invalidated by later configuration change.	Lifecycle Data
Readiness gap	The difference between what a product is capable of and what a deployment actually runs.	Lifecycle Data
Product CBOM	A CBOM describing what a product contains or can use. Vendor-produced, normally `implemented`.	Lifecycle Data
Service CBOM	A CBOM describing what a running deployment uses. Operator-produced, normally `configured` or `observed`.	Lifecycle Data
Provenance	The record of how a CBOM was produced: generating tool and version, inputs, lifecycle stage, and any mechanical upgrade applied.	Governance
SBOM Generation Context (CISA)	The lifecycle phase and data available when an SBOM was generated. The equivalent concept in the 2026 minimum elements guidance, at coarser granularity.	Lifecycle Data

Formats, mapping and versions

Term	Definition	Developed in
Carrier format	The format in which a CBOM is serialized, such as CycloneDX or SPDX. Distinct from the profile expressed in it.	Versioning
Mapping	The statement of where each profile attribute lives in a given format, including a canonical location where the format permits several.	Formats
Format adapter	The format-specific part of a validator, which extracts abstract attributes from a concrete document. The only component that changes between formats.	Formats
Acceptance range also: appliesTo	The carrier versions a profile accepts, expressed as a minimum and a tested version.	Versioning
Version bands	The four outcomes of the acceptance range: unsupported below the minimum, legacy between minimum and tested, target at tested, newer above it.	Versioning
Encoding normalization	Agreement on where a value is written, where a format permits more than one valid location.	Formats
Naming normalization	Agreement on how a value is expressed, so that equivalent values match. Addressed by the CycloneDX Cryptography Registry for algorithms.	Formats
Content revision	A successive version of a CBOM for the same subject. The sequence of revisions is the audit trail that progress tracking relies on.	Versioning

Inventory and exchange

Term	Definition	Developed in
Cryptographic inventory	An organization-wide, continuously maintained record of cryptography in use, aggregated from CBOMs and other sources.	Inventory
Extracted CBOM also: output CBOM	A scoped snapshot drawn from an inventory for a specific consumer, filtered and redacted as required.	Inventory
Disclosure variant public variant / restricted variant	One of two or more documents describing the same subject at the same content revision, differing only in which values have been replaced by a `withheld` marker for the audience that may hold it. A variant is not a version: audience is none of the three axes Versioning tracks — carrier format, profile, content revision.	Confidentiality
Redaction	Replacing a value with a `withheld` marker on release. Redaction by deletion is a different act and a worse one: it reads as `undeclared`, fails the rule, and leaves a policy decision indistinguishable from a gap in the producer's tooling.	Confidentiality
Central / distributed / federated inventory	Arrangements for where inventory data is held. In the federated case a profile defines the subset published upward, which makes separately-held inventories comparable.	Inventory
Supersedence	The replacement of a CBOM revision by a newer one for the same subject, with the earlier revision retained for audit.	Governance

Evaluation and policy

Term	Definition	Developed in
Fact	Something a producer observes or declares, recorded in the CBOM.	Policy Evaluation
Evaluation also: derived judgement	A conclusion drawn from facts against criteria that change over time. Produced by an external policy at the time of asking and dated, never stored as a CBOM attribute.	Policy Evaluation
Post-quantum posture	An evaluation, not an attribute. Whether an interface's algorithms are considered quantum-safe, assessed against current guidance.	Policy Evaluation
Cryptographic maturity	An evaluation, not an attribute, on the same basis as posture. The PQC Maturity Model is an instance of this kind of external policy.	Policy Evaluation
Advisory	A third party's statement that a named component, in a stated version range, carries a named weakness. Authored by a maintainer, a numbering authority or a research team — not by the subject's producer, and not part of a CBOM.	Vulnerabilities
VEX statement	A producer's judgement that its product is or is not affected by a named advisory, carrying a justification where it is not. A judgement about the intersection of the CBOM's facts with knowledge held elsewhere, revised when either changes, which is why it is a separate artifact from the document it is about.	Vulnerabilities
Implementation defect	A weakness in code that performs cryptography. Has a version range, a patch and an identifier in a feed, and is found by matching the implementing library (`I9`) against that feed. The CBOM's contribution is to say which interfaces use it.	Vulnerabilities
Algorithm or parameter weakness	A weakness in a choice rather than in code: a deprecated algorithm, an inadequate key length, a classical key exchange against a quantum adversary. Usually no identifier, and never a patch — the remedy is to use something else. Found by a policy evaluation over disclosed facts, for which the CBOM is the only evidence.	Vulnerabilities
Harvest now, decrypt later	Capturing encrypted traffic or stored ciphertext now, to decrypt once a cryptographically relevant quantum computer exists. The exposure depends on how long the data must stay confidential, so it is not visible in the cryptography alone.	Data Exposure
Confidentiality lifetime proposed	How long data carried over an interface must remain confidential after transmission. Recorded in bands so that it is comparable between organizations. A deployment-scope attribute, not a product one. It is a property of the traffic and not of the document; the confidentiality of the CBOM itself is a separate subject, in Confidentiality.	Data Exposure
Urgency ranking	An evaluation, not an attribute. An ordering of interfaces by exposure to the harvest-now-decrypt-later threat, computed from disclosed facts and an external estimate of when the capability arrives.	Data Exposure

Related artifacts

Term	Definition
CBOM	Cryptography Bill of Materials. A structured description of the cryptography a subject contains or uses, at a point in time.
SBOM	Software Bill of Materials. Consumed alongside a CBOM so that cryptography can be related to the components implementing it.
HBOM	Hardware Bill of Materials. Relevant where cryptography is bound to hardware and a change means replacement.
VEX (external)	Vulnerability Exploitability eXchange. The statement that a product is or is not affected by a known vulnerability, expressed as a CSAF VEX document, an OpenVEX document, or a `vulnerabilities` array in a CycloneDX BOM. The four statuses are affected, not affected, fixed and under investigation, and not affected carries a justification.
CSAF (OASIS)	Common Security Advisory Framework 2.0. The machine-readable advisory format, which includes a VEX profile.
CVE (external)	An identifier for one vulnerability in a component. Issued for implementation defects, and not for a product's use of an algorithm guidance has deprecated.
CWE (external)	A classification of weakness types. CWE-327, CWE-326 and CWE-328 are the cryptographic entries. A class rather than an instance, which is why it cannot serve as the identifier of a particular finding — see Q59.
purl (external)	Package URL. The identifier scheme used to name implementing libraries.
BCP 14 (IETF)	RFC 2119 with RFC 8174, defining the requirement keywords MUST, SHOULD and MAY.
Cryptography Registry (CycloneDX)	The registry of stable algorithm identifiers introduced in CycloneDX 1.7. It addresses naming normalization.

Terms deliberately not used

Each of these was considered and set aside. Recording the reasoning prevents the discussion recurring.

Term	Why it is not used
Interface, as the general term	It over-fits. The word suggests two parties communicating simultaneously over a link, which excludes relationships separated in time and those transferring no data. Retained for the subset that genuinely are interfaces.
Cryptographic context	Collides with established usage, where a context is the runtime state held by a cipher implementation.
`pqcPosture`	Removed from the profile. It encodes an evaluation, and its correct value changes when guidance changes without the product changing.
`vulnerable`, and any vulnerability status	Not an attribute. It encodes a judgement about the intersection of the document's facts with an advisory held by a third party, so its correct value changes while the product sits still. It is communicated as a VEX statement alongside the CBOM. Decision 0020.
`plannedAvailability`	Replaced by `capabilityStatus`, `blockedBy` and `roadmapRef`. A date on an interface duplicates one underlying change event across every interface that inherits it.
Maturity level, for a profile	Used in this documentation for a judgement about a product, derived by external versioned policy from disclosed facts — a PQC Maturity Model level, for instance. A profile is what such a judgement reads, so the same phrase for both would give one term two meanings, one of which is excluded from a CBOM on principle. The profile-family sense is called depth. See Maturity.
Tier, for a depth	Taken twice over: a supplier's position in a supply chain, and the ownership arrangement in Governance where the working group owns a baseline and sector bodies own what they derive.
`*Current` suffix	Redundant under the naming conventions, where a bare name already denotes present state.

← Governance Next: Related Work →

PKIC CBOM Profiles Working Group · illustrative documentation.