top of page

The Event Horizon II: THE DEFINITIVE CBOM OPERATING MODEL

Writer: Brian Couzens
Brian Couzens
8 hours ago
9 min read
“The Event Horizon II” in white Cinzel lettering above a dark vortex looming over a blue and violet wireframe city connected by glowing network lines. Beneath the city, the caption reads “(X + Y) > Z: The Survival Inequality”.

The CBOM Operating Model: From Dark Matter Liability to Defensible Fiduciary Asset


1. The Fiduciary Imperative

In February I published The Definitive CBOM Operating Model. This is its second edition. Cryptography is the keel of a digital business. It secures identity, privacy and the transfer of value across a global economy the IMF sizes at more than $120 trillion, and it sits below the waterline where nobody looks. Ask a bank, a hospital group, a grid operator or a ministry where its cryptography lives, how it behaves and whether it is still fit for purpose, and the answer is a shrug backed by a spreadsheet.

The numbers bear that out. ISACA polled 2,685 digital trust professionals and found that 95 per cent of their organisations had no defined strategy for the quantum transition. Ponemon's 2026 global study for Entrust found that only 43 per cent claim complete visibility of their cryptographic estate, and only 40 per cent of their keys and secrets.

Claim is the operative word. In a 2026 Axiad survey, 90 per cent of CISOs and CIOs said their organisation keeps a continuously updated cryptographic inventory. Among the architects and PKI engineers who manage those assets day to day, 33 per cent said the same. The practitioner sample was small, but the confidence gap is stark. Executive confidence is not evidence of operational visibility.

I call that hidden exposure Cryptographic Dark Matter: invisible, unmeasured and compounding.

Cryptographic opacity is not a technical inconvenience. It is a fiduciary failure, and the instrument that corrects it is the Cryptographic Bill of Materials (CBOM).

A CBOM is not a technical inventory. It is a fiduciary control system. It lets a board and its risk committee answer three questions with evidence:

  • Exposure: where is our weak, obsolete or non-compliant cryptography hiding?

  • Agility: what is our mean time to remediation when an algorithm or a library fails?

  • Readiness: can we prove we are prepared for the post-quantum era?

The mathematical driver: Mosca's inequality

The urgency comes from one ruthless inequality.

  • X, migration time: the years needed to discover, inventory and replace critical cryptography.

  • Y, data shelf life: the years the data must stay confidential. Seven for tax records. Twenty-five or more for health and national security.

  • Z, collapse time: the years until a cryptographically relevant quantum computer breaks today's public-key encryption.

    Mosca’s theorem quantum risk timeline: five years of cryptographic migration (X), followed by ten years of required data confidentiality (Y), extend beyond a quantum break at year twelve (Z). A red risk window highlights the three-year shortfall where X + Y exceeds Z, illustrating exposure to harvest now, decrypt later attacks.

If X + Y is greater than Z, the organisation has already failed. Data intercepted today is exposed to harvest now, decrypt later. Nobody controls Z. Y is set by law and by the business. X is the only variable management can move, and the CBOM Operating Model is the industrial mechanism for compressing it.

This is no longer one country's problem, or one sector's

When I first published this model the dates were proposals. They are now explicit transition milestones, some final and others proposed. NIST's final transition report deprecates RSA and elliptic-curve cryptography after 2030 and disallows them after 2035, at every approved key size. Singapore's central bank has proposed that financial institutions migrate critical systems by the end of 2030, with an earlier end-of-2029 milestone for designated critical information infrastructure. The United Kingdom expects discovery to be finished by 2028. Australia's signals directorate recommends completion by 2030.

The dates differ. The first step is identical in every one of them: find the cryptography. That applies to the hospital holding patient records for a generation, the utility with smart meters bolted to walls for twenty years, the manufacturer shipping vehicles and controllers with algorithms baked into firmware, and the telecoms operator whose network carries the traffic of all the others. None of them can migrate what they cannot see.

2. The Operational Reality: The Dirty Dozen

Traditional scanning fails because it looks for libraries, not usage. It assumes cryptography is static, visible and documented. A modern hybrid estate is none of those things.

The tooling evidence is blunt. In a peer-reviewed 2017 benchmark, five static analysis tools working together caught about 35 per cent of the cryptographic misuses planted in the test cases. Roughly two in every three went unseen, and that was in source code the tools could read. What is negotiated on the wire at runtime never reaches them at all.

These twelve operational realities explain why a legacy inventory is closer to a hallucination than a record.

  1. Vendor boundaries are where your CBOM dies. Suppliers treat embedded cryptography as a trade secret. If you cannot see their firmware signing chains, key handling and upstream dependencies, you hit a trust wall. If you cannot see their cryptography, you cannot validate your own.

  2. Cloud HSMs hide the parts that matter. A cloud provider gives you an API, not the truth. Firmware provenance, entropy validation, failover behaviour and key-usage telemetry stay out of sight. A CBOM without HSM internals is a CBOM without a trust anchor.

  3. On-premise HSMs drift silently. Without constant measurement there are no firmware attestation logs, no operator access histories and no evidence of dual control. Secure hardware drifts into insecurity while the asset register still says "secure".

  4. Off-premise services mutate your cryptography without telling you. CDNs, API gateways and identity brokers terminate TLS, rewrap keys, reissue certificates and downgrade cipher suites. Each mutation belongs in the CBOM.

  5. Hybrid estates break integrity by default. One transaction crosses cloud workloads, on-premise systems, third-party services, legacy appliances and shadow IT. Each has a different trust anchor. A CBOM that does not span all of them is incomplete.

  6. Agility creates drift faster than you can document it. Containers and serverless functions live for seconds. Cryptographic objects appear, change and vanish before governance has noticed. A static CBOM is obsolete the moment it is exported.

  7. Data in motion is negotiated, not configured. The config file says TLS 1.3. A middlebox forces something weaker on the wire. Only runtime telemetry shows what was negotiated.

  8. Data-at-rest encryption is meaningless without custody. "AES-256" tells you nothing. What matters is who holds the key encryption key, where it lives, how it rotates and whether the HSM boundary is shared. Encryption without lifecycle governance is decoration.

  9. Data in use is the blind spot. Secrets sit unencrypted in memory, buffers and enclaves. Ignore the execution environment and you miss the point of vulnerability.

  10. Orchestration layers change cryptography behind your back. CI/CD pipelines and service meshes regenerate keys and rotate secrets with no governance oversight. Automation without cryptographic awareness destroys CBOM integrity.

  11. Monitoring is the only thing that keeps a CBOM alive. Static inventories rot. Governance needs active drift detection that alerts when a compliant system regresses.

  12. A 100 per cent CBOM is impossible. Shadow IT, legacy fragmentation and multi-cloud complexity guarantee gaps. The goal is not perfection. It is governable visibility and continuous correction.

3. The Discovery Architecture: Triangulation

To beat the Dirty Dozen, reject single-source scanning. The Operating Model mandates triangulated discovery: three independent sources of truth, reconciled into one defensible picture.

Layer 1: Source code (the intent)

  • Scope: repositories, build pipelines, open-source and proprietary libraries.

  • Mechanism: static analysis and specialised cryptographic scanners.

  • Discovery: declared libraries, hardcoded seeds and entropy strings.

  • The nuance: what a library provides is not what the application uses.

  • Value: captures developer intent and technical debt before it reaches production.

Layer 2: Infrastructure configuration (the deployment)

  • Scope: HSMs, cloud key management, Kubernetes secrets, infrastructure-as-code.

  • Mechanism: control-plane scanning and certificate lifecycle management platforms.

  • Discovery: key encryption key ownership, HSM partitioning and certificate store content. The certificate inventory lives here, as a subset of the cryptographic picture and not a substitute for it.

  • Value: validates custody of data at rest and certificate status.

Layer 3: Runtime telemetry (the reality)

  • Scope: network interfaces, endpoints, load balancers, API gateways.

  • Mechanism: dynamic analysis using eBPF or network probes.

  • Discovery: actual TLS handshakes, cipher suite negotiation and ephemeral key exchange.

  • Value: validates data in motion and exposes the lie of configuration, where a secure server is quietly downgraded by legacy infrastructure.

Where the three layers disagree, you have found either a risk or a gap in your knowledge. Both are worth more than a clean report from a single scanner.

CBOM Triangulation Architecture: source code, infrastructure configuration and runtime telemetry feed an aggregation engine that produces a unified, audit-grade cryptographic inventory.

4. The Data Standard: OWASP CycloneDX

A CBOM is not a spreadsheet. It is a structured, machine-readable graph. The Operating Model standardises on OWASP CycloneDX, now at version 1.7 and ratified internationally as ECMA-424, with broader coverage of algorithm families and elliptic curves than the version this model was first written against.

Three fields turn raw data into governance intelligence:

  • nistQuantumSecurityLevel: the algorithm's recorded NIST quantum security category. A value of 0 indicates that none of the categories are met. This is one input to assessing post-quantum readiness.

  • executionEnvironment: where the cryptography runs, from plain software memory to a hardware security module.

  • BOM-Link: a reference to an external vendor attestation without ingesting the vendor's proprietary data. This is the practical answer to the first of the Dirty Dozen, the vendor boundary.

    SBOM versus CBOM comparison: a software bill of materials lists packages and versions, while a cryptography bill of materials lists algorithms, keys, protocols and certificates.

5. Strategic Applications: PQC and VEX

The PQC migration engine

The CBOM is the roadmap for the post-quantum transition. Query the estate for every asset where nistQuantumSecurityLevel is 0, and an existential threat becomes a prioritised worklist, with high-value assets first. Treat it as the starting list and not the complete assessment: assets with no recorded classification and classical components inside hybrid constructions need their own review.

VEX integration

A CBOM cuts alert fatigue by validating usage, not presence. A vulnerability is announced in an RSA implementation. The CBOM answers: we carry that library, we use only ECDSA keys, we are not affected. That is a precise, evidence-based statement of non-impact, produced in minutes.

6. Governance and Operations: The RAIDS Log

Technology without governance is chaos. Before deployment, the Operating Model requires a RAIDS log: risks, assumptions, issues, dependencies, safeguards.

  • Assumption: vendor APIs return truthful HSM data.

  • Safeguard: vendors must supply a PQC roadmap. If a vendor cannot give a date, the gap is logged as a supply chain dependency.

  • Risk: legacy IoT devices with hardcoded cryptography that cannot be patched.

  • Safeguard: a physical replacement plan, logged, budgeted and tracked on the critical path.

7. The Execution Engine: The Toxic Asset Register

The pilot must produce a Toxic Asset Register: a risk-ranked list of immediate remediation targets. It is the first output a board can act on.

  • Category A, critical: hardcoded seeds, secrets or API keys. Revoke immediately.

  • Category B, high: deprecated algorithms such as MD5, SHA-1, RC4 and RSA-1024.

  • Category C, medium: certificates within 30 days of expiry.

  • Category D, strategic: devices with baked-in algorithms that cannot be patched, such as legacy smart meters and industrial controllers. These need physical replacement.

    The Toxic Asset Register: four risk-ranked categories of cryptographic findings, from hardcoded keys to unpatchable devices, each with an example and the action required.

8. The Governance Spine

This is the layer that turns the CBOM from a technical artefact into a fiduciary control system.

8.1 Accountability

  • Accountable: the Chief Risk Officer, who owns the fiduciary risk of cryptographic failure.

  • Responsible: the CISO or Head of Cryptography, who owns the Operating Model, the toolchain and the accuracy of the data.

  • Consulted: application owners, who supply the business criticality of what the CBOM finds.

  • Informed: the board and audit committee, who receive the quarterly Toxic Asset burn-down.

8.2 The Kill Chain

Discovery is useless without action. The remediation workflow has four steps:

  1. Ingest and triage. Data arrives in CycloneDX format and the Toxic Asset Register classifies it.

  2. Contextualise. The finding is mapped to a business process: this weak certificate sits on the payments gateway.

  3. Remediate. Apply the fix, the patch or the replacement.

  4. Verify. Confirm the fix through runtime telemetry or the relevant code, infrastructure and key-management evidence.

A fix that has not been verified is a claim, not a result.

The Kill Chain remediation workflow in four steps: ingest and triage, contextualise, remediate, and verify with evidence, running as a continuous cycle.

8.3 Key lifecycle governance

Key records must include lifecycle state. The model follows the NIST SP 800-57 states: pre-activation, active, suspended, deactivated, compromised and destroyed. Compromised is the kill switch. When a key is marked compromised, the governance engine triggers revocation for every dependent artefact.

9. The Benchmarking Framework: The Maturity Model

Level

State

Description

Risk profile

L1

Dark Matter

No inventory. Reliance on developer tribal knowledge.

Existential. PQC indefensible.

L2

Static

Spreadsheets and ad hoc scans. Outdated immediately.

High. False sense of security.

L3

Dynamic

Automated ingestion from one or two sources. Partial visibility.

Medium. Reactive governance.

L4

Triangulated

Target state. Code, infrastructure and runtime synthesised. Drift detection active.

Managed. Defensible posture.

L5

Autonomous

Self-healing. Policy violations trigger auto-remediation such as auto-rotation.

Optimised.

A board should know which level it is at, which level its regulator and its insurer assume it is at, and how wide the distance is between the two.

10. The Board Assurance Statement

The CBOM Operating Model is not a security project. It is a restructuring of the balance sheet.

It moves the organisation from unquantifiable liability to defensible asset management. It does not just fix cryptography. It lays the governance rails needed to survive the post-quantum transition, in whichever jurisdiction and whichever sector the organisation operates.

The output is not a list. The output is trust.

Brian Couzens, CEO, SITG-Consulting

Sources for the figures in this article



Copyright 2026 SITG-Consulting. This work may be shared and quoted provided clear attribution is given to SITG-Consulting as the original author.

Comments


Need an independent assessment of your cryptographic exposure?

bottom of page