Skip to content

Your CBOM on demand: proof an auditor accepts, generated from the live inventory

A CycloneDX v1.6 CBOM on demand, with policy compliance read from what is on the wire.

Request a demo

Each links to its definition, with the source it came from.

All terms

What is a CBOM?

A cryptographic bill of materials (CBOM) is a machine-readable inventory of the algorithms, protocols, certificates and keys in use across your network. It extends the software bill of materials (SBOM) concept to cryptography, in the same CycloneDX standard.

QuProtect R3's CBOM Overview screen, which describes what a cryptographic bill of materials contains and offers Asset Discovery, Custom Asset Analysis and Policy Management as its reporting tools, beside the cover of the Cryptographic Bill of Materials executive guide it generates.

Why do you need one?

You cannot fix what you cannot see. Migration starts with knowing where legacy cryptography runs.

Regulators now ask for it. PCI DSS 12.3.3 requires a documented cryptographic inventory reviewed at least every 12 months. EO 14412, signed 22 June 2026, and OMB M-26-15, issued 24 June 2026, require federal inventories and a crypto-agility architecture, with agency plans due around 22 October 2026. CNSA 2.0 sets the algorithms those inventories are measured against.

Evidence an auditor can open. A CBOM is a file an auditor opens and checks against the standard, rather than a statement in a slide deck.

Not a snapshot

Row
Source
An audit report
Last quarter's project
A QuProtect report
The live inventory, on the wire now
Row
Freshness
An audit report
Out of date the day it ships
A QuProtect report
Current the moment you open it
Row
Format
An audit report
Static pages
A QuProtect report
CycloneDX v1.6 CBOM, generated on demand
Row
Detail
An audit report
Sampled systems
A QuProtect report
Each connection observed: protocol, key exchange, signature, certificate and key size
Row
Policy compliance
An audit report
Assessed once
A QuProtect report
What is in and out of policy, and what changed
Row
Remediation record
An audit report
Tracked separately
A QuProtect report
The finding, the policy change, the result
Row
The next report
An audit report
Another project
A QuProtect report
A button

Reporting is the proof layer of the same platform: Reconnaissance finds, Resilience fixes.

Mapped to the instruments you answer to

Each instrument, what it requires, and the artifact QuProtect Reporting produces for it.

  • OMB M-26-15 (24 June 2026)

    Agency plans with an automated inventory method and a crypto-agility architecture, due around 22 October 2026; CBOM guidance due 19 March 2027

    The automated inventory, and the CBOM in machine-readable form for submission

  • EO 14412 (22 June 2026)

    Migration of key establishment for high value assets and high impact systems by 31 December 2030, signatures by 31 December 2031

    Current state per connection, and the record of each policy change against it

  • CNSA 2.0

    ML-KEM-1024 and ML-DSA for National Security Systems

    Per-connection assessment against the CNSA 2.0 algorithm set

  • NIST IR 8547

    Transition planning away from quantum-vulnerable public-key cryptography

    The inventory the transition plan is built from

  • PCI DSS 4.0, 12.3.3

    A documented cryptographic inventory, reviewed at least every 12 months

    A live inventory, so the annual review is a read rather than a project

  • DORA

    ICT risk controls for financial entities, including encryption of data in transit, evidenced on request

    Evidence of what is negotiated on each connection, exportable on demand

QuProtect Reporting supports compliance with each instrument above. Where a specific control is satisfied directly, the report names it.

Where reporting changes the game

Whether you're securing infrastructure, supporting audits, or managing third-party risk, Reporting empowers you to act with clarity and confidence.

  • Board reporting

    Visibility into cryptographic posture for risk committees and executives, with no IT jargon required.

  • Vendor risk management

    Hold third parties accountable for deprecated cryptographic libraries and algorithms that fall outside your standards.

  • Compliance

    Demonstrate adherence to federal, industry, and internal mandates with zero guesswork.

  • Testing and QA

    Identify inconsistencies in algorithm use across dev, staging, and production environments.

Frequently asked questions

  • Can QuProtect show compliance gaps in real time for NIST and CNSA 2.0?

    Yes. Reporting assesses each observed connection against the policy in force, including the CNSA 2.0 algorithm set, and shows what is in and out of policy as the traffic changes rather than at an audit interval.

  • Does QuSecure help European financial institutions meet DORA requirements?

    QuProtect supports DORA’s ICT risk requirements for data in transit by producing evidence of the cryptography actually negotiated on each connection, and by changing it centrally when a control gap is found.

  • Can I export audit evidence for a SOC 2 audit?

    Yes. Reports export on demand in machine-readable and human-readable form, covering the cryptography in use, the policy in force and the record of changes, which is the evidence a cryptography control objective usually asks for.

  • Is the report a one-time snapshot?

    No. Reports generate on demand from the inventory, which updates continuously from live traffic. PCI DSS 12.3.3 requires the inventory to be reviewed at least every 12 months; a live source makes that review a read rather than a project.

  • Who holds the report data?

    You do. QuProtect R3 is self-managed: the platform, the inventory and every export stay in your environment, cloud, on-premises or air-gapped, under your control.

  • What happens after a report surfaces a problem?

    Remediation runs on the same platform. An administrator sets a policy in the Orchestrator, encryptors apply the new cryptography at the network layer, and the fix appears in the next export.

Terms on this page

  • CBOM Cryptographic Bill of Materials

    A structured inventory of the cryptographic assets in a system: the algorithms, keys and certificates in use, and how they relate to the software components that use them. CycloneDX, which publishes the format, calls it a Cryptography Bill of Materials.

    Source: OWASP CycloneDX , CycloneDX v1.6 (cyclonedx.org)

  • DORA Digital Operational Resilience Act

    The European regulation on digital operational resilience for the financial sector, in force since 2022. It consolidates ICT risk requirements that were previously spread across several financial services laws into one framework covering risk management, incident reporting, resilience testing and third-party providers.

    Source: EUR-Lex , Regulation (EU) 2022/2554 (eur-lex.europa.eu)

  • FedRAMP Federal Risk and Authorization Management Program

    A governmentwide program providing a standardized approach to security assessment and authorization for cloud products and services used by U.S. federal agencies. An agency buying a cloud service generally expects it to hold a FedRAMP authorization at a baseline matching the sensitivity of the data involved.

    Source: FedRAMP , FedRAMP program overview (www.fedramp.gov)

  • FIPS Federal Information Processing Standards

    A standard for adoption and use by federal departments and agencies, developed within NIST’s Information Technology Laboratory. A FIPS covers a specific topic in information technology to achieve a common level of quality or some level of interoperability. The post-quantum algorithms are published as FIPS 203, 204 and 205.

    Source: NIST , NIST SP 1800-12b (csrc.nist.gov)

  • PCI DSS Payment Card Industry Data Security Standard

    The payment security standard intended for entities that store, process or transmit payment account data, and for developers and manufacturers of the software and devices used in those transactions.

    Source: PCI Security Standards Council , PCI Security Standards Council (www.pcisecuritystandards.org)

  • SOC 2

    An examination of the controls at a service organization relevant to security, availability, processing integrity, confidentiality or privacy. A SOC 2 report is what a customer asks a vendor for as evidence, which is why the ability to export cryptographic evidence on demand matters to one.

    Source: AICPA , SOC 2: Reporting on an Examination of Controls at a Service Organization (www.aicpa-cima.com)

See the full glossary

Bring your auditor's question.

A technical session against your own architecture.

Request a demo The QuProtect R3 platform