KNX and LonWorks Building Protocol Security Guide: Locking down field buses, keys and IP gateways

KNX and LonWorks run the lights, blinds, heating and room controls in millions of buildings, and in their classic form both will accept configuration changes from anyone who can reach the bus or an IP gateway. Attackers have already used that: in 2021 hundreds of KNX devices in a German office building were wiped and locked with an attacker-set key, and in July 2026 CISA added the underlying KNX weakness, CVE-2023-4346, to its Known Exploited Vulnerabilities catalog. This guide goes deeper than the general building systems overview: it explains the security mechanisms KNX and LonWorks actually have, KNX Secure and how to configure it in ETS, how to handle BCU keys, FDSKs and project passwords as credentials, how to secure IP gateways and LON/IP channels, and how to migrate a mixed estate. It is for system integrators, facilities and OT security teams, and building owners who inherit installations they did not commission. For the wider BMS picture, see the Building Management System Security Guide.

Key takeaways

• Set a BCU key on every device before handover. Devices with no BCU key under Connection Authorization Option 1 can be purged and locked by anyone with network or physical access (CVE-2023-4346, CVSS 7.5, known exploited); the KNX Association's mitigation is to set the key and give it to the owner.
• Treat KNX keys and passwords as owned secrets. BCU keys, the ETS project password, device certificates (FDSKs), commissioning passwords and tunnelling passwords belong in the owner's credential vault, not in an installer's head or laptop.
• Use KNX IP Secure on anything IP and Data Secure where it matters. IP Secure protects the IP medium; Data Secure protects individual group addresses on any medium and can be adopted function by function.
• LonWorks has authentication but no encryption. LonTalk sender authentication uses a per-device key and a challenge-response, but traffic is clear text, so segmentation and gateway control do most of the work.
• Remove temporary gateways and internet exposure. Both documented 2021 KNX attacks started from a UDP port reachable from the internet or a construction-phase IP gateway that was never removed.

KNX and LonWorks at a glance

KNX began in 1990 as EIB and is maintained by the KNX Association, which publishes the specifications and the ETS engineering tool. LonWorks is built on the LonTalk protocol standardised as ISO/IEC 14908, with the Neuron chip at the heart of many devices. Both were designed for closed buses inside a building, and both now reach IP networks through routers, interfaces and supervisors.

The LonWorks cryptographic point comes from INCIBE, which notes that an April 2015 cryptanalysis found the ISO/IEC 14908 algorithm insecure by default and suggested authenticated encryption such as AES-CCM or AES-GCM instead. In practice, treat LonTalk authentication as a guard against casual injection, not as a security boundary.

How KNX Secure works

The KNX Association describes two complementary mechanisms, whose specifications and test specifications were approved by its Technical Board by the beginning of 2019.

• KNX IP Secure: fully encrypts telegrams on the IP medium only. Use it for the backbone and any segment exposed to wider IP networks. Only IP interfaces and routers need replacing; TP traffic below them stays unencrypted unless Data Secure is also used. Secure Routing uses a common key for all routing communication and a time-based counter, so routers keep a synchronised system time. Secure Tunnelling uses a Diffie-Hellman key exchange before the user ID and password are sent.
• KNX Data Secure: works at telegram level on any medium, with a separate key per group address, an authorisation code so only authorised devices take part, and a 6-byte sequence number that receivers require to increase. Every device in a secured function must support it.
• Mixed installations: secure and plain communication can coexist, and a Secure Proxy in a coupler can translate between secured and unsecured segments. Visualisation and integration software must now take group addresses and device participation from ETS, because importing group addresses alone is no longer enough.

The KNX credentials and who should hold them

These are machine credentials for a building's control layer, and they suffer the same lifecycle problems as any other secret: no owner, copies on laptops, and no rotation when an integrator leaves. See the Secrets Management Guide.

Configuring KNX Secure in ETS

The KNX Association's ETS guidance recommends ETS 5.7.6 or later (ideally ETS6) and gives this sequence. Build and test it on a bench or one line before rolling it across a building.

1. Set the project password first: on the project's main details tab, before adding any Secure devices.
2. Add device certificates: enter each FDSK from the device or its card, or scan the QR code instead of typing the key. Secure products show a padlock in the catalogue.
3. Enable IP Secure on the backbone: select the main or backbone line in topology view and set KNX IP Secure. "Automatic" only applies security when every device on that line supports it, so check the result rather than assuming.
4. Secure the routers and interfaces: enable secure commissioning and set a commissioning password on each IP device, and set the authentication code required for tunnelling security.
5. Secure tunnelling per connection: enable security on each tunnelling connection used for commissioning or third-party access and give each a password. Leave an unsecured tunnel only where a legacy system genuinely cannot connect, document it and plan its removal.
6. Apply Data Secure by group address: set security to "Automatic" on the Group Address settings so it applies where all participating objects come from Secure devices. Prioritise functions that affect access, safety, privacy or building operation.
7. Set BCU keys on devices that support them: including plain devices that cannot use Data Secure.
8. Hand over: export the project, certificates, BCU keys and passwords to the owner's vault and record who holds copies.

Testing and rollback: run diagnostics from within the project, because the keys are held there. Keep the pre-change project backup. A Secure device can be returned to its factory key with a master reset, using the manufacturer's procedure, and recommissioned from the backup.

Securing LonWorks installations

LonWorks gives you fewer levers, so the work shifts to architecture and tooling.

• Enable sender authentication on critical network variables: where devices and tools support it, authentication blocks injection of new commands, although INCIBE notes it adds traffic and does not hide content.
• Protect the authentication key: it cannot be read out of the Neuron and cannot be changed without already knowing it, so record it in the owner's vault at commissioning.
• Isolate LON/IP channels: treat IP tunnelling routers and the configuration server as management-plane devices on a dedicated VLAN, reachable only from the supervisor and engineering jump host.
• Control the network database: the LNS or equivalent network database describes every node and binding. Back it up, restrict who can open it and keep it off general file shares.
• Plan migration: where a LonWorks segment controls safety-relevant or security-relevant functions (door control, smoke extract interfaces), prioritise replacement with protocols that support authenticated encryption, such as BACnet/SC or KNX Secure. See the BACnet and BACnet Secure Connect Guide.

Network exposure, gateways and remote access

The 2021 KNX attacks, reported by Dark Reading from Limes Security's incident work, began from an unsecured UDP port exposed to the internet in one case and a temporary IP gateway left in place after construction in the other. CISA's advisory ICSA-23-236-01 repeats its standard OT mitigations: keep control devices off the internet, behind firewalls and isolated from business networks, with up-to-date VPNs for remote access.

Integrator access should be named, time-boxed and brokered; see the OT Remote Access Guide.

Detection and measurement

Building buses rarely send logs to a SIEM, so detection relies on gateways, visualisation servers and network monitoring.

• Unexpected programming traffic: device programming, memory writes, master resets or BCU key changes outside a change window are the signature of the 2021 attacks.
• New tunnelling connections: alert on tunnelling sessions to KNX IP interfaces from hosts other than the engineering jump host.
• Internet exposure: regular external scans for UDP 3671 and LON/IP routers on your public address ranges.
• Loss of secured communication: secured telegrams failing authentication can indicate tampering or clock problems on IP Secure routers.
• Device health: visualisation alarms for devices that stop responding, which was how the first victim noticed.

Passive OT monitoring tools that decode KNXnet/IP add visibility at the IP layer; see the OT Network Security Monitoring Guide.

Metrics:

• Percentage of KNX devices with a BCU key set and recorded in the owner's vault (target 100% of supporting devices).
• KNX IP routers and interfaces running IP Secure with secure tunnelling.
• Share of high-impact functions (access, safety interfaces, plant rooms) protected by Data Secure or behind authenticated gateways.
• Internet-reachable KNXnet/IP or LON/IP endpoints found by external scanning (target zero).
• Projects where the owner holds the current ETS project, password and certificates.

Decision guidance

• Existing plain KNX, no budget for replacement: set BCU keys, remove internet exposure and temporary gateways, segment the IP backbone and replace only IP routers and interfaces with IP Secure models. This closes the documented attack path.
• Refurbishment or new build: specify KNX Secure devices, IP Secure on the backbone, Data Secure on high-impact functions and owner-held keys in the contract. See the OT Product Procurement Guide.
• Homes and small buildings: the same risks apply at smaller scale; the most important steps are no port forwarding, a BCU key or Secure devices, and the owner holding the project.
• Large estates with LonWorks: keep LON segments behind supervisors on isolated VLANs and fold them into a replacement plan by risk, since the protocol cannot be secured to modern standards.

Common failure patterns

• No BCU key at handover: the exact condition in CVE-2023-4346. In the 2021 German case attackers wiped about three quarters of the devices and set their own BCU key; the owner ran lighting manually for weeks until Limes Security recovered the key from device memory.
• Construction gateway left in place: the second 2021 victim's entry point was an IP gateway meant to be removed at handover.
• Keys held only by the installer: lost BCU keys can mean returning devices to the manufacturer, and a lost ETS project password locks the owner out of a Secure installation.
• IP Secure set to Automatic and assumed on: one unsupported device on the line silently leaves the line unsecured.
• Unsecured tunnelling for a visualisation that was never upgraded: one plain tunnel undoes IP Secure for the whole router.
• LonTalk authentication treated as encryption: credentials and setpoints cross the bus in clear text.

Framework mapping

Practitioner checklist

• Scan your public address ranges for UDP 3671 and LON/IP endpoints and remove any exposure.
• Remove every temporary commissioning gateway and cellular router after handover.
• Set a BCU key on every KNX device that supports it and record it in the owner's vault.
• Protect every KNX Secure project with a strong project password held by the owner.
• Replace KNX IP routers and interfaces with IP Secure models and secure each tunnelling connection.
• Apply Data Secure to group addresses for access, safety-related and plant functions first.
• Put KNX IP and LON/IP traffic on dedicated VLANs behind a firewall.
• Enable LonTalk sender authentication where supported and plan replacement of high-impact LON segments.
• Alert on device programming, master resets and new tunnelling sessions outside change windows.
• Keep current backups of the ETS project and LON network database off general file shares.

Standards and references

• CISA: ICS Advisory ICSA-23-236-01 KNX Protocol
• CISA: Known Exploited Vulnerabilities Catalog
• KNX Association: KNX Secure, Protecting Installations Inside and Outside
• KNX Association: Configuring KNX Secure Systems in ETS
• KNX Association: KNX Plain Devices vs KNX Secure Devices
• KNX Association: Securing the KNX Bus Beyond the Network
• INCIBE: Security in Protocols for Building Automation
• Dark Reading: Cyberattacks Shut Down Building Automation Systems

Related NHI Mgmt Group resources: Building Management System Security Guide · BACnet and BACnet Secure Connect Guide · Johnson Controls Metasys Security Guide · OT Third-Party and Integrator Access Guide