CBOM (Cryptographic Bill of Materials): Format, Example and How to Generate One (2026)

A CBOM (cryptographic bill of materials), also called a cryptography bill of materials, is a machine-readable inventory of the cryptographic assets in a piece of software or a system: algorithms, keys, certificates and protocols, with their properties and the components that depend on them. The common format is OWASP CycloneDX, which added cryptographic assets in version 1.6. A CBOM is the starting point of a post-quantum migration, because it shows where quantum-vulnerable algorithms such as RSA and ECDSA are used.

You cannot migrate what you cannot see. Before a post-quantum migration plan means anything, someone has to answer a duller question first: which algorithms, key sizes and certificates does your estate use, right now, everywhere? A CBOM is that answer, in a format security teams, auditors and vulnerability-management tools can all read without a translation layer.

This guide covers what a CBOM is and how it differs from an SBOM, the CycloneDX fields, a complete JSON example, how to generate one with DuoKey's PQC Scanner and Cockpit (CLI, agentic MCP tools or CI/CD), how to use it for PQC migration, and which regulations now expect one.

---

Table of Contents

1. What a CBOM Is
2. CBOM vs SBOM vs Cryptographic Inventory
3. The CycloneDX CBOM Format and Fields
4. CBOM Example (CycloneDX JSON)
5. What Goes Into a DuoKey CBOM
6. Three Ways to Generate a CBOM
7. The Agentic Way: DuoKey MCP
8. Reading the Result: CBOM Explorer
9. Using a CBOM for PQC Migration
10. Who Requires a CBOM in 2026
11. Best Practices
12. Compliance and Reporting
13. FAQ

---

What a CBOM Is

A cryptographic bill of materials documents every cryptographic asset in your applications and infrastructure (algorithms, certificates, keys and protocols) in a standardized structure rather than a spreadsheet specific to whichever team produced it. For each asset it records what it is (for example ECDSA on curve P-256), its security properties (classical and quantum security level), where it is used, and which components depend on it.

The term comes from the software supply chain. IBM Research proposed the CBOM concept, and the OWASP CycloneDX project added native support for cryptographic assets in CycloneDX 1.6 (April 2024), which Ecma International also published as the ECMA-424 standard. CycloneDX 1.7 extends the cryptography model (for example algorithm families, a registry of elliptic curves and richer certificate lifecycle fields). DuoKey's PQC Scanner generates CBOMs against CycloneDX 1.7.

That standardization is the point. A CycloneDX CBOM can be:

• Shared with security teams as a common artifact, not a spreadsheet only its author understands
• Imported into vulnerability-management systems that already speak CycloneDX
• Used for compliance reporting against NIST, PCI-DSS and SOC 2 frameworks
• Tracked over time to show quantum-readiness migration progress
• Generated automatically in CI/CD pipelines, so the inventory doesn't go stale between manual audits

---

CBOM vs SBOM vs Cryptographic Inventory

The three terms overlap, and regulators use them loosely. The difference is scope.

In practice, CBOMs are the building blocks of the cryptographic inventory: one CBOM per application, release or host, aggregated into an organization-wide view. Our cryptographic inventory and discovery guide covers the inventory side.

---

The CycloneDX CBOM Format and Fields

In CycloneDX, each cryptographic asset is a component of type cryptographic-asset with a cryptoProperties object. The assetType field says which of four kinds of asset it is, and each kind has its own property block.

Every asset can also carry an oid. Two fields matter most for post-quantum work:

• nistQuantumSecurityLevel (0 to 6): the NIST post-quantum security category. A value of 0 means the algorithm offers no security against a quantum attacker (RSA, ECDSA, ECDH). ML-KEM-768, for example, is category 3.
• dependencies (at document level): which application, certificate or protocol uses which algorithm. This is what turns "we use RSA somewhere" into "these five services break if we change this key".

---

CBOM Example (CycloneDX JSON)

Below is a minimal, illustrative CBOM for a single service. The API uses TLS 1.3 with hybrid ML-KEM key exchange, but its certificate is still signed with ECDSA P-256, which a CBOM flags as quantum-vulnerable (nistQuantumSecurityLevel: 0). It validates against the CycloneDX 1.7 JSON schema.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "metadata": {
    "timestamp": "2026-11-02T09:00:00Z",
    "component": { "type": "application", "bom-ref": "app/payments-api", "name": "payments-api" }
  },
  "components": [
    {
      "type": "cryptographic-asset", "bom-ref": "crypto/protocol/tls-1.3", "name": "TLSv1.3",
      "cryptoProperties": {
        "assetType": "protocol",
        "protocolProperties": {
          "type": "tls", "version": "1.3",
          "cipherSuites": [{ "name": "TLS_AES_256_GCM_SHA384", "identifiers": ["0x13", "0x02"] }]
        }
      }
    },
    {
      "type": "cryptographic-asset", "bom-ref": "crypto/certificate/api.example.com", "name": "api.example.com",
      "cryptoProperties": {
        "assetType": "certificate",
        "certificateProperties": {
          "subjectName": "CN=api.example.com",
          "issuerName": "CN=Example Issuing CA",
          "notValidBefore": "2026-06-01T00:00:00Z",
          "notValidAfter": "2027-06-01T00:00:00Z",
          "signatureAlgorithmRef": "crypto/algorithm/ecdsa-p256-sha256",
          "certificateFormat": "X.509"
        }
      }
    },
    {
      "type": "cryptographic-asset", "bom-ref": "crypto/algorithm/ecdsa-p256-sha256", "name": "ECDSA-P256-SHA256",
      "cryptoProperties": {
        "assetType": "algorithm",
        "algorithmProperties": {
          "primitive": "signature", "algorithmFamily": "ECDSA", "ellipticCurve": "nist/P-256",
          "cryptoFunctions": ["sign", "verify"],
          "classicalSecurityLevel": 128, "nistQuantumSecurityLevel": 0
        },
        "oid": "1.2.840.10045.4.3.2"
      }
    },
    {
      "type": "cryptographic-asset", "bom-ref": "crypto/algorithm/ml-kem-768", "name": "ML-KEM-768",
      "cryptoProperties": {
        "assetType": "algorithm",
        "algorithmProperties": {
          "primitive": "kem", "algorithmFamily": "ML-KEM", "parameterSetIdentifier": "768",
          "cryptoFunctions": ["keygen", "encapsulate", "decapsulate"],
          "nistQuantumSecurityLevel": 3
        },
        "oid": "2.16.840.1.101.3.4.4.2"
      }
    }
  ],
  "dependencies": [
    { "ref": "app/payments-api", "dependsOn": ["crypto/protocol/tls-1.3", "crypto/certificate/api.example.com"] },
    { "ref": "crypto/certificate/api.example.com", "dependsOn": ["crypto/algorithm/ecdsa-p256-sha256"] },
    { "ref": "crypto/protocol/tls-1.3", "dependsOn": ["crypto/algorithm/ml-kem-768"] }
  ]
}

Read it the way a migration team would: the key exchange is already post-quantum (hybrid ML-KEM), so recorded traffic is protected against "harvest now, decrypt later"; the certificate signature is not, so it goes on the signature-migration list with a target of ML-DSA. A real CBOM for a production service has dozens to hundreds of such components, which is why it is generated by tools rather than written by hand.

---

What Goes Into a DuoKey CBOM

A DuoKey-generated CBOM follows the CycloneDX Cryptography Extensions, specifically:

Each component in the resulting document carries:

• Identifiers: BOM-Ref, OID, key type/size, format
• Quantum-exposure classification: e.g. flagged as quantum-broken for ECDSA-256
• A recommended migration: e.g. "Migrate to ML-DSA (Dilithium) or SLH-DSA (SPHINCS+) per NIST FIPS 204/205" for a broken signature algorithm
• Dependencies: relationships between components, not just a flat list
• Metadata: timestamps, tool information and application details

Every generated CBOM is validated against the CycloneDX 1.7 specification before it's considered final: format and version compliance, component structure, cryptographic-properties validity and asset-type consistency are all checked automatically.

---

Three Ways to Generate a CBOM

DuoKey's scanner (dke-scanner-agent) covers four scan surfaces, each of which can feed a CBOM:

1. Filesystem scan: walks a directory for certificates, keystores and private keys. Recognizes Java KeyStore (.jks), PKCS#12 (.p12, .pfx), PEM certificates and keys (.pem, .crt, .cer, .key), and on Windows, the LocalMachine and CurrentUser certificate stores.

2. Source-code scan: static analysis across 8 languages with 150+ detection rules for cryptographic usage patterns in code, not just certificate files sitting on disk.

3. Domain scan: a live TLS audit of a hostname. Add the PQC flag to get the post-quantum readiness report and Quantum Risk Score on top of the classic certificate/cipher-suite/protocol/vulnerability audit.

4. Host inventory scan: a one-shot, system-wide cryptographic inventory of a machine (distinct from agent mode, which runs persistently and sends heartbeats to a Cockpit but doesn't scan anything by itself).

Getting the scanner

dke-scanner-agent binaries aren't published on GitHub or a public Docker registry: each Cockpit tenant serves its own signed, short-TTL download link. In Cockpit: Scanner Agents → Generate Installer, pick a platform (Windows x64, Linux x64/arm64, macOS x64/arm64) and a token TTL. This returns a download link and a single-use enrollment token that redeems on first run, with no session JWT to copy and no long-lived credential sitting on the operator's machine.

The API key generated at enrollment is hashed (SHA-256) at rest and shown exactly once: it never appears in URLs, command-line arguments or process listings. On Windows, the installer panel hands you the two commands directly:

$env:DKE_AGENT_ENROLL_TOKEN = "TOKEN-FROM-THE-PANEL"
.\dke-scanner-agent.exe enroll --server https://YOUR-TENANT.duokey.cloud
.\dke-scanner-agent.exe agent

enroll registers the host and persists its configuration to ~/.dke/agent.toml (mode 0600 on Unix; the token comes from the environment variable, not a CLI flag, to keep it out of shell history and process listings). agent then runs as a persistent process sending heartbeats. It doesn't scan anything by itself; run one of the scan subcommands (filesystem, source-code, domain, inventory) separately to actually generate results.

Turning a scan into a CBOM

Once you have scan results, the cbom subcommand exports them as a CycloneDX 1.7 document: components (algorithms, certificates, keys, protocols), their dependencies, metadata and the risk/quantum-vulnerability properties described above, validated against spec before it's written.

For the exact flags on any of these subcommands (filesystem, source-code, domain, inventory, cbom, enroll, ci, upload-scan), run dke-scanner-agent SUBCOMMAND --help. Flags vary by scanner build (some scanners, like packet capture, require the agent to be built with a specific feature), so the CLI's own help output is the authoritative source, not a copy-pasted example that might not match your build.

View or push the result

dke-scanner-agent has no built-in web server. The interactive dashboard is the PQC Readiness module inside DuoKey Cockpit. Upload a scan result there, or use upload-scan after enroll to push results directly (the agent ID and API key come from the enrollment config, not the command line). Scans pushed this way appear on the CBOMs page tagged with the agent that created them.

---

The Agentic Way: DuoKey MCP

If you'd rather drive a scan from an AI agent than remember CLI subcommands and flags, DuoKey's MCP server exposes the same scan surfaces as typed tools. Connect it to Claude or ChatGPT the same way described in our F5 BIG-IP PQC guide, and these tools are available in the same chat.

Run a scan

scan_filesystem(path: "/etc/ssl", extensions: ".pem,.crt,.p12", recursive: true)

scan_source_code(repo_path: "/home/you/projects/my-service")

scan_github_repo(repo: "keycloak/keycloak", branch: "main")

scan_terraform_iac(path: "/home/you/infra/terraform")

Every one of these returns crypto metadata only (algorithms, key sizes, file locations, and the CBOM itself), never raw file contents, source code or secrets. scan_github_repo is worth calling out specifically: pin it to an exact commit (rather than a branch) when you need to reproduce a CBOM for a specific release and diff it against a later one.

Pull the CBOM and findings back out

get_cbom(scan_id: "YOUR-SCAN-ID")

get_vulnerable_assets(scan_id: "YOUR-SCAN-ID", severity: "Critical")

list_scans(search: "my-service", status: "Completed")

get_cbom returns the CycloneDX 1.6+ JSON document directly. get_vulnerable_assets is paginated (limit/offset, up to 2000 per call, with has_more telling you whether to page further), useful when a scan surfaces more findings than you want dumped into one response. list_scans filters server-side over your tenant's whole scan history, so if you're looking for a known target's scans, pass search rather than paging through everything.

Check a domain's quantum readiness score alongside it

get_qrs_score(domain: "example.com")

Returns the total score, risk band and 4-signal breakdown from the domain's most recent completed TLS/Domain scan. Worth noting explicitly: the QRS is a proprietary, observable-posture methodology, not a security audit or a regulatory attestation. Useful as a trend indicator and a conversation starter, not as evidence on its own.

Agentic CBOM in practice

DuoKey's MCP server isn't tied to one model. The same tools work the same way whether you're connected from Claude, ChatGPT, Gemini, Copilot or Mistral.

Here's what that end-to-end flow looks like in a real chat, from "what's our exposure" to an actual fix, entirely through typed tool calls:

You: What's our quantum exposure look like right now?

Claude: I'll fetch the CBOM and compute the QRS.

get_cbom(scan_id: "...") → CycloneDX 1.7, 19 assets

get_qrs_score(domain: "duokey.com") → DuoKey QRS v1.0, 4 weighted signals

Quantum Risk Score: 64/100, quantum-vulnerable. Migration posture 0/10, no hybrid path yet.

You: How do I improve my quantum score?

Claude: Two moves close the gap:

1. Provision a hybrid ML-KEM-768 key in DuoKey KMS.
2. Rotate your Fortinet IPsec VPN onto it.

You: Do it: create the PQC key and rotate my Fortinet IPsec VPN.

Claude: On it, provisioning in DuoKey KMS and rebinding the tunnel.

create_pqc_key(name: "...", key_type: "ml-kem-768", vault_id: "...") → Securosys HSM, hybrid ML-KEM + ECDH

activate_key(key_id: "...")

list_fortinet_ipsec_gateways(target_id: "...")

ensure_fortinet_mlkem_ipsec(target_id: "...", phase1_name: "...", kem_groups: ["ml-kem-768"])

Every tool in that second half is a real, permissioned write, not a demo stub. create_pqc_key generates the key pair inside the vault (FIPS 204/205 in the software vault, or in firmware on a Securosys Primus HSM) and requires Operations.Keys.Create; the private key never leaves the vault. The key starts in the NIST SP 800-57 PreActive state, so activate_key (Operations.Keys.Update) is a deliberate second step, not automatic. ensure_fortinet_mlkem_ipsec is outward-facing: it mutates a real FortiGate's IKEv2 configuration (RFC 9370 additional key exchanges) and requires Operations.Pki.Deploy.ConfigureTarget. An agent scoped only to read CBOMs and QRS scores simply cannot take that last step; provisioning and deployment permissions are separate grants.

---

Reading the Result: CBOM Explorer

Once a CBOM exists, from the CLI, an upload, or an MCP-driven scan, the CBOM Explorer in Cockpit renders it as an interactive cryptographic-asset graph rather than a JSON file you have to read manually.

The summary strip alone answers the question most people open a CBOM for: how many components, of which asset types, and what share is quantum-broken versus still unclassified. 13 components across 4 asset types, 15% broken or weak today, in the scan above.

Select any node in the graph and the side panel shows what it actually depends on: every DEPENDS-ON edge, not just the node's own metadata.

You can isolate quantum-vulnerable primitives directly in the graph, inspect any component's identifiers (BOM-Ref, OID, key type/size, format), and see its quantum-exposure classification and recommended migration inline. A component flagged as quantum-broken (say, ECDSA-256) shows the specific replacement to plan for (e.g. ML-DSA or SLH-DSA per NIST FIPS 204/205), not just a red flag with no next step.

This is the same graph referenced from the PQC Readiness module's scan results view: one CBOM, viewable from either the scan it came from or the CBOMs page directly.

---

Using a CBOM for PQC Migration

A CBOM is not the goal. It is the input to every decision in a PQC migration roadmap:

1. Find the quantum-vulnerable assets. Filter components with nistQuantumSecurityLevel 0 or with an RSA, ECDSA, ECDH or DH algorithm family. These are the assets NIST IR 8547 (draft) proposes to deprecate after 2030 and disallow after 2035.
2. Split key establishment from signatures. Key exchange (key-agree, kem, RSA key transport) is exposed to harvest now, decrypt later today and usually moves first, to hybrid ML-KEM (see ML-KEM key management). Signatures (signature) follow with ML-DSA or SLH-DSA, starting with CA keys.
3. Use dependencies to size the work. One CA key or one shared TLS library can sit under hundreds of components. The dependency graph shows the blast radius of each change and the order in which to make it.
4. Attach owners and data lifetime. A CBOM says what is used; your inventory adds who owns it and how long the protected data must stay confidential. Together they give the priority.
5. Diff CBOMs over time. Comparing the CBOM of each release or each monthly scan shows migration progress and catches regressions, such as a new service shipping with RSA-2048.

To see where your organization stands before a full CBOM exists, the free Quantum Risk Score measures the observable posture of your public domains, and our PQC readiness guide explains how to measure readiness across the estate.

---

Who Requires a CBOM in 2026

"Produce a cryptographic bill of materials" stopped being a best-practice suggestion and became a regulatory expectation in 2026, across three jurisdictions that matter to most regulated organizations.

United States: Executive Order 14412

On 22 June 2026, the White House signed Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks." It directs CISA and NIST to publish the minimum elements for a CBOM, building on the joint CISA/NSA/FBI 2026 Minimum Elements for a Software Bill of Materials (SBOM) (itself an update to NTIA's 2021 SBOM baseline), and tasks the Office of Management and Budget and the National Cyber Director with leading a national post-quantum migration program.

The order sets hard dates: high-value assets and high-impact federal systems must use post-quantum cryptography for key establishment by 31 December 2030, and for digital signatures by 31 December 2031. It builds on National Security Memorandum 10 (2022) and OMB Memorandum M-23-02 (November 2022), which already required agencies to submit a prioritized cryptographic inventory by 4 May 2023, and annually since. A CBOM is the natural, standardized format for exactly that inventory.

European Union: NIS2, the Cyber Resilience Act, and ENISA's roadmap

The EU's Coordinated Implementation Roadmap for the transition to post-quantum cryptography (published 23 June 2025) sets three milestones: Member States begin their PQC transitions, including establishing cryptographic inventories, by the end of 2026; high-risk systems are secured by the end of 2030; the full transition completes by the end of 2035.

Two regulations turn that roadmap into something you can be audited against. NIS2's implementing regulation (EU) 2024/2690 requires covered entities to describe the hardware and software components used in their systems: in practice, the same systematic inventory a CBOM already provides. The EU Cyber Resilience Act goes further, explicitly mandating machine-readable component inventories and requiring cryptographic transparency by December 2027. ENISA's coordinating role across both was expanded further by NIS2 amendments the Commission proposed in January 2026, which tighten supply-chain security requirements bloc-wide.

Switzerland: FINMA Guidance 05/2026

Published 9 July 2026, FINMA Guidance 05/2026 applies to every FINMA-supervised institution: banks, insurers, managers of collective assets, and financial market infrastructures. It's a supervisory communication (Aufsichtsmitteilung), not a new binding circular, but it applies FINMA's existing, technology-neutral operational-resilience rules directly to quantum risk, so "we had no specific rule for this" stops being an answer.

It requires a comprehensive, continuously updated cryptographic inventory covering encryption in transit and at rest, digital signatures, key management and authentication mechanisms, each flagged for quantum vulnerability. It sets crypto-agility as an explicit requirement for new ICT systems, applications and procurements, and requires evaluating the PQC readiness of service providers and outsourced functions before those contracts renew. The deadline: a board-approved PQC roadmap by mid-2027.

The urgency is not hypothetical. In FINMA's own survey of the institutions it supervises, 72% had not yet planned or implemented quantum-safe cryptography measures, and only 8% had a concrete roadmap in place.

What this means practically

Whichever of these applies to you, the deliverable underneath is the same: a systematic, standardized, continuously updated inventory of the cryptography you actually run, machine-readable enough to hand to a regulator or a vulnerability-management tool without a translation layer. That's what a CBOM is built to be, and the sections above show how to produce one.

---

Best Practices

Version your CBOMs. Use semantic versioning so you can tell "this is the current state" from "this is what we scanned three releases ago" at a glance, not by comparing timestamps.

Store them with your source code. Keep CBOMs alongside the codebase they describe rather than in a separate, easily-forgotten location. A CBOM that lives next to the code it inventories is far more likely to get regenerated when the code changes.

Automate regular scans. Schedule weekly CBOM generation via cron (or your CI scheduler) rather than relying on someone remembering to run it before an audit. A CBOM's value drops fast once it's stale.

Include CBOMs in release artifacts. Ship the CBOM alongside the release it describes, the same way you'd ship an SBOM: it's evidence of what actually shipped, not what you intended to ship.

---

Compliance and Reporting

A validated, standardized CBOM is what turns "we believe our cryptography is reasonably current" into something an auditor can actually check. Concretely, DuoKey's CBOM output is positioned to support:

• NIST-aligned reporting: component-level algorithm and key-size data maps directly onto NIST's post-quantum transition guidance (SP 800-131A, IR 8547)
• PCI-DSS: cryptographic asset inventory is a recurring requirement across PCI-DSS v4.0's key-management and cryptography controls
• SOC 2: a versioned, dated CBOM is concrete evidence for change-management and cryptographic-control narratives during an audit cycle

Compliance checking itself runs against saved scan results inside DuoKey CPM (Cryptographic Posture Management). Automated compliance publishing and ServiceNow integration are CPM product features, not standalone dke-scanner-agent CLI commands, so plan for that distinction if you're scripting the CLI path directly rather than working through Cockpit.

---

FAQ

Q: What is a CBOM (cryptographic bill of materials)?

A CBOM is a machine-readable inventory of the cryptographic assets in software or a system (algorithms, keys, certificates and protocols), with their properties and dependencies. It is usually written in CycloneDX format (version 1.6 or later) and is used to find quantum-vulnerable cryptography and plan post-quantum migration.

Q: What is the difference between a CBOM and an SBOM?

An SBOM lists software components (libraries, packages, versions). A CBOM lists the cryptography those components use: which algorithms, key sizes, certificates and protocols, and their quantum security level. CycloneDX can carry both in the same document, and a CBOM is often described as an extension of the SBOM.

Q: Which standard defines the CBOM format?

OWASP CycloneDX, from version 1.6 (April 2024), published by Ecma International as ECMA-424. Cryptographic assets are components of type cryptographic-asset with a cryptoProperties object. CycloneDX 1.7 extends the model; DuoKey generates CycloneDX 1.7 CBOMs.

Q: What format does DuoKey's CBOM use?

CycloneDX 1.7, the OWASP bill-of-materials standard, using its native cryptography model (algorithm, certificate, related-crypto-material and protocol properties). CycloneDX has been the de facto CBOM standard since cryptographic assets were added in version 1.6.

Q: Do I need source code, or can I scan certificates directly?

Either, or both. Filesystem scans find certificates, keystores and private keys on disk; source-code scans find cryptographic usage patterns in code itself; domain scans audit what a live TLS endpoint actually negotiates. Run whichever scan surfaces match what you're trying to inventory. Most teams end up running more than one.

Q: What happens to a component that uses a quantum-vulnerable algorithm?

It's flagged with a quantum-exposure classification (e.g. quantum-broken) and a specific recommended migration, for example ML-DSA or SLH-DSA per NIST FIPS 204/205 for a broken signature algorithm. You see this both in the raw CBOM's properties and inline in the CBOM Explorer graph.

Q: Can I generate a CBOM without installing the CLI agent?

Yes. DuoKey's MCP tools (scan_filesystem, scan_source_code, scan_github_repo, scan_terraform_iac) run the same scan surfaces from an AI agent connected to DuoKey's MCP server, with get_cbom returning the resulting document. See The Agentic Way.

Q: Can I reproduce a CBOM for a specific commit, to diff it against a later one?

Yes, via scan_github_repo with commit set to an exact SHA (which overrides branch). This pins the checkout so the CBOM reflects exactly that commit, letting you diff cryptographic posture across releases rather than just across scan dates.

Q: Is the Quantum Risk Score the same thing as a CBOM?

No. A CBOM is a full cryptographic asset inventory. The Quantum Risk Score (get_qrs_score) is a single score with a risk band and a 4-signal breakdown, computed from a domain's most recent TLS/Domain scan: a summary indicator, not the inventory itself, and explicitly not a substitute for a security audit.

Q: Can an agent actually fix what a CBOM finds, or just report on it?

Both, depending on what it's permissioned to do. Reading a CBOM or a QRS score only needs read scopes. Provisioning a new PQC key (create_pqc_key, activate_key) or rotating equipment onto it (ensure_fortinet_mlkem_ipsec, ensure_f5_mlkem_profile) needs separate, explicit write and deploy permissions. See Agentic CBOM in practice for what that looks like end to end.

Q: Where do compliance reports and ServiceNow integration fit in?

Those run inside DuoKey CPM (Cryptographic Posture Management) against saved scan results in Cockpit. They're not dke-scanner-agent CLI subcommands. If you're automating the CLI path directly (e.g. in a CI pipeline), plan to push results into Cockpit for the compliance/reporting layer rather than expecting the CLI to produce a compliance report on its own.

---

Further reading

• Cryptographic inventory
• PQC migration roadmap
• PQC readiness: how to assess and measure it
• Crypto agility
• ML-KEM key management

---

References

• The White House: Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks
• Federal Register: Securing the Nation Against Advanced Cryptographic Attacks
• CISA, NSA, FBI: 2026 Minimum Elements for a Software Bill of Materials (SBOM)
• European Commission: Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography
• EUR-Lex: Commission Implementing Regulation (EU) 2024/2690 (NIS2 implementing regulation)
• European Commission: EU Cyber Resilience Act
• FINMA: Supervisory Communication 05/2026 on Quantum Computing
• EY Switzerland: Post-quantum cryptography and FINMA Guidance 05/2026
• DuoKey Docs: CBOM - Cryptography Bill of Materials
• DuoKey Docs: Understanding Scanner Results (CBOM section)
• DuoKey Docs: Getting Started with PQC Scanner
• DuoKey Docs: CLI Reference
• OWASP CycloneDX
• CycloneDX: Cryptography Bill of Materials (CBOM)
• CycloneDX 1.7 JSON schema
• Ecma International: ECMA-424 (CycloneDX)
• NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA)
• NIST FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA)
• NIST IR 8547: Transition to Post-Quantum Cryptography Standards