Non-binding, but machine-readable

Anyone searching the Cyber Resilience Act for concrete measures will not find any. Annex I states objectives: no known exploitable vulnerabilities, security by default, updates throughout the support period. How a manufacturer gets there is left open by the regulation. This is exactly the gap targeted by the Technical Guideline the BSI has issued in version 1.0.0, dated 31 July on its cover page.

TR-03183-1 is deliberately modest: an entry aid, not a harmonised standard. Implementing it grants no presumption of conformity. It is aimed at manufacturers in the default product class who do not yet have mature security processes, and its core is not a checklist but a risk-based selection procedure: which measures fit this product, and why these in particular?

The real progress sits in a subordinate clause

Supplementing the guideline, the BSI provides an initial selection of the measures in the OSCAL format. That sounds technical, but it is the actual news. A catalog published as a PDF gets retyped, maintained in spreadsheets and goes stale there. A catalog published as data can be imported, linked to other requirements and simply re-read with every new version.

The BSI has chosen this path before: its state-of-the-art library on GitHub delivers IT-Grundschutz content as OSCAL data. That the CRA measures now appear the same way turns a recommendation into something tools can process directly for the first time.

One caveat belongs with that, and it is stated in the guideline itself: the catalog is not available for free download. The GitHub repository it names is not publicly reachable, and according to the document access is granted on request to the BSI functional mailbox. Anyone wanting to work with it writes an email first. That does not contradict the good news, but it shifts it: the format is settled, its distribution is not.

What this means for preparation

From 11 September the first reporting obligations of the CRA apply, with full application following at the end of 2027. The time in between is for the groundwork: selecting measures, justifying the selection, demonstrating implementation. A machine-readable list of measures is exactly the right starting material for that.

In the CRA module we already maintain the essential requirements of Annex I as an OSCAL catalog, with a conformity assessment per product and the reporting chain for incidents. Once the BSI's selection of measures is at hand, it can be maintained as a further layer alongside: the abstract requirement from the regulation on top, the concrete measure from the guideline below it, and in between the reasoning why it was chosen.