KNX Data Secure vs KNX IP Secure
Compare KNX Data Secure and KNX IP Secure by protection scope, media, ETS setup, keys, group addresses, and practical building-security use cases.
KNX Data Secure and KNX IP Secure solve different parts of the same security problem. IP Secure protects KNX traffic on the IP transport. Data Secure protects selected KNX data end to end between participating group objects. Many connected buildings need both.
The wrong question is “Which one is better?” The useful question is “Which communication path are we protecting?” Start with the topology and the sensitive functions, then choose the mechanism.
Side-by-side comparison
| Item | KNX IP Secure | KNX Data Secure |
|---|---|---|
| Protection scope | KNXnet/IP communication | KNX application data/telegrams |
| Typical location | IP backbone, IP routing, tunnelling, IP interfaces | Group communication between end devices |
| Supported media | IP | TP, RF, PL, and IP when supported by devices |
| ETS design level | Security of an IP topology segment and IP devices | Security selected on group addresses and supported group objects |
| End-to-end protection | Not beyond the protected IP transport | Yes, between Data Secure-capable endpoints |
| Typical use | Secure IP routing and ETS access | Door command, alarm state, setpoint, or other sensitive function |
| Can coexist with the other? | Yes | Yes |
Both mechanisms provide authentication, integrity, confidentiality, and protection against replay. KNX Secure uses AES-128 CCM-based mechanisms. The important difference is where encryption starts and ends.
How KNX IP Secure works in practice
KNX IP Secure wraps KNX IP communication so unauthorized devices on the LAN cannot simply read or inject valid KNXnet/IP traffic. It is relevant to IP routers, interfaces, and other compatible IP devices.
Consider a building with three KNX TP areas connected by an Ethernet backbone. If the backbone is shared with other systems, the KNX multicast and tunnelling traffic should not remain plain. KNX IP Secure protects that IP leg. The TP telegram below the router is a separate security decision; IP Secure alone does not turn plain TP end devices into Data Secure devices.
ETS applies security rules to the IP topology. In a secured segment, participating IP devices must support the same secure mode. A plain IP router cannot interpret secured traffic. This is why a late product substitution can break the security design even if the replacement is otherwise a valid KNX device.
How KNX Data Secure works in practice
KNX Data Secure is applied to group communication. Every group object linked to a secured group address must support Data Secure. ETS creates and distributes the necessary keys during secured commissioning.
Suppose a hotel room uses a wall switch, room controller, and actuator. The general lighting command may be acceptable as plain communication, while an access-related status or central override is classified as sensitive. Data Secure can be applied to the selected group addresses, provided every linked object supports it.
This granularity is useful, but it requires discipline. One legacy object linked to a secure group address can prevent the group from operating securely. Do not discover that during commissioning; confirm compatible objects in the device application programs before procurement.
FDSK, tool keys, and the ETS project
Every KNX Secure device is supplied with a unique Factory Default Setup Key (FDSK), normally represented in its device certificate. ETS needs this information for the initial secure commissioning. After commissioning, ETS manages device and group keys inside the protected project.
Three handling rules matter on site:
- Scan or record each certificate against the correct physical device before labels are hidden.
- Protect the ETS project with a strong password and include it in the controlled handover process.
- Never photograph a sheet of FDSK codes and leave the image in a general project chat.
The exported ETS project is not merely a drawing file. In a Secure installation it is part of the security system. Losing the final project or its password can turn a routine replacement into a recovery exercise.
Which one should a project use?
| Project condition | Recommended approach |
|---|---|
| KNX IP backbone on a shared corporate LAN | Use compatible KNX IP Secure routers/interfaces and coordinate VLAN/firewall policy |
| Sensitive command crosses TP and IP | Use Data Secure at capable endpoints; also protect the IP transport where applicable |
| ETS connects through the building LAN | Use a Secure-capable interface and controlled engineering access |
| Existing legacy installation | Segment the risk, secure compatible areas, and document every plain boundary |
| Internet-based maintenance | Do not expose KNX ports directly; use controlled remote access plus KNX Secure |
| Small stand-alone TP project with no IP | Data Secure may still be justified for sensitive group communication |
Security classification should be done by function. Exterior access, alarm states, central shutdowns, occupancy data, energy data, and remote overrides do not have the same risk as a bedside reading light.
Remote access: what KNX Secure does not solve by itself
KNX IP Secure is not permission to forward a KNX interface directly to the public internet. Remote maintenance still needs an access architecture: VPN or equivalent controlled channel, named user accounts, multifactor authentication where available, time-limited access, logging, and a process for revoking credentials.
The building LAN also needs ordinary IT controls. Keep automation on an appropriate VLAN, restrict routes, update gateways, disable unused services, and define who owns firewall changes. Encryption cannot compensate for an unmanaged router with a default password.
Commissioning checklist
| Check | Pass evidence |
|---|---|
| Device certificates collected | FDSK records match device serial numbers and locations |
| ETS project protected | Project password stored in the approved credential process |
| Secure topology consistent | No unintended plain IP device remains in a secured segment |
| Secure group addresses valid | Every linked group object supports Data Secure |
| Replacement method tested | Team can reset, replace, and recommission a sample device |
| Remote access controlled | No direct public exposure; access is authenticated and logged |
| Final backup accepted | Owner receives the final ETS export, credentials, and recovery notes |
During testing, capture both a permitted operation and a rejected one. It is not enough to show that a light switches. Demonstrate that an unauthorized or wrongly configured client cannot participate, and document the expected ETS diagnostics when security settings do not match.
Common mistakes seen in design reviews
The most common mistake is a specification that says only “all KNX shall be secure.” That is not testable. It should identify protected IP segments, secured group addresses, device capability, commissioning responsibility, credential ownership, and acceptance evidence.
Another mistake is mixing product generations without checking the application object. A device family may support KNX Secure, while a particular application version or object configuration does not support the intended secure link. Check the actual .knxprod data and product manual.
Finally, projects often protect commissioning but neglect operations. Secure startup, runtime IP protection, and runtime data protection are related but distinct settings. The security report and final ETS project should show what was actually enabled.
FAQ
Can KNX Data Secure and IP Secure be used together?
Yes. A sensitive group telegram can be protected end to end with Data Secure while the KNX IP transport is also protected by IP Secure.
Can a plain KNX device share a project with Secure devices?
Yes, under controlled mixed-operation rules. However, a plain group object cannot communicate on a Data Secure group address, and a plain IP device cannot join a secured IP segment as though it understood encrypted traffic.
What happens if the FDSK is lost?
The recovery path depends on the device and whether the final ETS project is available. Treat device certificates and the ETS backup as controlled handover assets, not packaging material.
Does KNX Secure remove the need for a VPN?
No. KNX Secure protects KNX communication. A VPN or comparable access layer controls how remote users reach the building network in the first place.
Official references
- KNX Association, KNX Security overview
- KNX Association, KNX Data Secure
- KNX Association, KNX Secure devices and FDSK
- KNX Association, Security and mixed operation in ETS
Security is strongest when the topology, devices, ETS project, and access process tell the same story. For a broader introduction, read KNX Secure basics for integrators. For connected-system architecture, see KNX Secure for connected buildings.