Qué es el Reglamento de Ciberresiliencia y a quién obliga
El Reglamento de Ciberresiliencia es la norma europea que obliga a que cualquier producto con elementos digitales que se venda en la Unión Europea sea seguro desde su diseño y reciba actualizaciones de seguridad durante toda su vida útil. Afecta a quien fabrica, importa o distribuye software y dispositivos conectados, no a quien simplemente los usa en su empresa. Es el Reglamento (UE) 2024/2847, y su aplicación es escalonada: las obligaciones de notificar vulnerabilidades explotadas empiezan el 11 de septiembre de 2026 y el cumplimiento completo se exige desde el 11 de diciembre de 2027. Si tu empresa vende una aplicación, un dispositivo conectado o un producto digital, te concierne; si la desarrollas a medida para un único cliente, el encaje es distinto y conviene mirarlo con detalle.
A quién obliga de verdad
La norma reparte responsabilidades según el papel que juegas en la cadena. Conviene identificar el tuyo antes de nada:
- Fabricante. Quien desarrolla un producto con elementos digitales y lo pone en el mercado con su nombre o marca. Soporta el grueso de las obligaciones. Aquí entra una empresa que vende su propia aplicación o plataforma, aunque sea pequeña.
- Importador. Quien introduce en la Unión Europea un producto de un fabricante de fuera. Tiene que verificar que el fabricante ha cumplido antes de comercializarlo.
- Distribuidor. Quien lo pone a disposición en el mercado sin ser ninguno de los anteriores. Debe comprobar que el producto lleva el marcado y la documentación, y actuar si sabe que no cumple.
Hay un punto que sorprende a muchas empresas: si modificas sustancialmente un producto ajeno o lo revendes bajo tu propia marca, asumes las obligaciones de fabricante. Es el caso de quien coge una solución de un tercero, la adapta y la vende como producto propio.
Y si solo usas software en tu empresa
Entonces la norma no te impone obligaciones directas, pero te afecta de rebote y a favor: los productos que compres tendrán que cumplir estos requisitos y tus proveedores tendrán que darte información sobre el periodo de soporte. Eso es un criterio nuevo y muy útil a la hora de contratar.
Qué productos entran en el ámbito
El criterio es amplio: productos de hardware y software cuyo uso implique una conexión de datos, directa o indirecta, a un dispositivo o a una red. En la práctica:
- Aplicaciones móviles y aplicaciones de escritorio que se comercializan como producto.
- Software empresarial vendido con licencia, incluidos componentes y bibliotecas comercializadas.
- Dispositivos conectados: sensores, cámaras, cerraduras, electrodomésticos, equipos industriales.
- Sistemas operativos, navegadores, gestores de contraseñas y herramientas de seguridad, que están además en categorías de mayor exigencia.
Quedan fuera los productos ya regulados por normativas sectoriales propias, como los dispositivos médicos, la automoción o la aviación, y los servicios en la nube puros, que se rigen por otras normas. El software libre también tiene un tratamiento específico: cuando se desarrolla y distribuye sin ánimo comercial no soporta las obligaciones de fabricante, pero sí las soporta quien lo integra en un producto que vende.
Qué obligaciones impone
Se agrupan en tres bloques. El primero es de diseño y construcción del producto:
- Entregarlo sin vulnerabilidades conocidas y explotables, con una configuración segura por defecto.
- Protección de los datos y las comunicaciones, y limitación de las superficies de ataque y de los privilegios.
- Posibilidad de aplicar actualizaciones de seguridad, en lo posible automáticas y separadas de las de funcionalidad.
- Registro de la actividad relevante para la seguridad y posibilidad de borrar los datos del usuario.
El segundo es la gestión de vulnerabilidades durante toda la vida del producto:
- Mantener un inventario de los componentes del producto, lo que se conoce como lista de materiales de software o SBOM.
- Publicar un canal para que cualquiera pueda comunicar una vulnerabilidad y una política de divulgación.
- Corregir las vulnerabilidades sin demora y distribuir las actualizaciones gratuitamente.
- Declarar el periodo de soporte del producto, que como regla general no debe ser inferior a cinco años salvo que la vida esperada del producto sea más corta.
El tercero es la notificación de incidentes, con plazos muy cortos. Ante una vulnerabilidad explotada activamente o un incidente grave, hay que enviar un primer aviso en un máximo de 24 horas desde que se tiene conocimiento y una notificación con el detalle disponible en un máximo de 72 horas. Esta obligación se aplica también a productos que ya estaban en el mercado.
A todo ello se suman la evaluación de conformidad, la documentación técnica, la declaración UE de conformidad y el marcado CE del producto.
El calendario: qué toca y cuándo
| Fecha | Qué ocurre | Qué deberías tener listo |
|---|---|---|
| 11 de junio de 2026 | Los organismos de evaluación pueden empezar a certificar | Saber si tu producto necesita certificación externa |
| 11 de septiembre de 2026 | Entra en vigor la obligación de notificar vulnerabilidades explotadas e incidentes graves | Procedimiento de detección y aviso, con responsable y plazos de 24 y 72 horas |
| 11 de diciembre de 2027 | Cumplimiento pleno del reglamento | Requisitos de seguridad, SBOM, política de divulgación, documentación y marcado CE |
La fecha que más se infravalora es la de septiembre de 2026, porque llega antes y porque exige algo que no se improvisa: alguien que vigile, un procedimiento escrito y la capacidad real de reaccionar en 24 horas, también en agosto y también en fin de semana.
En qué se diferencia de NIS2 y del RGPD
Son tres normas que se confunden a menudo porque las tres hablan de seguridad, pero protegen cosas distintas:
| Norma | Qué regula | A quién obliga |
|---|---|---|
| Reglamento de Ciberresiliencia | La seguridad del producto que vendes | Fabricantes, importadores y distribuidores de productos digitales |
| Directiva NIS2 | La gestión de la seguridad de tu organización | Entidades de sectores considerados esenciales o importantes |
| RGPD | El tratamiento de datos personales | Cualquiera que trate datos de personas |
Pueden aplicarse las tres a la vez. Una empresa que desarrolla y vende una plataforma de gestión sanitaria estaría sujeta al reglamento por el producto, posiblemente a NIS2 por su sector y al RGPD por los datos que trata.
Qué hacer ahora si desarrollas o vendes software
Un plan razonable y por orden de utilidad:
- Determina tu papel y tu catálogo. Haz la lista de lo que comercializas y decide para cada cosa si eres fabricante, importador o distribuidor. Un desarrollo a medida para un cliente concreto no es lo mismo que un producto que vendes repetidamente: la frontera es importante y conviene fijarla con criterio.
- Monta el inventario de componentes. Saber qué bibliotecas de terceros lleva tu producto y en qué versión es la base de todo lo demás, y además es lo que te permitirá reaccionar rápido cuando aparezca un fallo en una de ellas.
- Abre el canal de comunicación de vulnerabilidades. Una dirección de correo publicada, un responsable y una política escrita de cómo se tratan los avisos. Es barato y es visible.
- Escribe el procedimiento de notificación. Quién decide que algo es notificable, a quién se avisa y con qué plantilla, para cumplir los plazos de 24 y 72 horas sin improvisar.
- Define el periodo de soporte de cada producto y revisa qué dicen tus contratos actuales. Si prometes menos de lo que la norma exige, hay que ajustarlo.
- Automatiza las actualizaciones de seguridad y separa su vía de entrega de la de las novedades funcionales, para poder parchear sin esperar a la siguiente versión.
En resumen: una obligación que también es un argumento de venta
El Reglamento de Ciberresiliencia convierte en exigencia legal lo que hasta ahora era buena práctica: productos seguros por defecto, componentes inventariados, parches durante un periodo declarado y avisos rápidos cuando algo se rompe. Si vendes software o dispositivos conectados, el calendario ya está en marcha y la primera fecha real es septiembre de 2026 con la notificación de incidentes. Si solo compras tecnología, usa la norma a tu favor y empieza a preguntar a tus proveedores por el periodo de soporte y la política de actualizaciones. Lo razonable es tratarlo como un proyecto de varios meses, no como un trámite de última hora.
En Tangram Consulting construimos aplicaciones y plataformas pensando en su ciclo de vida completo, con el mantenimiento y las actualizaciones de seguridad incluidos en el planteamiento. Si vendes un producto digital y quieres saber qué te falta para llegar en plazo, cuéntanos qué desarrollas y lo revisamos contigo.