KNX Explained: Twisted Pair, KNXnet/IP and KNX Secure

KNX is an open building automation standard, published internationally as ISO/IEC 14543-3 and in Europe as EN 50090, that lets light switches, blind motors, thermostats, meters and sensors from hundreds of manufacturers share one bus. Most installations run on a dedicated twisted pair cable at 9,600 bit/s and connect to IP networks through KNXnet/IP on port 3671. KNX Secure adds AES-128 CCM protection, but only when installers turn it on, and many installations still run without it.

This post goes one level deeper than our explainers on BACnet and Modbus. It covers where KNX came from, its media and addressing, the telegram, ETS engineering, KNXnet/IP tunnelling and routing, and what KNX Data Secure and KNX IP Secure change, then ends with a defensive checklist for your own building. It does not repeat the KNX device advisories we have already covered; those are linked where they fit.

Key takeaways

• KNX began as the European Installation Bus (EIB), launched in 1990. In 1999 the EIB Association, Batibus Club International and the European Home Systems Association merged into the Brussels based KNX Association, and EIB devices stay compatible with KNX.
• KNX runs on twisted pair (TP) at 9,600 bit/s with bus power on the same pair, powerline (PL110) at 1,200 bit/s, radio (868.3 MHz for KNX RF Ready) and IP through KNXnet/IP. KNX IoT adds IPv6 media such as Thread and Wi-Fi.
• Devices have individual addresses (area.line.device). Functions are linked with 16 bit group addresses, usually written main/middle/sub, and each communication object carries a datapoint type (DPT).
• KNXnet/IP uses UDP and TCP port 3671 (registered with IANA in January 2003) and the multicast group 224.0.23.12 for routing.
• Classic KNX has no encryption or message authentication. KNX Data Secure protects telegrams on any medium; KNX IP Secure wraps KNXnet/IP traffic. Both use AES-128 CCM according to the KNX Association, and KNX Secure is standardised in EN 50090-3-4.
• The biggest real world risk is not cryptography but KNX IP interfaces reachable from the internet, flat building networks and unprotected ETS projects. The KNX Association calls a VPN for remote access "an absolute MUST."

Where KNX came from: EIB, BatiBUS, EHS and the 1999 merger

According to the KNX Association's "KNX Basics" handbook, the system "was originally known as the European Installation Bus (EIB), and was developed and marketed by the EIB Association (EIBA)." In 1999 EIBA, Batibus Club International (BCI, France) and the European Home Systems Association (EHSA, Netherlands) amalgamated, the name KNX was adopted and the KNX Association was set up in Brussels. The handbook says "all devices bearing either the KNX or the EIB logo are mutually compatible," which is why 1990s EIB actuators still run next to new KNX Secure devices.

A 2021 article on the KNX Association website says KNX "was launched in 1990 under the name EIB." That age matters for security. KNX was designed for a wired bus inside a building, where physical access to the cable was the trust boundary, long before buildings were routinely connected to the internet.

Standards: ISO/IEC 14543-3, EN 50090 and others

The handbook lists the formal standards that carry KNX: CENELEC EN 50090 (Europe), EN ISO 22510 (Europe), ISO/IEC 14543-3 (international), GB/T 20965 (China) and ANSI/ASHRAE 135 (USA). A 2018 peer reviewed survey of smart home protocol security on arXiv dates the ISO/IEC acceptance to 2006. The ISO catalogue page blocks scripted access, so we could not confirm part numbers and edition dates from ISO directly; check the ISO and IEC catalogues for the edition your procurement references. For KNX Secure, the KNX Association states that it "is standardised according to EN 50090-3-4."

The current KNX Association site describes "8,000+ certified devices from 500+ manufacturers." The older Basics handbook said more than 450 members in 45 countries, a reminder to quote ecosystem numbers with a date.

KNX timeline

What media KNX uses

The handbook names four media: KNX Twisted Pair (TP), KNX Powerline (PL), KNX Radio Frequency (RF) and KNX IP. The current KNX technology page adds KNX IoT over IPv6. Each has its own physical layer, but all carry the same logical telegram content, which is why media couplers can join them.

KNX TP: the twisted pair bus

Twisted pair is the workhorse: a two core cable that carries power and data. The rated bus voltage is 24 V, power supplies deliver 30 V, and devices must work between 21 V and 30 V, leaving a 9 V margin for cable losses.

The data rate is 9,600 bit/s, sent one byte at a time using asynchronous transfer. A logical zero is a short voltage dip that recovers within 104 microseconds. The open source knxd project describes KNX the same way, as running on "dedicated 9600-baud wire."

Bus access is random and event driven, using what the handbook calls CSMA/CA. Every sender listens to every bit it sends. If two devices transmit at once, the one sending a 1 hears a 0, aborts and retries after the winner finishes. The control field carries a priority, so alarms can have right of way; at equal priority the physical address decides. The scheme is non destructive, but it also means one device flooding high priority telegrams can starve the rest of its line.

KNX PL110: powerline

KNX Powerline uses the existing 230 V mains at 1,200 bit/s with spread frequency shift keying: 105.6 kHz for a logical zero and 115.2 kHz for a logical one. The 110 kHz centre frequency gives the name PL110. Band stop filters keep telegrams from leaving the building. It is mostly a retrofit option.

KNX RF: radio

The handbook describes two upward compatible radio versions. KNX RF Ready uses one channel centred on 868.3 MHz. KNX RF Multi adds channels and fast acknowledgement (Fast IACK) from up to 64 receivers, with automatic repetition. The KNX technology page says RF has regional sub-GHz variants for the EU, US, Japan and other markets.

The KNX Association is direct about RF risk. Its KNX Secure page says wireless installations "are the number 1 attack target, as communication between devices is completely out in the open," and recommends KNX Secure on that medium.

KNX IP and KNX IoT

The KNX technology page describes a KNX IP interface as connecting TP installations to IPv4 "using the KNXnet/IP protocol," offering tunnelling connections, while "a KNX IP Router can link several KNX TP sections using IP as a backbone." KNX IoT is the newest profile: an IPv6 based layer with an open source stack running over Ethernet, Wi-Fi and Thread, with a KNX IoT router bridging older media and a KNX IoT API server exposing the KNX Information Model that ETS6 exports. That puts KNX IoT near Matter, which our Zigbee, Thread and Matter explainer covers.

Media at a glance

How KNX addressing works

The arXiv paper on false data injection against building automation systems sums it up: "The KNX protocol supports two general types of 16-bit addresses: individual addresses and group addresses."

Individual addresses: area.line.device

An individual (physical) address identifies one device and follows the topology. The EPFL SVSHI thesis describes the format A.L.D: area 0 to 15, line 0 to 15, device 0 to 255, or AAAA.LLLL.DDDDDDDD in binary. Couplers always take device number 0, so the line coupler for area 1, line 2 is 1.2.0.

Individual addresses are used for management: programming a device, reading its properties, checking its status. Runtime switching goes to groups. So the most powerful operations, such as rewriting a device's application, are addressed individually.

Assigning an individual address is physical. The handbook describes pressing the device's programming button, which tells ETS that "the address next in line to be issued should be assigned to that particular device." The SVSHI thesis notes the press is needed for the first assignment, not for later downloads.

Group addresses and datapoint types

Group addresses are multicast destinations, which the SVSHI thesis calls "virtual cables linking devices together to implement functions." A push button sends "on" to 1/0/1; every actuator listening to 1/0/1 switches; everything else ignores it. There are 65,536 group addresses. ETS displays them in three level (0 to 31, 0 to 7, 0 to 255), two level (0 to 31, 0 to 2047) or free style; on the wire it is the same 16 bit number. The arXiv paper notes that 0/0 and 0/0/0 are reserved for broadcast.

Each device exposes communication objects, which ETS links to group addresses. Each object has a datapoint type named DPT X.Y, where X sets format and encoding and Y sets range and unit. Common types from the thesis:

Open source stacks implement the same catalogue; the Calimero README lists DPT encoding and decoding starting with 1.x Boolean types. That shared vocabulary enables multi vendor interworking, and also means anyone with bus access can read and write meaningful values without reverse engineering.

Worked example: office lighting

The SVSHI thesis uses two lights and three functions: "light 1 on/off," "light 2 on/off" and "light 1 and 2 on/off." Give them 1/0/1, 1/0/2 and 1/0/3. Light 1's actuator listens to 1/0/1 and 1/0/3; light 2's to 1/0/2 and 1/0/3. Each button sends to one group. Nothing is centralised, so one failed actuator does not stop the other. From a security view, every device on the line is also a potential sender for every group.

What a KNX telegram looks like

The handbook gives the TP telegram four fields:

The arXiv paper adds that extended telegrams carry an address type, a hop count that "limits the telegram distance," and an extended frame format. The payload says what the telegram does, such as a group value read or write.

Notice what is missing. Nothing proves the sender owns its source address. The checksum guards against line noise, not tampering. Nothing stops replay. These gaps are what KNX Data Secure fills, and why the arXiv paper describes how someone with bus access could "craft their own telegrams with respect to the victim device." The fix is authenticated telegrams and limiting who can reach the bus.

Line couplers, area couplers and filter tables

KNX TP is a tree. The handbook sets the limits:

• A line segment holds a power supply with choke and no more than 64 bus devices; line repeaters add segments (the SVSHI thesis says up to 256 devices in theory, but more lines is better practice).
• Up to 15 lines join a main line through line couplers to form an area.
• Up to 15 areas join the area line, or backbone, through area couplers.
• Each line has its own power supply, so one failure only takes down one line.

The handbook says a system can theoretically hold more than 50,000 devices.

A line coupler holds a filter table and "will not send a telegram to a line for which it is not destined." ETS writes into each coupler the group addresses that need to cross it. That keeps bus load down and acts as crude access control. It is weak: couplers can be set to pass everything (often during troubleshooting, then forgotten), and a filter table knows group addresses, not who may send to them. Treat filter tables as hygiene, not a security boundary.

The same applies to IP. The handbook says a KNXnet/IP router acting as a line coupler "will only send a telegram to the IP side if the corresponding group address appears in the filter table."

How installers engineer a system with ETS

ETS is the KNX Association's tool used "to plan, design and commission installations of KNX-certified products from any manufacturer." The SVSHI thesis notes it is closed source and licensed.

The workflow

1. Import the catalogue data each manufacturer publishes, and add every device.
2. Build the topology of areas, lines and couplers; ETS assigns individual addresses.
3. Set parameters for each device's application, which differ between manufacturers.
4. Create group addresses and link objects, one group per function.
5. Download through a USB or KNXnet/IP interface: addresses (with a programming button press), then applications, parameters and filter tables.
6. Diagnose with the bus and group monitor, which shows every telegram and can send test telegrams.

What the ETS project holds

The ETS project is the only complete description of the installation. The SVSHI thesis: "One should never lose the ETS project file because it is impossible to infer it from the devices."

KNX Secure raises the stakes. The KNX Association's ETS article says a project password must be set before Secure devices can be added, because "ETS is effectively the administrator in a secure installation." The project then holds every FDSK, the tool keys that replace them, group keys and IP Secure passwords, and diagnostics on a secure installation must run from within the project. ETS can export a keyring for other tools; the Calimero tools README shows a group monitor reading IP Secure multicast with a keyring file using the .knxkeys extension.

So the ETS project and any exported keyring are the crown jewels of a KNX building. Whoever holds them can program every device. Whoever loses them may have to reset and recommission.

How KNXnet/IP tunnelling and routing work

The handbook says KNX "uses two Ethernet communication methods, tunneling and routing, both of which use the UDP protocol." KNX IP Secure later added TCP for tunnelling.

Ports and multicast addresses

The Calimero tools README uses the same group, for example running a group monitor over "KNXnet/IP Routing with multicast group 224.0.23.12."

The KNXnet/IP frame

The handbook describes a header with four fields, then a body. Header length "is always the same" but is sent in case a later version changes it; protocol version; a service type identifier, which "indicates the action that is to be carried out"; and total length. The body usually carries an encapsulated KNX telegram. We have not listed numeric service type codes because we could only find them in implementation code, not a fetched KNX specification; check the KNX standard before relying on specific values.

Tunnelling

Tunnelling is connection oriented. The handbook says it is used "where ETS is to be used to send KNX telegrams in a connection-oriented manner," which is "always the case if a physical address is to be used as the destination address," as in programming. A client opens a connection to one KNX IP interface, which then acts for the client on the TP line.

ETS, visualisation servers and home automation integrations all use tunnelling. It is also the mode that matters most for exposure: a classic tunnelling server reachable from the internet is a direct, unauthenticated line into the building bus.

Routing

Routing is connectionless multicast, "the simultaneous, connectionless transmission of KNX telegrams to several participants via a KNXnet/IP router." KNX IP routers act as couplers, forward permitted group telegrams to 224.0.23.12, and pass multicast onto their TP line only if the group is in their filter table. Because it is multicast, routing lives in whatever IP segment the routers share. If that is the same flat VLAN as office PCs or guest Wi-Fi, every device there can see and send KNX routing traffic.

KNXnet/IP also defines discovery and self description. The Calimero tools README lists "KNXnet/IP discovery and self-description," which is useful for inventory and a reminder that KNX IP devices announce themselves to anyone on the segment.

What KNX Data Secure and KNX IP Secure add

The KNX Association describes KNX Secure as "double protection": KNX IP Secure for IP traffic, KNX Data Secure for individual telegrams on any medium. It says both meet "ISO 18033-3, such as AES 128 CCM encryption," and that more than 1,000 KNX Secure devices are certified.

Why it took until 2019

The KNX Association's 2021 KNX Secure article says specification "took several years," mainly because group addressing "is quite a challenge for secure encryption." Many to many communication does not map neatly onto schemes built for one sender and one receiver. The system and test specifications were approved at the beginning of 2019.

KNX Data Secure: protecting telegrams

KNX Data Secure works at the telegram level on any medium, for commissioning and runtime. The article describes:

• Factory default setup key (FDSK). Each Secure device ships with an individual key in firmware, printed with the serial number as a QR code. ETS must know it before programming, so even the first download is encrypted. (A second KNX Association article expands FDSK as "Factory Default Shared Key"; both describe the same per device key.)
• Tool key. Because the FDSK "may be known by others," ETS replaces it with a per device tool key.
• Group keys. "For maximum security, a separate key is used for each group address."
• Authentication. Encryption stops eavesdropping; an authorisation code ensures only authorised devices take part.
• Replay protection. Each sender numbers telegrams consecutively and receivers accept only higher numbers. The counter is six bytes, so overflow is "practically impossible and is interpreted as an error."

Mixed installations and the Secure Proxy

Security is set per group address. If every linked object supports it, ETS proposes a secure link; if even one does not, "the entire group must communicate insecurely." Objects in one device can differ: switching telegrams can be encrypted while feedback stays plain for a visualisation. For segments that must be encrypted, such as RF, but still talk to plain TP devices, a Secure Proxy in a coupler translates between the two. The KNX technology page describes a Segment Proxy that keeps easily reachable Secure devices, such as room thermostats, from talking directly to insecure back end devices.

KNX IP Secure: protecting the IP side

KNX IP Secure uses the same cryptography with a pragmatic premise: TP in a wall "is assumed to be relatively secure as a purely local medium," while IP "is often connected to the Internet." IP Secure protects KNX IP traffic and leaves TP unencrypted, so existing TP devices stay; only KNX IP interfaces and routers need replacing.

• Secure routing. A common key encrypts all routing traffic. The counter is time based, so obsolete telegrams can be detected; routers keep a shared, synchronised system time.
• Secure tunnelling. Client and KNX IP device first establish a secure channel with a Diffie-Hellman exchange, then transfer a user ID and password. Secure tunnelling can also use TCP.

The ETS article adds that IP Secure is enabled per line in the topology view, each IP device gets a commissioning password and authentication code, and each tunnel gets its own password. Tunnels can be secured one by one, so an older visualisation can keep working. The KNX Secure page warns installers to use "the strong passwords suggested by ETS."

KNX Secure at a glance

Why many installations are still unsecured

The KNX Association's own material explains it:

• Hardware. Adding KNX Secure to existing devices "will, in most cases, not be possible without changing the hardware," and buildings keep installations for decades.
• Mixed groups fall back to plain if one member lacks Secure support.
• Third party software. Integrations need more than group addresses; "each participant must be made known to all the devices it is to reach," currently only via ETS.
• Convenience. The ETS article cites "numerous KNX installations around the world that have been configured for open access from the Internet, either inadvertently or deliberately."
• Commissioning burden. FDSK labels must be collected and kept.

An older control is also often left unset. CISA advisory ICSA-23-236-01 (24 August 2023, CVE-2023-4346, CVSS v3 7.5) describes devices using Connection Authorization Option 1 with no BCU key, where someone with network or physical access could set a key and lock owners out. The KNX Association's recommendation there is to "always set the BCU Key" in every finished project and hand it to the building owner. See our posts on CVE-2023-4346, an FDSK exposure advisory and a KNX device replay advisory.

KNX compared with BACnet, Modbus, DALI and Matter

Buildings rarely run one protocol. KNX handles rooms, DALI drives luminaires, BACnet links HVAC plant to the building management system, Modbus reads meters, and Matter devices arrive with tenants.

Two patterns stand out. Every one of these started without security on its classic transport and added it as an option, so the gap between "the standard supports it" and "this building uses it" is the real exposure. And the gateways between them are where the protocols meet IP networks and where most of the software lives. See also our post on Matter device attestation.

Step by step: check exposure, enable IP Secure, protect ETS and device programming

This checklist is defensive. Scan only networks and addresses you own or are authorised to test, and coordinate with the building operator before touching a live installation.

Step 1: inventory KNX IP devices on your own network

From a machine on the building LAN, discover KNXnet/IP servers with the open source Calimero tools:

# From a laptop on the building LAN, with the operator's agreement
git clone https://github.com/calimero-project/calimero-tools.git
cd calimero-tools
./gradlew run --args="discover"

Record each responder's IP and MAC address, name, individual address, firmware version and whether it supports tunnelling, routing and IP Secure. A KNX IP interface missing from the ETS project is a finding in itself. Also check servers for software gateways; knxd's README gives TCP port 6720 and /run/knx as its socket defaults:

sudo ss -tulpn | grep -E ':3671|:6720'
systemctl status knxd 2>/dev/null | head -5

Step 2: check whether port 3671 is reachable from the internet

Start with configuration, the authoritative answer:

1. Export port forwarding and NAT rules from every internet router and firewall. Look for UDP or TCP 3671 and for "DMZ host" settings.
2. Check cellular routers installed by integrators for remote service.
3. Use the KNX Association's KNX Security Check, which it says lets you "check your IP address for an insecure KNX installation."

Then confirm from an authorised external host, against your own public address only:

# External host you control; your own public IP only
# UDP can report "open|filtered"; investigate anything not closed
sudo nmap -sU -p 3671 --reason 203.0.113.10
nmap -sT -Pn -p 3671 --reason 203.0.113.10

If anything answers, treat it as an incident: close the forward, save the current device state and review the ETS project for unexpected changes.

Step 3: put KNX IP on its own segment

The KNX Association recommends that you "use a VLAN separation and allow communication between the KNX IP network and other networks only via a suitable firewall." NIST SP 800-82 Rev. 3 gives the same direction for OT generally. A sketch for a Linux firewall (interfaces and addresses are examples):

# nftables sketch: KNX VLAN on knx0, building management VLAN on bms0, WAN on wan0
table inet knx_guard {
  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept
    # Only the ETS workstation and integration server may open tunnels
    iifname "bms0" oifname "knx0" ip saddr { 10.20.0.15, 10.20.0.20 } udp dport 3671 accept
    iifname "bms0" oifname "knx0" ip saddr { 10.20.0.15, 10.20.0.20 } tcp dport 3671 accept
    # Never forward KNXnet/IP from the internet
    iifname "wan0" udp dport 3671 drop
    iifname "wan0" tcp dport 3671 drop
  }
}

Keep routing multicast (224.0.23.12) inside the KNX VLAN.

Step 4: replace open remote access with a VPN

The KNX Association says a VPN for internet access is "an absolute MUST." CISA's advisory says the same for control systems: minimise exposure, keep devices off the internet, put them behind firewalls and use patched VPNs. Terminate the VPN on the firewall and give integrators named, expiring accounts.

Step 5: enable KNX IP Secure in ETS

Following the KNX Association's ETS article:

1. Use ETS 5.7.6 or later, ideally ETS6.
2. Set a project password before adding Secure devices.
3. Add each device's FDSK by scanning its QR code or typing the 32 digit code.
4. In the topology view, set security on the IP backbone or main line to Automatic.
5. On each IP router or interface, enable secure commissioning and set the commissioning password and authentication code.
6. Secure each tunnelling connection with its own strong password, keeping ETS's suggestions.
7. Download, then confirm integrations still connect. If one cannot use IP Secure yet, leave only that tunnel unsecured, restrict it at the firewall to that server, and record the exception with an owner and a date.

Step 6: enable KNX Data Secure where it matters

Set each group address's security to Automatic. Prioritise RF; devices in public areas, where the KNX Association warns that "even a wired KNX system can then be vulnerable to attack"; and window openers, door releases and alarm interfaces. Use a Secure Proxy where a public facing device must reach plain back end devices.

Step 7: set BCU keys and lock down programming

Following ICSA-23-236-01, set the BCU key in every finished project and hand it to the owner. Make sure couplers filter rather than pass everything, and keep USB and IP programming interfaces physically secured and inventoried.

Step 8: protect the ETS project, keyrings and FDSK cards

# Encrypt a dated copy of the ETS project export and keyring before storing it off site
tar -czf knx-project-2026-10-25.tar.gz Building-A.knxproj Building-A.knxkeys
gpg --symmetric --cipher-algo AES256 knx-project-2026-10-25.tar.gz
sha256sum knx-project-2026-10-25.tar.gz.gpg > knx-project-2026-10-25.sha256
shred -u knx-project-2026-10-25.tar.gz

File names are examples; use what your ETS export produces. Keep the passphrase separate, and make sure the building owner holds a copy, not only the integrator. Scan FDSK cards into the same protected store at commissioning and lock the originals away. Test a restore yearly on a clean ETS installation.

Step 9: monitor and inventory the software around KNX

Watch for KNXnet/IP from unexpected sources on the KNX VLAN:

sudo tcpdump -ni knx0 'udp port 3671 or tcp port 3671 or host 224.0.23.12' -c 500

Any tunnel from an address other than the ETS workstation or integration server deserves a question. Then inventory gateway software. Many integrations use open source libraries such as Calimero (Java, which lists KNX IP Secure and Data Secure support) or XKNX (asynchronous Python, Python 3.11 or later per its README):

pip show xknx | grep -E 'Name|Version'
safeguard scan --image registry.example.com/building/knx-gateway:2026.10

Common mistakes

• Port 3671 forwarded to the internet "for remote service" and never removed.
• One flat building network, so routing multicast is visible from office PCs, guest Wi-Fi and cameras.
• Lost FDSK labels, thrown away with the packaging.
• ETS project held only by the integrator, leaving the owner unable to change anything.
• Weak tunnel passwords replacing the ones ETS suggests.
• Mixed groups by accident, where one non Secure object makes a sensitive group plain.
• Couplers left passing all telegrams after troubleshooting.
• No BCU key, as described in ICSA-23-236-01.
• Unlisted cellular routers that bypass the site firewall.
• Assuming wired means safe when a room controller sits in a public corridor.

FAQ

What is KNX used for?

Lighting, blinds, heating, ventilation, air conditioning, metering, access control and audio and video in homes and commercial buildings, with devices from many manufacturers sharing one bus and configured in ETS.

Is KNX the same as EIB?

KNX succeeded EIB, the European Installation Bus launched in 1990. The KNX Association says devices bearing either logo are mutually compatible.

What port does KNX use?

KNXnet/IP uses port 3671 on UDP and TCP, registered with IANA in January 2003 as "efcp." Routing uses the multicast group 224.0.23.12.

How fast is the KNX bus?

KNX TP runs at 9,600 bit/s and KNX PL110 at 1,200 bit/s. That suits switching, dimming and sensor values of a few bytes each.

Is KNX encrypted?

Not by default. KNX Data Secure encrypts and authenticates telegrams on any medium and KNX IP Secure protects KNXnet/IP traffic, both with AES-128 CCM according to the KNX Association, and both must be configured in ETS.

What is the KNX FDSK?

A unique key in each KNX Secure device, printed with the serial number as a QR code. ETS uses it once, then replaces it with a per device tool key. Keep the cards.

What is the difference between KNXnet/IP tunnelling and routing?

Tunnelling connects one client, such as ETS, to one KNX IP interface for programming and access. Routing is connectionless multicast between KNX IP routers acting as couplers over 224.0.23.12.

Can I add KNX Secure to an existing installation?

Partly. IP Secure only needs new KNX IP interfaces and routers. Data Secure needs Secure capable end devices. Mixed installations work per group address, and Secure Proxy couplers can bridge segments.

How do I check whether my KNX installation is exposed to the internet?

Review port forwarding on every router and firewall for 3671, use the KNX Association's KNX Security Check, and confirm with an authorised external scan of your own address. Close anything that answers and move remote access to a VPN.

Where Safeguard fits

Safeguard does not monitor KNX traffic, configure ETS projects, manage KNX Secure keys, inventory devices on a building bus or scan device firmware. None of the steps above depends on it. The honest connection is the software around the building: visualisation servers, integration services, KNX to BACnet or KNX to cloud gateways and analytics jobs that teams build themselves, often on open source libraries such as Calimero or XKNX, and often shipped as container images.

For that software, Safeguard's software composition analysis builds a dependency inventory of your own code, container scanning shows which images carry which package versions, and SBOM generation and analysis records the result in SPDX or CycloneDX. The platform shows which projects contain a given component and version, vulnerability matching and reachability analysis help you decide what to fix first, and policies and gates can stop a build that pulls in a known vulnerable version. When an advisory lands for a KNX library, "which of our gateways still ship the old version" has a quick answer. See using SBOMs to find affected products fast.

Device firmware is different: when the vulnerable code sits inside a KNX IP router or actuator, the fix must come from that manufacturer's firmware release and an ETS download.

KNX gateways, visualisation servers and integration services are built from the same open source packages and base images as any web service, so a vulnerable dependency there is a path toward the building bus. Supply chain hygiene will not fix a KNX device's firmware, but it does cover the software your team builds and deploys next to it.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not KNX monitoring or building network security. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at a KNX gateway or visualisation container image your team builds, the same scan lists the packages and versions inside it and their known vulnerabilities, so you know which images to rebuild after a KNX library advisory.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before any command that changes something, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approval flow applies when you bump a KNX library such as XKNX in a Python integration service.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version, such as a specific Calimero or XKNX release, and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• KNX Association: What makes KNX the secure solution for your smart building?
• KNX Association: KNX Secure, protecting installations from inside and outside
• KNX Association: Configuring KNX Secure systems in ETS
• KNX Association: KNX Technology
• KNX Association: KNX Basics handbook (archived PDF)
• KNX Association: A brief introduction to KNX (archived)
• IANA: port registry, 3671
• IANA: IPv4 multicast address registry
• CISA: ICSA-23-236-01, KNX Protocol
• NVD: CVE-2023-4346
• NIST SP 800-82 Rev. 3
• arXiv 2208.02733: False Data Injection Attack against Building Automation Systems
• arXiv 2206.11786: SVSHI, EPFL
• arXiv 1801.07090: Wireless IoT Protocol Security in the Smart Home Domain
• Calimero project
• Calimero core
• Calimero tools
• knxd
• XKNX
• BACnet Committee (ASHRAE SSPC 135)
• BACnet Secure Connect reference implementation
• Modbus/TCP Security specification (archived PDF)
• DALI Alliance: Introducing DALI
• Connectivity Standards Alliance: Matter

Last reviewed: 25 October 2026. KNX Secure product availability, ETS versions and NIST SP 800-82 are all moving; check the pages above for the versions your installation actually runs.