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: Ein Gerät ist grundsätzlich erfasst, wenn es im Rahmen einer Geschäftstätigkeit auf dem EU-Markt bereitgestellt wird und sein bestimmungsgemäßer Zweck oder seine vorhersehbare Verwendung eine direkte oder indirekte Datenverbindung mit einem Gerät oder Netz einschließt (Art. 2 Abs. 1).

Die eigentliche Herausforderung dieser Branche ist die Kollision zweier Zeithorizonte. Eine Gebäudeautomationsanlage kann 15 bis 20 Jahre und länger laufen. Der CRA verlangt jedoch Security-by-Design, ein aktives Schwachstellen-Handling und Sicherheitsupdates über einen definierten Unterstützungszeitraum, der der erwarteten Nutzungsdauer entspricht (in der Regel mindestens fünf Jahre, kürzer nur bei kürzerer voraussichtlicher Nutzungsdauer, Art. 13 Abs. 8). 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 spätestens beim nächsten Modellwechsel zum Thema, ebenso in Ausschreibungen, in denen Betreiber nach CRA-Konformität fragen.

Hinzu kommt die OT/IT-Doppelrolle der Hersteller in dieser Branche: Man baut Steuerungstechnik mit Elektrotechnik-DNA, muss aber 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. Produkte ohne Anhang-III- oder Anhang-IV-Funktion fallen 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: Es zählt die Kernfunktion eines Geräts (Art. 7 Abs. 1), nicht seine Größe oder sein Anlagenwert; eine eingebaute Teilfunktion allein stuft ein Gerät nicht hoch. Die folgende Einordnung ist ein schematischer Anhaltspunkt; die konkrete Klasse ist im Einzelfall zu prüfen.

Der Konformitätspfad folgt aus der Klasse: Standardprodukte bewertet der Hersteller selbst (Modul A). Klasse I erlaubt Modul A nur bei vollständiger Anwendung harmonisierter Normen, gemeinsamer Spezifikationen oder eines europäischen Cybersicherheitszertifizierungsschemas (mindestens Stufe „mittel“); fehlt das, ist eine notifizierte Stelle einzubinden (Modul B+C oder H). Klasse II verlangt Modul B+C, Modul H oder ein europäisches Schema mindestens „mittel“. 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 löst die Konformitätsvermutung aus.

Anhang III kennt keine eigene Kategorie für Automatisierungs- und Steuerungssysteme. Ein Gerät ist ein wichtiges Produkt, wenn es die Kernfunktion einer gelisteten Kategorie hat, etwa als Router, VPN-Produkt oder Netzschnittstelle (Art. 7 Abs. 1). Ein Raumcontroller ohne eine solche Kernfunktion bleibt in der Standardkategorie.

Zur Abgrenzung angrenzender Regime: NIS2 adressiert Einrichtungen, etwa den Gebäudebetreiber, wenn er als wesentliche oder wichtige Einrichtung gilt; die Cybersicherheit des Controllers als Produkt regelt der CRA. Hersteller elektronischer Erzeugnisse oder elektrischer Ausrüstungen können ab mittlerer Größe selbst unter NIS2 fallen (Anhang II Nr. 5); das betrifft dann die Organisation, nicht die Produktkonformität. Funkfähige Komponenten (z. B. Funk-Gateways, Wireless-Sensorik) können zusätzlich unter die RED-Delegierte-Verordnung (EU) 2022/30 fallen, soweit sie über das Internet kommunizieren können; bis zu deren Aufhebung zum 11.12.2027 ist die Abgrenzung sauber zu ziehen. Enthält ein GLT-Server ein KI-System, gilt zusätzlich der AI Act, mit Pflichten je nach Risikostufe. Diese Regime bestehen nebeneinander und dürfen nicht gleichgesetzt werden.

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

GLT-Anlagen sind heterogen und langlebig. Firmware-Stände unterscheiden sich je Liegenschaft, eingebettetes Linux mit Drittkomponenten ist verbreitet - TLS-Bibliotheken, Web-Stacks, BACnet-/Modbus-Bibliotheken, teils quelloffen. Genau hier setzt der CRA an: Die technische Dokumentation muss eine Software-Stückliste (SBOM) enthalten.

Der CRA verlangt eine Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten hervorgehen (Anhang I Teil II Nr. 1). Ein bestimmtes Format schreibt die Verordnung nicht vor; die Kommission kann Format und Elemente per Durchführungsrechtsakt festlegen (Art. 13 Abs. 24). Die Technische Richtlinie BSI TR-03183-2 (v2.1.0) empfiehlt CycloneDX ab Version 1.6 oder SPDX ab Version 3.0.1; sie ist eine nationale Empfehlung, keine Pflicht aus dem CRA. 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.

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

Seit dem 11.09.2026 gelten die Melde- und Berichtspflichten nach Artikel 14. Hersteller müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle über die einheitliche Meldeplattform (Art. 16) melden, über den Endpunkt des als Koordinator benannten CSIRT im Mitgliedstaat ihrer Hauptniederlassung, gleichzeitig für ENISA zugänglich. Die Kaskade ist präzise einzuhalten:

• 24 Stunden - Frühwarnung: unverzüglich, spätestens 24 Stunden nach Kenntnis.
• 72 Stunden - Meldung: unverzüglich, spätestens 72 Stunden nach Kenntnis, mit den verfügbaren allgemeinen Informationen und den ergriffenen Korrektur- oder Risikominderungsmaßnahmen.
• 14 Tage - Abschlussbericht nach Verfügbarkeit einer Korrektur- oder Risikominderungsmaßnahme, für aktiv ausgenutzte Schwachstellen.
• 1 Monat - Abschlussbericht (nach der 72-h-Meldung) bei einem schwerwiegenden 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 schwerwiegenden 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 Unterstützungszeitraum 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. Seit dem 11.09.2026 greifen die Melde- und Berichtspflichten (Art. 14), die erste harte Herstellerpflicht. Wer heute kein PSIRT und keinen CVD-Prozess hat, ist bei der nächsten 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 „seit September 2026 gilt der ganze CRA" ist ein teurer Irrtum: Seitdem gilt nur die Meldepflicht.

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: Sofort richtet er, falls noch nicht geschehen, ein PSIRT mit veröffentlichter Kontaktadresse und CVD-Policy ein und übt die Melde-Kaskade (Frühwarnung unverzüglich, spätestens nach 24 Stunden, Meldung spätestens nach 72 Stunden) an einem Testfall durch. Parallel baut er eine SBOM-Pipeline (etwa 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, gemeinsame Spezifikationen oder ein europäisches Cybersicherheitszertifizierungsschema (mindestens Stufe „mittel“) vollständig anwendbar sind - falls nicht, plant er die notifizierte Stelle ein (Modul B+C oder H). 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 bewahrt die technische Dokumentation mindestens zehn Jahre nach Inverkehrbringen oder für den längeren Unterstützungszeitraum auf (Art. 13 Abs. 13). So entsteht bis zum 11.12.2027 die Grundlage für EU-Konformitätserklärung und CE-Kennzeichnung.

Was Blackfort für Sie tut

Blackfort Technology begleitet Hersteller und Importeure der Gebäudetechnik entlang des gesamten CRA-Pfads - technisch fundiert, branchenkonkret und ohne Rechtsberatung:

• Betroffenheits- und Scope-Analyse: technische Einschätzung, welche Ihrer Controller, Gateways und GLT-Komponenten PDE sind, welche in Anhang III (Klasse I/II) fallen und welcher Konformitätspfad daraus folgt, zur Prüfung durch Ihre Rechtsabteilung.
• SBOM-Setup: Integration von CycloneDX- oder SPDX-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 einheitliche Meldeplattform.
• Risikobewertung und Threat-Modeling: dokumentationsfähige Anhang-I-Nachweise, ausgerichtet an IEC 62443.
• Technische Dokumentation: Aufbau der Unterlagen nach Anhang VII bis zur EU-Konformitätserklärung, aufbewahrt mindestens zehn Jahre oder für den längeren Unterstützungszeitraum (Art. 13 Abs. 13).

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.