KNX Secure: la evolución necesaria de la ciberseguridad en las instalaciones KNX
Una instalación KNX ya no es un bus aislado: cuando sus comunicaciones viajan sobre IP forman parte de la superficie de ataque del edificio. Analizamos qué aporta KNX Secure, qué relación tiene con IEC 62443, NIS2, el ENS y el CRA, y cuándo es técnicamente justificable exigirlo.
De bus de automatización a sistema de control conectado
Durante años, las instalaciones KNX han disfrutado de una característica que ha contribuido decisivamente a su éxito: la robustez y sencillez de un sistema de automatización distribuido, diseñado originalmente para controlar las funciones de un edificio mediante una red específica de automatización. Sin embargo, la evolución hacia arquitecturas cada vez más conectadas ha cambiado sustancialmente este escenario.
Hoy es habitual que una instalación KNX no funcione como un sistema aislado. Controladores y dispositivos KNX se integran con plataformas BMS, sistemas de gestión energética, redes corporativas, servicios cloud, aplicaciones móviles y sistemas de mantenimiento remoto. Para facilitar esta integración, KNX amplió su alcance con KNXnet/IP, que transporta las comunicaciones KNX sobre redes Ethernet/IP convencionales.
Esta evolución aporta enormes ventajas en interoperabilidad, supervisión y explotación de las instalaciones, pero introduce también una nueva superficie de ataque. Un telegrama KNX que antes circulaba exclusivamente por un bus de automatización puede ahora atravesar una infraestructura IP compartida con otros sistemas. La seguridad de la red de automatización deja de depender únicamente de la seguridad física del bus y pasa a depender también de la arquitectura y las medidas de protección de la red IP.
La cuestión ya no es solo si una instalación KNX funciona correctamente, sino si podemos confiar en quién envía una orden, si el mensaje ha sido modificado durante su transmisión y si un tercero podría reproducir o inyectar comunicaciones en la instalación.
Un marco regulatorio que exige proporcionalidad
Esta transformación coincide con una evolución significativa del marco regulatorio europeo. Normativas como NIS2, el Esquema Nacional de Seguridad y los nuevos requisitos europeos de ciberresiliencia consolidan un principio común: los sistemas conectados deben incorporar medidas de seguridad proporcionales a los riesgos que gestionan. En la automatización de edificios, este principio alcanza progresivamente a sistemas que tradicionalmente se consideraban instalaciones técnicas y que hoy forman parte de ecosistemas digitales mucho más amplios.
En este contexto aparece KNX Secure, la extensión de seguridad de KNX diseñada para proteger sus comunicaciones. Su objetivo no es sustituir la arquitectura KNX ni convertirla en una infraestructura de seguridad independiente, sino incorporar mecanismos criptográficos que protejan las comunicaciones frente a amenazas. Y plantea una pregunta clave para instalaciones existentes y nuevos proyectos: ¿cuándo es suficiente KNX convencional y cuándo debemos exigir KNX Secure?
La respuesta no está en una versión concreta de KNX ni en la afirmación genérica de que "todo KNX debe ser seguro", sino en un análisis de la arquitectura, de los activos controlados, de las posibles amenazas y, especialmente, del nivel de exposición de la red de automatización.
Conexión de sistemas sobre infraestructura IP
La interconexión de la instalación de automatización y control con terceros sistemas —BMS, gestores de energía o servidores de monitorización— requiere por lo general KNXnet/IP como medio de comunicación entre las líneas KNX y dichas interfaces. La norma ISO 22510:2019 (KNXnet/IP communication) define su uso para integrar KNX sobre redes IP.
Al usar IP como transporte, las comunicaciones KNX dejan de estar confinadas al par trenzado (KNX TP) y pasan a una infraestructura que puede estar compartida con otros sistemas y, según la arquitectura, ser accesible desde redes corporativas o externas. Por ello, a efectos de ciberseguridad la instalación debe tratarse como un sistema de control conectado a una red IP, no como un bus aislado. Es especialmente relevante cuando la red KNX/IP comparte infraestructura Ethernet con:
- Red corporativa y servidores.
- Sistemas BMS, SCADA y de gestión energética.
- Mantenimiento remoto y plataformas cloud.
- Dispositivos IoT y redes Wi-Fi.
- Sistemas de seguridad y control de accesos.
- Otros sistemas de automatización.
El riesgo de KNXnet/IP convencional
Al igual que el resto de protocolos usados en gestión técnica de edificios, KNXnet/IP no ofrece autenticación, integridad ni confidencialidad. Cualquier equipo con alcance IP a la red KNX podría leer y enviar telegramas:
Sin autenticación
Cualquier equipo que alcance la interfaz por IP puede abrir un túnel y actuar como herramienta de puesta en marcha o cliente de supervisión.
Multicast abierto
Los routers KNX IP aceptan cualquier telegrama multicast recibido en la dirección de routing. Un equipo en la misma red o VLAN puede inyectar telegramas en todas las líneas.
Sin protección
Un telegrama capturado puede reenviarse más tarde con el mismo efecto.
Tráfico en claro
Estados, consignas y direcciones de grupo son legibles, lo que facilita el reconocimiento de la instalación.
Como KNX actúa sobre equipos físicos, una manipulación de las comunicaciones tiene efectos directos sobre el edificio:
- Modificación de consignas y horarios de climatización y ventilación.
- Accionamiento no autorizado de iluminación, persianas o compuertas.
- Alteración del estado de equipos y de las estrategias de eficiencia energética.
- Interferencia con sistemas integrados, como el control de accesos.
Por tanto, la seguridad de la red IP es también seguridad de la infraestructura física controlada por KNX.
KNX Secure: alcance y límites
KNX Secure es la medida técnica adecuada para proteger las comunicaciones KNX, al tratarse de un mecanismo normalizado y abierto. Sin embargo, ninguna norma vigente lo exige de forma literal: su exigencia se deriva del análisis de riesgos y de las obligaciones generales de seguridad de la normativa aplicable. Presenta tres componentes con alcances distintos que deben analizarse por separado en cada proyecto:
| Mecanismo | Qué protege | Qué no protege |
|---|---|---|
| KNX IP Secure — tunnelling | Sesión unicast entre cliente e interfaz: autenticación del cliente con contraseña por túnel, intercambio de claves de sesión, integridad, cifrado y protección frente a repetición. | El tramo TP detrás de la interfaz. |
| KNX IP Secure — routing | Tráfico multicast entre routers KNX IP: clave de backbone compartida, integridad, cifrado y protección frente a repetición basada en sincronización temporal. | El tramo TP de cada línea; equipos que conozcan la clave de backbone. |
| KNX Data Secure | Telegramas de extremo a extremo entre dispositivos en cualquier medio (TP, IP, RF): autenticación, integridad y cifrado a nivel de aplicación. | Disponibilidad; telegramas de dispositivos no configurados como seguros. |
De ello se derivan tres consecuencias para el diseño de una instalación:
KNX IP Secure solo protege el tramo IP
Un atacante con acceso físico a una línea TP (por ejemplo, un pulsador en zona pública) puede seguir inyectando telegramas en esa línea. Para funciones sensibles debe evaluarse KNX Data Secure.
Ningún mecanismo garantiza la disponibilidad
No protegen frente a saturación de red, tormentas multicast ni denegación de servicio. La disponibilidad depende de la segmentación, el control de tráfico y la calidad de la red.
La protección es tan fuerte como el eslabón no seguro
Un único túnel convencional habilitado, por ejemplo, para un BMS que no soporta IP Secure, anula la protección del segmento.
Marcos técnicos y normativos de referencia
La aplicación de KNX Secure da soporte al cumplimiento de los requisitos de seguridad de distintos marcos normativos. Por ello, la decisión de usarlo —y los ajustes necesarios para su aplicación— deben tomarse en función del marco que requiera cada proyecto.
IEC 62443: el marco técnico de referencia
La serie IEC 62443 es la referencia técnica para la seguridad de sistemas de automatización y control, y sirve de base a este criterio con independencia de que el cliente esté sujeto a NIS2 o al ENS. Su modelo de zonas y conductos se aplica directamente a la instalación:
- Zonas: agrupaciones de activos con requisitos de seguridad comunes. Cada línea de campo KNX TP, el backbone KNX/IP, la zona de supervisión (BMS/SCADA) y la red corporativa pueden interpretarse como zonas.
- Conductos: canales de comunicación entre zonas, como el enlace entre el backbone KNX/IP y el BMS o el acceso remoto de mantenimiento.
- Nivel de seguridad objetivo (SL-T): se asigna a cada zona y conducto según el análisis de riesgos (IEC 62443-3-2) y determina los requisitos técnicos del sistema (IEC 62443-3-3).
En este marco, KNX IP Secure aporta la integridad y la confidencialidad (requisitos FR 3 y FR 4) en los conductos KNX/IP, mientras que el firewall y la segmentación implementan el flujo restringido de datos entre zonas (FR 5).
Directiva (UE) 2022/2555 (NIS2)
NIS2 no menciona KNX Secure, pero su artículo 21 obliga a las entidades esenciales e importantes a adoptar medidas técnicas proporcionadas para gestionar los riesgos de las redes y sistemas que utilizan, incluidos los de control del edificio. Las medidas del artículo 21.2 relevantes para KNX/IP son:
- a) Políticas de análisis de riesgos y de seguridad de los sistemas de información.
- d) Seguridad de la cadena de suministro, incluidos integradores y mantenedores.
- e) Seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, incluida la gestión de vulnerabilidades.
- h) Políticas y procedimientos de uso de criptografía y, en su caso, cifrado.
- i) Control de acceso y gestión de activos.
- j) Autenticación multifactor y comunicaciones seguras cuando proceda.
El apartado h) es el anclaje directo de KNX Secure como medida criptográfica. Además, el enfoque all-hazards de la Directiva incluye el entorno físico, lo que refuerza la relevancia de los efectos físicos de una manipulación. La obligación alcanza tanto a sistemas mantenidos internamente como externalizados: la red KNX/IP debe incluirse en el análisis de riesgos aunque la opere un tercero.
Esquema Nacional de Seguridad (RD 311/2022)
Si el sistema de automatización forma parte de un sistema sujeto al ENS, las medidas de protección de las comunicaciones del Anexo II aplican a la red KNX/IP, y KNX Secure es la forma técnica de cumplirlas en ese tramo.
El primer paso es justificar el ámbito: el sistema de automatización está dentro del alcance cuando soporta servicios prestados por la entidad pública, comparte infraestructura con sus sistemas de información o se integra en ellos (BMS, SCADA, control de accesos, red corporativa). Esta inclusión debe constar en la declaración de aplicabilidad.
Son aplicables los principios básicos del Capítulo II —seguridad integral, gestión basada en riesgos, prevención, detección, respuesta y conservación, líneas de defensa y vigilancia continua— y los requisitos mínimos del Capítulo III: análisis y gestión de riesgos (art. 13), autorización y control de accesos (art. 16), mínimo privilegio (art. 19), protección de la información almacenada y en tránsito con especial atención a redes abiertas (art. 21) y prevención ante sistemas interconectados con control de los puntos de unión (art. 22).
| Medida (Anexo II) | Contenido | Implementación en la instalación |
|---|---|---|
| mp.com.1 | Perímetro seguro | Firewall entre la red de automatización y otras redes |
| mp.com.2 | Protección de la confidencialidad | Cifrado KNX Secure en el tramo IP |
| mp.com.3 | Protección de la autenticidad y de la integridad | Autenticación de túneles y routing seguro con KNX Secure |
| mp.com.4 | Separación de flujos de información en la red | VLAN específica de automatización y ACL |
| op.acc | Control de acceso | Contraseñas por túnel, control de acceso a ETS e interfaces |
Su exigibilidad depende de la categoría del sistema (básica, media o alta) y de sus refuerzos. En consecuencia, mantener KNX/IP convencional en un sistema sujeto al ENS requiere una justificación expresa en el análisis de riesgos.
Reglamento (UE) 2024/2847 (CRA) y Directiva de equipos radioeléctricos
El CRA obliga a los fabricantes, no al instalador, pero fija el principio de seguridad desde el diseño y por defecto que debe guiar nuevas instalaciones y renovaciones importantes. Las fechas de aplicación previstas son:
- 11 de septiembre de 2026 (ya en vigor): obligaciones de notificación de vulnerabilidades explotadas activamente e incidentes graves.
- 11 de diciembre de 2027: aplicación general, incluidos los requisitos esenciales del Anexo I.
El Anexo I exige, entre otros, configuración segura por defecto y protección de la confidencialidad e integridad de los datos transmitidos, incluido el cifrado. Los productos KNX que salgan al mercado desde diciembre de 2027 deberán cumplirlos, lo que refuerza la elección de dispositivos compatibles con KNX Secure en las instalaciones que hoy se diseñan.
Para equipos con componente radio (interfaces Wi-Fi o KNX RF), el Reglamento Delegado (UE) 2022/30 de la Directiva 2014/53/UE aplica requisitos de ciberseguridad desde el 1 de agosto de 2025, con la serie EN 18031 como normas armonizadas.
Criterio técnico de diseño
¿Qué criterios de seguridad debemos seguir al diseñar una infraestructura de control conectada? En nuevas instalaciones y modificaciones sustanciales, KNX Secure es obligatorio en toda red KNX/IP que no sea física y exclusivamente de automatización.
La propia KNX Association recomienda revisar la exposición de la parte IP de las instalaciones existentes, considerar KNX Secure al sustituir interfaces, actualizar el backbone o realizar una revisión de seguridad y, bajo ningún concepto, exponer KNX/IP directamente a Internet.
La siguiente tabla cruza topología de red y criticidad para facilitar la evaluación de riesgos. Si una instalación encaja en varias opciones, prevalece la más exigente.
| Topología | Criticidad baja | Criticidad media (NIS2, ENS básica o media) | Criticidad alta (ENS alta, infraestructura crítica) |
|---|---|---|---|
| KNX TP sin tramo IP | IP Secure no aplica; Data Secure a evaluar | Data Secure a evaluar | Data Secure obligatorio en funciones sensibles |
| KNX/IP en red física aislada, dedicada y controlada | Evaluar en el análisis de riesgos | IP Secure recomendado | IP Secure obligatorio |
| KNX/IP en VLAN o red compartida con otros sistemas | IP Secure obligatorio | IP Secure obligatorio | IP Secure obligatorio; Data Secure en funciones sensibles |
| KNX/IP conectado a BMS, SCADA o red IT | IP Secure obligatorio, también en los clientes de integración | IP Secure obligatorio, también en los clientes de integración | IP Secure obligatorio; Data Secure en funciones sensibles |
| KNX/IP con acceso remoto | IP Secure obligatorio + VPN | IP Secure obligatorio + VPN con autenticación multifactor | IP Secure obligatorio + VPN con autenticación multifactor y registro de sesiones |
| KNX/IP accesible desde Internet sin VPN | Prohibido | Prohibido | Prohibido |
Defensa en profundidad
KNX Secure protege la comunicación KNX sobre IP, pero no sustituye a otras medidas de seguridad como el firewall, la segmentación o el acceso remoto seguro. La arquitectura exigida combina varias capas, y cada una limita lo que puede hacer un atacante que haya superado la anterior:
Medidas exigibles junto con KNX Secure
Segmentación
VLAN o red específica de automatización, sin tráfico de otros sistemas.
Control de tráfico
Firewall o ACL que solo permita los flujos necesarios, incluida la gestión de multicast (IGMP) del routing KNX.
Sin exposición a Internet
Prohibido publicar el puerto KNXnet/IP (UDP 3671) o cualquier interfaz KNX.
Acceso remoto
Solo mediante VPN o mecanismo equivalente, con autenticación robusta.
Modo exclusivamente seguro
Interfaces y routers configurados para rechazar túneles y routing no seguros.
Clientes de integración compatibles
Todo SCADA, BMS, pasarela o visualización debe soportar KNX IP Secure; no se admite un túnel no seguro para ningún cliente.
Gestión de claves
Custodia del proyecto ETS, del fichero de claves (keyring), de los certificados de dispositivo (FDSK) y de las contraseñas de túnel y de puesta en marcha, con entrega a la propiedad en la recepción.
Control de acceso a ETS e interfaces
Contraseña de proyecto, cuentas nominales y mínimo privilegio.
Inventario
Registro de dispositivos KNX/IP, direcciones IP, direcciones individuales, versión de firmware y estado de seguridad.
Actualizaciones y vulnerabilidades
Procedimiento de seguimiento de avisos del fabricante y actualización de firmware.
Sincronización horaria
El routing seguro se protege frente a repetición con un temporizador sincronizado entre routers; la latencia de la red debe ser compatible con la tolerancia configurada.
Registro y monitorización
Registro de eventos y de sesiones de acceso cuando la arquitectura lo permita.
Conclusiones: KNX Secure por defecto, excepciones justificadas
Siempre que diseñemos una infraestructura de control integrada en una red KNX/IP, debemos plantear KNX Secure como obligatorio por defecto y admitir excepciones únicamente mediante un análisis de riesgos documentado y aprobado. Los requisitos de ciberseguridad de las comunicaciones se basarán en estos principios:
Las comunicaciones KNXnet/IP se diseñarán considerando la infraestructura IP como parte de la superficie de ataque del edificio, conforme a la gestión de riesgos de la normativa aplicable: NIS2 y su transposición, el ENS (RD 311/2022) y la normativa sectorial, cuando proceda.
Todas las comunicaciones KNX sobre IP utilizarán KNX Secure o un mecanismo equivalente que garantice autenticación, integridad, confidencialidad y protección frente a repetición, tanto en tunnelling como en routing.
Se considera equivalente el mecanismo que proporcione, como mínimo, autenticación de los extremos, cifrado no inferior a AES-128 y protección frente a repetición, y que sea interoperable con los dispositivos KNX de la instalación.
Solo se admitirá KNXnet/IP convencional en redes física y exclusivamente dedicadas a automatización, sin conexión con otras redes, y cuando el análisis de riesgos lo justifique.
Interfaces y routers KNX IP en modo exclusivamente seguro. Todo sistema integrado (SCADA, BMS, pasarelas, visualización) deberá soportar KNX IP Secure; no se aceptará ningún túnel no seguro.
En las funciones definidas como sensibles se evaluará KNX Data Secure extremo a extremo, y se aplicará cuando la criticidad sea alta.
KNX Secure se complementará con segmentación, firewall, control de acceso y acceso remoto por VPN. Queda prohibida la exposición directa de cualquier interfaz KNXnet/IP a Internet.
El proyecto ETS incluirá el fichero de claves, los certificados de dispositivo (FDSK), las contraseñas de túnel y de puesta en marcha y el inventario de dispositivos.
Como mínimo: captura de tráfico que demuestre que los telegramas KNX sobre IP viajan cifrados; prueba de rechazo de un túnel sin credenciales y de routing no seguro; comprobación de que ningún puerto KNXnet/IP es accesible desde fuera de la red de automatización; y revisión de la documentación del punto 8.
Mantener KNXnet/IP convencional deberá justificarse con un análisis de riesgos documentado. Al sustituir interfaces, routers o acopladores, ampliar el backbone IP o modificar sustancialmente las comunicaciones, se migrará a dispositivos compatibles con KNX Secure, salvo justificación aprobada.
Normativa de referencia
| Norma | Relación con KNX Secure |
|---|---|
| ISO/IEC 27001:2022 | Marco de gestión de la seguridad de la información en el que se integra el análisis de riesgos de la instalación. |
| IEC 62443 | Modelo de zonas y conductos; KNX IP Secure cubre FR 3 y FR 4 en los conductos KNX/IP. |
| Directiva (UE) 2022/2555 (NIS2) | Art. 21.2 h): uso de criptografía y cifrado como medida técnica proporcionada. |
| ENS (RD 311/2022) | Medidas mp.com.1–4 y op.acc del Anexo II aplicables a la red KNX/IP. |
| Reglamento (UE) 2024/2847 (CRA) y Directiva 2014/53/UE | Seguridad desde el diseño y por defecto en los productos; requisitos para equipos radio. |
| KNX Specifications, Vol. 3 · ISO 22510:2019 | Especificación del sistema KNX y de la comunicación KNXnet/IP. |
Preguntas frecuentes sobre KNX Secure
¿Es obligatorio KNX Secure por ley?
Ninguna norma vigente lo exige de forma literal. Su exigencia se deriva del análisis de riesgos y de las obligaciones generales de seguridad de NIS2, el ENS o IEC 62443. En la práctica, en un sistema sujeto al ENS, mantener KNX/IP convencional requiere una justificación expresa.
¿Qué diferencia hay entre KNX IP Secure y KNX Data Secure?
KNX IP Secure protege el tramo IP (tunnelling entre cliente e interfaz y routing entre routers KNX IP). KNX Data Secure protege los telegramas de extremo a extremo entre dispositivos en cualquier medio (TP, IP o RF), incluida la línea de campo.
¿Basta con KNX IP Secure para proteger toda la instalación?
No. Solo protege el tramo IP: un atacante con acceso físico a una línea TP puede seguir inyectando telegramas. Además, ningún mecanismo KNX Secure garantiza la disponibilidad, que depende de la segmentación, el control de tráfico y la calidad de la red.
¿Puedo mantener un túnel convencional para un BMS que no soporta IP Secure?
No es recomendable: un único túnel convencional anula la protección del segmento. El criterio es que todo SCADA, BMS, pasarela o visualización soporte KNX IP Secure.
¿Qué hago con una instalación KNX existente sin KNX Secure?
Documentar un análisis de riesgos que justifique su permanencia y migrar a dispositivos compatibles con KNX Secure al sustituir interfaces, routers o acopladores, ampliar el backbone IP o modificar sustancialmente las comunicaciones.
La pregunta ya no es si tu instalación KNX está conectada.
Es si puedes confiar en cada orden que recibe. Descubre cómo diseñamos infraestructuras de control seguras en NECHI GROUP.