El Reglamento de Ciberresiliencia, Reglamento (UE) 2024/2847, no certifica productos frente a una norma. Exige que todo producto con elementos digitales en su ámbito cumpla los requisitos esenciales de ciberseguridad del anexo I, y exige al fabricante que lo demuestre, en una documentación técnica, por la vía de evaluación de la conformidad que el nivel del producto permite. El anexo I es, por tanto, la lista de la que cuelga cualquier otra obligación: la evaluación de riesgos es una evaluación de riesgos frente a él, la documentación técnica lo documenta, el organismo notificado lo comprueba.
Son dos páginas del Reglamento y merece la pena tenerlo como una sola tabla. Aquí está, con la lectura que decide si un requisito puede excluirse.
La estructura, y la única distinción que importa
El anexo I tiene dos partes.
Parte I, «Requisitos de ciberseguridad relativos a las propiedades de los productos con elementos digitales». El punto 1 es el requisito general: un nivel de ciberseguridad adecuado a los riesgos. El punto 2 enumera trece propiedades concretas, letras a) a m), y se abre con las palabras «sobre la base de la evaluación de riesgos de ciberseguridad a que se refiere el artículo 13, apartado 2, y cuando proceda». Esa frase hace el trabajo. Un requisito del punto 2 de la parte I puede dejarse fuera de un producto, pero solo sobre la base de la evaluación de riesgos y con la justificación escrita en la documentación técnica. «No lo pensamos» no es una exclusión.
Parte II, «Requisitos de gestión de las vulnerabilidades». Ocho requisitos sobre lo que el fabricante hace durante el período de soporte del producto, no sobre el producto en sí. Ninguno es «cuando proceda». Se aplican a todo producto en el ámbito, incluido el más pequeño.
Esa distinción es lo primero que hay que hacer bien en una documentación técnica, y es la que la determinación gratuita del ámbito no cubre, porque pertenece al producto, no a la cuestión de si el Reglamento se aplica.
Parte I: propiedades del producto
| Referencia | Requisito | Qué debe cumplirse | Se aplica |
|---|---|---|---|
| Parte I, punto 1 | Nivel de ciberseguridad adecuado desde el diseño | El producto se diseña, desarrolla y fabrica de modo que garantice un nivel de ciberseguridad adecuado a los riesgos, sobre la base de la evaluación de riesgos de ciberseguridad. | siempre |
| Parte I, punto 2, letra a) | Sin vulnerabilidades explotables conocidas al comercializarse | El producto se comercializa sin vulnerabilidades explotables conocidas. | cuando proceda |
| Parte I, punto 2, letra b) | Configuración segura por defecto | El producto se entrega con una configuración segura por defecto, incluida la posibilidad de restablecerlo a su estado original, salvo acuerdo en contrario con un usuario profesional para un producto a medida. | cuando proceda |
| Parte I, punto 2, letra c) | Actualizaciones de seguridad | Las vulnerabilidades pueden abordarse mediante actualizaciones de seguridad, incluidas actualizaciones automáticas por defecto con una exclusión clara y notificación a los usuarios, cuando proceda. | cuando proceda |
| Parte I, punto 2, letra d) | Protección frente al acceso no autorizado | Mecanismos de control adecuados, incluidos autenticación, gestión de identidades y accesos, y notificación de posibles accesos no autorizados. | cuando proceda |
| Parte I, punto 2, letra e) | Confidencialidad de los datos | Los datos almacenados, transmitidos o tratados de otro modo, personales o no, están protegidos, por ejemplo mediante cifrado en reposo y en tránsito con mecanismos conforme al estado de la técnica. | cuando proceda |
| Parte I, punto 2, letra f) | Integridad de datos, órdenes y configuración | Los datos, órdenes, programas y configuración almacenados, transmitidos o tratados están protegidos frente a manipulaciones o modificaciones no autorizadas por el usuario, y se notifican las corrupciones. | cuando proceda |
| Parte I, punto 2, letra g) | Minimización de datos | Solo se tratan los datos adecuados, pertinentes y limitados a lo necesario para la finalidad prevista. | cuando proceda |
| Parte I, punto 2, letra h) | Disponibilidad de las funciones esenciales y básicas | Las funciones esenciales y básicas siguen disponibles, también tras un incidente, con resiliencia y mitigación frente a ataques de denegación de servicio. | cuando proceda |
| Parte I, punto 2, letra i) | Sin impacto negativo en otros dispositivos y redes | El producto minimiza su propio impacto negativo en la disponibilidad de los servicios prestados por otros dispositivos o redes. | cuando proceda |
| Parte I, punto 2, letra j) | Superficie de ataque limitada | Las superficies de ataque, incluidas las interfaces externas, son limitadas. | cuando proceda |
| Parte I, punto 2, letra k) | Impacto reducido de los incidentes | El impacto de un incidente se reduce mediante mecanismos y técnicas adecuados de mitigación de la explotación. | cuando proceda |
| Parte I, punto 2, letra l) | Registro y supervisión de seguridad | Se proporciona información relacionada con la seguridad registrando y supervisando la actividad interna pertinente, incluido el acceso a datos, servicios o funciones o su modificación, con posibilidad de exclusión para el usuario. | cuando proceda |
| Parte I, punto 2, letra m) | Eliminación segura y sencilla de datos y ajustes | Los usuarios pueden eliminar de forma segura y sencilla, y de manera permanente, todos los datos y ajustes, y cuando los datos puedan transferirse a otro producto, esto se hace de forma segura. | cuando proceda |
Parte II: gestión de vulnerabilidades
| Referencia | Requisito | Qué debe cumplirse |
|---|---|---|
| Parte II, punto 1 | Identificar y documentar vulnerabilidades y componentes, con una SBOM | Las vulnerabilidades y los componentes del producto se identifican y documentan, incluida una lista de materiales de software en un formato legible por máquina de uso común que cubra al menos las dependencias de primer nivel. |
| Parte II, punto 2 | Corregir las vulnerabilidades sin demora | Las vulnerabilidades se abordan y corrigen sin demora, también mediante actualizaciones de seguridad; cuando sea técnicamente viable, las actualizaciones de seguridad están separadas de las funcionales. |
| Parte II, punto 3 | Pruebas y revisiones periódicas | Se aplican pruebas y revisiones eficaces y periódicas de la seguridad del producto. |
| Parte II, punto 4 | Divulgar las vulnerabilidades corregidas | Una vez disponible una actualización de seguridad, la información sobre las vulnerabilidades corregidas se comparte y divulga públicamente: descripción, productos afectados, impactos, gravedad y cómo remedian los usuarios; la divulgación puede retrasarse cuando el riesgo de seguridad de publicar supere el beneficio. |
| Parte II, punto 5 | Política de divulgación coordinada de vulnerabilidades | Se establece y aplica una política de divulgación coordinada de vulnerabilidades. |
| Parte II, punto 6 | Un contacto para notificar vulnerabilidades | Se facilita el intercambio de información sobre posibles vulnerabilidades, incluida una dirección de contacto para notificar vulnerabilidades descubiertas en el producto. |
| Parte II, punto 7 | Distribución segura y puntual de las actualizaciones | Existen mecanismos para distribuir actualizaciones de forma segura de modo que las vulnerabilidades se corrijan o mitiguen a tiempo y, cuando sea aplicable a las actualizaciones de seguridad, automáticamente. |
| Parte II, punto 8 | Parches de seguridad gratuitos con avisos | Los parches o actualizaciones de seguridad se difunden sin demora y, salvo acuerdo en contrario para un producto a medida, gratuitamente, acompañados de mensajes de aviso que dan a los usuarios la información pertinente, incluida la posible acción a emprender. |
Cómo leer la lista
Las palabras están parafraseadas; las referencias no. La columna «Qué debe cumplirse» es nuestra lectura breve de cada punto en lenguaje llano. Clasifique frente a la redacción del Reglamento, que las referencias le permiten encontrar en segundos, y cítela en la documentación.
La parte II presupone que existen cuatro documentos. Una política de divulgación coordinada de vulnerabilidades (punto 5), un contacto público para notificaciones (punto 6), una lista de materiales de software (punto 1) y una forma de distribuir actualizaciones de manera segura y gratuita (puntos 7 y 8). La mayoría de los pequeños fabricantes no tiene ninguno de los cuatro por escrito. No son difíciles de redactar; lo difícil es acordarse de redactarlos antes de que alguien los pida.
«Sin vulnerabilidades explotables conocidas» es un estado en la comercialización, no una promesa. El punto 2, letra a), de la parte I trata del momento en que el producto se comercializa. Lo que ocurre después es la parte II, y la obligación de notificación del artículo 14, en vigor desde el 11 de septiembre de 2026, se suma para las vulnerabilidades explotadas activamente.
El período de soporte forma parte de la respuesta. El artículo 13, apartado 8, exige al fabricante determinar un período de soporte durante el cual se cumple la parte II, de al menos cinco años salvo que se espere que el producto se use menos tiempo, y declararlo. Una documentación que enumera los requisitos de la parte II sin decir durante cuánto tiempo está incompleta.
Las exclusiones son un argumento, no una casilla. Para cada requisito del punto 2 de la parte I que no implemente, la documentación necesita la razón de la evaluación de riesgos. Un organismo notificado, o una autoridad de vigilancia del mercado una vez que su Estado miembro haya nombrado una, leerá esas razones antes que nada.
Qué hacer con ello
Para cada producto en el ámbito, una fila por requisito: implementado, cómo, y dónde está la evidencia; o excluido, sobre la base de qué conclusión de la evaluación de riesgos. Veintidós filas. Esa tabla, con el nivel y la determinación del ámbito delante, es la mayor parte de la columna vertebral de una documentación técnica, y es la tabla de la que realmente trata el plazo de diciembre de 2027.
Fuentes
- Reglamento (UE) 2024/2847, anexo I, partes I y II; artículo 13, apartado 2, para la evaluación de riesgos a la que se refiere el «cuando proceda»; artículo 13, apartado 8, para el período de soporte; artículo 31 y anexo VII para la documentación técnica; artículo 71, apartado 2, para las fechas.
- La FAQ técnica de la Comisión sobre el CRA, versión 1.3 de 1 de julio de 2026, sobre las exclusiones del punto 2 de la parte I.
Esto no es asesoramiento jurídico. Las referencias están ahí para que pueda leer cada requisito en el Reglamento y decidir para su propio producto.