El Cyber Resilience Act —Reglamento (UE) 2024/2847— convierte la ciberseguridad en un requisito legal de acceso al mercado europeo para cualquier producto conectado, con el marcado CE como prueba de conformidad. Si necesitas resolver primero el encuadre —qué productos entran, qué rol te corresponde, cómo se clasifica tu cartera y qué sanciones hay—, empieza por Cyber Resilience Act (CRA): qué es, a quién obliga y cómo se clasifican los productos.
Esta segunda parte va al trabajo real: qué exige técnicamente el Anexo I, cómo se monta el proceso de notificación de vulnerabilidades e incidentes, qué contiene el expediente de marcado CE, cómo encaja el CRA con NIS2 e ISO 27001 sin duplicar esfuerzo y en qué orden conviene abordarlo todo.
11 de septiembre de 2026 — obligaciones de notificación de vulnerabilidades explotadas activamente e incidentes graves, a través de la plataforma única gestionada por ENISA. Se aplica también a los productos ya comercializados, sin periodo transitorio. Es lo primero exigible y está a semanas.
11 de diciembre de 2027 — requisitos esenciales del Anexo I, evaluación de la conformidad, documentación técnica, declaración UE de conformidad y marcado CE.
Un aviso sobre el terreno: la Comisión ha propuesto retrasar dos meses los plazos de la petición de normalización. Las normas horizontales de gestión de vulnerabilidades se esperan hacia finales de octubre de 2026 y las normas verticales por producto a lo largo de diciembre de 2026. Como la autoevaluación de los productos importantes de clase I depende de poder aplicar normas armonizadas, conviene revisar su estado antes de cerrar el plan de conformidad.
Requisitos esenciales del Anexo I: seguridad por diseño y gestión de vulnerabilidades
El corazón técnico del CRA es su Anexo I, dividido en dos partes que se corresponden con dos momentos distintos del ciclo de vida: cómo se diseña y entrega el producto, y cómo se mantiene una vez vendido.
Parte I — Propiedades de ciberseguridad del producto
El producto debe diseñarse, desarrollarse y fabricarse de forma que garantice un nivel de ciberseguridad adecuado al riesgo. Entre otros requisitos:
- Comercializarse sin vulnerabilidades explotables conocidas.
- Entregarse con una configuración segura por defecto, y con posibilidad de restablecerla.
- Permitir la corrección de vulnerabilidades mediante actualizaciones, automáticas cuando proceda y con aviso al usuario.
- Proteger frente a accesos no autorizados con mecanismos de autenticación, gestión de identidades y control de accesos.
- Garantizar la confidencialidad e integridad de datos y órdenes, con cifrado en reposo y en tránsito.
- Aplicar minimización de datos: tratar solo los datos necesarios para el uso previsto.
- Proteger la disponibilidad de las funciones esenciales y reducir la superficie de ataque.
- Registrar y supervisar la actividad interna relevante para la seguridad (logs).
- Permitir el borrado seguro y la portabilidad de datos y configuraciones.
Ninguno de estos requisitos es exótico para un equipo que ya trabaja con prácticas de desarrollo seguro. La novedad no es el «qué», sino que a partir de diciembre de 2027 hay que poder demostrarlo documentalmente, producto a producto, ante una autoridad de vigilancia del mercado.
Parte II — Gestión de vulnerabilidades durante el periodo de soporte
La segunda parte obliga a mantener el producto seguro tras la venta. Aquí aparecen las tres novedades que más impacto operativo tienen:
Lista de materiales de software
El fabricante debe identificar y documentar los componentes del producto y elaborar un SBOM en formato legible por máquina que cubra, como mínimo, las dependencias de primer nivel.
Periodo de soporte
Debe declararse un periodo de soporte de al menos cinco años —o la vida útil esperada del producto, si es inferior— con fecha de fin explícita (mes y año) conocida en el momento de la compra.
Divulgación coordinada
Hay que publicar una política de divulgación coordinada de vulnerabilidades, un punto de contacto para reportarlas y distribuir los parches de seguridad de forma gratuita y sin demora.
Estas tres piezas están encadenadas: sin SBOM no se sabe si una vulnerabilidad publicada afecta al producto; sin saberlo, no se puede parchear dentro del periodo de soporte declarado; y sin parche no hay nada que comunicar en los plazos de notificación que vienen a continuación.
Notificación de vulnerabilidades e incidentes: 24 horas, 72 horas y 14 días
Desde el 11 de septiembre de 2026, los fabricantes deben notificar simultáneamente al CSIRT designado como coordinador —el del Estado miembro donde tengan su establecimiento principal; en España, INCIBE-CERT— y a ENISA, a través de la plataforma única de notificación. Se notifican dos supuestos: vulnerabilidades explotadas activamente e incidentes graves que afecten a la seguridad del producto.
Alerta temprana
Desde que el fabricante tiene conocimiento. Basta indicar que existe y, si se conocen, los Estados miembros afectados.
Notificación
Información general sobre el producto afectado, la naturaleza del problema y las medidas correctoras o mitigadoras disponibles.
Informe final
14 días desde que se dispone de una medida correctora, en vulnerabilidades explotadas activamente. 1 mes desde la notificación, en incidentes graves.
En paralelo a esos tres hitos, el fabricante debe informar sin demora indebida a los usuarios afectados —y, cuando proceda, al público— sobre el incidente y las medidas correctoras que deben aplicar. No es un cuarto plazo: es una obligación simultánea que conviene tener guionizada, porque implica a comunicación y soporte, no solo a seguridad.
Las microempresas y pequeñas empresas no se enfrentan a multas por incumplir específicamente el plazo de la alerta temprana de 24 horas, pero sí mantienen el resto de obligaciones de notificación.
Marcado CE y evaluación de la conformidad
Antes de comercializar el producto —y con fecha límite del 11 de diciembre de 2027—, el fabricante tiene que completar y conservar un expediente de conformidad. En orden:
- Realizar y documentar una evaluación de los riesgos de ciberseguridad del producto.
- Superar el procedimiento de evaluación de la conformidad que corresponda a su clase —autoevaluación por control interno, examen UE de tipo, aseguramiento de calidad total o certificación europea, según la clasificación del producto.
- Elaborar la documentación técnica que acredite el cumplimiento de los requisitos del Anexo I.
- Emitir la declaración UE de conformidad.
- Colocar el marcado CE en el producto, su embalaje o la documentación que lo acompaña.
- Entregar instrucciones de uso e información al usuario, incluida la fecha de fin del periodo de soporte.
Esa documentación debe conservarse durante al menos diez años —o el periodo de soporte, si es mayor— a disposición de las autoridades de vigilancia del mercado.
En España, el reparto institucional previsto queda así:
| Función | Organismo |
|---|---|
| Autoridad de vigilancia del mercado Inspecciona, requiere documentación y puede ordenar la retirada del producto. |
Ministerio para la Transformación Digital y de la Función Pública |
| Autoridad notificante Designa y supervisa los organismos de evaluación de la conformidad. |
Centro Criptológico Nacional (CCN) |
| CSIRT coordinador Receptor de las notificaciones de vulnerabilidades e incidentes, junto con ENISA. |
INCIBE-CERT |
¿Tienes que dejar listo el proceso de notificación antes de septiembre de 2026? Te mostramos cómo se gestionan los relojes de 24 h, 72 h y 14 días con registro auditable de cada comunicación.
Solicita una demoCRA, NIS2 e ISO 27001: cómo encajan sin duplicar trabajo
Es la confusión más habitual, y tiene una respuesta clara: el CRA regula productos; NIS2 regula organizaciones. Una empresa puede estar sujeta a ambos —como entidad esencial o importante bajo NIS2 y como fabricante bajo el CRA— y en ese caso los dos marcos se solapan en gobernanza, gestión de riesgos y notificación de incidentes, pero no en el objeto regulado.
Enfoque en silos
- Un proyecto independiente por cada norma: CRA, NIS2, ISO 27001, ENS.
- Inventarios de activos y de productos duplicados y desalineados.
- Evidencias recogidas tres veces para controles que son el mismo.
- Notificaciones gestionadas por correo, sin trazabilidad de plazos.
- Ninguna visión consolidada del riesgo ante la dirección.
Enfoque integrado
- Un único marco de controles con trazabilidad a cada requisito legal.
- Inventario compartido de productos, componentes y proveedores.
- Una evidencia satisface a la vez el CRA, NIS2 e ISO 27001.
- Flujos de notificación con relojes de 24 h/72 h y registro auditable.
- Cuadro de mando único de riesgo y cumplimiento para el comité.
La buena noticia es que un Sistema de Gestión de Seguridad de la Información basado en ISO/IEC 27001:2022 cubre buena parte del terreno común con la Parte I y la Parte II del Anexo I: análisis de riesgos, gestión de vulnerabilidades técnicas, seguridad en el desarrollo, relaciones con proveedores y gestión de incidentes. Para el ciclo de vida del producto, la referencia sectorial es la serie IEC 62443 (especialmente 62443-4-1 y 4-2) y, en desarrollo seguro de software, ISO/IEC 27034. Ninguna certificación sustituye por sí sola la conformidad con el CRA, pero todas reducen drásticamente el esfuerzo del análisis de brecha que viene a continuación.
Cómo prepararse para el CRA: hoja de ruta en 7 pasos
Con septiembre de 2026 a la vuelta de la esquina y diciembre de 2027 como horizonte de aplicación plena, este es el orden de trabajo que mejor funciona:
Inventaría y clasifica tu cartera
Lista todos los productos con elementos digitales que comercializas en la UE y clasifícalos según el Anexo III/IV y el Reglamento de Ejecución 2025/2392. Determina también tu rol: fabricante, importador o distribuidor.
Haz un análisis de brecha frente al Anexo I
Contrasta cada requisito esencial con lo que hoy hace tu proceso de desarrollo. Identifica qué está cubierto por tu SGSI, qué exige cambios de ingeniería y qué requiere documentación nueva.
Prioriza el bloque de notificación
Es lo primero exigible. Define el proceso, los roles de guardia, las plantillas y los relojes de 24 h, 72 h y 14 días, y ensáyalo antes de septiembre de 2026.
Genera SBOM y trazabilidad de componentes
Automatiza la generación del SBOM en formato legible por máquina e intégralo con la vigilancia de vulnerabilidades de tus dependencias.
Fija y publica el periodo de soporte
Decide el periodo por familia de producto, documenta el criterio y coordina la comunicación comercial: la fecha de fin debe ser visible en el momento de la compra.
Extiende las exigencias a tu cadena de suministro
Traslada requisitos del CRA a contratos con proveedores de componentes y software de terceros, y pide SBOM y compromisos de parcheo. Tu conformidad depende de la suya.
Prepara el expediente y la vía de conformidad
Monta la documentación técnica, la declaración UE de conformidad y, si tu producto es importante clase II o crítico, contrata con antelación al organismo notificado o al esquema de certificación.
¿Cómo puede ayudar un software GRC a cumplir el Cyber Resilience Act?
Desde GlobalSuite Solutions abordamos el CRA como lo que realmente es: un problema de gobierno, riesgo y cumplimiento con plazos legales tasados, no una hoja de cálculo de requisitos técnicos. Nuestra plataforma GlobalSuite® permite trazar cada requisito esencial del Anexo I hasta un control, un responsable y una evidencia concreta, reutilizando lo que ya tengas implantado en tu SGSI basado en ISO 27001, de forma que el análisis de brecha deje de ser un documento suelto y se convierta en un plan de acción con responsables y alertas de vencimiento. Sobre esa misma base se gestionan el análisis de riesgos de ciberseguridad del producto, el ciclo de vida de las vulnerabilidades ligado al inventario de componentes y al SBOM, la evaluación de proveedores y de la cadena de suministro, y los flujos de notificación con los relojes de 24 h, 72 h y 14 días y registro auditable de cada comunicación a INCIBE-CERT y ENISA. Y porque casi ninguna organización se enfrenta al CRA en solitario, el enfoque multinorma de la plataforma permite mapear una sola vez los controles comunes con NIS2, ISO 27001, IEC 62443, DORA o el ENS, de forma que una evidencia sirva para varios marcos y la dirección disponga de un cuadro de mando único del estado de cumplimiento y del riesgo residual, listo para auditoría o para una inspección de la autoridad de vigilancia del mercado.
Preguntas frecuentes sobre el cumplimiento del CRA
¿Qué es el SBOM y por qué lo exige el CRA?
El Software Bill of Materials (SBOM) es la lista de componentes y dependencias que integran un producto de software, en formato legible por máquina. El Anexo I, parte II, del CRA exige elaborarlo y mantenerlo —cubriendo al menos las dependencias de primer nivel— porque sin conocer los componentes es imposible saber si una vulnerabilidad publicada afecta al producto y actuar en los plazos de notificación.
¿Cuánto tiempo debe mantener el fabricante la seguridad del producto?
Durante el periodo de soporte, que debe ser de al menos cinco años —o igual a la vida útil esperada del producto si esta es inferior— y cuya fecha de finalización (mes y año) tiene que ser conocida por el comprador en el momento de la adquisición. Durante ese periodo el fabricante gestiona las vulnerabilidades y distribuye parches de seguridad de forma gratuita.
¿A quién hay que notificar una vulnerabilidad explotada y en qué plazo?
Simultáneamente al CSIRT designado como coordinador —el del Estado miembro del establecimiento principal; en España, INCIBE-CERT— y a ENISA, a través de la plataforma única de notificación. Los plazos son 24 horas para la alerta temprana, 72 horas para la notificación con detalle del producto y las medidas, y 14 días desde que se dispone de una medida correctora para el informe final (1 mes en el caso de incidentes graves). En paralelo hay que informar a los usuarios afectados.
¿Qué documentación técnica hay que conservar y durante cuánto tiempo?
La evaluación de riesgos de ciberseguridad, la documentación técnica que acredita el cumplimiento del Anexo I, los resultados del procedimiento de evaluación de la conformidad y la declaración UE de conformidad. Debe conservarse al menos diez años desde la introducción del producto en el mercado —o durante el periodo de soporte, si es más largo— y estar a disposición de las autoridades de vigilancia del mercado.
¿Qué diferencia hay entre el CRA y NIS2?
El CRA regula productos y NIS2 regula organizaciones. El CRA impone requisitos de ciberseguridad a lo que se fabrica y vende, con marcado CE como prueba de conformidad; NIS2 obliga a entidades esenciales e importantes de sectores críticos a implantar medidas de gestión de riesgos y notificar incidentes. Una empresa puede estar sujeta a ambos y conviene abordarlos de forma integrada para no duplicar controles ni evidencias.
¿Sirve la ISO 27001 para cumplir el CRA?
No sustituye a la conformidad con el CRA, pero acorta mucho el camino. Un SGSI conforme a ISO/IEC 27001:2022 ya cubre gestión de riesgos, gestión de vulnerabilidades técnicas, seguridad en el desarrollo, relaciones con proveedores y gestión de incidentes. Para los requisitos específicos del ciclo de vida del producto conviene complementarlo con la serie IEC 62443 y con prácticas de desarrollo seguro.
El cumplimiento del CRA se sostiene en tres bloques. El Anexo I fija las propiedades de ciberseguridad del producto (Parte I) y la gestión de vulnerabilidades durante el periodo de soporte (Parte II), con SBOM, cinco años mínimos de soporte y política de divulgación coordinada como novedades de más impacto operativo. La notificación impone relojes de 24 horas, 72 horas y 14 días ante INCIBE-CERT y ENISA. Y el expediente de marcado CE —evaluación de riesgos, documentación técnica y declaración UE de conformidad— debe conservarse diez años.
El orden importa: primero el bloque de notificación, porque es exigible desde el 11 de septiembre de 2026 y también sobre productos ya vendidos; después el análisis de brecha frente al Anexo I, el SBOM, el periodo de soporte, la cadena de suministro y el expediente, con vista al 11 de diciembre de 2027. Cuanto más integrado sea el enfoque con NIS2 e ISO 27001, menor será el coste total: una sola evidencia puede servir a varios marcos.
Prepara tu conformidad con el CRA sobre una única plataforma
Trazabilidad del Anexo I hasta control, responsable y evidencia; gestión de vulnerabilidades ligada al SBOM; flujos de notificación con relojes de 24 h y 72 h y registro auditable; evaluación de proveedores y mapeo multinorma con NIS2 e ISO 27001. Te lo mostramos con un caso real.
Solicita una demo
