Una cerradura conectada puede abrir la puerta de tu casa.
Una cámara puede mostrar imágenes del interior.
Un termostato puede hablar con Internet todos los días sin que nadie se pregunte qué ocurre si aparece un fallo de seguridad.
Hasta ahora, para muchos consumidores la respuesta dependía de esperar una actualización y confiar en que el fabricante supiera lo que hacía.
La Unión Europea quiere cambiar esa relación.
Desde el 11 de septiembre de 2026 ya se aplican las obligaciones de notificación de determinados problemas de ciberseguridad del Cyber Resilience Act (CRA). ENISA mantiene ya operativa la plataforma creada para gestionarlas: la SRP entró en servicio el 11 de septiembre, fue actualizada a la versión 1.1 el 12 de octubre y sus preguntas frecuentes se actualizaron el 15 de octubre.
La idea central se entiende rápidamente: cuando un fabricante conoce un problema de seguridad especialmente grave, no puede limitarse a tratarlo como un asunto interno sin plazos de comunicación.
Pero el titular de las 24 horas necesita una explicación.
Qué empieza a contar desde 24 horas
El reglamento establece un primer aviso dentro de las 24 horas desde que el fabricante tiene conocimiento de una vulnerabilidad activamente explotada o de un incidente grave que afecte a la seguridad de su producto digital.
Después debe enviar una notificación más completa dentro de las 72 horas desde ese conocimiento.
En vulnerabilidades explotadas, el informe final se presenta como máximo 14 días después de estar disponible una medida correctora o de mitigación.
Para incidentes graves, el informe final se remite dentro del mes siguiente a la notificación de 72 horas.
Es importante fijarse en la palabra notificación.
La ley no dice que cualquier dispositivo vulnerable tenga que estar completamente reparado 24 horas después de que alguien encuentre un fallo.
Esos primeros plazos se refieren a comunicar información a las autoridades competentes.
Confundir aviso con solución generaría expectativas incorrectas sobre lo que ya protege al consumidor.
No cualquier error activa el cronómetro
Imagina que un investigador descubre una debilidad en una cámara, pero nadie ha observado todavía que un atacante la utilice.
Esa situación puede requerir análisis, corrección y gestión de vulnerabilidades.
Sin embargo, la obligación de informar de una vulnerabilidad activamente explotada tiene un criterio más concreto: que exista evidencia fiable de aprovechamiento malicioso real.
Además, el CRA exige notificar incidentes graves que afecten a la seguridad de productos digitales, según las condiciones del propio reglamento.
Por tanto, hay dos vías de notificación.
No basta con que un usuario diga que la aplicación va lenta.
Y no hace falta esperar a que todo el problema esté resuelto si el fabricante ya sabe que se ha producido uno de los supuestos regulados.
Es una diferencia esencial entre gestionar un fallo ordinario y activar una comunicación de ciberseguridad obligatoria.
Ilustración conceptual · Muyrecomendados
¿A quién tiene que avisar el fabricante?
La respuesta tampoco es «a todos los gobiernos por separado».
ENISA ha puesto en funcionamiento una plataforma única de notificaciones, denominada Single Reporting Platform (SRP).
El fabricante presenta la información seleccionando el equipo nacional de respuesta a incidentes de seguridad designado como coordinador, conocido como CSIRT.
La información llega al organismo coordinador y, por regla general, también a ENISA, con un sistema de distribución para otros Estados miembros afectados.
Existen circunstancias excepcionales en las que la difusión puede aplazarse por razones justificadas de ciberseguridad.
Para el consumidor esto tiene una consecuencia interesante: un incidente en un producto vendido en varios países puede coordinarse a escala europea sin depender de procesos nacionales completamente desconectados.
No es lo mismo que publicar inmediatamente todos los detalles técnicos del ataque en abierto.
La comunicación debe equilibrar información, respuesta y riesgo.
Qué pasa con tu vivienda inteligente
Pensemos en una instalación real.
En la misma casa puede haber videoportero, cerradura, sensores inalámbricos, router, televisor, control de iluminación y climatización.
Aunque todos parezcan parte de una única vivienda inteligente, pueden pertenecer a fabricantes y ciclos de actualización completamente diferentes.
Si se detecta un problema en un componente utilizado por varios productos, averiguar quién debe investigarlo y notificarlo no siempre es sencillo.
El propio ENISA aborda en sus preguntas frecuentes la cuestión de los componentes de terceros y remite a las aclaraciones de la Comisión sobre cuándo debe reportar el fabricante final.
La nueva exigencia no convierte a cada instalador doméstico automáticamente en responsable de presentar una notificación CRA por cada dispositivo que monta.
La obligación depende del papel jurídico concreto de cada operador económico y de si actúa como fabricante de un producto comprendido en el reglamento.
No conviene confundir fabricante, distribuidor, integrador o usuario.
Pero sí obliga a toda la cadena a tomarse mucho más en serio la trazabilidad de componentes y la capacidad de responder ante incidentes.
Ilustración conceptual · Muyrecomendados
¿También afecta a los dispositivos que ya tengo?
Aquí hay un matiz que merece atención.
Según las aclaraciones de ENISA sobre la aplicación del reglamento, las obligaciones de notificación pueden alcanzar también a productos digitales dentro del ámbito del CRA que ya estaban comercializados antes de diciembre de 2027.
Eso no significa que se aplique retroactivamente cada una de las demás obligaciones técnicas a todos los aparatos antiguos.
Tampoco obliga a comunicar ahora cualquier explotación conocida antes del 11 de septiembre de 2026; el momento en que el fabricante adquiere conocimiento y los supuestos legales son relevantes.
En otras palabras: la fecha de entrada de las obligaciones de notificación es distinta de la fecha de aplicación general de buena parte del reglamento.
La aplicación general principal del CRA comienza el 11 de diciembre de 2027, mientras que el régimen de avisos ya está en marcha.
Y las obligaciones de notificación para determinados responsables de software libre incluidos expresamente en la norma siguen su propio calendario.
Lo que todavía no ha cambiado
¿Significa todo esto que una cerradura inteligente vendida hoy en España ya cuenta con años garantizados de actualizaciones por esta nueva obligación de aviso?
No.
Los requisitos de diseño seguro, gestión de vulnerabilidades y soporte se integran en un régimen más amplio con fases de aplicación diferenciadas.
Una obligación de comunicar un incidente no se confunde con una certificación completa del producto.
Tampoco acredita que todos los dispositivos conectados tengan el mismo nivel de protección o que las aplicaciones y servicios del fabricante sean infalibles.
Y, como señala la documentación de ENISA, en el lanzamiento inicial la plataforma SRP no ofrece una API pública para automatizar envíos; la información debe presentarse mediante su interfaz.
Para fabricantes con muchos productos, eso añade un reto organizativo real.
Por qué debería importarte aunque no fabriques nada
Cuando compramos un equipo domótico solemos comparar precio, diseño, aplicaciones y compatibilidad.
La seguridad aparece mucho más abajo en la lista.
Sin embargo, un producto que controla un acceso o permanece conectado durante años necesita una respuesta fiable cuando falla.
La pregunta interesante no es solo «¿funciona con Matter?» o «¿se conecta por Zigbee?».
También es: ¿quién responde cuando se descubre un problema y cuánto tarda en reaccionar?
Con el CRA, Europa está empezando a convertir esa responsabilidad en procesos verificables y plazos legales.
No es una garantía de cero incidentes. Ningún reglamento puede prometer eso.
Pero cambia el incentivo para fabricantes: detectar, coordinar y notificar dejan de ser tareas opcionales cuando se cumplen las condiciones de la norma.
La seguridad de una casa conectada también depende de lo que sucede después de descubrir un fallo.