Generate a CycloneDX 1.7 Cryptography Bill of Materials (CBOM) with DuoKey Cockpit: filesystem, source-code and domain scans, the CBOM Explorer, and the agentic MCP path.
You cannot migrate what you cannot see. Before any post-quantum migration plan means anything, someone has to answer a much duller question first: which algorithms, key sizes and certificates does your estate actually use, right now, everywhere? A Cryptography Bill of Materials (CBOM) is that answer, in a format security teams, auditors and vulnerability-management tools can all consume without a translation layer.
This guide covers how to generate one with DuoKey's PQC Scanner and Cockpit: what a CBOM actually contains, the three ways to produce one (CLI, agentic MCP tools, or CI/CD), and how to read the result in the CBOM Explorer once you have it.
"Generate a CBOM" stopped being a best-practice suggestion and became a regulatory expectation in 2026, across three jurisdictions that matter to most regulated organizations.
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.
The EU's Coordinated Implementation Roadmap for the transition to post-quantum cryptography (published 23 June 2025) sets three binding 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.
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.
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 generating one is what the rest of this guide covers.
A CBOM is a specialized inventory format for documenting every cryptographic asset in your applications and infrastructure (algorithms, certificates, keys and protocols) in a structure that's standardized rather than bespoke to whichever team produced it.
DuoKey's PQC Scanner generates CBOMs that comply with CycloneDX 1.7, the OWASP standard for Software Bill of Materials (SBOM). Version 1.7 added native support for cryptographic assets, which is what turned CycloneDX into the de-facto standard for CBOM specifically. Before that, teams either hand-rolled a format or repurposed SBOM fields that weren't built for cryptographic properties.
That standardization is the point. A CycloneDX CBOM can be:
A DuoKey-generated CBOM follows the CycloneDX Cryptography Extensions, specifically:
| Section | Covers |
|---|---|
| Algorithm Properties (§6.1) | The cryptographic algorithm itself: family, key size, mode |
| Certificate Properties (§6.2) | X.509 certificate metadata: subject, issuer, validity, signature algorithm |
| Related Crypto Material Properties (§6.3) | Keys, keystores and material associated with a component |
| Protocol Properties (§6.4) | Protocol-level cryptographic configuration (e.g. negotiated TLS parameters) |
Each component in the resulting document carries:
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.
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).
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.
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.
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.
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.
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.
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.
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.
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 signalsQuantum 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:
- Provision a hybrid ML-KEM-768 key in DuoKey KMS.
- 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.
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.
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.
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:
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.
Q: What format does DuoKey's CBOM use?
CycloneDX 1.7, the OWASP SBOM standard, using its native cryptography extensions (algorithm, certificate, related-crypto-material and protocol properties). This is the de-facto CBOM standard as of the 1.7 release.
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.
Written by
Nagib Aouini
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
