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): a device is generally in scope if it is made available on the EU market in the course of a commercial activity and its intended purpose or reasonably foreseeable use includes a direct or indirect data connection to a device or network (Article 2(1)).

The actual challenge in this sector is the collision of two time horizons. A building automation installation can run for 15 to 20 years or longer. Yet the CRA requires security-by-design, active vulnerability handling and security updates across a defined support period matching the expected period of use (as a rule at least five years, shorter only where the expected period of use is shorter, Article 13(8)). 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, therefore becomes an issue at the next model change at the latest, and in tenders where operators ask about CRA conformity.

Add the OT/IT dual role that manufacturers in this sector face: they build control technology with electrical-engineering DNA, yet 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. Products without an Annex III or Annex IV function 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: what counts is the core function of a device (Article 7(1)), not its size or plant value; a built-in partial function alone does not raise a device's classification. The following is a schematic indication; the actual class must be assessed case by case.

The conformity path follows from the class: the manufacturer assesses default products itself (Module A). Class I allows Module A only with full application of harmonised standards, common specifications or a European cybersecurity certification scheme (at least “substantial”); without that, a notified body is required (Module B+C or H). Class II requires Module B+C, Module H or a European scheme of at least “substantial”. 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.

Annex III contains no category of its own for automation and control systems. A device is an important product if it has the core function of a listed category, for example as a router, VPN product or network interface (Article 7(1)). A room controller without such a core function stays in the default category.

On adjacent regimes: NIS2 addresses entities, for example the building operator where it qualifies as an essential or important entity; the cybersecurity of the controller as a product is governed by the CRA. Manufacturers of electronic products or electrical equipment can themselves fall under NIS2 from medium size upwards (Annex II point 5); that concerns the organisation, not product conformity. Radio-capable components (e.g. wireless gateways, wireless sensors) may additionally fall under the RED Delegated Regulation (EU) 2022/30 where they can communicate over the internet; until it is repealed with effect from 11 Dec 2027, the delimitation must be drawn cleanly. If a BMS server contains an AI system, the AI Act applies in addition, with duties depending on the risk level. These regimes coexist and must not be equated.

SBOM and supply-chain reality in KNX/BACnet systems

BMS installations are heterogeneous and long-lived. Firmware levels differ per site, and embedded Linux with third-party components is common - TLS libraries, web stacks, BACnet/Modbus libraries, some open source. This is exactly where the CRA bites: the technical documentation must contain a software bill of materials (SBOM).

The CRA requires a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies (Annex I Part II(1)). The Regulation does not prescribe a specific format; the Commission may specify format and elements by implementing act (Article 13(24)). The German BSI guideline TR-03183-2 (v2.1.0) recommends CycloneDX 1.6 or later or SPDX 3.0.1 or later; it is a national recommendation, not a CRA obligation. 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.

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

Since 11 September 2026 the reporting and notification duties under Article 14 have applied. Manufacturers must report actively exploited vulnerabilities and severe incidents via the single reporting platform (Article 16), through the endpoint of the CSIRT designated as coordinator in the Member State of their main establishment, simultaneously accessible to ENISA. The cascade must be observed precisely:

• 24 hours - early warning: without undue delay and in any event within 24 hours of becoming aware.
• 72 hours - notification: without undue delay and in any event within 72 hours of becoming aware, with the general information available and the corrective or mitigating measures taken.
• 14 days - final report after a corrective or mitigating measure is available, for actively exploited vulnerabilities.
• 1 month - final report (after the 72-hour notification) for a severe 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. Since 11 September 2026 the reporting and notification duties (Art. 14) have applied, the first hard manufacturer obligation. Anyone without a PSIRT and CVD process today is not reporting-capable at the next 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 has applied since September 2026" is a costly error: only the reporting duty has applied since 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: immediately, if not already done, it sets up a PSIRT with a published contact address and CVD policy and rehearses the reporting cascade (early warning without undue delay and within 24 hours at the latest, notification within 72 hours at the latest) on a test case. In parallel it builds an SBOM pipeline (for example 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, common specifications or a European cybersecurity certification scheme (at least “substantial”) are fully applicable - if not, it plans for a notified body (Module B+C or H). 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 at least ten years after placing on the market or for the longer support period (Article 13(13)). By 11 December 2027 this creates the basis for the EU declaration of conformity and CE marking.

What Blackfort does for you

Blackfort Technology supports manufacturers and importers in building technology along the entire CRA path - technically grounded, sector-specific and without legal advice:

• Applicability and scope analysis: a technical assessment of which of your controllers, gateways and BMS components are PDE, which fall under Annex III (class I/II) and which conformity path follows, for review by your legal department.
• SBOM setup: integrating CycloneDX or SPDX 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 single reporting platform.
• Risk assessment and threat modelling: documentation-ready Annex I evidence, aligned with IEC 62443.
• Technical documentation: building the documentation under Annex VII up to the EU declaration of conformity, retained for at least ten years or the longer support period (Article 13(13)).

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.