KNX Secure erklärt: Wie es funktioniert, was es bringt und wo die Grenzen liegen

Ein Fachbeitrag der WENGET GmbH zum Thema KNX Planung & Engineering.

KNX-Anlagen steuern Beleuchtung, Beschattung, Heizung und Zutrittsfunktionen in Gebäuden. Wer auf dem Bus mithört oder Telegramme einspeist, kann Funktionen auslösen, Zustände verfälschen oder eine Anlage in einen undefinierten Betriebszustand bringen. Lange war das ein theoretisches Risiko, das vor allem bei isolierten TP-Netzen ohne IP-Anbindung wenig praktische Relevanz hatte. Mit dem Einzug von KNXnet/IP und der Anbindung an IT-Netze hat sich das geändert. KNX Secure gibt es seit einigen Jahren als Antwort darauf. Dieser Artikel erklärt, wie die beiden Schutzmechanismen KNX Data Secure und KNX IP Secure funktionieren, was sie leisten und wo ihre Grenzen liegen. Wir richten uns an Bauherren, Betreiber, IT-Verantwortliche, Planer und Integratoren, die eine fundierte Entscheidungsgrundlage suchen.

Warum Sicherheit im KNX-Bus ein Thema ist

Ein KNX-Telegramm auf dem TP-Bus enthält keine Authentifizierung. Jeder Teilnehmer, der physisch an die Busleitung angeschlossen wird, kann Telegramme senden und empfangen. Das ist im ursprünglichen Design so vorgesehen: Der Bus ist ein gemeinsames Medium, auf das alle Teilnehmer gleichberechtigt zugreifen. Solange der Zugang zur Busleitung physisch gesichert ist, also in einem verschlossenen Verteiler liegt und nicht von aussen zugänglich ist, ist das Risiko überschaubar.

Die Situation ändert sich, sobald KNXnet/IP ins Spiel kommt. Über IP-Koppler oder IP-Router wird der KNX-Bus an das Gebäudenetz angebunden. Damit ist er grundsätzlich von jedem Gerät im selben Netz erreichbar, das die Multicast-Adresse 224.0.23.12 kennt. Wer Zugang zum Netz hat, kann mit einem einfachen Tool Telegramme mitsehen oder einspeisen. In Unternehmensnetzen mit vielen Nutzern, in Hotels, Schulen oder öffentlichen Gebäuden ist das ein reales Risiko.

Dazu kommt ein weiterer Aspekt: Regulatorische Anforderungen wie die europäische NIS2-Richtlinie und der Cyber Resilience Act (CRA) erhöhen den Druck auf Hersteller und Betreiber, Sicherheit in vernetzte Systeme einzubauen. KNX Secure ist die Antwort der KNX Association auf diese Anforderungen. Es ist kein Pflichtstandard, aber ein zunehmend gefordertes Merkmal in Ausschreibungen für öffentliche Gebäude und kritische Infrastrukturen.

Die zwei Schichten von KNX Secure

KNX Secure besteht aus zwei unabhängigen, aber kombinierbaren Mechanismen. Sie adressieren unterschiedliche Angriffsvektoren und können separat oder gemeinsam eingesetzt werden.

KNX Data Secure

KNX Data Secure schützt die Kommunikation auf der Anwendungsschicht. Das bedeutet: Das Telegramm selbst, also der Nutzdatenanteil, wird verschlüsselt und mit einem Authentifizierungscode versehen. Dieser Schutz gilt unabhängig vom Übertragungsmedium. Ein Data-Secure-Telegramm ist auf dem TP-Bus genauso geschützt wie über IP oder Funk.

Die Verschlüsselung erfolgt mit AES-128 im CCM-Modus (Counter with CBC-MAC). AES-128 gilt heute als kryptografisch sicher und ist in vielen sicherheitskritischen Anwendungen etabliert. Der CCM-Modus kombiniert Verschlüsselung und Authentifizierung in einem einzigen Verfahren: Der Empfänger kann prüfen, ob das Telegramm tatsächlich vom erwarteten Absender stammt und ob es unterwegs verändert wurde.

Gegen Wiederholungsangriffe, bei denen ein Angreifer ein gültiges Telegramm aufzeichnet und später erneut einspielt, schützt ein Sequenzzähler. Jedes Gerät führt einen eigenen Zähler, der mit jedem gesendeten Telegramm hochgezählt wird. Der Empfänger akzeptiert nur Telegramme mit einem Zählerstand, der höher ist als der zuletzt empfangene. Ein aufgezeichnetes Telegramm mit einem alten Zählerstand wird verworfen.

KNX IP Secure

KNX IP Secure schützt die Kommunikation auf der IP-Ebene. Es sichert den Datenaustausch zwischen IP-fähigen KNX-Geräten, also zwischen IP-Kopplern, IP-Routern und der ETS. Die Grundlage bildet die Norm EN ISO 22510, die KNXnet/IP und damit auch KNX IP Secure normiert.

IP Secure verwendet ebenfalls AES-128 im CCM-Modus. Zusätzlich zum Sequenzzähler kommt hier ein Zeitstempel zum Einsatz, der Wiederholungsangriffe auf der IP-Ebene erschwert. Die Kommunikation zwischen IP-Geräten wird über einen gemeinsamen Backbone-Schlüssel gesichert. Dieser Schlüssel wird in der ETS verwaltet und bei der Inbetriebnahme auf die Geräte übertragen.

IP Secure schützt den IP-Tunnel zwischen Geräten, aber nicht das Telegramm auf dem TP-Segment dahinter. Wer also nur IP Secure einsetzt, schützt den IP-Backbone, lässt aber den TP-Bus ohne Schutz. Wer den TP-Bus ebenfalls absichern will, braucht Data Secure auf den Feldgeräten.

Schlüssel, Zertifikate und Projektpasswort

Das Herzstück von KNX Secure ist das Schlüsselmanagement. Hier liegt auch die grösste Herausforderung im Betrieb.

Jedes KNX-Secure-fähige Gerät trägt ab Werk ein individuelles Gerätezertifikat und einen zugehörigen Schlüssel, den sogenannten FDSK (Factory Default Setup Key). Dieser Schlüssel ist auf dem Gerät aufgedruckt oder als QR-Code vorhanden und wird bei der Inbetriebnahme in die ETS eingelesen. Er dient als Ausgangspunkt für den sicheren Schlüsselaustausch zwischen ETS und Gerät.

Die ETS verwaltet alle Schlüssel im Projekt. Das Projektpasswort schützt den Zugang zum ETS-Projekt und damit zu allen Schlüsseln. Wer das Projektpasswort kennt, kann die Anlage programmieren, Geräte ersetzen und Schlüssel neu vergeben. Wer es nicht kennt, kann die Anlage nicht mehr verändern, auch wenn er physischen Zugang zu den Geräten hat.

Das ist der entscheidende Punkt für Bauherren und Betreiber: Das ETS-Projekt mit dem Projektpasswort ist der Schlüssel zur Anlage. Geht es verloren, ist die Anlage im schlimmsten Fall nicht mehr wartbar, ohne alle Geräte auf Werkseinstellungen zurückzusetzen und neu in Betrieb zu nehmen. Wir empfehlen deshalb, das ETS-Projekt und das Projektpasswort von Beginn an als Eigentum der Bauherrschaft zu behandeln und sicher zu verwahren. Mehr dazu behandelt Teil 5 der Serie «KNX richtig planen» unter dem Titel «Das ETS-Projekt gehört dem Bauherrn».

Gemischter Betrieb: Secure und Non-Secure nebeneinander

In der Praxis stellt sich fast immer die Frage, ob alle Geräte einer Anlage KNX Secure unterstützen müssen oder ob ein gemischter Betrieb möglich ist. Die Antwort ist differenziert.

KNX erlaubt den gemischten Betrieb von Secure- und Non-Secure-Geräten auf derselben Linie. Ein Secure-Gerät kann so konfiguriert werden, dass es sowohl gesicherte als auch ungesicherte Telegramme akzeptiert. Das ermöglicht eine schrittweise Migration, zum Beispiel bei Sanierungen, bei denen nicht alle Geräte gleichzeitig ersetzt werden können.

Der gemischte Betrieb hat jedoch eine wichtige Konsequenz: Der Sicherheitsgewinn ist nur so gross wie das schwächste Glied. Wenn ein Taster ohne Data Secure auf einer Linie mit gesicherten Aktoren betrieben wird, kann dieser Taster weiterhin ungesicherte Telegramme senden, die von den Aktoren akzeptiert werden, sofern diese für den gemischten Betrieb konfiguriert sind. Ein Angreifer, der Zugang zum Bus hat, kann denselben Angriff wie vorher durchführen.

Für sicherheitskritische Anwendungen, also überall dort, wo Manipulation echten Schaden anrichten kann, empfehlen wir, konsequent auf reine Secure-Konfigurationen zu setzen und den gemischten Betrieb nur als Übergangslösung zu verstehen. Die Planung sollte von Anfang an festlegen, welche Linien oder Bereiche vollständig gesichert werden und welche Geräte dafür beschafft werden müssen. Wie das in der Ausschreibung und im Projektablauf umgesetzt wird, behandelt Teil 4 der Serie «KNX richtig planen» unter dem Titel «KNX Secure im Projekt: Data Secure und IP Secure».

Vor- und Nachteile im Überblick

Die folgende Tabelle fasst die wesentlichen Vor- und Nachteile von KNX Secure zusammen. Sie soll Bauherren und Betreibern helfen, eine informierte Entscheidung zu treffen.

Was KNX Secure nicht leistet

KNX Secure ist ein wichtiger Baustein, aber kein vollständiges Sicherheitskonzept. Es gibt Risiken, die es nicht adressiert.

KNX Secure schützt die Telegramme, nicht die Geräte selbst. Ein Angreifer, der physischen Zugang zu einem Gerät hat, kann es unter Umständen auf Werkseinstellungen zurücksetzen und neu einbinden, sofern er den FDSK kennt oder ablesen kann. Die physische Sicherheit der Geräte und Verteiler bleibt deshalb eine eigenständige Anforderung.

KNX Secure ersetzt auch keine Netzwerksegmentierung. Wenn der KNX-IP-Backbone im selben Netz liegt wie Büroarbeitsplätze oder Gäste-WLAN, ist das ein Planungsfehler, der durch IP Secure allein nicht behoben wird. Die richtige Antwort ist eine konsequente Netztrennung, zum Beispiel durch dedizierte VLANs für die GA-Kommunikation. Wie das in der Topologie umgesetzt wird, behandelt Teil 2 der Serie «KNX richtig planen» unter dem Titel «Topologie, Linien und IP-Backbone sauber aufbauen».

KNX Secure schützt ferner nicht vor Fehlkonfigurationen. Eine falsch parametrierte Anlage kann auch mit Secure-Mechanismen falsch reagieren. Und es schützt nicht vor Angriffen auf die ETS selbst oder auf den Rechner, auf dem die ETS läuft. Das Projektpasswort ist nur so sicher wie der Ort, an dem es gespeichert wird.

Einordnung in den regulatorischen Kontext

Die europäische NIS2-Richtlinie verpflichtet Betreiber kritischer Infrastrukturen und wichtiger Einrichtungen, angemessene technische und organisatorische Massnahmen zur Cybersicherheit zu ergreifen. Der Cyber Resilience Act (CRA) stellt Anforderungen an Hersteller vernetzter Produkte. Beide Regelwerke nennen KNX nicht explizit, aber sie schaffen einen Rahmen, in dem KNX Secure als nachweisbare technische Massnahme relevant wird.

In der Schweiz gibt es keine direkte Umsetzung von NIS2, aber das Informationssicherheitsgesetz (ISG) und die zugehörige Verordnung (ISVO) stellen für Bundesstellen und Betreiber kritischer Infrastrukturen ähnliche Anforderungen. Für private Betreiber ist der regulatorische Druck heute noch geringer, aber die Tendenz ist klar: Cybersicherheit in der Gebäudetechnik wird zunehmend als Pflicht und nicht als Option betrachtet.

Wir empfehlen, KNX Secure nicht primär als regulatorische Pflichtübung zu sehen, sondern als technisch sinnvolle Massnahme überall dort, wo KNX-Anlagen an IP-Netze angebunden sind oder sicherheitsrelevante Funktionen steuern. Für reine TP-Anlagen ohne IP-Anbindung in physisch gesicherten Gebäuden ist die Risikoabwägung eine andere.

Empfehlungen für die Praxis

Aus unserer Erfahrung in der Planung und Inbetriebnahme von KNX-Anlagen haben wir einige Empfehlungen, die wir Bauherren, Betreibern und Planern mitgeben.

Erstens: Entscheiden Sie frühzeitig, ob und wo KNX Secure eingesetzt wird. Die Entscheidung beeinflusst die Gerätebeschaffung, den Inbetriebnahmeaufwand und die Anforderungen an das ETS-Projektmanagement. Eine nachträgliche Einführung ist möglich, aber aufwendiger als eine von Anfang an geplante Secure-Konfiguration.

Zweitens: Behandeln Sie das ETS-Projekt und das Projektpasswort als kritische Betriebsunterlagen. Legen Sie fest, wer das Passwort kennt, wo es sicher verwahrt wird und wie es im Falle eines Personalwechsels oder Integratorwechsels übergeben wird. Ein verlorenes Projektpasswort kann im schlimmsten Fall eine vollständige Neuinbetriebnahme erfordern.

Drittens: Erfassen Sie die FDSKs aller Geräte systematisch bei der Inbetriebnahme. Der FDSK ist auf dem Gerät aufgedruckt und nach dem Einbau oft schwer zugänglich. Wir empfehlen, die FDSKs vor dem Einbau zu fotografieren oder zu scannen und im ETS-Projekt zu hinterlegen.

Viertens: Planen Sie den gemischten Betrieb bewusst und zeitlich begrenzt. Wenn Sie Secure schrittweise einführen, legen Sie fest, bis wann alle Geräte auf einer Linie auf Secure umgestellt sein sollen. Dokumentieren Sie, welche Linien im Übergangsbetrieb sind und welche vollständig gesichert sind.

Fünftens: Kombinieren Sie KNX Secure mit Netzwerksegmentierung. IP Secure allein reicht nicht, wenn der KNX-IP-Backbone in einem ungesicherten Netz liegt. Arbeiten Sie mit der IT zusammen, um dedizierte Netzsegmente für die GA-Kommunikation zu definieren.

Der rote Faden zu unseren Fachbeiträgen

Dieser Artikel gibt einen allgemeinen Überblick über KNX Secure. Wer wissen möchte, wie KNX Secure konkret in Ausschreibung und Projektablauf verankert wird, findet das in Teil 4 der Serie «KNX richtig planen»: «KNX Secure im Projekt: Data Secure und IP Secure». Die Grundlagen der KNX-Topologie und des IP-Backbones, die für das Verständnis von IP Secure wichtig sind, behandelt Teil 2 derselben Serie: «Topologie, Linien und IP-Backbone sauber aufbauen». Warum das ETS-Projekt der Bauherrschaft gehört und wie es sicher verwahrt wird, erklärt Teil 5: «Das ETS-Projekt gehört dem Bauherrn».

Für Einsteiger, die zuerst verstehen wollen, was KNX überhaupt ist und wie der Bus funktioniert, empfehlen wir Teil 1 der Serie «KNX Grundlagen: die Schulungsreihe»: «Was ist KNX? Standard, Normen und Übertragungsmedien». Das KNX-Telegramm und den Buszugriff erklärt Teil 8 derselben Serie: «Das KNX-Telegramm: Buszugriff, Bestätigung und Buslast».

Wer KNX im Kontext der Gebäudeautomation einordnen möchte, findet in unserem Artikel «Warum proprietäre Gebäudeautomation ein Risiko für Ihre Liegenschaft ist» eine ergänzende Perspektive. Und wer sich fragt, ob KNX für sein Gebäude überhaupt das richtige System ist, findet Antworten in Teil 1 der Serie «KNX richtig planen»: «KNX im Zweckbau: wann es passt und wann nicht».

Für Betreiber, die sich mit Cybersicherheit in der Gebäudeautomation generell beschäftigen, ist unser Artikel «KBOB IKT-Sicherheit in der Gebäudeautomation: Was die neue Empfehlung für Planer und Betreiber bedeutet» ein sinnvoller nächster Schritt. Dort behandeln wir auch, wie Sicherheitsanforderungen in der GA-Planung verankert werden.

Fazit

KNX Secure ist eine technisch durchdachte Antwort auf reale Risiken in vernetzten KNX-Anlagen. KNX Data Secure schützt die Telegramme auf der Anwendungsschicht mit AES-128 im CCM-Modus, Authentifizierungscode und Sequenzzähler. KNX IP Secure schützt die IP-Kommunikation zwischen KNX-Geräten mit demselben Verschlüsselungsverfahren und einem zusätzlichen Zeitstempel. Beide Mechanismen zusammen bieten einen soliden Schutz vor Abhören, Manipulation und Wiederholungsangriffen.

Der Preis für diesen Schutz ist ein sorgfältiges Schlüsselmanagement. Das Projektpasswort und die Gerätezertifikate sind die Schlüssel zur Anlage. Wer sie verliert, verliert die Kontrolle. Das ist keine Schwäche des Systems, sondern eine Konsequenz, die von Anfang an in die Betriebsplanung einbezogen werden muss.

KNX Secure ersetzt keine Netzwerksegmentierung und keine physische Zugangskontrolle. Es ist ein Baustein in einem umfassenderen Sicherheitskonzept, kein Ersatz dafür. Wer das versteht und KNX Secure konsequent und vollständig einsetzt, hat eine Anlage, die auch in vernetzten Umgebungen sicher betrieben werden kann.

Sie haben Fragen dazu?

Sie planen eine KNX-Anlage und möchten wissen, ob und wie KNX Secure für Ihr Projekt sinnvoll ist? Oder Sie betreiben bereits eine KNX-Anlage und fragen sich, wie Sie das Sicherheitsniveau beurteilen und verbessern können? Wir helfen Ihnen bei der Einschätzung und begleiten Sie von der Planung bis zur Inbetriebnahme. Nehmen Sie Kontakt auf unter wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• KNX Association Support: KNX Secure Devices, KNX Data Secure (support.knx.org), abgerufen 2025
• KNX Swiss: KNX Secure (knx.ch), abgerufen 2025
• EN ISO 22510: KNXnet/IP, Kommunikation über IP-Netze (KNX IP Secure)
• EN 50090 / ISO/IEC 14543-3: KNX-Standard für Heimautomation und Gebäudeautomation; KNX und ETS sind eingetragene Marken der KNX Association, Brüssel (knx.org)
• Eigene Projekterfahrung der WENGET GmbH aus KNX-Planung, Inbetriebnahme und Betriebsbegleitung