The Weakest Point In Your KNX System Might Be The Router

For years, the easy way to give a client remote support was to forward port 3671 straight through their router to the KNX installation. It worked. The installer could dial in from anywhere, support calls got shorter, everyone was happy. There was just one problem nobody thought through properly at the time: if the installer could reach the system that easily from outside, so could anyone else who went looking.

KNX Association just published a piece on exactly this, and it's worth walking through because I still see old installs configured this way.

Start with the router, not the field devices

Port 3671 is the standard UDP port for KNXnet/IP. There's nothing wrong with it sitting on the local network doing its job. The problem is when that port gets forwarded through the internet-facing router, making the installation directly reachable from anywhere in the world, not just from the installer's laptop.

If you're servicing an older KNX system, the first question worth asking is simple: can this installation be contacted directly from the internet right now? KNX Association runs a free KNX Security Check tool through their support site that flags exactly this. Old router settings have a habit of outliving whoever configured them.

Remote access doesn't require an open door

Closing that port off doesn't mean giving up remote diagnostics. A VPN or a dedicated secure remote-access gateway gets an installer the same practical access without leaving the KNX connection sitting exposed to the internet. Access should be authenticated and deliberately granted, not just publicly reachable because it's convenient.

If you're supporting more than a handful of projects, it's worth standardising this rather than improvising a different remote-access method for every site. Five projects with five different remote-access setups is a support headache waiting to happen a few years down the line.

Not everything belongs on the same network

Once the router's sorted, the next question is what else is sitting on that same network as the KNX system. A modern home can have printers, TVs, cameras, access control, guest Wi-Fi and a KNX IP interface all talking on one flat network by default, mostly because that's the path of least resistance during install.

Separating building automation traffic onto its own VLAN, with a firewall or router controlling what can talk to what, closes that gap without adding real complexity. The guest network doesn't need a route to the KNX backbone. Neither does the smart TV in the media room. Once that's in place, security stops being about locking down one device at a time and becomes a property of how the network's actually structured.

KNX IP Secure is the layer underneath all of this

Older KNX IP interfaces and routers still work fine and don't need to be ripped out on principle. But when a device gets replaced, or a backbone gets upgraded, or a system's due for a proper security review, it's worth specifying KNX IP Secure-capable hardware. It adds authentication, data integrity, freshness checking and encryption to KNX communication over IP, and because it's part of the open standard rather than one manufacturer's own scheme, it works the same way across brands rather than locking you into a single vendor's ecosystem.

The three layers do different jobs. A VPN protects the route into the network. Segmentation limits which devices can talk to which. KNX IP Secure protects the KNX communication itself once it's on the wire. None of them substitutes for the others. Stacked together, they're a properly defended installation instead of one good idea doing all the work alone.

This is a checklist, not a rebuild

None of this requires tearing out a working system. Remote access can be changed without touching a single field device. A network can be segmented without an actuator ever coming off the bus. Interfaces and routers get upgraded on their own schedule, when it makes sense.

Next time you're doing maintenance on an older system, or taking one over from another installer, it's worth running through a short list: is port 3671 open to the internet, how is remote access being provided, does it require real authentication, is the KNX traffic separated from the rest of the network, are the firewall rules still the ones somebody meant to set, and is any of this written down anywhere. That last one matters more than people expect. A lot of future problems start with nobody remembering why a router was configured a certain way five years earlier.

If you're taking over an existing KNX installation, or want one audited before you hand it to a client, get in touch. Just a conversation about what the project needs.

Wayne | KNX Logic

wayne@knxlogic.co.za | 082 564 3982 | www.knxlogic.co.za

Source: KNX Association, "Is Your KNX Installation Exposed? Securing the IP Side" (21 Sep 2026) — https://www.knx.org/news/your-knx-installation-exposed-securing-ip-side