A taxonomy, not a dialect

In June 2024, Ecma International ratified CycloneDX 1.6 as ECMA-424 and gave cryptographic inventory a standardised format. The cryptoProperties structure made algorithms, keys, protocols and certificates first-class inventory objects, and version 1.7 followed in October 2025, becoming ECMA-424’s second edition that December. If you need to record what cryptography exists in an estate, the format question is settled, and it wasn’t settled by us.

The gap

You can read from a CBOM that ML-KEM-768 terminates TLS on a payment gateway. You can’t read whether the migration behind that record is funded or stalled, whether the connection settles card traffic or SWIFT messages, or whether the implementation descends from the same upstream codebase as three other vendors’ products. Those questions stay out of the core by design. Migration governance, sector context and concentration inputs are consumer concerns, and a base inventory model that absorbed them would stop being a base inventory model.

No financial-sector cryptographic inventory schema exists. The sector reuses CycloneDX, which is why the Applied Quantum CBOM Profile exists – a property taxonomy layered on the standard, published under the appliedquantum namespace, adding typed and versioned properties for those three concerns.

Where cryptoProperties already defines a field, we reference it and never restate it. The Profile is not a competing specification and not a fork of the data model. A conforming document is a valid CycloneDX BOM that standard tooling parses today.

The mechanism

The registration mechanism is CycloneDX’s own, run through the project’s public property-taxonomy registry, where IBM, Siemens, NVIDIA, GitLab, Amazon and BSI already publish vendor namespaces. The closest precedent for ours is BSI’s, which expresses TR-03183, Germany’s technical guideline for cyber resilience, as properties on the standard model rather than as a rival format.

We filed the appliedquantum registration as issue #189 on August 14, 2026, and it stays RESERVED until the maintainers add the taxonomy link to the published table, the normal path that IBM, Red Hat, JFrog and ServiceNow entries share today. The Profile’s own front matter puts it this way: a registered namespace is a stable extension mechanism, not a waiting room.

Four tiers

Tier	Content	Namespace	Serves
1	CycloneDX core cryptographic fields	native cryptoProperties	Both frameworks
2	PQC migration governance	appliedquantum:pqc	PQC Migration Framework
3	Sector context	appliedquantum:fs, appliedquantum:custody	Both
4	Concentration and dependency-resolution data	appliedquantum:conc, :pki, :path, :entropy, :lineage	CCF

Tiers are additive and independently adoptable, so an institution running a post-quantum migration adopts Tiers 1 to 3, one computing concentration adds Tier 4, and neither requires the other.

Two frameworks consume the Profile today, the Cryptographic Concentration Framework and the PQC Migration Framework, and each cites a minimum Profile version in its own documents. What a framework requires of a CBOM is that framework’s decision. The CCF publishes a CBOM Conformance Statement at ccframework.org defining which fields its assessments need at which level. The Profile supplies the fields, and what a field means for a score or a milestone is the consuming framework’s call.

Neither consumer owns the Profile, and it versions on its own schedule, for its own reasons. A CCF release doesn’t move it, and neither does a PQC Migration Framework one. That independence is what lets a third framework adopt the taxonomy tomorrow without asking anyone’s permission, and it’s why the Profile has its own home, its own repository and, yes, its own teal.

The exit policy

Every vendor namespace gets asked the same question. What happens when the core adopts a field? The Profile’s deprecation and migration policy is binding, and it makes five commitments. Deprecation is marked in the release following acceptance. A normative one-to-one mapping to the core field is published, including enumeration translation. The deprecated form stays valid for no fewer than two subsequent Profile versions. Tooling must accept both forms during that window. Nothing is removed without a major version increment. And where the core adopts different semantics rather than an equivalent, the appliedquantum field is retained and the difference documented, because silent semantic drift is the failure mode the policy exists to prevent. The whole policy, mapping by mapping, is in a companion post.

Status, licence and review

The Profile publishes as version 1.0-RC under CC BY 4.0, with comment open through October 31, 2026. The specification is at cbomprofile.org, the public taxonomy at github.com/appliedquantum/cyclonedx-property-taxonomy, and the registration record is issue #189 on the CycloneDX property-taxonomy repository. A JSON Schema and a validator ship with the release, with positive and negative fixtures, licensed Apache-2.0 to match CycloneDX’s own schema licensing.

A release candidate is a request – we want the review before v1.0 final, and the taxonomy repository’s issue tracker is where to file it.

The launch set

Five companion posts publish with this one, covering why we used pedigree rather than inventing an ancestry field, what the TLP label in CycloneDX 1.7 does and doesn’t do, the deprecation policy in full, why the Profile is owned by neither framework, and how namespace registration works. None of them needs the others, and the method is the same throughout. Extend ECMA-424 through its own property mechanism, add only where the standard is silent, and upstream what generalises.