CBOM Vendor Landscape

Scope and method

This article treats the cited pages as official documentation from the named publishers. NIST and OWASP provide the principal standards-oriented context in the cited source set; the remaining product descriptions are vendor documentation and should be read as self-reported scope statements. The comparison is intentionally limited to what the passages say. A product is not marked as supporting CBOM merely because it mentions cryptography, post-quantum cryptography, inventory, certificates, or compliance. Explicit wording is distinguished from a reasonable but unproven implication.5316

The source set identifies the NIST overview as current, versioned “NIST PQC overview,” published on 2024-08-13. OWASP’s page is current and identifies CycloneDX as ECMA-424, but supplies no publication or update date. The cited vendor source records are marked current; most have no publication date, update date, or product version. QuProtect is referred to in the passage as “QuProtect R3,” while the QuantumGenie page supplies no product version. These dating differences matter when using the landscape for procurement or architecture decisions.73

What CBOM means in this landscape

OWASP CycloneDX describes itself as a full-stack bill-of-materials standard for supply-chain capabilities and identifies support for software, SaaS, hardware, machine-learning, cryptography, manufacturing, and operations bills of materials, as well as vulnerability disclosure reports, vulnerability exploitability exchange, and attestations. The same passage identifies JSON, XML, and protocol-buffer representations. This establishes a standards context for CBOM, but it does not establish that a listed vendor implements the complete CycloneDX specification or that its output is interoperable with every CycloneDX tool.1

The purpose of a CBOM evaluation is therefore broader than asking whether a product has a “CBOM” label. The practical questions are: what cryptographic objects are found; how are algorithms, keys, certificates, dependencies, owners, and usage contexts represented; which environments are covered; how is evidence refreshed; how are risks prioritized; and whether the resulting information can drive migration, remediation, governance, or reporting. The cited evidence answers these questions unevenly, so absence of a statement is recorded as an evidence gap rather than treated as a negative product finding.164

Landscape by documented capability

The cited vendor material describes several overlapping but non-identical categories. QuantumGenie’s platform page states that it maps applications, services, databases, identities, certificates, and keys, traces paths to weak or quantum-vulnerable cryptography, and scans code, infrastructure, certificates, keys, cloud, and endpoints. Its supporting passage describes an illustrative Cipherscan model with ten discovery surfaces and seven inventory categories, plus a CBOM reference. The page also describes an evidence-led remediation workflow and endpoint, IoT, and OT telemetry. Because the figures and scan are presented as representative or illustrative, they should not be read as independently verified deployment results.2

QuSecure’s QuProtect R3 passage is the clearest explicit CBOM-report statement in the cited vendor evidence: it says the platform can generate cryptographic bill-of-materials reports with one click for CNSA 2.0, CNSSP 15, and GDPR compliance. The same material describes discovery across cloud, on-premises, air-gapped, and legacy systems, cryptographic command and control, remediation, crypto agility, and reporting. The passage is a product claim and does not specify the report schema, export format, validation method, completeness criteria, or whether the compliance mappings are independently assessed.3

SandboxAQ describes AQtive Guard as a unified cryptography-management platform covering inventory through remediation. Its passage emphasizes continuous monitoring, policy compliance, encryption, user and device trustworthiness, and on-demand reports concerning algorithms, data protection, key management, and certificate lifecycle. This supports a broad management and reporting scope, but the cited text does not explicitly say that AQtive Guard produces a CBOM or supports CycloneDX.4

ISARA describes cryptographic discovery and inventory across cloud, on-premises, and hybrid environments, including keys, certificates, algorithms, and dependencies. It also describes risk assessment, prioritized remediation, phased modernization, and identification of quantum-vulnerable cryptography, including hybrid and crypto-agile approaches. The cited passage does not explicitly identify a CBOM export or CycloneDX interoperability, so those items remain evaluation questions.6

QIZ describes visibility into cryptographic assets, dependencies, and exposure, with questions framed around what cryptography is used, where it is applied, and what should be fixed first. PQShield’s material explains the strategic rationale for post-quantum preparation and standards alignment, but the cited passages do not present a CBOM product workflow. Keyfactor’s passage focuses on a living PQC glossary and interoperability testing across TLS, CMS, CLM, and HSMs, including supported algorithms and version requirements. These are relevant to migration planning and interoperability assessment, but they are not, by themselves, evidence of CBOM generation.89

Other cited sources describe adjacent rather than clearly CBOM-centered scope. SafeLogic presents commercial cryptography software and post-quantum cryptography software. Entrust’s cited documentation is for nShield products, integrations, HSMs, monitoring, attestation, and a post-quantum cryptography option pack. CyberArk describes machine-identity security following the combination of Venafi capabilities with its identity-security platform. These passages may be relevant to cryptographic infrastructure, certificates, keys, or implementation, but the cited source set does not establish a CBOM capability for them.51011

Neutral comparison criteria

A defensible comparison should separate five questions. First, is CBOM explicitly named, and is the format or schema identified? Second, what is discovered or inventoried: algorithms, keys, certificates, dependencies, applications, services, data stores, endpoints, or other assets? Third, what operational context is added: ownership, provenance, paths, business impact, lifecycle, policy, or vulnerability status? Fourth, what actions follow: reporting, prioritization, migration planning, automated remediation, code changes, or policy enforcement? Fifth, what proof is available: dated documentation, versioned release notes, test results, customer evidence, or independent assessment? The cited bundle answers the first four selectively and offers little independent validation.16423

• CBOM and standards: explicit CBOM language; CycloneDX or another identified format; JSON, XML, protocol-buffer, or other export details; attestations and provenance.
• Discovery coverage: code, repositories, applications, services, databases, cloud, on-premises, air-gapped, legacy, endpoints, IoT, OT, certificates, keys, and HSMs.
• Context and prioritization: dependencies, algorithm strength, lifecycle, exposure, ownership, business impact, policy status, and quantum vulnerability.
• Actionability: migration candidates, hybrid or crypto-agile planning, remediation workflows, pull requests, validation, policy enforcement, and human review.
• Governance and reporting: compliance mappings, report frequency, audit evidence, change history, access control, and data retention.
• Validation: product version, publication date, supported integrations, test methodology, independently corroborated results, and known exclusions.

Why post-quantum scope matters to CBOM decisions

NIST’s 2024-08-13 overview says that quantum computers could threaten some cryptographic algorithms and that NIST released its first three finalized post-quantum cryptography standards in 2024. The overview explains that post-quantum algorithms are intended to resist attacks by conventional and quantum computers and support general encryption and digital signatures. This provides the external context for identifying cryptographic assets that may require migration, but it does not prescribe a vendor platform or establish that any product fully implements the NIST standards.7

The PQShield material cited here distinguishes the primary quantum impact as concentrated on public-key mechanisms used for key exchange and digital signatures, while symmetric algorithms and hash functions are described as comparatively more robust, subject to key sizes and usage patterns. It also emphasizes standards-based migration, interoperability, and the practical constraints of performance and resources. A CBOM evaluation should therefore test whether a product records algorithm role and usage context, rather than merely counting cryptographic assets.12

This distinction also explains why discovery alone is insufficient. An inventory that identifies an RSA key, certificate, or signature mechanism may still need to show where it is used, what depends on it, how long protected data must remain confidential, and whether replacement affects performance or interoperability. The cited vendor passages variously claim dependency mapping, risk prioritization, migration candidates, interoperability testing, or remediation; they do not establish a common data model across products.16412

A practical evaluation process

Begin with a representative estate rather than a feature checklist. Include source repositories, build pipelines, applications, APIs, certificates, keys, cloud services, databases, endpoints, legacy systems, and—where relevant—IoT, OT, air-gapped environments, and HSMs. Ask each vendor to identify the evidence source for every CBOM entry and to distinguish observed configuration from inferred dependency or risk. QuantumGenie’s passage, for example, describes algorithm provenance, owner responsibility, connections, and source-line context in a representative view; those are useful test dimensions even when the page does not prove universal coverage.26

Next, request a sample CBOM and its machine-readable representation. Confirm whether the output is actually CBOM, whether it follows CycloneDX or another named schema, how relationships are represented, and whether the output can be refreshed without losing history. Compare the same asset across discovery, risk, remediation, and reporting views. For QuSecure, specifically test the stated reports for CNSA 2.0, CNSSP 15, and GDPR and ask how each mapping is maintained. For vendors whose cited passages do not explicitly mention CBOM, ask whether they export or consume it and request documentation supporting the answer.132

Finally, test operational change. Introduce a controlled algorithm or certificate change, an expired artifact, a newly discovered dependency, and an intentionally ambiguous asset. Measure detection latency, evidence quality, ownership assignment, prioritization, remediation review, rollback, and report update behavior. For AI-assisted or automated remediation, require human approval boundaries and validation evidence. The QuantumGenie passage describes proposed ML-KEM migration candidates, testing, security scanning, performance checks, and a pull-request artifact for human review; this is a documented workflow claim, not proof of outcomes in a buyer’s environment.26

Evidence gaps and change risk

The cited source set is not a comprehensive market census. Several well-known security vendors appear only in adjacent product contexts, while many passages are short extracts from product pages. The evidence does not provide comparable pricing, deployment time, product maturity, customer counts, independent testing, support quality, contract terms, or total cost of ownership. It also does not establish common definitions for “cryptographic asset,” “continuous,” “real time,” “automated,” “quantum safe,” or “CBOM report.” Such terms should be converted into acceptance criteria before comparison.1623

Documentation freshness is another risk. The cited source records mark the documents current, but only the NIST record supplies a publication date, and only some passages identify a product or document version. Vendor capabilities, supported algorithms, integrations, schemas, and compliance mappings can change. Recheck the exact product edition, release notes, supported environments, output examples, and legal or compliance claims during a live evaluation. Do not infer that a current page proves historical availability or future support.73

Conclusion

The CBOM vendor landscape is best understood as a set of overlapping capability scopes rather than a single ranked market. OWASP CycloneDX supplies the standards context; QuSecure explicitly documents CBOM reporting; QuantumGenie, SandboxAQ, ISARA, QIZ, and other vendors describe varying combinations of discovery, inventory, risk management, remediation, migration, interoperability, or cryptographic infrastructure. The evidence does not support superiority claims or independent efficacy conclusions. Buyers should compare named schemas, asset coverage, evidence lineage, operational workflows, reporting, validation, and change controls, while treating undocumented capabilities as open questions and vendor statements as claims requiring verification.1532