Reglamento de Ciberresiliencia.
Desarrollar productos con elementos digitales seguros, gestionar vulnerabilidades y preparar la acreditación de conformidad adecuada.
- Reglamento (UE) 2024/2847
- Por Derya Altinay
- Actualizado: 22/10/2026
- Tiempo de lectura: 9 min.
Respuesta breve.
El Reglamento de Ciberresiliencia regula en la UE la ciberseguridad de productos comprendidos con elementos digitales. Los fabricantes responden de la seguridad durante desarrollo, comercialización y soporte. Sus obligaciones de notificación rigen desde el 11 de septiembre de 2026; las obligaciones generales del producto, desde el 11 de diciembre de 2027. Su base es el Reglamento (UE) 2024/2847.
Reglamento de Ciberresiliencia y plazos del CRA.
El Reglamento de Ciberresiliencia, abreviado CRA por sus siglas inglesas, regula la ciberseguridad de los productos. El Reglamento (UE) 2024/2847 combina requisitos de diseño con obligaciones durante el ciclo de vida del producto. El objeto de análisis es el producto concreto, incluidos los componentes relevantes y el tratamiento remoto de datos asociado. Un programa de seguridad de toda la empresa puede apoyar este trabajo, pero por sí solo no resuelve las cuestiones específicas del producto.
Los plazos del CRA se aplican por etapas. Según el art. 71, apartado 2, CRA, los requisitos generales comienzan el 11 de diciembre de 2027; las notificaciones de fabricantes del art. 14 se aplican desde el 11 de septiembre de 2026. El capítulo IV sobre la notificación de organismos de evaluación de la conformidad se aplica desde el 11 de junio de 2026. Esta fecha institucional no adelanta una fecha general de marcado CE para todos los productos de software.
Los productos anteriores no quedan exentos de forma general de las notificaciones de fabricantes. El art. 69, apartados 2 y 3, CRA distingue las reglas transitorias de conformidad del producto de las notificaciones. Las directrices de la Comisión C(2026) 5252, apartado 9.1, explican esta distinción también para los productos introducidos en el mercado antes de diciembre de 2027. Las directrices son una ayuda interpretativa jurídicamente no vinculante; el Reglamento sigue siendo determinante.
A qué productos y empresas afecta el CRA.
El CRA afecta a productos de hardware y software comprendidos que se comercializan en la UE y prevén una conexión de datos directa o indirecta con un dispositivo o una red. Los arts. 2 y 3 CRA determinan el ámbito de aplicación y las definiciones. Esto puede incluir componentes ofrecidos de forma independiente. Examine la función real y las excepciones legales antes de clasificar toda la cartera de la misma manera.
La función de la empresa determina sus obligaciones. Fabricantes, importadores y distribuidores tienen tareas diferentes; la condición de fabricante también puede ser relevante cuando se comercializa bajo marca propia. En el software de código abierto, deben distinguirse la comercialización, las contribuciones individuales y la función particular del administrador de programas informáticos de código abierto. Una licencia libre no exime de forma general al fabricante de un producto comercial de su responsabilidad.
Un servicio SaaS no queda incluido ni excluido del CRA solo por su denominación comercial. Son decisivos los límites del producto y el tratamiento remoto de datos asociado. Las directrices de la Comisión, apartados 2 y 8, distinguen los productos de software de los servicios prestados a distancia. Documente la justificación de la arquitectura concreta; una afirmación general sobre todas las ofertas de nube sería demasiado amplia.
Las áreas principales de los requisitos del CRA.
Los requisitos del CRA combinan la seguridad del producto basada en riesgos con una responsabilidad continua. El art. 13 y el anexo I CRA constituyen la base de las obligaciones del producto; el art. 14 regula las notificaciones de fabricantes aplicables de forma anticipada. Las áreas siguientes ofrecen orientación sin sustituir los requisitos legales concretos.
Comprender el producto y los riesgos.
Una evaluación de riesgos de ciberseguridad fundamenta las decisiones de seguridad durante el ciclo de vida. Los fabricantes consideran el uso previsto y el razonablemente previsible. Describa de forma práctica las funciones, interfaces y dependencias del producto y las consecuencias que un problema de seguridad puede tener para sus usuarios.
Incorporar la seguridad al producto.
El diseño seguro y la configuración segura por defecto van unidos. El anexo I CRA recoge propiedades del producto como la protección del acceso, la protección de datos y la limitación de las superficies de ataque. Una política redactada a posteriori no puede sustituir propiedades técnicas; las decisiones de desarrollo y su verificación deben ajustarse a la evaluación de riesgos.
Integrar componentes de forma responsable.
Los componentes integrados siguen formando parte del análisis del producto. Los fabricantes necesitan información trazable sobre lo que entregan y sobre cómo afectan a su producto las vulnerabilidades de las dependencias. La Comisión describe expresamente la diligencia debida respecto de componentes de terceros; transmitir sin más la información de un proveedor no resuelve todas las cuestiones del producto.
Gestionar vulnerabilidades y actualizaciones.
La gestión de vulnerabilidades es una tarea continua durante el período de soporte pertinente. Incluye canales de notificación accesibles, evaluación, subsanación y suministro seguro de actualizaciones de seguridad. Separe el tratamiento técnico de un hallazgo de la evaluación jurídica sobre si una vulnerabilidad explotada activamente o un incidente grave están sujetos a notificación.
Definir el soporte y la información al usuario.
El período de soporte depende de los criterios del art. 13, apartado 8, CRA y del uso esperado. En principio, se prevén al menos cinco años; si el uso esperado es menor, se aplica esa duración, y si es mayor, puede ser necesario un período más largo. Las directrices de la Comisión, apartado 5, explican expresamente que cinco años no es un máximo general.
Habilitar las notificaciones de fabricantes.
El art. 14 CRA distingue las vulnerabilidades explotadas activamente de los incidentes de seguridad graves. Los fabricantes deben notificar por etapas: sin demora y, a más tardar, una alerta temprana en 24 horas e información adicional en 72 horas desde que tengan conocimiento. Los plazos finales difieren según el desencadenante. Por ello, un hallazgo de un escáner por sí solo no constituye automáticamente una notificación obligatoria ni una razón suficiente para cerrar el evento.
Preparar la conformidad y la documentación.
La documentación técnica y la evaluación de la conformidad deben explicar el producto ofrecido. El art. 32 CRA y la categoría del producto determinan el procedimiento admisible. Conserve la base de evaluación elegida junto con la versión del producto; una colección general de documentos sin relación trazable con la versión examinada no basta como estrategia práctica de acreditación.
La implantación del CRA como proceso del producto.
Delimitar la cartera y las funciones.
Como primer paso práctico, registre los productos ofrecidos, sus funciones relevantes, la entidad jurídica responsable y la función en cada canal de comercialización.
Distinguir las fases de aplicación.
Separe la preparación de las notificaciones de fabricantes ya exigidas de la preparación de la conformidad general del producto y examine las transiciones para productos existentes.
Traducir los riesgos en decisiones de producto.
Conecte la evaluación de riesgos con el diseño, la elección de componentes y los criterios de seguridad verificables para el desarrollo y la aprobación.
Ensayar los canales de notificación.
Designe responsables y suplentes y practique la evaluación, el escalado y la transmisión con información incompleta dentro de los plazos aplicables.
Definir el soporte y la vía de acreditación.
Planifique el mantenimiento de las versiones de producto con soporte y aclare, según la categoría, qué evaluación de la conformidad y documentación técnica serán necesarias.
Marcado CE del software y acreditación del producto.
La acreditación del CRA es una evaluación de la conformidad del producto. La Comisión explica, respecto al art. 32 CRA, que para la categoría estándar es posible una evaluación interna. Para determinados productos importantes o críticos, se aplican procedimientos más estrictos con un organismo notificado u otras vías de acreditación admisibles en cada caso. La función real del producto determina la categoría; un nombre comercial no basta.
La declaración UE de conformidad y el marcado CE siguen el procedimiento aplicable. No son un certificado general de toda la empresa ni una promesa de que el producto nunca tendrá vulnerabilidades. Por ello, una vigencia uniforme de certificado no describe adecuadamente el CRA: deben considerarse la documentación, la gestión de vulnerabilidades y las obligaciones aplicables durante el ciclo de vida pertinente.
Otros marcos y obligaciones independientes.
ISO 27001 organiza un sistema de gestión de seguridad de la información; su certificado no confirma por sí solo la conformidad de un producto con el CRA. NIS2 considera las entidades comprendidas y su organización de la seguridad. El RGPD protege los datos personales, por lo que un evento del producto puede plantear cuestiones adicionales de protección de datos. Los procesos relacionados pueden coordinarse, pero sus desencadenantes jurídicos y evidencias deben seguir examinándose por separado.
En Secani.
Secani incluye un catálogo editorial de trabajo del CRA con fuentes, preguntas de evaluación y ejemplos de evidencias. El perfil de empresa recoge, entre otros datos, las funciones y la fecha de evaluación; los supuestos sin aclarar siguen visibles como cuestiones que deben examinarse. La herramienta apoya la organización del análisis, pero no confirma ni la clasificación jurídica ni la conformidad de un producto.
Empezar con un producto delimitado.
Elija un producto concreto y aclare primero sus límites, la entidad jurídica responsable y las personas competentes para las notificaciones de seguridad. Examine después qué obligaciones actuales y futuras afectan a ese producto. Este comienzo permite manejar la preparación y evita que un proyecto general de cumplimiento oculte la preparación de notificaciones ya exigida.
Fuentes.
- Reglamento (UE) 2024/2847: Reglamento de Ciberresiliencia
- Comisión Europea: Reglamento de Ciberresiliencia y fechas de aplicación
- Comisión Europea: resumen del acto jurídico
- Comisión Europea: obligaciones de los fabricantes
- Comisión Europea: evaluación de la conformidad
- Comisión Europea: CRA y código abierto
- Comisión Europea: directrices C(2026) 5252 con anexo
Preguntas frecuentes.
Sí, los fabricantes comprendidos deben realizar las notificaciones del art. 14 CRA desde el 11 de septiembre de 2026. Las obligaciones generales del producto comienzan el 11 de diciembre de 2027; las funciones particulares y las transiciones deben examinarse por separado.
No, la denominación SaaS no determina el ámbito de aplicación. Examine el producto de software, sus funciones y el tratamiento remoto de datos asociado según la arquitectura concreta.
No, el tratamiento particular de las contribuciones previas de código abierto no exime de forma general al fabricante comercial del producto de sus obligaciones. Debe distinguirse la condición de fabricante de la posible función de administrador de código abierto.
No, un certificado ISO 27001 se refiere a un sistema de gestión delimitado. El CRA exige un análisis independiente del producto y la acreditación de conformidad aplicable en cada caso.
Organizar la seguridad del producto de forma trazable.
Trabaje de forma estructurada los requisitos del CRA y su evaluación con Secani.
Esta página explica el Reglamento de Ciberresiliencia en términos generales y no sustituye la evaluación jurídica de cada producto. Son determinantes los actos jurídicos vigentes.