In the first part of this series, we looked at closing off unnecessary Internet exposure: checking the router, securing remote access and separating the KNX network from everyday traffic.
That’s an important first step, but it is only one layer of protection. From device access to secured telegrams and ETS project credentials, there are several ways KNX professionals can strengthen the installation itself.
Job done? Not quite.
Network security helps stop unwanted visitors reaching the KNX installation from outside. But what happens if somebody already has access to the building, the network or the KNX bus itself?
This is where the next layer of protection begins.
Protecting devices from unwanted changes
Anyone who has worked on an existing KNX project knows how valuable access to the original ETS project is. Without it, life becomes considerably more difficult.
It is therefore worth considering who should be able to reprogramme devices in the first place. Where supported by the equipment and project, device-access protection and programming locks can make unauthorised changes more difficult.
This becomes particularly relevant in buildings where KNX components or bus access points are located in areas accessible to multiple contractors, tenants or service companies. A hotel, school or office building is a very different environment from a locked plant room in a private home.
Physical access is part of cybersecurity too.
The BCU Key: useful, but handle with care
For compatible KNX devices, ETS also provides the option of setting a BCU Key. Once applied to supported devices during download, the BCU Key helps protect access to their configuration, making unauthorised programming or modification more difficult without the correct key.
That can provide another useful layer of protection, particularly on existing installations where KNX Secure devices are not yet present.
There is, however, a rather important catch. Don’t lose the key.
Recovering access after a BCU Key has been forgotten can be difficult and may depend on the particular device and manufacturer. The key should therefore be treated as part of the project documentation and credential-management process, not as something an installer enters once and hopes to remember several years later.
Security measures are only useful if they can still be managed by the authorised people.
From protecting access to protecting the telegram
Device passwords and access restrictions help control who can make changes. KNX Data Secure goes further by protecting KNX communication between participating devices.
When Data Secure is enabled for a function, the relevant KNX telegrams are authenticated and encrypted. This makes it considerably harder for somebody without the correct security information to read the data or inject valid commands into that secured communication.
And this is where security becomes particularly interesting for existing projects.
KNX Data Secure is applied at Group Address level. This means that an installation does not necessarily need to move from completely unsecured to completely secured in a single major upgrade.
Instead, protection can be planned around the functions that matter most. The devices participating in secured communication must, of course, support the required KNX Secure functionality.
Not every telegram carries the same risk
Consider two functions in a large building. The first switches a light in a storage cupboard. The second unlocks an entrance, disables an alarm function or issues a central command affecting an entire floor.
Technically, both are KNX telegrams.
From a security perspective, however, the consequences of manipulating them are very different.
This allows KNX professionals to approach upgrades based on risk. Which functions would cause the greatest problem if somebody could monitor them? Which commands would have serious consequences if manipulated? Where would unauthorised operation affect safety, access, privacy or important building functions?
Those are sensible places to prioritise secured communication.
This can turn a potentially overwhelming conversation about replacing every field device into a much more practical security plan.
Upgrade when the opportunity appears
KNX installations are often designed for long service lives. Perfectly serviceable devices may remain in operation for many years, and replacing them simply because a newer device exists can create unnecessary electronic waste.
Security upgrades therefore need some judgement.
If an actuator fails and needs replacement anyway, selecting a KNX Data Secure-capable alternative can help prepare that part of the installation for secured communication, provided the other devices participating in the relevant function also support the required KNX Secure functionality. The same principle applies when an area is refurbished, an access-control system is upgraded or a particularly sensitive function is being redesigned.
Because KNX is an open standard, that choice isn’t limited to a single manufacturer. With hundreds of KNX manufacturers offering compatible products, an installer can select a suitable replacement without being tied to one supplier’s roadmap.
Over time, more of the installation can move towards secured communication without requiring a complete rip-and-replace project.
For many customers, that can be a more realistic approach to improving security over time.
Secure devices mean secure credentials
There is another part of KNX Secure that should not be overlooked: the ETS project itself.
Once KNX Secure is introduced, the project contains security-related information and becomes an important part of the protection concept. ETS therefore requires KNX Secure projects to be protected by a project password.
This makes good project management particularly important. The latest ETS project should be backed up appropriately. Passwords and project access should be managed securely. Device certificates and project information should not be left scattered across laptops, email inboxes or shared folders without thought as to who can access them.
The project file is no longer just documentation of the installation. It is part of the security of the installation.
Think in layers
It is tempting to look for one setting or product that makes an installation “secure”.
In practice, security does not work like that.
An installation may have an excellent VPN but no protection on its KNX communication. It may use KNX Data Secure but sit on a poorly configured IP network. Devices may be well protected whilst the ETS project password is written on a piece of paper inside the cabinet.
One strong layer does not compensate for weaknesses everywhere else.
A stronger approach is to combine sensible measures: control physical access, protect device configuration where appropriate, secure important KNX communication, safeguard project credentials and maintain proper documentation.
None of these measures is particularly dramatic on its own. That’s rather the point.
Conclusion
Improving KNX security does not need to begin with a complete rebuild. Existing installations can be strengthened through practical measures such as device-access protection and BCU Keys where supported. As projects are modernised, KNX Data Secure-capable devices can then be introduced progressively, helping to prepare important functions for protected communication as the necessary devices are upgraded.
At the same time, the ETS project and its credentials need to be treated with the same care as the installation itself.
For installers and integrators, the important shift is to start thinking about security as part of normal project design and maintenance rather than something added after a problem occurs. That shift also reshapes the relationship with the customer: security isn’t a box ticked once at handover, but something to revisit as the installation, and the building around it, evolves.
We already ask what a function should do, how it should behave and what happens if it fails.
Increasingly, there is one more question worth adding: Who should be allowed to control it?
