ABB's KNX Tool Flaw Is a Symptom of a 20-Year-Old Design Problem
A new CISA advisory on ABB's KNX Update Tool reads like a vendor admitting the real problem: KNX devices built before security was part of the spec, and no easy way to fix them.
ABB got a responsible disclosure report on its KNX Update Tool, and the fix summary is unusually honest. A successful attack could make the product unusable — a denial-of-service condition — but ABB is quick to point out that the exposure only applies to “classic” KNX devices, the ones that never got KNX Secure support. Read between the lines and what ABB is really saying is: this isn’t a flaw in our tool so much as a flaw baked into a protocol generation that predates modern security thinking by decades.
KNX has been the backbone of European building automation since the 1990s. Lighting, HVAC, blinds, access control, all riding on a bus protocol designed for reliability and interoperability, not confidentiality or integrity. KNX Secure arrived years later as a bolt-on, and adoption has been exactly what you’d expect from a bolt-on security layer in a market driven by installers and cost per point: patchy, slow, and concentrated in new builds rather than the vast fleet of buildings running gear installed a decade ago.
Why building automation keeps losing this fight
Building automation systems don’t get the attention that power grids or water plants do, and that’s a mistake. A hospital’s BMS controls airflow in surgical suites. A data center’s BMS controls cooling for racks worth more than the building itself. When a vulnerability report says an attacker can “make the product unusable,” that’s not an abstract inconvenience — it’s an outage that can cascade into physical consequences depending on what’s riding on that bus.
The uncomfortable truth is that KNX Secure adoption is a retrofit problem, and retrofit problems in OT rarely get solved by a patch. You can’t push a firmware update to a bus coupler that was installed in 2011 and never designed to receive one. Fixing this properly means swapping hardware, which means budget cycles, which means it doesn’t happen until something forces the issue — usually an incident, sometimes a compliance mandate, occasionally an insurer asking pointed questions.
What this advisory should actually trigger
If you run a facility with KNX in it, the advisory itself is almost secondary to the inventory question it raises: do you actually know which of your KNX devices support Secure and which don’t? Most facility teams don’t have a clean answer, because KNX projects get built by system integrators over years, with device lists buried in commissioning documentation nobody’s opened since handover.
The fix here isn’t a patch. It’s knowing what you have.
That’s the real value of an advisory like this one — not the specific vulnerability, but the prompt to go find out how much of your building automation estate is running on protocol generations that were never meant to survive contact with a hostile network. ABB did the right thing by disclosing it plainly. The harder work is on the operator side, deciding whether to keep patching around legacy KNX or finally budget for the hardware refresh that actually closes the gap.
Source: https://www.cisa.gov/news-events/ics-advisories/icsa-26-209-07