Cyber Resilience Act
Lista de comprobación de preparación para fabricantes
Utilice esta lista para asignar responsables y recopilar evidencias mientras prepara sus productos con elementos digitales para el CRA.
Guía del Cyber Resilience Act
Una hoja de ruta práctica para los equipos que crean productos con elementos digitales: qué hacer, quién es responsable y qué evidencias conservar. Para saber qué dice la ley, lea qué es el Cyber Resilience Act.
Última actualización: 15 de octubre de 2026
What the Cyber Resilience Act asks manufacturers to do
El ámbito del Reglamento (UE) 2024/2847, las fechas en que empieza a aplicarse, los plazos de notificación y dónde se sitúan las obligaciones sobre la SBOM y la gestión de vulnerabilidades.
Petteri Pulkkinen y Erika Marttinen en Kubernetes Community Days Helsinki 2026, 8:03 a 15:20 de SBOMbastic: Getting Ready for Upcoming EU Cybersecurity Regulation in Software Supply Chains.
Los pasos siguen aproximadamente este orden, pero los pasos 5 a 8 son prioritarios para los productos ya comercializados, porque la notificación ya se les aplica.
Enumere todos los productos con elementos digitales que pone a disposición en la UE, incluidos el software vendido por separado y los backends en la nube que los productos necesitan para funcionar. Para cada uno, confirme que no está excluido (productos sanitarios, vehículos, aviación, equipos marinos, defensa) y si usted es su fabricante, importador o distribuidor.
Compruebe un producto con el CRA Checker →La mayoría de los productos pertenecen a la categoría por defecto. Compare los suyos con las listas de productos importantes (anexo III) y críticos (anexo IV); el Reglamento de Ejecución (UE) 2025/2392 ofrece sus descripciones técnicas. La categoría determina si puede autoevaluarse o si necesita un organismo notificado o una certificación.
Redacte una evaluación de los riesgos de ciberseguridad para cada producto. Determina cómo se aplican los requisitos esenciales del anexo I y forma parte de la documentación técnica. Actualícela cuando cambien el producto o las amenazas.
Decida durante cuánto tiempo gestionará las vulnerabilidades de cada producto: al menos cinco años, salvo que se prevea que el producto se utilice durante menos tiempo. Informe a los usuarios de cuándo termina el soporte y mantenga cada actualización de seguridad disponible durante al menos 10 años.
El CRA pide una lista de materiales de software en un formato de uso común y legible por máquina que abarque, como mínimo, las dependencias de nivel superior. Generarla en el build que produce la versión, en lugar de una sola vez a mano, la mantiene fiel a lo distribuido.
Dónde encaja CRACI: CRACI registra la SBOM mientras se ejecuta cada build, incluidas las dependencias transitivas y los paquetes restaurados desde cachés, y la exporta en CycloneDX o SPDX.
Vigile las versiones publicadas, no solo la rama principal, en busca de nuevas vulnerabilidades durante todo el periodo de soporte. Corríjalas sin demora y distribuya actualizaciones de seguridad gratuitas y, cuando sea posible, separadas de las actualizaciones de funcionalidades.
Dónde encaja CRACI: CRACI vuelve a cotejar las SBOM monitorizadas con las nuevas vulnerabilidades después de la distribución, y los equipos de seguridad hacen el triaje de los hallazgos y los envían a los equipos responsables de la corrección. Los controles de política pueden bloquear un build según los hallazgos.
Ofrezca a investigadores y clientes un contacto para notificar vulnerabilidades y una política de divulgación coordinada de vulnerabilidades. Cuando haya una actualización disponible, publique información sobre las vulnerabilidades que corrige.
Desde el 11 de septiembre de 2026, una vulnerabilidad explotada activamente o un incidente grave requieren una alerta temprana en un plazo de 24 horas, una notificación en un plazo de 72 horas y un informe final, a través de la plataforma única de notificación. Designe quién confirma la explotación activa, quién presenta la notificación y quién informa a los usuarios. Lo difícil es saber en cuestión de horas qué productos y versiones contienen el componente vulnerable.
Dónde encaja CRACI: El historial de builds de CRACI muestra qué builds contenían una dependencia vulnerable, su vista de inventario muestra qué versiones están desplegadas en qué productos y CRACI presenta las notificaciones del CRA en su nombre.
Distribuya sin vulnerabilidades explotables conocidas y con una configuración segura por defecto, proteja los datos y el acceso, limite la superficie de ataque y haga posibles las actualizaciones de seguridad, automáticas por defecto cuando proceda. Pruebe y revise la seguridad con regularidad.
Dónde encaja CRACI: CRACI aplica una política de egress sobre lo que los builds pueden descargar, y los controles de política pueden bloquear un build según los hallazgos.
Recopile la documentación técnica descrita en el anexo VII, realice la evaluación de la conformidad de su categoría, redacte la declaración UE de conformidad y coloque el marcado CE. Conserve la documentación y la declaración durante al menos 10 años o durante el periodo de soporte, lo que sea más largo.
Dónde encaja CRACI: CRACI exporta las SBOM en CycloneDX o SPDX, incluidas las vulnerabilidades encontradas en sus componentes, y su API devuelve SBOM, trazas de red y procedencia para su documentación técnica. La evaluación y la declaración siguen siendo su proceso.
Las autoridades de vigilancia del mercado pueden solicitar su documentación técnica. Este es el rastro que deja cada requisito, y dónde lo registra CRACI a partir de sus builds.
| Requisito | Dónde | Evidencias que conservar | De CRACI |
|---|---|---|---|
| Evaluación de los riesgos de ciberseguridad | Artículo 13, anexo I | Evaluación documentada por producto | Su proceso |
| Ninguna vulnerabilidad explotable conocida en el lanzamiento | Anexo I, parte I | Estado de vulnerabilidades del build de lanzamiento | SBOM del build de lanzamiento cotejada con los avisos; controles de política |
| Lista de materiales de software | Anexo I, parte II | SBOM legible por máquina por versión | Registrada en cada build, en CycloneDX o SPDX |
| Gestión de vulnerabilidades durante el periodo de soporte | Artículo 13, anexo I, parte II | Hallazgos, decisiones de triaje, correcciones, avisos | Reevaluación continua, triaje, VEX |
| Diligencia debida con los componentes de terceros | Artículo 13 | Registros de componentes, incluido el software adquirido | SBOM de proveedores monitorizadas con las suyas; licencias declaradas |
| Notificación de vulnerabilidades explotadas e incidentes graves | Artículo 14 | Alertas tempranas, notificaciones, informes finales | Presenta las notificaciones en su nombre |
| Periodo de soporte | Artículo 13 | Fecha de fin de soporte publicada | Su proceso |
| Documentación técnica y declaración | Artículo 13, anexo VII | Conservadas durante 10 años o durante el periodo de soporte | Exportación de SBOM y datos de la API para la documentación |
Cyber Resilience Act
Utilice esta lista para asignar responsables y recopilar evidencias mientras prepara sus productos con elementos digitales para el CRA.
Preguntas prácticas que se hacen los equipos al empezar con el CRA
Cumplir los requisitos esenciales del anexo I a partir de una evaluación de los riesgos de ciberseguridad, conservar una SBOM, gestionar las vulnerabilidades durante un periodo de soporte de al menos cinco años, notificar las vulnerabilidades explotadas activamente y los incidentes graves, conservar la documentación técnica, superar una evaluación de la conformidad y colocar el marcado CE.
Por el ámbito y la notificación. Averigüe qué productos cubre el CRA y después asegúrese de que podría cumplir la alerta temprana de 24 horas ante una vulnerabilidad explotada activamente, porque la notificación se aplica desde el 11 de septiembre de 2026, también a los productos ya comercializados. El resto se aplica a partir del 11 de diciembre de 2027.
La enumera el anexo VII. Incluye la evaluación de los riesgos de ciberseguridad del producto, la SBOM e información sobre cómo gestiona el fabricante las vulnerabilidades. Se conserva durante al menos 10 años o durante el periodo de soporte, lo que sea más largo, y se entrega a las autoridades de vigilancia del mercado cuando la solicitan.
No. La SBOM forma parte de la documentación técnica y se entrega a una autoridad de vigilancia del mercado cuando la solicita. El reglamento no exige publicarla.
Sí. El 27 de julio de 2026, la Comisión Europea publicó unas directrices no vinculantes, C(2026) 5252, con 67 ejemplos prácticos. Abordan el tratamiento remoto de datos, el software libre y de código abierto, la modificación sustancial, los periodos de soporte, la notificación y la evaluación de riesgos. El Reglamento de Ejecución (UE) 2025/2392 describe las categorías de productos importantes y críticos.
Las obligaciones son las mismas, pero las microempresas y pequeñas empresas no reciben multas por incumplir el plazo de 24 horas de la alerta temprana, y las directrices de la Comisión están redactadas teniendo en cuenta a las microempresas y las pymes.
No. Cumplir el CRA es un proceso del fabricante, que incluye la evaluación de riesgos, la evaluación de la conformidad y la declaración. CRACI automatiza una parte significativa de la visibilidad de la cadena de suministro y de las evidencias que necesita ese proceso: SBOM de cada build, seguimiento de vulnerabilidades después del lanzamiento y las notificaciones del CRA.
Vea cómo CRACI registra una SBOM de cada build, monitoriza lo que usted ha distribuido y presenta las notificaciones del CRA en su nombre