Skip to main content

KNX Secure

Classic KNX TP sends telegrams in clear text. On a cable inside a private home that was historically acceptable; for connected buildings, IP-reachable installations, and multi-tenant or commercial sites it is not. KNX Secure is the standard's answer: authentication and encryption on the bus.

You do not configure any of this in KNX Clarity, but you will meet its artefacts — protected .knxproj files and .knxkeys keyrings — so it is worth understanding.

Two layers​

LayerProtectsWhere it applies
KNX IP SecureThe KNXnet/IP tunnel/routingKNX traffic over IP networks
KNX Data SecureThe application telegram itselfEnd-to-end, device to device
  • IP Secure wraps KNX-over-IP so anyone on the LAN cannot read or inject KNX traffic. It secures the transport.
  • Data Secure authenticates and encrypts the actual group communication between devices, so even a compromised segment cannot forge a valid command. It secures the content.

A project can use either, both, or (legacy) neither.

Keys, FDSK and the keyring​

Secure devices ship with a FDSK — Factory Default Setup Key — usually printed on a label/QR on the device. During commissioning, ETS uses the FDSK to take ownership and then assigns the device its operational keys, managed centrally in the project.

When the project is exported, the secure material is written to a keyring file:

project.knxproj     ← topology, devices, parameters, group addresses
project.knxkeys     ← the keyring: device & group keys (separate file)

The keyring is itself password-protected. The .knxproj may also be password-protected as a whole.

No keyring, no control

Without the .knxkeys (and its password) a new integrator cannot re-commission or modify a KNX Secure installation — they would have to factory-reset every secure device and rebuild it. For a secure building, the keyring is as critical as the project file itself.

Why this matters for handovers​

KNX Secure sharpens the exact problem KNX Clarity exists to solve. With an insecure project, a lost file is painful. With a secure project, a lost or withheld keyring can make the installation effectively unmaintainable by anyone but the original integrator — the opposite of what the owner paid for.

So when a project changes hands, a clean handover must include:

  • the latest .knxproj,
  • the matching .knxkeys keyring,
  • and the passwords for both.

This is precisely why KNX Clarity treats the ETS export as a first-class, versioned, auditable asset and models an explicit escrow and transfer flow rather than "email me the files". The platform is the neutral ground where the project — and the right to maintain it — moves with the building, not with whoever last held the laptop.

Handling secrets responsibly

Treat keyrings and project passwords like any other credential. Storing the .knxproj in KNX Clarity makes the engineering durable; the keyring's password should still follow your organisation's secret -handling policy, not live in a comment field. See Settings → Security.