← Back to news 15.09.2026

The second bill of materials

By now everyone knows the software bill of materials; the Cyber Resilience Act requires it. Hardly anyone knows the second one: which cryptographic algorithms run where. Since 2024 there has been a format for it, and since this week three ways to fill it.

The software bill of materials has arrived. Annex I Part II of the Cyber Resilience Act requires it "in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products". Anyone buying software today asks for it.

Hardly anyone asks for the second bill of materials, and hardly anyone could deliver it: which cryptographic algorithms does the organisation use where, with which key length, and which of them are being phased out?

Who demands it

The question is not new, it just never sat in a list. BSI C5 demands it in CRY-01. ISO 27001:2022 requires in A.8.24 rules for the use of cryptography, and rules need an inventory to refer to. The CRA requires in Annex I Part I that confidentiality be protected "such as by encrypting relevant data at rest or in transit by state of the art mechanisms", and whoever has to evidence that has to know what they use. DORA Regulation (EU) 2024/1774 requires in Articles 6 and 7 policies and a register of cryptographic procedures.

So the trigger is not the year quantum computers break RSA. The trigger is an audit catalogue being asked about today.

A format, since 2024

CycloneDX, the format software bills of materials are usually delivered in, has had a dedicated component type since version 1.6: cryptographic-asset. An algorithm, a key, a certificate or a protocol is described in it like a software component, with algorithm, parameters, purpose and dependencies. The result is called a Cryptography Bill of Materials, CBOM, standardised as ECMA-424.

A manufacturer can deliver it, an operator can import it, two organisations can compare theirs.

Three ways to fill it

The cryptography inventory in isidaten outputs a CBOM under CycloneDX 1.6 and imports foreign CBOMs, as JSON or XML. An import is a harvest run: every entry carries the origin CBOM import, is recognised by its reference so that the same supplier imported twice creates no duplicates, and is assessed immediately. Nothing is retired on import, because a missing line in someone else’s list does not say the algorithm has disappeared.

The third way is the agent. From version 1.92 it knows the task crypto-scan: SSH host keys, the SSH algorithms offered by the server, certificates from the certificate stores, disk encryption. Those become assessed entries on the respective IT system.

What must never enter the list

A bill of materials about cryptography contains no cryptography. Such a register stands or falls on that rule, and it cannot be kept as a promise, only as a barrier.

That is why the agent’s reporting endpoint reads the raw report before anything is processed and rejects it if it contains a PEM block, a base64 blob or a field name that sounds like key material: error code, log entry, nothing stored. The CBOM import rejects files without a format declaration or below version 1.6 and processes XML without external entities and without DOCTYPE. Otherwise an import that accepts foreign documents is an attack path.

What the list is for

Not for filing. From the assessment against BSI TR-02102 and CNSA 2.0 a migration programme emerges: algorithms being phased out or impermissible, each with a target algorithm, rank and status. The rank follows what an attacker could record today and decrypt later; long-lived first. Every entry moves from open to migrated, and the side exit permanent exception requires an effective exception on the object, not a checkbox.

The question to ask

Can you produce today a list of every place where SHA-1 or 2048-bit RSA is still in use? With a location, not a guess?

If not, you have the first bill of materials and not the second. And the second is the one that gets more expensive over the coming years.

More on the cryptography inventory module page.

Sources

Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex I Part I point 2(e) and Part II point 1. CycloneDX 1.6, Cryptography Bill of Materials, standardised as ECMA-424. BSI TR-02102-1, cryptographic mechanisms: recommendations and key lengths. Delegated Regulation (EU) 2024/1774 under DORA, Articles 6 and 7.

Matching solution isidaten for Cyber Resilience Act

Questions about this update?

Talk to us – we are happy to show you this feature in a demo.