KNX protocol security: what KNX Secure fixes, and why classic KNX cannot be patched

No. KNX (standardized as EN 50090 / ISO 22510, and the dominant open protocol for European and global commercial building automation — lighting, HVAC, blinds, access control) was designed as a trusted-bus protocol, and its original specification carries no cryptographic protection at all: any device on a classic KNX TP (twisted-pair) bus segment, or any attacker who can reach a KNXnet/IP gateway, can read and inject telegrams without authentication. This is not a bug that was later discovered and left unfixed — it is a structural property of the original design that the KNX Association itself now states plainly in vulnerability disclosures: a 2026 CISA ICS advisory covering an ABB/Busch-Jaeger KNX update tool (CVE-2026-12705, missing firmware-image integrity protection) quotes the vendor's own position that 'legacy KNX standards were never designed to meet state of the art security standards' and that, for classic KNX products, 'there are no options to resolve the vulnerability with a software update on a technical level.'

KNX Secure, introduced by the KNX Association in 2017, is two complementary mechanisms rather than one umbrella fix. KNX Data Secure protects telegrams directly on the TP/RF bus media, adding data integrity (an authentication code appended to every message, so a receiver can detect a modified or forged frame), freshness (a sequence number that defeats simple replay of a captured telegram), and confidentiality via AES-128 CCM encryption with asymmetric key handling, compliant with the ISO 18033-3 cipher standard. KNX IP Secure does the equivalent job for IP-based installations, encrypting the KNXnet/IP traffic that runs over a building's backbone or management network. KNX IP Secure went further than a vendor spec: it was published as the international standard EN ISO 22510 in November 2019, making it, per the KNX Association's own description, the first vendor- and application-independent security standard for building automation. Both mechanisms are additive to the base protocol, not a replacement for it — a device has to explicitly support and be configured for KNX Secure to get any of this.

Yes, and this is the central practical risk in any real KNX deployment, because KNX Secure was designed to be backward-compatible rather than to force a rip-and-replace. A coupler or line device can bridge secure and non-secure segments so that older, non-upgradeable field devices keep working alongside newer KNX Secure ones. The security consequence is straightforward: KNX Secure only protects the segments and devices actually configured to use it. A non-secure device on a bridged segment still communicates in the clear, and an attacker who can reach that segment (physically, or through a weak IP gateway) sees and can inject telegrams on it exactly as they could on a fully classic installation, regardless of how well the secure side of the same building is configured. The CISA/ABB advisory above makes the same point from the vendor side: the integrity gap it describes 'applies exclusively to legacy KNX products' still in the field, which in most real buildings means a meaningful fraction of the installed base, not a hypothetical edge case.

The most concrete publicly tracked one sits in ETS (Engineering Tool Software), the KNX Association's own configuration tool, not in the bus protocol: CVE-2021-36799 (CVSS v3.1 8.8) found that ETS5 through version 5.7.6 stores project passwords by obfuscating them with a hard-coded password, 'ETS5Password,' and a hard-coded salt value, letting any local user who can read the project file recover the actual credential protecting that project's KNX Secure key material. A separate, protocol-level finding, CVE-2023-4346 (CVSS v3.1 7.5), affects devices implementing KNX Connection Authorization Option 1 with no BCU key configured: an attacker with network access to the installation can purge every device that has no additional security option enabled and then set their own BCU key, locking the legitimate operator out of devices they previously controlled with no software-only recovery path. Neither of these is a break of KNX Secure's AES-128 cryptography itself — both are tooling and configuration-authorization gaps around it, which is consistently where documented KNX incidents actually occur.

No — standardization describes what the specification requires of a conformant implementation, not what any given deployed building actually runs. EN ISO 22510 means KNX IP Secure is now a vendor-neutral, internationally specified mechanism any manufacturer can implement and interoperate against; it does not retroactively enable itself on a building's existing KNXnet/IP router, which has to be a model that supports it, correctly configured with ETS, and actually running in secure mode rather than in a legacy-compatible plain mode most routers still ship with by default. The KNX Association's own guidance on when to apply which layer is explicit about risk, not blanket mandate: it calls out wireless (RF) installations as a particular priority because 'communication between devices is completely out in the open,' and states that for any installation linked to the internet, 'the use of a VPN tunnel to access it via the internet is an absolute MUST' — implying that IP Secure alone, without that network-layer control, is not treated by KNX's own guidance as sufficient for an internet-facing deployment.

Start from the assumption that most of a mixed-age KNX installation is still running in the clear, and work outward. First, inventory which lines and devices actually negotiate KNX Data Secure or KNX IP Secure today versus which are classic/legacy devices bridged in — a datasheet claiming 'KNX Secure capable' is not the same claim as a device actually configured and running in secure mode in that specific building. Second, treat the KNXnet/IP router and any internet-facing access path as the highest-priority segment to lock down, per the KNX Association's own VPN-and-firewall guidance, since that is the one path an attacker doesn't need physical building access to reach. Third, patch and update ETS and any KNX engineering workstations to current versions, and don't assume the project password is a meaningful secret on older ETS5 installs given CVE-2021-36799's findings. Fourth, check which devices use KNX Connection Authorization Option 1 without a configured BCU key, since CVE-2023-4346's lockout risk applies specifically to that unconfigured state and is fixable by simply setting the key. None of this requires replacing classic KNX field devices overnight — it requires knowing, specifically, which parts of the installation the CISA/ABB disclosure's 'cannot be fixed with a software update' statement actually applies to.