KNX IP Secure (defined in IEC 61784-3-3 and the KNX Application Note AN172) provides cryptographic security for KNXnet/IP communication — tunnelling, routing, and device management. Without KNX IP Secure, all KNX group address communication on the IP backbone is unencrypted UDP multicast, readable and injectable by anyone on the same network segment. For commercial buildings with network access from multiple tenants, IoT devices, or guest WiFi, this is a real attack surface. KNX IP Secure uses AES-128-CCM (Counter with CBC-MAC) authentication and encryption, requiring a shared backbone key distributed to all participating IP devices via ETS6.

What KNX IP Secure protects

KNX IP Secure applies to the KNXnet/IP layer — not to KNX TP bus traffic. KNX TP bus (the physical twisted pair at 9600 baud, 29V DC) remains unencrypted by design — physical access to the cable is considered the security boundary. KNX IP Secure protects: KNXnet/IP tunnelling connections (laptop with ETS6 accessing panel remotely), KNXnet/IP routing (backbone communication between KNX IP routers across subnets), group communication via KNXnet/IP (KNX devices reading/writing group addresses via Ethernet). KNX Data Secure (a separate specification) applies to individual TP devices — encrypted telegram on the TP bus itself. Both can coexist: TP bus uses Data Secure, IP backbone uses IP Secure.

ETS6 configuration — backbone key

In ETS6: Project → Security → IP Backbone Key. Generate a new random 128-bit backbone key (or import an existing key from another ETS6 project sharing the same network). This key is distributed to all KNX IP Secure devices during programming — stored in device non-volatile memory. All KNX IP routers and KNXnet/IP interfaces on the project must share the same backbone key to communicate. Changing the backbone key requires re-programming all participating devices.

Device-level configuration

In ETS6, each KNX IP Secure device (Weinzierl 770, MDT KNX IP Router, Gira X1) shows Security configuration in the device properties. Enable: KNX IP Secure tunnelling (for ETS6 and panel management tools), KNX IP Secure routing (for backbone group communication). Individual tunnelling connections each have a unique password (user-specific authentication) — distribute different passwords to different users for audit trail. For the Gira X1: IP Secure is also required for the Gira Home App remote connection — configure under Gira X1 → Access → IP Secure → enable + set passwords.

Firewall and VLAN considerations

KNX IP Secure uses the same UDP port 3671 as standard KNXnet/IP. Multicast address 224.0.23.12 (same as unsecured). Firewall rules: allow UDP 3671 between VLANs where KNX IP routers communicate. Do not NAT KNX multicast — routing multicast across VLANs requires IGMP snooping and PIM multicast routing on managed switches (Cisco, HP, Ubiquiti Enterprise). Recommended VLAN design for commercial KNX: KNX automation VLAN (IP routers, Gira X1, WAGO controller), building IT VLAN (ETS6 laptop, BMS server), guest VLAN (no access to KNX VLAN). Firewall allows specific IP addresses from building IT VLAN to connect to KNX automation VLAN on port 3671 — all other traffic blocked.

KNX Data Secure on TP bus

For installations where TP bus physical security cannot be guaranteed (external cable runs in car parks, access to cable trays by third parties): enable KNX Data Secure on individual TP devices. MDT SCN-IP100.01 KNX IP Router supports Data Secure: each telegram encrypted with device-specific key derived from backbone key + device individual address. KNX TP devices without Data Secure support ignore secure telegrams — a mixed secure/unsecure TP bus requires careful planning. ETS6 Security view shows device Data Secure status per device in project. In practice for residential projects: KNX IP Secure on backbone is sufficient — TP Data Secure is mainly specified for commercial buildings with shared infrastructure.