Hub/Spoke-Architektur
Struktur für über das Internet realisierte Security (Quelle: Beckhoff)
Funktion des Failover-Hubs (Quelle: Beckhoff)
Optionale Speiche-zu-Speiche-Kommunikation (Quelle: Beckhoff)
Beim Beckhoff Certificate Exchange Summit in Berlin wurde u. a. der Umgang mit X.509-Zertifikaten erprobt. (Quelle: Bacnet Interest Group Europe)
Anstelle des verbindungslosen UDP-Protokolls bei Bacnet/IP verwendet Bacnet/SC zur Kommunikation das TCP-Protokoll, also einen verbindungsorientierten Datenaustausch mit einer „Nabe/Speiche“-Architektur. Der Hub (Nabe) stellt dabei den zentralen Kommunikationspunkt bereit, über den sämtliche Kommunikation der angeschlossenen Geräte (über die Speichen) transportiert wird. Damit bei Ausfall des Hubs nicht die gesamte Kommunikation unterbrochen wird, kann (und sollte) ein Failover-Hub an einer getrennten Stromversorgung und möglichst an einem anderen Netzwerkzugangspunkt, optimal in einem weiteren Brandabschnitt installiert werden. Ist der zentrale Hub nicht mehr erreichbar, schalten die Geräte automatisch auf den Failover-Hub um, sodass die Kommunikation fortgeführt werden kann. Die Leistungsfähigkeit des Hubs/Failover-Hubs wird dabei im Wesentlichen durch die Anzahl der Broadcast-Nachrichten bestimmt.
Zwar existieren bei Bacnet/SC keine Netzwerk-Broadcasts mehr, jedoch gibt es weiterhin Bacnet-Dienste, die an alle Teilnehmer gerichtet sind (z. B. Gerätesuche oder Uhrzeitsynchronisation). Der Hub nimmt ein solches Telegramm entgegen, entschlüsselt es, stellt fest, dass die Nachricht an alle Teilnehmer gerichtet ist, und verschlüsselt und versendet die Nachricht dann einzeln an jeden angeschlossenen Teilnehmer. Als Anhaltspunkt sind circa 50 bis 150 angeschlossene Teilnehmer pro Hub realistisch. Das aus Bacnet/IP bekannte Verfahren des BBMD (Bacnet Broadcast Management Device) entfüllt und wird für Bacnet/SC nicht mehr benötigt. Ebenso entfüllt die Notwendigkeit statisch konfigurierter IP-Adressen, was das IT-Management durch den Einsatz von DHCP-Servern vereinfachen kann.
Als zusätzliche Option wurde das sogenannte Direct-Connect zusätzlich zur Hub-Kommunikation spezifiziert. Dies kann z. B. zum Lastmanagement oder für den Transport dringender Nachrichten (z. B. Alarme) verwendet werden.
X.509-Zertifikate
Damit sich innerhalb eines Bacnet/SC-Netzwerks alle Teilnehmer gegenseitig vertrauen können, wird eine zentrale Instanz einer CA (Certificate Authority) benötigt. Diese „unterschreibt“ mit ihrem eigenen Zertifikat Zertifikatsanträge der Geräte, welche mithilfe des internen privaten Schlüssels erzeugt werden. Damit können alle Teilnehmer prüfen, ob diese derselben CA vertrauen. Um zum Beispiel im Fall kompromittierter Schlüssel einen Missbrauch zu verhindern, haben Zertifikate eine zeitlich begrenzte Gültigkeit und müssen daher im operativen Betrieb regelmägig getauscht werden. Mit Bacnet Revision 24 wurde im Standard das Verfahren zum Austausch von Zertifikaten beschrieben.
Im Dezember 2025 hat Beckhoff Automation in der Niederlassung Berlin ein Certificate Exchange Summit veranstaltet, bei dem als Schwerpunktthema dieses Verfahren praktisch erprobt wurde. Als Ergebnis der ersten Veranstaltung dieser Art lässt sich feststellen, dass der (zukünftig auch automatisierte) Tausch von Zertifikaten grundsätzlich sehr gut interoperabel funktioniert, jedoch bei einer großeren Anzahl an Geräten und kurzen Aktualisierungsintervallen einer erhöhten Aufmerksamkeit bedarf. Dies gilt, wenn zum Beispiel ein Gerät durch Wartungseingriff zum Zeitpunkt des Tausches nicht erreichbar war und die Zertifikate nachträglich aktualisiert werden müssen. Läuft ein Zertifikat zeitlich ab, kann mit diesem Gerät keine Kommunikation mehr stattfinden und das Zertifikat muss (meist durch manuellen Eingriff) ersetzt werden.
Organisatorische Anforderungen
Für die Systemintegration und den operativen Betrieb der Gebäudeautomation ergeben sich neue Verantwortlichkeiten. So muss festgelegt werden, wie Geräte erstmalig in einen sicheren Betrieb versetzt werden (Stichwort: Onboarding). Im laufenden Betrieb sind Zertifikate regelmigäßig zu tauschen; ein Zertifikat mit einer Gültigkeit von zum Beispiel 100 Jahren ist wertlos!
Insbesondere für Betreiber ergibt sich aus den Vorgaben des NIS-2 die Verpflichtung, sich für den Fall einer Cyberattacke vorzubereiten (Stichwort: Back-up, Recovery- Strategien, Incident-Verantwortlichkeiten und vieles mehr). Weiterhin nützt die Bereitstellung von Updates durch Hersteller nichts, wenn diese nicht auch zeitnah installiert werden. Hier sind ebenfalls Verantwortlichkeiten zu klären – wer führt diese Updates durch und vor allem wann? Weiterhin wird im Bacnet-Standard explizit die fachgerechte Entsorgung von Geräten in Bezug auf das Rücksetzen des Werkszustandes gefordert.
Alle genannten Maßnahmen erfordern eine Absprache beider Bereiche (Stichwort: IT/OT-Konvergenz). Hier sind insbesondere Verantwortlichkeiten, Service-Level und eine gemeinsame Risikoanalyse und Cyberstrategie gefordert. Abschießend lässt sich feststellen, dass Gebäudeautomation zukünftig nicht nur betriebssicher, sondern darüber hinaus auch cybersicher sein muss.
Weitere Kommunikationsprotokolle
Viele der beschriebenen Verfahren lassen sich auch auf andere in der Gebäudeautomation eingesetzte Kommunikationsprotokolle anwenden. So spezifizierte die OPC Foundation bereits sehr früh für den Standard OPC UA direkt im Protokoll festgelegte Verfahren zur Cybersicherheit. Diese wurden vom Bundesamt für Sicherheit in der Informationstechnik (BSI) umfangreich analysiert und sind als sicher eingestuft. Die KNX Association hat mit KNX Secure eine Erweiterung geschaffen, die KNX auf IP-Ebene (IP Secure) und Geräte auf der Busleitung über Data Secure schützt. Das Industrial-Ethernet-System Ethercat erfüllt nach Aussagen der Ethercat Technology Group (ETG) die CRA-Anforderungen für Security Level 2 ohne änderungen. Der T.V S.D arbeitet mit der ETG an einem entsprechenden Prüfbericht (Stand November 2025). Andere Protokolle wie Modbus/TCP, OCPP (Open Charge Point Protocol) oder MQTT (Messag Queuing Telemetry Transport) k.nnen mit TLS-Verfahren (meist TLS 1.2) ebenfalls sicher verwendet werden.
Gesetzliche Anforderungen
Cyber Resiliance Act: Die Umsetzung des CRA bedeutet vor allem für Hersteller digitaler Produkte mit Kommunikationseigenschaften verschärfte Verantwortlichkeiten, u. a. Risikoanalysen. So besteht zum Beispiel für den gesamten Lebenszyklus eines Produkts die Verpflichtung, Schwachstellen zu beheben und Updates bereitzustellen. Die Einhaltung des CRA wird mit dem CE-Logo dokumentiert, im Dezember 2027 endet die Übergangsfrist.
Europäische Maschinenrichtlinie: Diese betrifft vor allem sicherheitsgerichtete Produkte (Safety). Als weitere Anforderung kommt ab Januar 2027 Cybersicherheit hinzu. Prüfungen werden von anerkannten Organisationen wie dem TÜV durchgeführt.
IEC 62443: Dieser Standard richtet sich ebenfalls an Hersteller in Bezug auf Dokumentation und Einhaltung von Cybersicherheit im Produktlebenszyklus. Im Wesentlichen unterteilt sich dies in:
- 62443-4-1: Vorgaben für den Produktentwicklungs-Lebenszyklus, z. B. sicheres Design und
- 62443-4-2: Vorgaben für die Implementierung von Cybersicherheit in Geräte
Die Vorgaben ähneln denen des CRA, sind jedoch davon unabhängig zu betrachten. Die IEC 62443 hat aber einen direkten Bezug zur Europäischen Maschinenrichtlinie. Dieser Standard existiert bereits seit 2019, wird aber ergänzend zu anderen Regularien wie dem CRA oder NIS-2 weiter an Bedeutung gewinnen.
NIS-2: Diese EU-Vorgabe bezieht sich auf den operativen Betrieb und betrifft circa 30000 Unternehmen in Deutschland (mehr als 50 Angestellte und ein Jahresumsatz von mind. 10 Mio. € oder als Kleinunternehmen im Bereich Cybersecurity tätig). Dabei ist die Einhaltung der Vorgaben mit hohen Sanktionen verbunden. Geschäftsführer haften zum Beispiel bei Nicht-Einhaltung persönlich. Die betroffenen Unternehmen müssen in mindestens einem von 18 Sektoren tätig sein. Dazu zählen neben den Betreibern kritischer Infrastrukturen (Kritis), wie Energieversorgung, Wasserversorgung und Entsorgung, auch digitale Infrastrukturen und Dienste sowie Post und Transportdienste. Weiterhin sind Hersteller, Verarbeiter oder Distributoren von Lebensmitteln, Chemieerzeugnissen, medizinischer Geräte, Maschinenbau, Kraftfahrzeuge und elektrischer oder elektronischer Produkte sowie auch Forschungseinrichtungen oder Firmen mit Bezug zu Weltraumaktivitäten betroffen. Gültig ist NIS-2 in Deutschland seit dem 6.12.2025. Im Rahmen von NIS-2 sind u. a. Maßnahmen zum Risikomanagement einzuführen, zu dokumentieren und Mitarbeiter entsprechend zu schulen (z. B. Umgang mit suspekten E-Mails). Der Zutritt zu Produktionsstätten ist ausschließlich autorisierten Personen zu gestatten. Datensicherungs- und Wiederherstellungsverfahren sind zu planen, zu dokumentieren und anzuwenden. Es sind Vorkehrungen zur Abwehr, Erkennung und Behandlung von Sicherheitsvorfällen (Cyberangriffen) zu treffen. Bei einem Vorfall besteht eine Meldepflicht (z. B. in Deutschland an das BSI). Für Betreiber von Kritis-Liegenschaften gelten darüber hinaus weitere Verpflichtungen (Erweiterung der NIS-1 aus 2016).