DEV Community

Max Bayern
Max Bayern

Posted on Originally published at ot-cyber.de

EU CRA and BSI TR-03183: What Grid Tech Vendors Need to Do Now

#security #iot #cybersecurity #cra

Since 11 September 2026 (Art. 71 CRA, Regulation (EU) 2024/2847), manufacturers of products with digital elements must report actively exploited vulnerabilities and severe security incidents via a reporting platform that ENISA is establishing (BSI). Under the German government's draft CRA implementation act, the BSI is meant to become the market surveillance authority (cyber-regulierung.de). If you build protection, telecontrol, control or metering technology, gateways, routers or software for grid operators, you should now put three things in place: a rehearsed reporting process (mandatory since September 2026), SBOMs, and an intake channel for vulnerability reports. SBOM and vulnerability handling under Annex I become mandatory on 11 December 2027, when all CRA requirements apply (Art. 71, Regulation (EU) 2024/2847). According to the BSI, TR-03183 is an aid to implementation.

This is the English adaptation of my German original.

I'm Max Gilg, an OT cybersecurity expert from Rosenheim. In this series I put the Cyber Resilience Act (CRA) into context for individual industries. Today: vendors supplying the power and grid sector in Germany. It is about obligations and deadlines, not incidents or lab results.

What has been mandatory since 11 September 2026?

The CRA is Regulation (EU) 2024/2847. It applies directly; no national transposition is needed. According to the BSI, it entered into force 20 days after its publication in the Official Journal. Since then it has become applicable in stages (BSI). The reporting obligation under Art. 14 has applied since 11 September 2026 (Art. 71, Regulation (EU) 2024/2847). Reports go through a reporting platform that ENISA is establishing (BSI).

Art. 14 CRA provides for staged deadlines: an early warning, a more detailed notification, and a final report (Regulation (EU) 2024/2847).

The obligation also covers products that were on the market before December 2027 (McCann FitzGerald). For the power sector this means: even a telecontrol substation unit that has been running in the field for years and falls within the CRA's scope is covered as soon as the manufacturer learns that a vulnerability in it is being actively exploited.

Will the BSI become the CRA market surveillance authority?

That is what the government draft of the CRA implementation act provides: the BSI is to take on the role of market surveillance authority. The draft creates no new obligations; those come directly from the EU regulation (cyber-regulierung.de). Important: As of today (14 Oct 2026) I could not verify that the act has been passed and promulgated. Check the status before making decisions.

Violations of Annex I and Art. 13 and 14 can lead to significant fines (Regulation (EU) 2024/2847; Jones Day).

Which power and grid products are particularly affected?

  • Annex IV (critical): smart meter gateways in smart metering systems (Springlex)
  • Annex III, Class II: firewalls, intrusion detection and prevention systems (Springlex)
  • Annex III, Class I: among others VPN products, routers, switches, operating systems, network management and SIEM systems

The EU Commission has clarified these categories technically; the core function is what counts (HSF Kramer). My OT assessment: an embedded VPN module does not automatically make a substation automation system an "important" product, whereas a remote access gateway with VPN as its core function can fall under it in individual cases. For protection devices, RTUs and inverters, classification depends on the individual case. Non-binding EU Commission guidance helps with support period, risk assessment and reporting obligations (Hunton).

What does BSI TR-03183 require?

TR-03183 is the BSI Technical Guideline on the CRA (BSI TR-03183):

  • Part 1: general requirements for manufacturers and products, modeled on the CRA's articles and annexes
  • Part 2: formal and technical requirements for SBOMs
  • Part 3: handling of incoming vulnerability reports

Part 2 requires machine-readable SBOMs. Which format versions and mandatory fields per component apply is defined by the respective version of the TR; the current BSI TR-03183-2 is authoritative.

The BSI presents the TR as an aid to implementation. The details are meant to be defined by harmonised standards that are currently being drafted (BSI).

Which steps should vendors take now?

I map the steps to the SANS Five ICS Cybersecurity Critical Controls (my own assignment):

  1. Rehearse the reporting process (CC1 ICS Incident Response): Who decides on a weekend night whether a vulnerability is "actively exploited"? Define roles, keep a template for the early warning ready, and run the reporting deadlines once against the clock.
  2. An SBOM per firmware release (CC5 Risk-Based Vulnerability Management): generate it automatically in the build, not by hand. Only then can you quickly see which devices in the field are affected after a new CVE.
  3. Intake channel for reports (CC5): security.txt, a reachable PSIRT address, a Coordinated Vulnerability Disclosure policy, and CSAF advisories for grid operators.
  4. Review remote access functions (CC4 Secure Remote Access): default passwords, open services, maintenance ports and permanent tunnels belong in the Annex I risk assessment. Remote access should be disableable, logged and use its own authentication.
  5. Document the architecture (CC2 Defensible Architecture): disclose ports, protocols and security functions so operators can plan zones and conduits per IEC 62443-3-3. IEC 62443-4-1 and -4-2 provide the framework for development.
  6. Logging for operators (CC3 ICS Network Visibility & Monitoring): make security events exportable, for example via syslog, so the grid operator's attack detection (SzA) can analyse them.
  7. Clarify support period and conformity route: The CRA generally requires at least five years of support, adjusted to the expected product lifetime (Art. 13). In grids, devices often run considerably longer. If you need a third-party assessment, plan early.

My take: The reporting obligation is the test run for the whole CRA. Without an SBOM per firmware version, the short reporting deadlines are hard to meet in a real incident.

In my view, AI can also help small product teams, for example with matching SBOMs against new CVEs, drafting advisories, and pre-sorting incoming reports. What matters is focusing on the five SANS controls rather than on individual tools.

What does this mean for grid operators and buyers in Bavaria?

In my experience, many grid operators fall under NIS2 or KRITIS rules and therefore need suppliers that report vulnerabilities quickly. Buyers should already demand an SBOM per TR-03183-2, CSAF advisories, a support period and a PSIRT contact in tenders. This helps the manufacturer meet key CRA obligations and the operator meet its supply chain obligations.

My recommendation: Build the reporting path and the SBOM first. The CRA already requires the reporting path today, the SBOM from December 2027, and grid operators should demand both in tenders.

Who helps manufacturers in Bavaria with the CRA?

With CRA as a Service and OT vulnerability management, I set up reporting process, SBOM pipeline and vulnerability intake with manufacturers in a practical way. For operators there is an OT asset inventory. When things are on fire, there is OT emergency help. I work across the DACH region, with a focus on Bavaria, Salzburg and Tyrol.

Sources

If you want your teams (maintenance, engineering) to practise this, see Cyber-Awareness für Instandhaltung und Technik.

Original (German): https://ot-cyber.de/blog/cra-bsi-und-tr-03183-was-netztechnik-hersteller-tun-muessen.html

Max Gilg is an OT cybersecurity consultant based in Rosenheim, Germany (OT-Cyber.de).

Top comments (0)