A cryptographic bill of materials needs enough context to drive migration, but adding context can also make the artifact harder to exchange. The Applied Quantum CBOM Profile, corrected September 9 and open for comment through October 31, offers one approach: a versioned property taxonomy layered on CycloneDX rather than a replacement for its native cryptographic structures.
The profile is an independent release candidate from Applied Quantum, not a finalized CycloneDX standard. Its namespace-registration issue remains open. That status is part of the story. Organizations evaluating any CBOM extension should know which fields are standardized, which come from a registered or proposed namespace, and which are local conventions.
Base facts and governance facts serve different purposes
CycloneDX can represent cryptographic assets and relationships. Migration programs also need organizational facts such as owner, business context, data lifetime, counterparty readiness, remediation status, exception, or target date. Those facts help teams decide what to do, but they may not belong in the core standard or may differ across organizations.
A good extension preserves the distinction. A reader should be able to identify native fields without knowing the extension, process supported standard content when custom properties are ignored, and understand the semantics and version of every additional field.
That requires more than a property name. Useful extension governance includes:
- a stable namespace and documented owner;
- clear definitions, data types, cardinality, and controlled vocabularies;
- a schema and machine-readable validation rules;
- examples for valid, invalid, missing, and unknown values;
- versioning, deprecation, and compatibility policies;
- provenance for derived or assessed values; and
- a path for fields later absorbed by the base standard.
Unknown is not the same as false
Governance extensions often introduce fields that look deceptively simple: PQC ready, migration complete, harvest exposure, supplier ready, or compliant. A Boolean value can hide scope and evidence. “False” may mean tested and not supported, while “unknown” may mean the asset was inaccessible, the supplier did not answer, or the discovery method cannot observe the mechanism.
Profiles should preserve uncertainty explicitly. An assessment value should carry the rule or methodology, observation time, evidence source, coverage, confidence where appropriate, and assessor. Otherwise, a derived conclusion can be mistaken for a directly observed fact.
The same principle applies to canonical identity. Two tools may describe the same certificate, library, endpoint, or algorithm differently. Without stable references and reconciliation rules, merging CBOMs can create duplicates or attach governance state to the wrong asset.
Portability depends on graceful degradation
A CBOM should remain useful outside the tool that created it. A receiving system may understand CycloneDX cryptographic assets but not a custom governance namespace. It should still be able to parse the base artifact, retain unfamiliar fields, and report that some semantics were not evaluated.
Exporters should avoid encoding essential cryptographic facts only in custom properties when a native field exists. Importers should not silently discard extensions. Validation should distinguish a structurally valid CBOM from one that conforms to a particular profile version.
Organizations also need a mapping layer. Internal risk, ownership, and workflow fields can be associated with canonical CBOM assets without forcing every internal process into a shared interchange format. That keeps the artifact portable while allowing richer local governance.
A CBOM is evidence, not automatic truth
Neither a base standard nor an extension solves discovery coverage. A well-formed CBOM can faithfully describe an incomplete scan. It can also contain stale supplier information or inferred relationships. Every material fact needs provenance and freshness.
Teams should record how the artifact was produced: source repositories, binaries, endpoints, configuration, certificate stores, supplier declarations, or manual review. They should identify excluded environments and unsupported asset classes. Completeness should be evaluated against the expected asset population, not assumed from schema validity.
What organizations should do next
First, define the decisions the CBOM must support before selecting extension fields. Migration prioritization, procurement, audit, concentration analysis, and incident response need different context.
Second, prefer native standard structures for native facts. Use extensions for genuinely additional semantics and document the boundary.
Third, test round-trip portability. Export, validate, import into another implementation, preserve unknown properties, and verify that identifiers and relationships survive.
Fourth, version assessments and vocabularies. A change in policy or definition should not silently reinterpret historical artifacts.
Finally, link findings to action. A CBOM becomes operational when out-of-policy cryptography has an owner, remediation plan, exception, re-observation, and proof of closure.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop—discovery, canonical inventory, evaluation, action, and proof—helps teams retain source evidence, normalize cryptographic assets and relationships, evaluate policy, and track remediation.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted, not indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Learn more about Vista’s CBOM and compliance approach.
Where uncertainty remains
The Applied Quantum profile is still a release candidate, its proposed namespace registration is not final, and later versions may change fields or identity conventions. Organizations should evaluate it alongside the current CycloneDX specification and their exchange partners. The broader lesson is stable: extensions are most trustworthy when their ownership, version, semantics, provenance, and relationship to the base standard remain visible.
Source
- About the CBOM Profile, Applied Quantum, corrected release candidate dated September 9, 2026.