Reglamento de Ciberresiliencia: qué te obliga si vendes software
Si tu empresa vende un programa, una aplicación o un aparato que se conecta a internet, el Reglamento de Ciberresiliencia te va a obligar a diseñarlo de forma segura, a dar actualizaciones durante años y a avisar en 24 horas cuando alguien esté aprovechando un fallo de tu producto. Es el Reglamento (UE) 2024/2847, conocido también como Cyber Resilience Act. Su aplicación general llega el 11 de diciembre de 2027, pero la parte de notificación ya está en vigor desde el 11 de septiembre de 2026, así que no es una norma del futuro: es una norma que ya te afecta si has puesto producto en el mercado europeo.
A qué productos se aplica y a cuáles no
El reglamento habla de «productos con elementos digitales», y su artículo 2 fija el criterio: se aplica a los productos comercializados cuya finalidad prevista o uso razonablemente previsible incluya una conexión de datos, directa o indirecta, lógica o física, a un dispositivo o red. En la práctica, eso abarca programas que vendes o licencias, aplicaciones móviles, firmware, componentes de software que se comercializan por separado y aparatos conectados de cualquier tipo.
Queda fuera lo que ya regula otra norma europea específica: los productos sanitarios, los vehículos de motor, el material aeronáutico certificado y los equipos marinos. Y hay una exclusión que importa a muchas empresas españolas: los proyectos de código abierto. Quien mantiene una comunidad de software libre sin actuar como fabricante no asume las obligaciones del reglamento, y precisamente por eso no puede colocar el marcado CE en lo que desarrolla.
Si lo que vendes es un servicio web o un SaaS, lee esto antes de alarmarte
Es la duda más repetida y el reglamento la resuelve con bastante claridad. Un servicio en la nube solo entra en el ámbito de esta norma si encaja en la definición de «tratamiento de datos a distancia»: aquel que el fabricante ha diseñado y desarrollado, o se ha hecho bajo su responsabilidad, y cuya ausencia impediría que el producto cumpliera alguna de sus funciones. El ejemplo que da el propio reglamento es nítido: la función en la nube que permite controlar a distancia un dispositivo del hogar inteligente sí está dentro.
En cambio, los sitios web que no sostienen la funcionalidad de un producto y los servicios en la nube diseñados y desarrollados fuera de la responsabilidad del fabricante de un producto quedan fuera del Reglamento de Ciberresiliencia. Ojo: fuera de esta norma, no fuera de toda obligación. A los servicios en la nube, incluido el software como servicio, se les aplica la Directiva NIS2 cuando la entidad que los presta alcanza el tamaño que esa directiva fija.
Dicho de forma práctica: si vendes una plataforma a la que tus clientes acceden con navegador y nada más, tu marco es NIS2. Si vendes un aparato, una aplicación instalable o un programa con una parte en la nube sin la cual no funciona, tu marco es el Reglamento de Ciberresiliencia.
El calendario, con las fechas del texto oficial
| Fecha | Qué ocurre |
|---|---|
| 11 de junio de 2026 | Es aplicable el capítulo IV (artículos 35 a 51): la parte de los organismos de evaluación de la conformidad |
| 11 de septiembre de 2026 | Es aplicable el artículo 14: obligación de notificar vulnerabilidades aprovechadas activamente e incidentes graves |
| 11 de diciembre de 2027 | Aplicación general del reglamento: requisitos de ciberseguridad, documentación y marcado |
Hay un matiz que conviene entender bien. Los productos introducidos en el mercado antes del 11 de diciembre de 2027 solo quedan sujetos a los requisitos del reglamento si, a partir de esa fecha, sufren una modificación sustancial. Es decir: lo que ya has vendido no tienes que rehacerlo, pero en cuanto le metas un cambio de fondo, entra. Y eso, en software, llega antes de lo que parece.
La obligación que ya está en vigor: avisar en 24 horas
El artículo 14 es el que más cerca tienes. Obliga al fabricante a notificar simultáneamente al CSIRT designado como coordinador y a la Agencia de la Unión Europea para la Ciberseguridad cualquier vulnerabilidad de su producto que esté siendo aprovechada activamente, a través de la plataforma única de notificación prevista en el artículo 16. El primer aviso —la notificación de alerta temprana— debe presentarse sin demora indebida y, en todo caso, dentro de las 24 horas desde que el fabricante tiene conocimiento de la vulnerabilidad, indicando en qué Estados miembros sabe que se ha comercializado el producto. Después vienen las notificaciones de seguimiento con la información completa.
Veinticuatro horas es poco tiempo para improvisar. Significa que necesitas decidido de antemano quién recibe los avisos de seguridad, quién valora si la vulnerabilidad se está explotando, quién firma la notificación y dónde está anotado el listado de países donde vendes. Una nota para empresas pequeñas: el reglamento prevé que las microempresas y pequeñas empresas no sean sancionadas con multas administrativas por incumplir ese plazo de 24 horas de la alerta temprana. No te exime de notificar, pero rebaja el riesgo mientras montas el procedimiento.
Qué tendrás que tener listo para 2027
Cuando llegue la aplicación general, el producto tiene que poder demostrar que cumple. Estas son las piezas que conviene empezar a construir ya, porque son trabajo de desarrollo y no de papeleo:
- Seguridad desde el diseño. Requisitos esenciales de ciberseguridad aplicados al producto entero, incluidos todos los componentes integrados. Si usas una biblioteca de terceros, respondes también de ella.
- Diligencia debida sobre los componentes. El reglamento espera que compruebes cosas verificables: si el componente lleva marcado CE, si recibe actualizaciones de seguridad con regularidad y si tiene vulnerabilidades registradas en la base de datos europea de vulnerabilidades. Eso implica saber qué llevas dentro, es decir, mantener un inventario de componentes.
- Un canal para recibir avisos. Una dirección pública donde cualquiera pueda comunicarte un fallo de seguridad, y alguien que la lea.
- Actualizaciones durante el periodo de soporte. La norma establece que el periodo durante el cual el fabricante garantiza la gestión eficaz de las vulnerabilidades no sea inferior a cinco años, salvo que la vida útil prevista del producto sea menor, en cuyo caso se ajusta a esa vida útil.
- Transparencia con el cliente. El periodo de soporte tiene que ser información conocida por quien compra, no un dato interno.
- Documentación y marcado. Documentación técnica, evaluación de la conformidad y marcado CE. Los productos clasificados como importantes o críticos pasan por procedimientos de evaluación más estrictos.
Cómo prepararte sin frenar el producto
Si vendes software o un aparato conectado, un orden razonable de trabajo para los próximos meses es este:
- Decide si estás dentro. Repasa tu catálogo producto por producto con el criterio del artículo 2 y anota la conclusión por escrito, con su motivo. Si tienes dudas con un producto mixto, consúltalo antes de asumir que estás fuera.
- Monta el procedimiento de notificación. Es lo único exigible hoy. Responsable, suplente, cómo se decide que hay explotación activa, dónde se notifica y qué se guarda.
- Haz el inventario de componentes. Qué bibliotecas y dependencias lleva cada producto, en qué versión y con qué soporte. Sin esto, la diligencia debida es imposible.
- Fija y publica tu periodo de soporte. Y comprueba que puedes sostenerlo: implica mantener versiones vivas, no solo prometerlas.
- Mete la seguridad en el ciclo de desarrollo. Revisión de dependencias, análisis automático y una vía rápida para publicar un parche. Si cada actualización de seguridad es un proyecto, no llegarás a los plazos.
- Revisa los contratos con tus proveedores. Si parte de tu producto lo desarrolla alguien externo, el reparto de responsabilidades sobre parches y avisos debe estar escrito.
En resumen: empieza por saber si te aplica
El Reglamento de Ciberresiliencia convierte en obligación lo que hasta ahora era buena práctica: productos diseñados con seguridad, componentes conocidos, parches durante años y avisos rápidos cuando algo se está explotando. La fecha grande es el 11 de diciembre de 2027, pero el deber de notificar en 24 horas ya corre, y el inventario de componentes y el ciclo de parches no se montan en una semana. Lo primero, y es gratis, es determinar con criterio si tu producto está dentro del ámbito o si tu caso es de NIS2. Si desarrollas una aplicación, un producto conectado o una plataforma y quieres que alguien revise contigo en qué situación quedas y qué hay que tocar en el desarrollo, escríbenos y lo analizamos antes de que las fechas aprieten.
Artículos relacionados
Preguntas frecuentes sobre
Cómo mejorar mi negocio con la metodología Anticompetencia
En Tangram no queremos que la información pase por una cadena interminable de intermediarios donde se pierden los detalles importantes.
Contarás con un interlocutor que coordinará la comunicación y trasladará las decisiones al equipo responsable de tu proyecto.
Cuando sea necesario profundizar en cuestiones de estrategia, diseño o tecnología, podremos involucrar a los especialistas correspondientes.
Así tendrás una comunicación organizada, sin necesidad de gestionar personalmente a todos los profesionales que intervienen.
Queremos que tengas acceso al conocimiento de un equipo especializado, sin sufrir la complejidad de coordinarlo.
No tendrás que averiguar a quién escribir cada vez que tengas una duda.
En Tangram contemplamos la figura del Account Manager como interlocutor principal, encargado de acompañarte durante el proyecto, coordinar la comunicación y facilitar el seguimiento de las decisiones.
Nuestra metodología incluye reuniones de revisión, canales de comunicación y herramientas para que puedas participar en el trabajo.
La organización concreta, la frecuencia de las reuniones y los canales disponibles se establecerán según el proyecto contratado.
Lo importante es que sepas con quién hablar, en qué punto está tu proyecto y qué decisiones necesitan tu participación.
Sí, podemos valorar una colaboración con los profesionales que ya trabajan en tu empresa.
No siempre tiene sentido sustituir un equipo que conoce bien tu negocio. En muchas situaciones, lo más útil es complementar sus conocimientos con especialistas en determinadas áreas.
Podemos estudiar qué responsabilidades asumiría Tangram, cuáles mantendría tu equipo y cómo coordinar las decisiones para evitar duplicidades.
La forma concreta de colaboración dependerá de la organización, las herramientas y las necesidades del proyecto.
No se trata de reemplazar lo que ya funciona, sino de aportar el conocimiento que necesitas para llegar más lejos.
No tienes por qué cambiar de proveedor para explorar una colaboración con Tangram.
Durante nuestra trayectoria hemos trabajado con agencias y consultoras, participando en proyectos en los que cada empresa asumía una parte diferente del trabajo.
Esa experiencia nos permite comprender la importancia de definir responsabilidades y coordinar a los profesionales implicados.
Podemos valorar una colaboración para cubrir necesidades concretas que tu proveedor actual no ofrece o para reforzar determinadas áreas.
Si tienes una relación profesional que funciona, no queremos que la rompas sin motivo. Queremos encontrar dónde podemos aportar valor.
La confidencialidad es especialmente importante cuando hablamos de nuevas ideas de negocio, información económica, estrategias comerciales o desarrollos tecnológicos.
En Tangram tenemos experiencia trabajando en proyectos sujetos a acuerdos de confidencialidad, motivo por el que no podemos mostrar públicamente muchos de los trabajos en los que hemos participado.
Si tu proyecto requiere un acuerdo de confidencialidad (NDA) antes de compartir información sensible, podemos revisar sus condiciones y acordar cómo proteger esa información antes de entrar en los detalles.
Entendemos que la confianza empieza por respetar lo que todavía no quieres hacer público.