KNX Secure
KNX Secure provides specific protection for KNX communication. Check the secure mode, device support, key management and commissioning process used on the site.
Sources and scopeChecked 29 September 2026
Former checklist URL disposition and replacement guidance scope only
Detailed algorithms, telegram formats, commissioning sequences, and certification requirements remain normative KNX specification material.
On this page
Overview#
KNX Secure has two complementary scopes. KNX IP Secure protects KNXnet/IP communication between IP endpoints. KNX Data Secure protects selected KNX group/object data across supported media so protection can survive routers. KNX Association describes AES 128 CCM based confidentiality and integrity and identifies KNX IP Secure as standardised in ISO 22510.12
Using one doesn't imply the other. An IP secured backbone can still carry unprotected application telegrams onto a field segment, while Data Secure doesn't automatically protect device web interfaces, ETS tunnelling, or unrelated management traffic.
Commissioning trust#
Secure commissioning depends on authentic device bootstrap information, the approved ETS project, and its generated keyring. Factory Device Setup Keys (FDSKs) and project keys are secrets, not asset labels. Capture them through an authorised process, restrict export, avoid screenshots/logging, and record which project/keyring version was deployed.
Operational design must cover:
- unique device enrolment and replacement rather than shared fleet secrets;
- group security assignment and the impact of one group member compromise;
- sequence/freshness state across reboot, restore, cloning, and device replacement;
- keyring backup, recovery, rotation, revocation, and technician offboarding;
- mixed secure/unsecure devices and explicit downgrade prevention;
- audit of project changes, secure mode changes, key export, and commissioning access.
Don't reset secure state or reprogram a live device simply to recover sequence synchronisation. Follow the exact ETS and product recovery procedure under change control; incorrect recovery can make legitimate telegrams fail or reintroduce old trust material.
Gateway design#
A gateway decrypting secure KNX and publishing plaintext to another API terminates the security boundary. Authenticate and authorise the downstream consumer, protect cached values and keys, and label the export as derived, not end to end KNX Secure. Conversely, a generic VPN doesn't turn endpoints into KNX IP Secure devices or provide group level Data Secure semantics.
Verification boundary#
Confirm the precise product certification, firmware, supported secure roles, ETS version, DPT/group configuration, keyring, time/sequence behaviour, and fallback settings. Test enrolment, rotation, replacement, rollback, outage, and mixed mode rejection only in a controlled project environment.
Primary sources#
- KNX Association, KNX Data Secure
- KNX Association, configuring KNX Secure with ETS
- KNX Association, installation security guidance. The former checklist PDF URL redirects to the generic website; obtain the current checklist through KNX before using it as acceptance evidence.