Cyber Resilience Act
Checklist CRA: qué preparar para cumplir, y en qué orden
Una lista de comprobación para cumplir el CRA empieza por el alcance y la notificación, porque el artículo 14 ya se aplica desde el 11 de septiembre de 2026, y después recorre la gestión de vulnerabilidades, los requisitos de seguridad y la documentación antes de que el resto del Cyber Resilience Act se aplique el 11 de diciembre de 2027. La lista siguiente sigue ese orden.
Plan gratuito, sin tarjeta.
1. Alcance y roles
Empieza por decidir cuáles de tus productos son productos con elementos digitales y qué papel desempeñas en cada uno: fabricante, importador o distribuidor. Todo lo demás depende de esa respuesta.
- Enumera todos los productos y versiones que comercializas en la UE, incluido el software que se vende por separado.
- Registra tu papel en cada producto: fabricante, importador, distribuidor o administrador de comunidad de código abierto.
- Comprueba si algún producto entra en las categorías de productos importantes (anexo III) o críticos (anexo IV).
- Anota los productos cubiertos por normas sectoriales excluidas, como los productos sanitarios o los vehículos de motor.
2. Notificación: ya es aplicable
El artículo 14 se aplica desde el 11 de septiembre de 2026 y cubre los productos que ya están en el mercado. Esta parte no puede esperar.
- Identifica el CSIRT designado como coordinador que corresponde a tu establecimiento principal.
- Consigue acceso a la plataforma única de notificación de ENISA.
- Designa a las personas que deciden si una vulnerabilidad se está aprovechando activamente, con sus suplentes.
- Prepara plantillas para la alerta temprana de 24 horas, la notificación de 72 horas y el informe final.
- Decide cómo informarás a los usuarios afectados, preferiblemente en un formato legible por máquina.
3. Saber qué contiene tu producto
No puedes notificar ni corregir un componente que no sabes que distribuyes. El anexo I, parte II, empieza por un inventario.
- Genera un SBOM para cada versión del producto que cubra, como mínimo, las dependencias de máximo nivel.
- Usa un formato de uso común y legible por máquina, como CycloneDX o SPDX.
- Incluye el firmware y las imágenes de contenedor, no solo los repositorios de código fuente.
- Conserva los SBOM de todas las versiones que sigan con soporte, no solo de la última compilación.
4. Gestión de vulnerabilidades
Estas obligaciones se aplican desde el 11 de diciembre de 2027 a los productos introducidos en el mercado a partir de esa fecha.
- Contrasta los componentes con las vulnerabilidades conocidas con una periodicidad fija.
- Subsana sin demora, con actualizaciones de seguridad separadas de las de funcionalidad cuando sea viable.
- Publica una política de divulgación coordinada de vulnerabilidades y una dirección de contacto.
- Divulga las vulnerabilidades corregidas una vez que haya una actualización disponible.
- Distribuye las actualizaciones de seguridad de forma segura y gratuita, con mensajes de aviso.
- Prueba y revisa periódicamente la seguridad del producto.
5. Requisitos de seguridad y período de soporte
El anexo I, parte I, fija las propiedades de seguridad del producto. Varias de ellas son decisiones de diseño difíciles de cambiar a última hora.
- Comercializa el producto con una configuración segura por defecto y la posibilidad de restablecerla.
- Protege frente al acceso no autorizado y protege la confidencialidad y la integridad de los datos.
- Limita la superficie de ataque y reduce el impacto de los incidentes.
- Fija un período de soporte de al menos cinco años, salvo que se prevea un uso más corto del producto, e indica su fecha de fin en el momento de la compra.
6. Documentación y conformidad
El último paso convierte el trabajo en un expediente que una autoridad pueda revisar. La documentación técnica debe conservarse durante diez años o durante el período de soporte, si este es más largo.
- Redacta la documentación técnica descrita en el anexo VII, incluidos el SBOM y el proceso de gestión de vulnerabilidades.
- Elige el procedimiento de evaluación de la conformidad según la categoría de cada producto.
- Redacta la declaración UE de conformidad y coloca el marcado CE.
- Facilita la información y las instrucciones para el usuario que exige el anexo II.
7. Mantenerlo en marcha
El cumplimiento no es un proyecto puntual. Las obligaciones duran todo el período de soporte de cada versión del producto que vendes, así que la lista se convierte en una rutina.
- Vuelve a comprobar el SBOM de cada versión con soporte cada vez que se publiquen nuevos datos de vulnerabilidades.
- Revisa el buzón de divulgación coordinada de vulnerabilidades y clasifica los informes con un ritmo fijo.
- Ensaya una notificación del artículo 14 una vez al año, desde la detección hasta el informe final.
- Actualiza la documentación técnica cuando un producto se someta a una modificación sustancial.
Disponible hoy en KROMSE
Varios puntos de esta lista son justo lo que KROMSE genera hoy.
- SBOM en CycloneDX y SPDX de cada análisis de un repositorio, una imagen de contenedor o una imagen de firmware basada en Linux.
- Comprobación de tus componentes frente a vulnerabilidades conocidas, con los indicadores de explotación conocida del catálogo KEV de CISA.
- En los planes de pago, borradores internos del artículo 14 para todas las fases de notificación, que una persona completa y presenta.
- Decisiones registradas y un paquete de evidencias CRA para tu expediente técnico.
Próximamente
En la hoja de ruta, todavía no disponible. Las fechas son objetivos, no promesas; esta página cambia el mismo día en que una funcionalidad está operativa.
- Próximamente · T4 2026Evaluación de la conformidad CRA. Un flujo de trabajo guiado relacionará tus evidencias con los requisitos del anexo I, para que una persona lo revise y lo complete.
- Próximamente · T4 2026Generador de la declaración UE de conformidad. KROMSE redactará la declaración UE de conformidad a partir de la ficha de tu producto, para que la persona firmante la revise y la firme.
Preguntas frecuentes
¿Qué debe hacer primero un fabricante para el CRA?
Prepararse para notificar. El artículo 14 se aplica desde el 11 de septiembre de 2026 y cubre los productos que ya están en el mercado, así que el primer paso es saber cuál es tu CSIRT coordinador, tener acceso a la plataforma única de notificación de ENISA y saber qué productos contienen qué componentes.
¿Es obligatorio un SBOM según el Cyber Resilience Act?
Sí, para los productos incluidos en su ámbito. El anexo I, parte II, exige a los fabricantes identificar y documentar los componentes, también mediante la elaboración de una nomenclatura de materiales de los programas informáticos (SBOM) en un formato de uso común y legible por máquina que cubra, como mínimo, las dependencias de máximo nivel. Forma parte de la documentación técnica; no es algo que haya que publicar.
¿Durante cuánto tiempo hay que ofrecer actualizaciones de seguridad?
Durante el período de soporte, que debe reflejar el tiempo de uso previsto del producto y ser de al menos cinco años, salvo que se prevea un uso más corto. Cada actualización de seguridad debe seguir disponible durante al menos diez años o durante el resto del período de soporte, si este es más largo.
¿Se aplica esta lista a los proyectos de código abierto?
Depende del papel. Una empresa que introduce un producto de código abierto en el mercado en el curso de una actividad comercial es fabricante y sigue la lista completa. Los administradores de comunidad de código abierto tienen obligaciones más ligeras y no pueden ser multados, y quienes contribuyen sin actividad comercial suelen quedar fuera del Reglamento.
¿Puedo descargar este checklist?
Sí. Usa el botón de imprimir de esta página y elige Guardar como PDF en el cuadro de impresión de tu navegador. La lista es orientativa y no sustituye al asesoramiento jurídico sobre si el Reglamento se aplica a tus productos y cómo.