CRA in der Gebäudetechnik & Gebäudeleittechnik

Wenn das Gebäude online geht: Warum der CRA die Gebäudeautomation trifft

Moderne Gebäudeautomation ist längst kein isoliertes Feldbus-Universum mehr. KNX, BACnet und Modbus enden heute an IP-Gateways, hängen an Cloud-Dashboards, werden per Fernwartung gepflegt und liefern Betriebsdaten an übergeordnete Gebäudeleittechnik (GLT). Genau diese Vernetzung ist der Grund, warum DDC-Controller, Raumautomationsstationen, IP-Gateways und GLT-Server nach dem Cyber Resilience Act (Verordnung (EU) 2024/2847) als „Produkte mit digitalen Elementen" (PDE) einzuordnen sind: Sobald ein Gerät eine direkte oder indirekte Datenverbindung hat, ist es grundsätzlich im Anwendungsbereich.

Der reale Schmerz dieser Branche ist nicht die Regulierung an sich, sondern die Kollision zweier Zeithorizonte. Eine Gebäudeautomationsanlage läuft typischerweise 15 bis 20 Jahre, teils länger. Der CRA verlangt jedoch Security-by-Design, ein aktives Schwachstellen-Handling und Sicherheitsupdates über einen definierten Support-Zeitraum, der der erwarteten Produktlebensdauer entspricht (Leitlinie: mindestens fünf Jahre, keine starre Frist). Ein Controller, der vor Jahren mit einem eingebetteten Linux und einer inzwischen veralteten TLS-Bibliothek ausgeliefert wurde und heute in hunderten Liegenschaften ohne dauerhafte Internetverbindung steckt, wird damit zum Thema – nicht in der Theorie, sondern beim nächsten Modellwechsel und bei jeder Ausschreibung, in der Betreiber nach CRA-Konformität fragen.

Hinzu kommt die OT/IT-Doppelrolle vieler Hersteller: Man baut Steuerungstechnik mit Elektrotechnik-DNA, muss aber zunehmend Software-Lieferketten, CVE-Monitoring und eine Meldeorganisation aufbauen. Dieser Beitrag ordnet schematisch ein, was auf Hersteller und Importeure der Gebäudetechnik zukommen kann – branchenkonkret und ausdrücklich ohne Rechtsberatung.

Typische PDE-Produkte der Gebäudetechnik und ihre wahrscheinliche Anhang-III-Klasse

Der CRA staffelt Produkte nach Kritikalität. Die Mehrheit fällt in die Standardkategorie mit Selbstbewertung (Modul A). Erst die in Anhang III gelisteten „wichtigen" Produkte (Klasse I / Klasse II) und die „kritischen" Produkte nach Anhang IV verschärfen den Konformitätspfad. Wichtig für die Gebäudetechnik: Maßgeblich ist die Sicherheitsfunktion eines Geräts, nicht seine Größe oder sein Anlagenwert. Die folgende Einordnung ist ein schematischer Anhaltspunkt; die konkrete Klasse ist im Einzelfall zu prüfen.

Der Konformitätspfad folgt aus der Klasse: Standard und Klasse I lassen (bei Klasse I nur unter voller Anwendung einschlägiger harmonisierter Normen) die Selbstbewertung nach Modul A zu; sobald keine passende harmonisierte Norm vollständig angewandt wird, ist bei Klasse I eine notifizierte Stelle einzubinden. Bei Klasse II ist die notifizierte Stelle immer vorgesehen. Die technischen Beschreibungen dieser Kategorien konkretisiert die Durchführungsverordnung (EU) 2025/2392.

Branchennormen und Abgrenzung zu angrenzenden Regimen

Für Automatisierungs- und Steuerungssysteme (IACS) ist IEC 62443 die einschlägige Normenreihe. Sie deckt Gebäudeautomation mit ab: Zonen- und Conduit-Modell, Security-Level (SL 1–4) sowie sichere Produktentwicklung nach IEC 62443-4-1 und technische Anforderungen nach 62443-4-2. Diese Normen liefern die technische Substanz für den Anhang-I-Nachweis des CRA – etwa Härtung, Authentisierung, sichere Update-Mechanismen. Sie ersetzen aber keine harmonisierte CRA-Norm; erst eine unter dem CRA harmonisierte Norm entfaltet die Konformitätsvermutung.

Ein häufiges Missverständnis betrifft die IACS-Klasse: IACS-Produkte sind nur dann als „wichtiges" Produkt nach Anhang III einzuordnen, wenn sie für den Einsatz durch NIS2-wesentliche oder -wichtige Einrichtungen bestimmt sind – nicht per se. Ein Standard-Raumcontroller wird dadurch nicht automatisch hochgestuft.

Zur Abgrenzung angrenzender Regime: NIS2 adressiert die Betreiber von Anlagen (etwa den Gebäudebetreiber als wesentliche Einrichtung), nicht den Hersteller des Controllers – das ist der CRA. Funkfähige Komponenten (z. B. Funk-Gateways, Wireless-Sensorik) können zusätzlich unter die RED-Delegierte-Verordnung (EU) 2022/30 fallen; hier ist die Abgrenzung sauber zu ziehen. Enthält ein GLT-Server KI-gestützte Funktionen, kann perspektivisch der AI Act mitspielen. Diese Regime bestehen nebeneinander und dürfen nicht gleichgesetzt werden.

SBOM- und Lieferketten-Realität in KNX-/BACnet-Landschaften

GLT-Landschaften sind heterogen und langlebig. Firmware-Stände divergieren pro Liegenschaft, viele Geräte laufen auf eingebettetem Linux mit Third-Party-Komponenten – TLS-Bibliotheken, Web-Stacks, BACnet-/Modbus-Bibliotheken, teils quelloffen. Genau hier setzt der CRA an: Die technische Dokumentation muss eine maschinenlesbare Software-Stückliste (SBOM) enthalten.

Konkret verlangt die SBOM ein maschinenlesbares Format – CycloneDX ≥ 1.6 oder SPDX ≥ 3.0.1, wie in der BSI TR-03183-2 (v2.1.0) beschrieben – und mindestens die Top-Level-Abhängigkeiten mit Komponentenname, Version und Lieferant. Es besteht keine allgemeine Veröffentlichungspflicht; die SBOM ist Teil der technischen Dokumentation. Ihr eigentlicher Nutzen für die Branche liegt im Betrieb: Nur wer weiß, welche Bibliothek in welchem Gateway-Modell steckt, kann bei einer neuen CVE (etwa in einer verbreiteten TLS- oder BACnet-Bibliothek) innerhalb von Stunden statt Wochen sagen, welche Modelle in welchen Liegenschaften betroffen sind. EOL-Risiken – ein nicht mehr gepflegter Kernel oder eine abgekündigte OSS-Komponente – werden so früh sichtbar und planbar, statt beim Audit aufzuschlagen.

Meldefähigkeit und PSIRT: die Art.-14-Kaskade richtig aufsetzen

Ab dem 11.09.2026 gelten die Melde- und Berichtspflichten nach Artikel 14. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle über die ENISA Single Reporting Platform (SRP) melden, die die Meldung an das zuständige CSIRT der Hauptniederlassung und ENISA verteilt. Die Kaskade ist präzise einzuhalten:

• 24 Stunden – Frühwarnung (early warning) ab Kenntnisnahme.
• 72 Stunden – vollständige Meldung inklusive erster Korrektur- und Minderungsmaßnahmen.
• 14 Tage – Abschlussbericht nach Verfügbarkeit einer Korrekturmaßnahme, für aktiv ausgenutzte Schwachstellen.
• 1 Monat – Abschlussbericht (nach der 72-h-Meldung) bei einem schweren Sicherheitsvorfall.

Die pauschale Merkregel „24h/72h/14 Tage" ist falsch: Der Abschlussbericht kennt zwei Fälle (14 Tage für die ausgenutzte Schwachstelle, 1 Monat für den schweren Vorfall). Für Gebäudetechnik-Hersteller heißt das praktisch: Es braucht ein PSIRT bzw. eine benannte Meldeorganisation mit erreichbarem Kontakt, eine Coordinated-Vulnerability-Disclosure-Policy (CVD) über den gesamten Support-Zeitraum und geübte Prozesse, um binnen 24 Stunden reaktionsfähig zu sein – auch am Wochenende, auch wenn die betroffene Anlage offline im Technikraum steht.

Was zuerst kommt: 11.09.2026 vor 11.12.2027

Zwei Daten strukturieren die Vorbereitung. Zum 11.09.2026 greifen die Melde- und Berichtspflichten (Art. 14) – die erste harte Herstellerpflicht. Wer bis dahin kein PSIRT und keinen CVD-Prozess hat, ist bei der ersten ausgenutzten Schwachstelle nicht meldefähig. Erst zum 11.12.2027 gelten die vollen Produktanforderungen (Security-by-Design, SBOM, technische Dokumentation, CE-Kennzeichnung, EU-Konformitätserklärung).

Die praktische Konsequenz: Zuerst die Meldefähigkeit herstellen (organisatorisch, schnell umsetzbar), parallel die Produkt- und Dokumentationsseite aufbauen (technisch, mit langem Vorlauf, weil Firmware-Redesigns und SBOM-Toolchains Zeit brauchen). Die Falschaussage „ab September 2026 gilt der ganze CRA" ist ein teurer Irrtum – nur die Meldepflicht gilt dann.

Szenario: ein Hersteller von BACnet/IP-Gateways

Nehmen wir einen mittelständischen Hersteller von BACnet/IP-Gateways und DDC-Controllern, der überwiegend in Deutschland fertigt und in die EU liefert. Seine Geräte laufen auf eingebettetem Linux, die Gateways sind Standard-PDE, eine optionale Fernwartungs-Appliance mit VPN fällt jedoch in Anhang III Klasse I.

Sein Fahrplan könnte so aussehen: Bis Q3/2026 richtet er ein PSIRT mit veröffentlichter Kontaktadresse und CVD-Policy ein und übt die 24-/72-Stunden-Kaskade an einem Testfall durch. Parallel baut er eine SBOM-Pipeline (CycloneDX ≥ 1.6) in seinen Build-Prozess ein, sodass jedes ausgelieferte Firmware-Image automatisch eine Stückliste erzeugt. Für die VPN-Appliance prüft er, ob passende harmonisierte Normen vollständig anwendbar sind – falls nicht, plant er die notifizierte Stelle ein. Für die Standard-Gateways führt er die Risikobewertung nach Anhang I per Threat-Modeling durch, dokumentiert Härtung und sichere Update-Mechanismen und hält die technische Dokumentation für die vorgeschriebene Aufbewahrungsfrist von zehn Jahren vor. Bis 11.12.2027 kann so die CE-Kennzeichnung mit belastbarer Grundlage erfolgen – ohne Last-Minute-Redesign.

Was Blackfort für Sie tut

Blackfort Technology UG (haftungsbeschränkt) begleitet Hersteller und Importeure der Gebäudetechnik entlang des gesamten CRA-Pfads – technisch fundiert, branchenkonkret und ohne Rechtsberatung:

• Betroffenheits- und Scope-Analyse: Welche Ihrer Controller, Gateways und GLT-Komponenten sind PDE, welche fallen in Anhang III (Klasse I/II) – und welcher Konformitätspfad folgt daraus?
• SBOM-Setup: Integration von CycloneDX-≥-1.6- oder SPDX-≥-3.0.1-Toolchains in Ihren Firmware-Build, inkl. EOL-/OSS-Risikoüberwachung.
• PSIRT und CVD: Aufbau der Meldeorganisation, CVD-Policy und geübte Art.-14-Kaskade für die SRP.
• Risikobewertung und Threat-Modeling: dokumentationsfähige Anhang-I-Nachweise, ausgerichtet an IEC 62443.
• Technische Dokumentation: von der Konformitätserklärung bis zur zehnjährigen Aufbewahrung.

Starten Sie mit einer strukturierten Standortbestimmung: unser Betroffenheits-Check ordnet Ihre Produktpalette ein, und über Kontakt besprechen wir den konkreten Fahrplan. Kleinere Hersteller finden im KMU-Bereich einen pragmatischen Einstieg, Hintergründe im CRA-Überblick.