Remote access has become an essential part of many KNX projects. But the same connection that makes support easier can also create an unnecessary opening if it is not configured correctly. A few practical checks can make a significant difference.
You wouldn’t leave an electrical cabinet unlocked in a public corridor. Yet, digitally speaking, something similar has happened on more KNX installations than many of us would probably like to admit. For years, one of the simplest ways to provide remote access was to forward port 3671 through the customer’s router. It worked. The installer could reach the KNX installation from outside, support calls became easier and everybody went home happy.
There was just one problem. If the installation could be reached that easily by the installer, it could potentially be reached by somebody else as well.
Today, we have much better options. So if you’re returning to an older KNX installation for maintenance or an upgrade, the IP side of the project is a very good place to start your security check.
First stop: the router
|
Image
|
Port 3671 is the default UDP port used for KNXnet/IP communication. There is nothing wrong with using it within the local network. The problem starts when that port has been forwarded through the Internet-facing router to make the KNX installation directly reachable from outside. That approach should no longer be part of a modern installation. The first practical question is therefore simple: can the KNX installation be contacted directly from the Internet? If the answer is yes, the remote-access setup needs attention. KNX Association provides the KNX Security Check to help identify KNX installations that may be accessible from the Internet. For an installer carrying out a maintenance visit, it can be a useful way to identify something that may have been configured years earlier. And old router settings have a habit of being forgotten about. |
Remote access without opening the front door
Closing external access to port 3671 does not mean giving up remote support. Quite the opposite. VPNs and dedicated secure remote-access solutions allow installers to retain the practical benefits of remote diagnostics without simply exposing the KNX connection to the Internet. Depending on the project, this might be handled by the customer’s network infrastructure or by a dedicated gateway designed for secure remote access.
Whichever method is chosen, the principle is the same: access should be authenticated and deliberately granted rather than made publicly reachable. For professionals who support a large number of installations, this is also worth standardising. Having five different remote-access methods across five projects makes support unnecessarily complicated. A defined approach to remote access, credentials, documentation and handover will make life much easier several years down the line.
Your future self will probably thank you.
Don’t put everything on the same network
Once the router has been checked, it is worth looking one step further into the customer’s network. Modern homes and buildings can contain an extraordinary collection of IP-connected equipment: PCs, printers, televisions, cameras, access-control equipment, Wi-Fi devices, building servers and KNX IP interfaces. Putting all of them onto one unrestricted network may be simple, but it is not necessarily good network design. Network segmentation allows building-automation equipment to be separated from other devices.
This is where VLANs (Virtual Local Area Network) can become useful. KNX equipment can be placed within an appropriate dedicated network segment, with traffic between that segment and the rest of the network controlled through the router or firewall. You don’t need to turn every KNX professional into a network engineer, but the underlying principle is straightforward: a device should only be able to communicate with systems it genuinely needs to reach.
Guest Wi-Fi probably does not need access to the KNX IP backbone. Neither does the smart television in meeting room three. Get this right, and the conversation moves on from securing one device at a time to managing building automation as part of a properly structured network rather than treating every device in isolation.
Look at the IP devices themselves
|
Image
|
Older installations may contain perfectly functioning KNX IP interfaces and routers that predate KNX IP Secure. That does not automatically mean ripping them all out. However, when an interface is being replaced, a backbone is being upgraded or a project is undergoing a wider security review, it makes sense to consider KNX IP Secure-capable devices. Because KNX is an open standard supported by more than 500 manufacturers, that choice isn’t limited to a single vendor’s ecosystem. KNX IP Secure is standardised across compatible certified devices, regardless of manufacturer. KNX IP Secure protects KNX communication on the IP medium by adding authentication, data integrity, freshness and encryption. In practical terms, devices that do not have the correct security information cannot read or take part in secured KNX IP communication. There is an important distinction here. KNX IP Secure protects the KNX communication travelling over IP. It does not replace the need for good network design, firewall configuration or secure remote access. Think of these measures as layers rather than alternatives. A VPN (Virtual Private Network) protects the route into the network. Network segmentation limits where devices can communicate. KNX IP Secure protects the KNX communication itself. Together, they provide a much stronger setup than any one measure used in isolation. |
An upgrade does not need to happen overnight
One of the realities of KNX is that many installations remain in operation for a very long time. That’s a strength, but it also means we encounter projects designed under very different assumptions about cybersecurity. The good news is that improving security does not have to mean replacing an entire installation.
Closing unnecessary Internet exposure can be done without touching field devices. Remote access can be changed. Networks can be segmented. Firewalls can be reviewed. IP interfaces and routers can then be upgraded when it makes practical or commercial sense. This allows an installer to improve an existing installation step by step rather than presenting the customer with an all-or-nothing decision.
A useful maintenance checklist
The next time you’re carrying out maintenance on an older KNX installation, the following questions are worth asking:
- Is port 3671 exposed to the Internet?
- How is remote access currently provided?
- Does that access require proper authentication?
- Is the KNX IP infrastructure separated appropriately from other network traffic?
- Are the firewall rules still appropriate?
- Could older KNX IP interfaces or routers be upgraded to KNX IP Secure-capable alternatives?
- Is the current network configuration actually documented?
A surprising number of future problems begin with nobody knowing why a router was configured a particular way five years earlier.
Download our more comprehensive KNX Secure checklist here
Conclusion
Securing a KNX installation does not always begin with replacing devices. Often, the most useful first step is simply understanding how the installation connects to the outside world. Removing direct Internet exposure, using secure remote-access methods, improving network segmentation and introducing KNX IP Secure where appropriate can significantly strengthen an existing project without changing the fundamental installation. For KNX professionals, this is becoming an increasingly important part of maintenance and modernisation. We already check power supplies, actuators, sensors and bus communication when servicing an installation. The router deserves a place on that checklist too.
Next month, we will focus on security beyond the network.
