CRA in building technology & building management systems

When the building goes online: why the CRA hits building automation

Modern building automation is no longer an isolated fieldbus universe. KNX, BACnet and Modbus now terminate at IP gateways, connect to cloud dashboards, are serviced by remote maintenance and feed operating data to higher-level building management systems (BMS). This very connectivity is why DDC controllers, room automation stations, IP gateways and BMS servers qualify as "products with digital elements" (PDE) under the Cyber Resilience Act (Regulation (EU) 2024/2847): once a device has a direct or indirect data connection, it is generally in scope.

The real pain in this sector is not regulation as such, but the collision of two time horizons. A building automation installation typically runs 15 to 20 years, sometimes longer. Yet the CRA requires security-by-design, active vulnerability handling and security updates across a defined support period matching the expected product lifetime (guideline: at least five years, not a rigid deadline). A controller shipped years ago with an embedded Linux and a now-outdated TLS library, sitting today in hundreds of properties without a permanent internet connection, becomes an issue – not in theory, but at the next model change and in every tender where operators ask about CRA conformity.

Add the OT/IT dual role of many manufacturers: they build control technology with electrical-engineering DNA, yet increasingly must build up software supply chains, CVE monitoring and a reporting organisation. This article outlines schematically what may come towards manufacturers and importers in building technology – sector-specific and explicitly not legal advice.

Typical PDE products in building technology and their likely Annex III class

The CRA tiers products by criticality. The majority fall into the default category with self-assessment (Module A). Only the "important" products listed in Annex III (class I / class II) and the "critical" products under Annex IV tighten the conformity path. Key point for building technology: the security function of a device is decisive, not its size or plant value. The following is a schematic indication; the actual class must be assessed case by case.

The conformity path follows from the class: default and class I allow self-assessment under Module A (class I only where relevant harmonised standards are fully applied); once no suitable harmonised standard is fully applied, class I requires a notified body. For class II a notified body is always foreseen. The technical descriptions of these categories are specified in Implementing Regulation (EU) 2025/2392.

Sector standards and delimitation from adjacent regimes

For industrial automation and control systems (IACS), IEC 62443 is the relevant standards series. It also covers building automation: the zones-and-conduits model, security levels (SL 1–4) as well as secure product development per IEC 62443-4-1 and technical requirements per 62443-4-2. These standards supply the technical substance for the CRA's Annex I case – hardening, authentication, secure update mechanisms. They do not, however, replace a harmonised CRA standard; only a standard harmonised under the CRA triggers the presumption of conformity.

A common misconception concerns the IACS class: IACS products qualify as an "important" product under Annex III only if they are intended for use by NIS2 essential or important entities – not per se. A standard room controller is not automatically upgraded by this.

On adjacent regimes: NIS2 addresses plant operators (e.g. the building operator as an essential entity), not the controller manufacturer – that is the CRA. Radio-capable components (e.g. wireless gateways, wireless sensors) may additionally fall under the RED Delegated Regulation (EU) 2022/30; the delimitation must be drawn cleanly. If a BMS server contains AI-based functions, the AI Act may play a role in future. These regimes coexist and must not be equated.

SBOM and supply-chain reality in KNX/BACnet landscapes

BMS landscapes are heterogeneous and long-lived. Firmware levels diverge per property, and many devices run embedded Linux with third-party components – TLS libraries, web stacks, BACnet/Modbus libraries, some open source. This is exactly where the CRA bites: the technical documentation must contain a machine-readable software bill of materials (SBOM).

Specifically, the SBOM requires a machine-readable format – CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1, as described in BSI TR-03183-2 (v2.1.0) – and at least the top-level dependencies with component name, version and supplier. There is no general publication duty; the SBOM is part of the technical documentation. Its real value for the sector lies in operations: only those who know which library sits in which gateway model can say, within hours rather than weeks, which models in which properties are affected by a new CVE (for instance in a widely used TLS or BACnet library). EOL risks – an unmaintained kernel or a deprecated OSS component – become visible and plannable early, instead of surfacing at audit time.

Reporting capability and PSIRT: setting up the Art. 14 cascade correctly

From 11 September 2026 the reporting and notification duties under Article 14 apply. Manufacturers must report actively exploited vulnerabilities and severe incidents via the ENISA Single Reporting Platform (SRP), which forwards to the competent CSIRT of the main establishment and to ENISA. The cascade must be observed precisely:

• 24 hours – early warning from becoming aware.
• 72 hours – full notification including initial corrective and mitigating measures.
• 14 days – final report after a corrective measure is available, for actively exploited vulnerabilities.
• 1 month – final report (after the 72-hour notification) for a severe security incident.

The blanket rule "24h/72h/14 days" is wrong: the final report has two cases (14 days for the exploited vulnerability, 1 month for the severe incident). In practice this means, for building-technology manufacturers: a PSIRT or named reporting organisation with a reachable contact, a coordinated vulnerability disclosure (CVD) policy across the entire support period, and rehearsed processes to be responsive within 24 hours – including weekends, and even when the affected plant sits offline in a plant room.

What comes first: 11 September 2026 before 11 December 2027

Two dates structure the preparation. On 11 September 2026 the reporting and notification duties (Art. 14) take effect – the first hard manufacturer obligation. Anyone without a PSIRT and CVD process by then is not reporting-capable at the first exploited vulnerability. Only on 11 December 2027 do the full product requirements apply (security-by-design, SBOM, technical documentation, CE marking, EU declaration of conformity).

The practical consequence: first establish reporting capability (organisational, quick to implement), and in parallel build the product and documentation side (technical, with long lead time, because firmware redesigns and SBOM toolchains take time). The false statement "the whole CRA applies from September 2026" is a costly error – only the reporting duty applies then.

Scenario: a maker of BACnet/IP gateways

Consider a mid-sized manufacturer of BACnet/IP gateways and DDC controllers, producing mainly in Germany and shipping into the EU. Its devices run on embedded Linux, the gateways are default PDE, but an optional remote-maintenance appliance with VPN falls into Annex III class I.

Its roadmap could look like this: by Q3/2026 it sets up a PSIRT with a published contact address and CVD policy and rehearses the 24/72-hour cascade on a test case. In parallel it builds an SBOM pipeline (CycloneDX ≥ 1.6) into its build process, so every shipped firmware image automatically produces a bill of materials. For the VPN appliance it checks whether suitable harmonised standards are fully applicable – if not, it plans for a notified body. For the default gateways it performs the Annex I risk assessment via threat modelling, documents hardening and secure update mechanisms, and retains the technical documentation for the required ten-year period. By 11 December 2027 the CE marking can thus rest on a solid basis – without a last-minute redesign.

What Blackfort does for you

Blackfort Technology UG (haftungsbeschränkt) supports manufacturers and importers in building technology along the entire CRA path – technically grounded, sector-specific and without legal advice:

• Applicability and scope analysis: which of your controllers, gateways and BMS components are PDE, which fall under Annex III (class I/II) – and which conformity path follows?
• SBOM setup: integrating CycloneDX ≥ 1.6 or SPDX ≥ 3.0.1 toolchains into your firmware build, incl. EOL/OSS risk monitoring.
• PSIRT and CVD: building the reporting organisation, CVD policy and a rehearsed Art. 14 cascade for the SRP.
• Risk assessment and threat modelling: documentation-ready Annex I evidence, aligned with IEC 62443.
• Technical documentation: from the declaration of conformity to the ten-year retention.

Start with a structured baseline: our applicability check classifies your product range, and via contact we discuss the concrete roadmap. Smaller manufacturers find a pragmatic entry point in the SME section, and background in the CRA overview.