Proving Your Crypto Inventory Is Complete Without Handing Over the Map

Table of Contents

• Introduction
• A prototype and its limit
• Two claims, one of them provable
• The field knows, and says so
• The proof-of-solvency precedent
• Why the CBOM case is harder than the SBOM case
• Three layers that close the gap
  • Layer one, commitment
  • Layer two, provenance of discovery
  • Layer three, predicate disclosure
• The coverage predicate
• The sector-level question
• What I would ask for in the March guidance
• What this does not fix

Introduction

A prototype and its limit

In December 2025, at a healthcare security workshop in Honolulu, three researchers demonstrated that a compliance document could be turned into working exploit demonstrations for about twenty cents of model compute per tested vulnerability. That same conference week, in the same city, they presented the fix.

Jiarou Deng, Yang Yang and Michael Rushanan brought both to ACSAC 2025: the attack paper to the HealthSec workshop on December 9, and a zero-knowledge framework for validating software bills of materials (SBOMs) to the poster session. It is a working prototype rather than a proposal – a sorted Merkle tree over component hashes, a construction they call TreeGap that proves a component inside or outside a designated subset from its neighbouring hashes, and Groth16 for the proofs, with batch proofs and Merkle forests for scale.

Three parties take part – a manufacturer commits to the inventory and publishes proofs, a trusted third party analyses vulnerabilities and issues signed assessment reports, and a regulator validates them.

The claims the prototype supports are the useful narrow ones. This inventory contains no components with known vulnerabilities as of time T. This inventory does not include the component affected by CVE-X. Richer predicates, meaning true-or-false statements about an inventory that a verifier can check, are possible over a suitably committed one. Proving that a specific component is in a designated list, or provably absent from it, is what this prototype demonstrates. The paper calls these membership and non-membership proofs, and the members here are components; the set they belong to is the list.

A cryptographic bill of materials (CBOM) inventories the cryptographic assets an organization runs, covering algorithms, keys, certificates, and where each is used, and it is among the most sensitive documents a security program produces. The regulators who are starting to ask for these documents – and the March 2027 guidance discussed below will make the request routine – have said almost nothing about protecting them. That was the companion piece, and it ends where a CISO gets stuck. The requests are already arriving. Regulators are starting to ask for cryptographic inventories, and the March 2027 guidance discussed below will make the request routine. Insurers have started pricing quantum readiness and want the document behind the answers. Enterprise customers now send supply-chain questionnaires that ask for evidence, not assurances.

Sending the document as-is is the problem, and Honolulu is the reason. A CBOM is the map of exactly which systems still run breakable cryptography and where, and the December demonstration turned a document of that kind into working exploits for pocket change. Every copy sent is a copy that can leak, and the companion piece showed how the aggregate of everyone’s copies becomes the incident.

You have classified the inventory, split aggregate from detail, put query logging on the joins – and then the legitimate requests arrive anyway. None of this is harvest-now-decrypt-later or any other future threat. It’s next quarter, and every control is beside the point, because the disclosure is legitimate.

Deng’s framework delivers one of the two things a supervisor needs from an inventory. The other is the one supervisors care about most, and no proof system can deliver it. This article separates the two, shows that the researchers already agree, and lays out what closes the gap instead.

Two claims, one of them provable

A regulator or an insurer wants two different things from an inventory, and they behave nothing alike.

Content claims are statements about the record itself – the kind you would want to demonstrate to an outsider, and each one is a predicate. A predicate is a yes-or-no question asked of the inventory, written precisely enough that a machine can answer it, and a proof of a predicate lets someone verify the answer without ever seeing the inventory.

You want to show that no entry matches RSA-2048 and internet-facing and restricted data, because that three-way combination points an attacker at systems that are weak, reachable, and worth the effort, and it is the join that turns an inventory into a target list. Or that ninety-four percent of Tier 1 entries have a migration owner and a target date, or that every certificate in the payment path chains to an approved root.

Zero-knowledge handles these well, and a simple explanation is enough here. A commitment is a cryptographic fingerprint of the inventory: you publish the fingerprint and keep the document. A zero-knowledge proof then convinces a verifier that a statement about the fingerprinted document is true, and tells them nothing else. So the flow is commit to the inventory, publish the commitment, and issue succinct proofs of predicates over it. The verifier receives the answer without receiving the inventory – exactly what TreeGap does when it shows that a component is in a designated list or provably absent from it. The answer itself, and the sequence of questions permitted, still leak something, and a later section returns to that.

Coverage claims are statements about the world, the claim that this record describes the estate, and that is what a supervisor means by comprehensive. It decides whether the evidence means anything, and no zero-knowledge proof can produce it.

This is not a gap waiting for better circuits, since it comes from what a proof is. A zero-knowledge proof checks that a statement is consistent with the committed document, meaning the inventory behind the published fingerprint. The prover chooses that document, and nothing in the mathematics checks the chosen document against the world. So an organization that commits to the clean forty percent of its estate, cherry-picked, gets proofs over it that verify perfectly, and a verifier reading them learns about forty percent of an estate and believes it has learned about the whole. The mathematics is sound and the conclusion is false.

The field knows, and says so

On its own, the point above is a one-paragraph objection that any reviewer could raise. It becomes an article because the researchers building these systems have already raised it themselves, in their own limitations sections, and nobody has read those sections side by side. Four systems, and each states a different piece of the same limitation.

The KTH group behind zkSBOM state it plainly in their limitations. The scheme does not address SBOM accuracy, so an artifact can be proven safe when a vulnerable dependency is simply missing from the record, and they assume the supplier generates the inventory honestly. Their suggested remedies are attestation-based approaches or verifiable execution in a zkVM, which is the right instinct and is future work.

Petra, from Eman Abu Ishgair, Chinenye Okafor, Santiago Torres-Arias at Purdue and Marcela Melara at Intel, goes further and scopes it out by name. Detecting maliciously crafted SBOMs that conceal malicious components is, in the paper’s own words, out of scope. Petra is a redaction and selective-disclosure system, accepted at USENIX Security 2026, and it does what it says. Its abstract calls the mechanism selective encryption. Its design section specifies ciphertext-policy attribute-based encryption. The second implements the first, and neither one addresses completeness – the assumption this article is about.

VeriSBOM, from Castiglione, Ebrahimi and Khakpour, adds an auditor. The auditor validates compliance metadata into a second Merkle structure alongside the package tree. Its decisive assumption is the one this article is about. The supplier’s SBOM is taken to be correct and complete, and the paper concedes the trusted-auditor dependency. The staleness critique often attached to VeriSBOM belongs to the KTH team’s related work rather than to its own limitations section.

And the Johns Hopkins prototype names four open challenges of its own. Data normalization across inconsistent naming and version formats. Scalability of proof generation. Snapshot freshness and reissuance as vulnerability intelligence evolves. Governance of the roles among manufacturers, trusted third parties and regulators, and completeness does not appear on the list.

Two of the four introduce a trusted institution. Precisely what those institutions are given matters, because it is not this problem. VeriSBOM’s auditor validates policy metadata over the SBOM it receives. The trusted third party in Deng’s framework analyses vulnerabilities in the inventory it receives. Neither is asked to go and look at the product to establish that the inventory covers it.

So completeness is not delegated to a human, and in all four systems it is not part of what gets proved. The limitation sections, read together, say the field has agreed to leave it that way.

The proof-of-solvency precedent

Cryptographic finance ran this experiment already, at scale, with money.

A proof of solvency lets an exchange demonstrate that its reserves are sufficient to settle every customer account. Provisions, from Gaby Dagher, Benedikt Bünz, Joseph Bonneau, Jeremy Clark and Dan Boneh at CCS 2015, made it privacy-preserving. The exchange proves assets exceed liabilities without revealing its addresses, its totals, or any customer balance. Elegant, implemented, practical at millions of customers.

Then Kexin Hu, Zhenfeng Zhang and Kaiwen Guo published Breaking the Binding in Computers & Security in 2019. They showed that the Maxwell protocol and the summation Merkle tree underlying this family are not secure against the exchange itself. An exchange can produce a valid proof over a subset of liabilities, and an omitted customer discovers the omission only by performing the inclusion check themselves. Their bound, precisely: the lower bound on successfully verified liabilities is the largest single account balance in the exchange’s dataset. Konstantinos Chalkias, Panagiotis Chatzigiannis and Yan Ji catalogued further failures in Broken Proofs of Solvency, an FC 2022 workshop paper published in the 2023 proceedings.

Each proof was valid for the set presented, and the false step was the inference that the presented set was complete. The cryptography was sound and the omission was upstream of it, since a proof about a committed set says nothing about what was left out, and the exchange chose what went in.

A cryptographic inventory has the same structure and a weaker incentive to catch omissions, because nobody audits a CBOM the way an exchange’s customers audit their own balances. In every vendor conversation, ask what the proof is over, and then ask who decided what went into it.

Why the CBOM case is harder than the SBOM case

Three differences separate the CBOM case from the SBOM case, and every one of them makes the problem harder.

The first is leakage. The KTH team measured this properly for SBOMs and found an asymmetry. A non-inclusion proof leaks fewer than two additional components on average. An inclusion proof leaks between seventeen and a hundred and twenty, depending on the ecosystem. Those figures measure leakage rather than proof-generation cost. An absence answer told the verifier far less about the rest of the inventory than a presence answer did.

Cryptographic estates make that worse, because the value space is small and correlated. Package ecosystems have hundreds of thousands of components. The set of key establishment algorithms in production use across an enterprise numbers in the dozens. A proof that no system uses RSA-2048 on an internet-facing endpoint narrows the remaining possibilities far more than a proof that no application depends on a particular npm package, and a verifier who asks enough such questions reconstructs a good deal of the inventory from answers alone. I have found no published measurement of leakage from cryptographic-inventory predicates as of August 15, 2026, and somebody should do it.

The second is that the interesting predicates are joins. An SBOM proof answers a question about one dimension: is the component present. The questions a supervisor asks about cryptography are conjunctions across exposure, data sensitivity, retention horizon and remediation ownership. Every additional conjunct is another dimension of the inventory the answer discloses something about.

The third is tool disagreement, and here the coverage problem stops being philosophical. A large-scale empirical study of SBOM tooling, published in ACM Transactions on Software Engineering and Methodology in January 2026 from 55,444 SBOMs generated by six tools across 3,287 repositories, found inter-tool consistency for package detection between 7.84 and 12.77 percent depending on language, with license accuracy below twenty percent. Those are tools reading package manifests – a comparatively tractable problem with a written ground truth.

Cryptographic discovery reads binaries, network captures, configuration files and hardware. NIST’s NCCoE built SP 1800-38B around a multi-tool architecture spanning source code, running systems and network traffic. That preliminary draft demonstrates the architecture and does not measure inter-tool agreement. The equivalent number for cryptographic discovery does not exist. A proof over one tool’s output remains a proof about one tool’s output.

Three layers that close the gap

Three layers close it, and the first two are unglamorous, deployable now, and solve most of the problem; most of the discussion is about the third.

Layer one, commitment

Sign and timestamp a Merkle root of each inventory snapshot into a transparency log. The cost is close to nothing and the property is tamper evidence. An inventory cannot be quietly improved after an incident, and a claim made in 2027 can be checked in 2032 against what was actually held. The 2026 SBOM minimum elements already require an author signature, so this is an increment rather than an invention. The IETF finished standardising the rest of it in June 2026 as RFC 9943, the SCITT architecture – an append-only transparency service, COSE-signed statements and receipts – written explicitly for compliance with auditing procedures and regulatory requirements.

Insurers should want this layer more than any other, because their exposure is the claims-time dispute about what the insured knew and when.

Layer two, provenance of discovery

This is the real answer to comprehensiveness, and it works by changing the subject of the attestation. Do not attest the findings; attest the run that produced them. Which scanners at which versions, against which address ranges and repositories and cloud accounts, over what window, authenticated or not, and what failed. A regulator verifies that the discovery covered ninety-six percent of the asset register, and that the register was reconciled against network observation, without ever seeing a finding. Coverage becomes a claim about a process, and a process can be attested – ground truth cannot.

The in-toto attestation framework already defines typed predicates for build provenance, SBOMs, vulnerability scans and verification summaries, and that envelope machinery could be reused. As of August 15, 2026, the in-toto predicate directory contains no registered type for scanning or discovery coverage.

Layer three, predicate disclosure

Near term this is selective opening under sampling, where the assessor draws a random sample using a public beacon so the subject cannot prepare for it and then opens those entries with inclusion proofs against the committed root. Statistically strong, cryptographically trivial, available today with no new research. Longer term it is zero-knowledge proofs of aggregate predicates, where the four systems above already point.

Cost depends on the circuit, the commitment structure and the normalisation rules. The published work does not establish a general direction, so anyone promising cheap aggregate proofs over an estate should be asked to show the benchmark.

The coverage predicate

Applied Quantum is building the layer-two piece as part of the Cryptographic Concentration Framework, and it will be published at CCFramework.org with a resolvable predicate type URI. That is my own firm’s work, and nothing below has been independently validated. The argument here is about the gap rather than about my firm’s implementation of it. Three design decisions are settled enough to state now, and the reason to state them is that any of the three could be reached independently by someone else building the same thing.

Coverage is asserted against a named reference set, identified by cryptographic digest, never against the estate. An estate is unknowable, and any claim to have covered it is unfalsifiable. A claim to have covered this configuration-management database (CMDB) export, these cloud accounts, this repository manifest, each pinned by hash, is checkable by anyone holding the same reference.

ETSI’s TC CYBER quantum-safe group agreed a work item at QSC#31 to build a protocol inventory cataloguing the quantum-safe status of each identified protocol, and then stopped it at QSC#38 in September 2025. A public catalogue of that kind is the sort of object a coverage claim can denominate against, and the fate of that work item is a fair warning about how hard shared reference catalogues are to maintain.

The gap register is mandatory rather than optional, because what was attempted and failed is the field that makes the claim honest, and it is the first thing any voluntary disclosure regime drops. A discovery run that could not authenticate to the mainframe, could not connect to the operational-technology (OT) segment, and timed out on two cloud accounts has produced a legitimate result with three named holes. An attestation that omits the holes is worse than no attestation, because it converts a partial scan into an apparently clean one.

Scanner provenance is attested separately from findings – two artifacts, two audiences. The coverage attestation goes to the regulator, the insurer and the customer, and contains no findings at all. The inventory stays where the controls in the companion article put it. That separation makes the disclosure problem tractable without a zero-knowledge circuit at all.

One thing this does not do, stated plainly because the vendor version of this idea will leave it out. A coverage predicate does not establish that the reference set is right. If a CMDB is missing a quarter of the estate, a perfect attestation against it is a perfect attestation of three quarters of the estate, and the number on the certificate will read ninety-six percent.

My own practitioner estimate in Quantum Ready is that asset registers carry substantial error, worst in operational technology and decentralised estates. That is why I put observed-versus-recorded reconciliation into Phase 1 of the PQC Migration Framework rather than leaving it to a later pass. What the predicate buys is a denominator that is a named, versioned, checkable object instead of an unstated assumption. The argument between an organization and its supervisor becomes an argument about a specific artifact rather than about confidence.

The sector-level question

There’s a version of this problem where the cryptography fits perfectly, and it’s not the one anyone is building.

A supervisor’s real question is not whether one bank’s inventory is comprehensive. It is how many institutions depend on the same hardware security module firmware, the same TLS implementation, the same certificate authority. That is a concentration question rather than a per-firm one. Answering it today requires every institution to hand its inventory to a central authority, and that reproduces the aggregation problem the companion article describes, at sector scale.

Secure multi-party computation was built for exactly this. Mark Flood, Jonathan Katz, Stephen Ong and Adam Smith made the argument in a 2013 Office of Financial Research working paper, including a section on what secure computation does not provide. Emmanuel Abbe, Amir Khandani and Andrew Lo showed in the American Economic Review in 2012 how to compute concentration indexes across institutions without a trusted third party.

The technique ships – the Danish sugar-beet auction cleared 25,000 tons of production rights across 1,200 bidders in about thirty minutes in January 2008. SEPIA aggregated multi-domain network security statistics across up to 140 input providers at USENIX Security in 2010. The Boston Women’s Workforce Council has run recurring wage-gap computations across roughly a hundred employers and 165,000 employees for a decade, and no employer has disclosed payroll.

In financial supervision, this has never left pilot. The BIS Innovation Hub’s Project Aurora is a proof of concept on synthetic data. The FCA’s 2019 TechSprint produced no market-ready solution. Transaction Monitoring Netherlands ran on pooled data, kept the privacy-preserving computation on a separate research track, and wound down before either became supervisory infrastructure. Singapore’s COSMIC platform is live, and it’s a secure sharing system whose public documentation doesn’t establish that it uses multi-party computation at all. Thirteen years after the OFR paper, the technology is deployable, and as of August 15, 2026 I have found no documented production deployment in which a financial supervisor uses secure computation for cross-institution statistics.

What I would ask for in the March guidance

CISA and NIST have until March 19, 2027 to publish minimum elements for a cryptographic bill of materials, a deadline set by Executive Order 14412. The companion article argues they should include a handling model, and here is the other half of that ask.

Specify a disclosure profile, in four parts. Commitment, so that inventories are tamper-evident and claims are checkable later. Provenance attestation of how discovery was performed, so that coverage can be demonstrated without disclosure. Predicate disclosure, so that a recipient can verify a property rather than receive a document. And defined redaction tiers, so that what goes to a regulator, an insurer, a customer and the public are four different artifacts rather than four copies of one.

The precedent for the last of those exists, and it’s not American. CERT-In’s July 2025 guidelines tell organizations to maintain a complete internal bill of materials while producing a customized version for consumers that addresses their security requirements without exposing sensitive data. That’s a two-tier disclosure concept in a national guideline, a year before this conversation started.

What this does not fix

None of this makes a dishonest inventory honest.

An organization that wants to hide a system can leave it out of the reference set, and the attestation will be truthful about a denominator chosen to flatter. Layer one makes that choice permanent and checkable later. Layer two makes the denominator explicit rather than assumed. Layer three lets a sampler test entries the subject did not select. Together they make dishonesty detectable after the fact and honest disclosure possible without exposure. A well-designed audit does the same three things: it fixes the denominator, preserves the evidence as it stood, and tests what the subject did not choose in advance.

The alternative on the table right now is that supervisors keep asking for the document, organizations keep sending it, and the aggregate accumulates somewhere until it becomes the incident. The SEC’s Consolidated Audit Trail ran for fourteen years before the Commission opened a concept release asking whether the design had been right. The cryptographic version of that question is still open, and the answer costs less to build now than to retrofit later.

Disclosure: Applied Quantum, the firm I run, is building the coverage predicate described above and will publish it at CCFramework.org. This article argues that a gap exists and that the artifact my own firm is building would help fill it. Read the argument accordingly.

The post Proving Your Crypto Inventory Is Complete Without Handing Over the Map appeared first on PostQuantum - Quantum Computing, Quantum Security, PQC.