Supervisors Can Measure a Sector’s Cryptographic Exposure Without Collecting Anyone’s Inventory

From December 11, 2027, a group of European regulators can decide to find out which software components an entire category of products depends on. The group is ADCO, the dedicated administrative cooperation group made up of representatives of the national market surveillance authorities that enforce the EU’s Cyber Resilience Act (CRA), the 2024 regulation that sets cybersecurity requirements for hardware and software sold in the EU. Under Article 13(25), ADCO may decide to run a Union-wide dependency assessment for specific product categories. National authorities may then ask the manufacturers in those categories for their software bills of materials (SBOMs) and give ADCO “anonymised and aggregated information about software dependencies.” ADCO reports the results to the NIS Cooperation Group, where EU member states coordinate their network and information security policy.

The CRA’s authors addressed the confidentiality of those documents. Recital 22 of the regulation says authorities should report to ADCO in anonymized and aggregated form in order to protect the confidentiality of SBOMs. The anonymizing happens after the documents have changed hands, though. A manufacturer that receives a request sends the relevant SBOMs in full to its national authority. The authority anonymizes only its report to ADCO. No assessment under Article 13(25) can run before December 2027, so ADCO and the authorities still have time to decide whether the SBOMs need to leave the manufacturers at all.

Financial supervisors face the same choice in measuring sector-wide cryptographic exposure. Their deadlines are closer. On August 27, 2026, the Saudi Central Bank (SAMA) gave the banks and other institutions it supervises until December 31, 2026 to make their procedures for inventorying cryptographic assets accurate and comprehensive. Under Executive Order 14412, the US Cybersecurity and Infrastructure Security Agency (CISA), working with the National Institute of Standards and Technology (NIST), has until March 19, 2027 to publish guidance on the minimum elements of a cryptographic bill of materials (CBOM). A supervisor can count how many of its banks still use quantum-vulnerable key exchange on internet-facing systems, or depend on the same hardware security module (HSM) vendor, without holding any bank’s CBOM. Collecting the CBOM itself should be the exception, and a supervisor that asks for one should say why.

In Guidance 05/2026, issued in July 2026, Switzerland’s financial regulator, FINMA, recommended that the institutions it supervises have a post-quantum roadmap by mid-2027. The Hong Kong Monetary Authority (HKMA) has already published a figure for its whole banking sector: a Quantum Preparedness Index of 2.3 out of 10, built from a survey of banks in early 2026, which I covered in August.

In August I also described a CBOM as a ranked target list that stays useful to attackers for years. In the companion piece on proving an inventory complete, I argued that a supervisor that answered its concentration question by collecting every bank’s inventory would recreate that risk across a whole sector.

In that piece I listed the precedents for secure computation across institutions, from the Danish sugar-beet auction of 2008 to Project Aurora at the Bank for International Settlements (BIS) Innovation Hub, and found no documented production use of the technique by a financial supervisor. As of October 17, 2026, I still have not found one.

Three Questions Supervisors Ask About a Sector’s Cryptography

Supervisors ask about totals, about exposure to a named flaw, and about concentration on shared suppliers.

Sessions that use only classical key exchange produce the traffic that harvest-now-decrypt-later attackers record today, because a cryptographically relevant quantum computer (CRQC) could decrypt it later. A correctly implemented hybrid key exchange with ML-KEM (CRYSTALS-Kyber) is designed to resist that later decryption. From a count of classical-only sessions, tracked over time, a supervisor can see how fast its banks are migrating against the deadlines it has set.

An endpoint that supports hybrid key exchange can still accept classical-only sessions. A bank answering the query therefore counts the key exchange negotiated in each endpoint’s sessions. Where it has no session data, it reports the endpoint as unknown. The same query can count deprecated or broken configurations, such as TLS 1.0 endpoints or certificates signed with SHA-1.

Supervisors need exposure counts during incident response and concentration counts to judge systemic risk. When many banks use the same vendor, one firmware flaw or one compromised certificate authority can affect all of them at once. Ten banks that use a library in peripheral services pose less systemic risk than ten banks that depend on it for payment authorization, so a concentration query has to ask which service uses each dependency.

A supervisor does not need to read an inventory to get the first, sector-level answer to any of the three. It needs a number computed over the inventories, and each bank can calculate its contribution from its own CBOM.

Central Collection and the 2025 OCC Email Breach

The Office of the Comptroller of the Currency (OCC) supervises US national banks. On February 11, 2025, the OCC learned of unusual interactions between an administrative account in its office automation environment and its users’ mailboxes. On April 8 it notified Congress of a major information security incident under the Federal Information Security Modernization Act. Six days later it wrote to the chief executives of the banks it supervises that the accessed data included “financial supervision information provided by OCC supervised institutions.”

Bloomberg reported, citing two people familiar with the matter and a draft of the OCC’s letter to Congress, that the intruders intercepted the emails of about 103 bank regulators and had access to roughly 150,000 emails from mid-2023 until they were discovered. The OCC’s own letter gives no start date.

A supervisor that gathers documents from its banks puts them where one intruder can take all of them. The OCC’s intruders reached emails. An intruder who reached a central store of cryptographic inventories would leave with a ranked list of every supervised bank’s weakest systems.

Central collection of cryptographic inventories already exists. Since May 2023, US federal agencies have been directed to send inventories of their systems containing quantum-vulnerable cryptography to the Office of the National Cyber Director (ONCD) and CISA every year, under Memorandum M-23-02 from the Office of Management and Budget (OMB), until 2035 or as superseding guidance directs. That is the largest central collection of cryptographic inventories I know of. OMB limited what went into it: agencies were to submit system identifiers, not names that reveal a system’s function or its logical or physical location.

When the Government Accountability Office (GAO) audited 24 agencies between February 2024 and September 2025, it found that one of them had a complete inventory of its priority systems. OMB’s Memorandum M-26-15 of June 2026 now asks agencies to keep a continuously updated inventory of all their cryptographic assets.

EU financial supervisors already pool a related record. Under the EU’s Digital Operational Resilience Act (DORA), financial entities in the EU keep a Register of Information on their contracts with ICT third-party providers. They file it, in the templates set by Implementing Regulation (EU) 2024/2956, with their national authority, which passes it to the European Supervisory Authorities (ESAs). The ESAs drew on those registers to designate the first 19 critical ICT third-party providers in November 2025.

If supervisors built a cryptographic register the same way, both the national authority and the ESAs would receive every bank’s inventory, or a summary of it.

Federated Queries on the FDA Sentinel Model

The US Food and Drug Administration (FDA) answers many of its safety questions about approved drugs and medical devices without collecting patient records. Its Sentinel System is a network of health care organizations, called data partners, that have medical billing information and electronic health records. According to the FDA’s own description, the data partners convert their records into a common data model and run standardized programs that execute identically at every site. They review the results before sending them back through a secure portal, and they keep physical and operational control of the data throughout.

As of October 2025, the Sentinel Distributed Database covered 541.5 million unique patient identifiers from 2000 to 2025. Of the members with both medical and drug coverage, 138.7 million were accruing new data. The FDA launched the Sentinel Initiative in May 2008. After a pilot called Mini-Sentinel, the full system officially launched in February 2016. The data partners send back results, and their records stay with them.

A supervisor can run the same pattern over cryptographic inventories:

1. A common data model. Banks keep their CBOMs in CycloneDX, which Ecma International has standardized as ECMA-424. The supervisor publishes a profile that specifies how libraries, HSM firmware, certificate authorities and endpoint exposure are identified. Without the profile, two banks running the same library would describe it differently, so the supervisor could not add their counts together.
2. A query catalog. The supervisor publishes versioned query programs, such as a count of internet-facing endpoints that negotiate only classical key exchange, grouped by service tier.
3. Local execution against a committed snapshot. Each bank runs the program against a dated snapshot of its CBOM whose hash it has already recorded in a transparency log. The bank returns the answer with that hash attached, together with the counting unit, the population the count covers and the gaps the bank could not resolve. It reports those gaps as unknown.
4. Review before release. As in Sentinel, nothing leaves the bank until the bank has checked it.

The hash binds the bank to one snapshot. It does not show that the query ran against that snapshot, that the answer is right, or that the snapshot covers the bank’s estate.

An examiner who later inspects the bank in place can verify the snapshot against its hash and rerun the query. To test coverage, the examiner samples systems in the estate and looks for them in the snapshot. If the bank builds the commitment as a Merkle tree, it can prove that a sampled entry belongs to the committed snapshot without revealing the other entries. In August I described this kind of commitment as the first of three layers for checking a CBOM without disclosing it.

Per-bank answers still show where each bank stands. A supervisor entitled to examine each bank may want exactly that for routine supervision, alongside examinations in which its staff inspect the underlying records in place. For figures it needs only as sector totals, or figures a national computer emergency response team (CERT) computes across several sectors, the banks can use secure aggregation, so that only the total is revealed under the protocol’s assumptions about collusion.

Counting Exposure With Secure Aggregation and Private Set Intersection

Sector Totals Without Per-Bank Figures

In 2017, Keith Bonawitz and colleagues, most of them at Google, published a secure aggregation protocol with which a server can compute the sum of many participants’ values without learning any participant’s individual value. Each pair of participants derives a shared random mask through Diffie-Hellman key agreement. One adds the mask to its value and the other subtracts it, so the masks cancel when the server adds everything up. The team built the protocol for federated learning on mobile devices, which can drop out mid-protocol. They reported results for up to about 16,000 participants.

A supervisor’s setting is smaller. A few dozen banks on a scheduled run can use a simpler design than one built for phones, provided its designers specify what happens when a bank fails, aborts or submits malformed input mid-run. Each bank computes its count from its own CBOM and submits it masked. The supervisor learns the sector total without learning any single bank’s count, as long as it does not collude with more banks than the protocol is designed to tolerate. With secure aggregation, the supervisor has no way to check whether a bank’s input is true.

KyberSlash and Flaw Lists That Are Already Public

Kyber is the key-encapsulation algorithm from which NIST derived ML-KEM, standardized in August 2024. In late 2023, researchers found that its reference implementation divided secret-dependent values by a public constant, the modulus 3329. On many processors a division takes longer for some inputs than for others, so the running time leaked information about the secret numerator.

Daniel J. Bernstein announced the issue on December 15, and Prasanna Ravi and Matthias Kannwischer reported further secret-dependent divisions on December 30. In the KyberSlash paper, published in 2025, ten researchers recovered Kyber secret keys within minutes through one of the two flaws and within a few hours through the other, on a Raspberry Pi 2 and an Arm Cortex-M4. The maintainers of the affected libraries patched them quickly.

Once the flaw was public, so was the list of affected libraries. A supervisor asking how many of its banks ran an affected version needed no special cryptography. Each bank could check its CBOM against the public list and return a count through a federated query or a secure sum.

Private Set Intersection for Embargoed Flaws

A supervisor needs private set intersection (PSI) only when the list itself is secret. Suppose a national CERT learns, under embargo, that a firmware version used in a family of hardware security modules leaks keys. If the CERT sent the affected versions to 40 banks, it would disclose the flaw before the vendor had a fix. With PSI, the CERT and each bank compare the CERT’s list with the bank’s component identifiers, and neither side learns the other’s set beyond what the agreed output reveals.

In PSI-cardinality, the CERT learns only how many of the bank’s components are on the list. If the CERT should see only the sector total, the protocol has to output each bank’s count as secret shares, which are added up across banks before anything is revealed.

In labeled PSI, the bank learns which of its own components match, along with any remediation notes the CERT attached to them, and nothing else about the list. A bank that feeds in components it does not run could learn more of the list than its own exposure, so its inputs have to be tied to its committed snapshot.

In 2022, Srinivasan Raghuraman and Peter Rindal reported a PSI protocol that computes the intersection of two sets of about a million items each in 0.37 seconds, single-threaded. That figure is for its semi-honest version, which assumes both parties follow the protocol. A 2026 preprint reports cardinality and related set operations on sets of the same size in about three seconds over a local network. A bank’s list of distinct libraries, firmware versions and certificate authorities is unlikely to approach a million entries, so speed is not the obstacle.

Post-Quantum Key Agreement Inside the Protocols

The widely used constructions of both techniques depend on public-key steps that a CRQC could break. Bonawitz’s protocol derives its masks from Diffie-Hellman key agreement. Most practical PSI protocols start from a small number of oblivious transfers. In a 2024 paper, Shen Dong and colleagues note that most practical oblivious transfer protocols, such as those of Naor and Pinkas and of Chou and Orlandi, are based on Diffie-Hellman-like assumptions.

A party that keeps the transcript of an aggregation session, the aggregating party included, could later use a CRQC to undo the masking and read each bank’s own answer. A recorded PSI transcript is exposed in the same way. That is harvest-now-decrypt-later aimed at the privacy protocol itself. Years after the recording, per-bank exposure figures would still describe the systems that are hardest to migrate.

Post-quantum oblivious transfer exists. In 2019, Daniel Masny and Peter Rindal instantiated their oblivious transfer construction with Kyber’s key agreement, and it ran in under a millisecond. In a September 2026 preprint, researchers prove that this construction does not meet the universal composability (UC) definition of security against quantum adversaries, even when built on a post-quantum key-encapsulation mechanism. They prove a weaker, game-based form of security for it instead.

A supervisor commissioning either technique today should require post-quantum key establishment, such as ML-KEM, for every key agreement and transport channel in the protocol, and treat that as necessary but not sufficient. It should also commission a security analysis of the whole deployed protocol against a quantum adversary, covering its internal primitives, authentication and composition. It can keep the query log and delete protocol transcripts after each run where retention rules allow, though it cannot delete copies an attacker has already recorded.

The EU’s Dependency Assessment Under Cyber Resilience Act Article 13(25)

With its dependency assessment, ADCO asks the concentration question about products: which components, especially open-source ones, the products in a category depend on, and how many of them share each component.

I would have ADCO get those answers without the SBOMs ever leaving the manufacturers. It would publish the assessment’s questions as a query catalog. National authorities would ask manufacturers to run the queries against their own SBOMs. Manufacturers would return counts through secure aggregation, so each authority sees totals for its market. ADCO would receive what Article 13(25) already provides for, anonymized and aggregated information about dependencies.

An authority that needs one manufacturer’s documentation can still ask for it with a reasoned request under Article 13(22). On such a request, manufacturers must give the authority the information it needs to assess their products against the CRA’s requirements.

Authorities are not obliged to collect SBOMs under Article 13(25); the text says they may request them. It does not say whether computed answers can replace the documents, and I would want ADCO and the Commission to settle that before the first assessment.

Annex I, Part II, point (1) of the CRA requires an SBOM to cover “at the very least the top-level dependencies” of a product. Cryptographic libraries are often deeper than that. A developer whose application calls libcurl, or a language runtime’s TLS module, gets OpenSSL or another TLS library as a transitive dependency. ADCO would therefore miss much of the cryptographic-library concentration if it relied on minimum SBOMs.

Under Article 13(24), the Commission can specify the SBOM’s format and elements through implementing acts. I would propose using that power to require cryptographic libraries at any depth. Whether Article 13(24) allows that is for the Commission’s lawyers to confirm.

Limiting What Query Answers Reveal About Individual Firms

A questioner who combines query answers can learn facts that no single answer contains. In 1979, Dorothy and Peter Denning and Mayer Schwartz showed that refusing queries about very small or very large groups does not protect the individual records in a statistical database. They found that almost every such database has a “general tracker,” a formula a questioner can use to get answers to refused queries from a few permitted ones.

Banking sectors are often small enough for this to work. If a supervisor already knows five banks’ answers from its examinations, it can work out the sixth bank’s answer from a sector total over six banks. A questioner who can run two permitted queries whose groups differ by a single bank gets that bank’s answer by subtraction.

A supervisor can design four controls into the system before the first query runs:

1. A closed, versioned catalog. The supervisor can run only published queries. To add a query, it follows a change process that the banks can see and comment on.
2. Minimum cell sizes. No result is reported for a group smaller than a set number of banks. The general tracker is the reason this control cannot be the only one.
3. Query budgets and overlap review. The supervisor limits overlapping queries against the same snapshots. It also reviews what a questioner could learn by combining answers from the whole catalog, across reporting periods and as banks join or leave. A cap on the number of queries is not enough, because the subtraction attack needs only two.
4. A query log the banks can read. The supervisor records every query, with its parameters and the snapshot it ran against, in an append-only, access-controlled transparency log that the participating banks and authorized auditors can read. The Internet Engineering Task Force (IETF) set out an architecture for such services in RFC 9943, published in June 2026. Anyone reading a fully public log would see the parameters of embargoed queries.

These controls reduce what a questioner can infer from released results and outside knowledge, without guaranteeing that nothing about a single bank can be inferred.

The US federal government has already widened one aggregate channel. Under CISA’s Continuous Diagnostics and Mitigation (CDM) program, agencies shared summary-level data with CISA. In Executive Order 14028, signed on May 12, 2021, the President gave agencies 75 days to sign agreements with CISA to ensure “object level data, as defined in the MOA, are available and accessible to CISA.” CDM’s acting program manager later described the agreements as giving CISA object-level data in place of the summary-level data it had required before.

I don’t think CISA was wrong to want the detail. A supervisor running a sector query system will want the same detail. Because the supervisor publishes the catalog and logs every query, the banks would see any change to the catalog before it took effect.

Query Answers Depend on Inventory Quality

A query can only count what the inventory contains. The HKMA built its index from survey answers. About half of the banks it surveyed had no formal post-quantum planning in place. GAO went further and asked for evidence. At three of the five sampled agencies that had an inventory, officials supplied no documents supporting the algorithms listed for any sampled system. In Saudi Arabia, as I reported in September, some banks facing SAMA’s deadline have commissioned interview-based inventories that, from what I hear, the banks themselves expect to be inaccurate.

If a bank built its CBOM from workshops with application owners, it can answer a federated query only with what those owners remembered.

In August I proposed three layers for making a CBOM checkable without disclosing it, and two of them apply here. With a commitment, the bank fixes the inventory as it stood on a date, so an examiner can later test the bank’s answers against it. Provenance of discovery means the bank attests which tools ran, against which address ranges, repositories and cloud accounts, and what they failed to reach, so the supervisor can tell a scanned estate from a questionnaire.

Several regulators I talk to are now preparing to test inventory quality: discovery coverage and process, the CBOMs banks receive from their vendors, and how each bank manages its vendors’ quantum readiness. A supervisor that receives per-bank answers and runs those tests can examine first the banks whose answers look weakest, and use the findings to calibrate how far it relies on each bank’s later submissions.

What Firms Can Do Before a Supervisor Asks

I would ask a CISO to do five things before the first request arrives:

1. Commit to dated snapshots. Take a snapshot of the CBOM, date it and record a signed hash of it in a transparency log. Answer every external question against a named snapshot.
2. Keep the CBOM in CycloneDX with stable identifiers. Record libraries, HSM firmware and certificate authorities under the identifiers another bank’s CBOM would use for the same thing, or the supervisor cannot combine the counts.
3. Run the three sector questions against your own CBOM now. If counting internet-facing endpoints with classical-only key exchange takes a week of spreadsheet work, a supervisor that sends the first query is likely to ask for the document instead.
4. Propose answers or inspection in place before a copy. When a supervisor asks for the full CBOM, propose the query answers first. If those are not enough, propose an inspection in which the examiner reads the CBOM in a controlled environment and leaves with notes rather than a copy. Ask which question the supervisor needs the copy to answer. A lawful request still has to be met. The bank can propose alternatives but cannot make compliance conditional on them.
5. Ask for handling terms on any copy that leaves. Ask the supervisor to confirm in writing who will keep the copy, where, for how long, who else may see it and when it will be deleted. I set out the reasons in August.

What the Quantum Policy Forum Paper Recommends

The Quantum Policy Forum, which I chair, has published a longer paper on this question for supervisors and policymakers, with an example query catalog and a pilot design. Its main recommendations are these:

1. Make queries the default and collection the exception. A raw CBOM leaves a bank only on a reasoned request, and the supervisor inspects it in place where it can.
2. Standardize the inputs and the questions, with CycloneDX CBOMs under a published profile, a versioned query catalog with suppression rules and budgets, and a transparency log of every query.
3. Build the incident capability with national CERTs before the next flaw is disclosed, with secure aggregation for totals and PSI where the list is sensitive.
4. Ask supervised firms for committed inventory snapshots and attested discovery coverage.
5. Run the CRA’s dependency assessments without moving SBOMs wherever possible, and count cryptographic libraries at any depth.

The paper also proposes a pilot with five to ten institutions, one supervisor and one CERT, and asks for query outputs to be protected as confidential supervisory information.

When the EU Can Run Its First Dependency Assessment

No SBOM can be requested under Article 13(25) before December 11, 2027. Financial supervisors will send their first requests sooner. SAMA’s deadline for Saudi banks’ inventory procedures is December 31, 2026. CISA’s guidance on the minimum elements of a CBOM is due in March 2027.

The HKMA has set full readiness for its banks, a score of 10 on its index, as its target for 2030, and it will need a sector figure better than survey answers to know when its banks get there. ADCO, SAMA and the HKMA can each still choose a method in which the inventories stay with the firms that produced them.

From the author