124% más CVE notificadas al día en 2026 que el año pasado.

Guía del Cyber Resilience Act

Requisitos del CRA, paso a paso

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

Situación actual

  • La notificación ya se aplica. Desde el 11 de septiembre de 2026, los fabricantes notifican las vulnerabilidades explotadas activamente y los incidentes graves, también en productos ya comercializados.
  • Todo lo demás se aplica a partir del 11 de diciembre de 2027. Los productos introducidos en el mercado antes de esa fecha solo entran en el ámbito del resto del CRA si se modifican sustancialmente.
  • Las directrices ya están publicadas. Las directrices no vinculantes C(2026) 5252 de la Comisión, de 27 de julio de 2026, explican el ámbito, la modificación sustancial, los periodos de soporte y la notificación, y el Reglamento de Ejecución (UE) 2025/2392 describe las categorías de productos importantes y críticos.
CRA timeline The CRA was adopted in 2024 as Regulation (EU) 2024/2847. Its reporting obligations apply from 11 September 2026, including for products already on the market, and the regulation applies in full from 11 December 2027. 2024 Adopted as Regulation (EU) 2024/2847 11 September 2026 Reporting obligations apply, also for products already on the market 11 December 2027 The regulation applies in full Now Reporting clock is running Plan the SBOM and vulnerability handling before full application

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.

La hoja de ruta: diez pasos

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.

  1. 1

    Confirme el ámbito y su rol

    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.

    Responsable
    Gestión de producto con el equipo legal
    Evidencias que conservar
    Un inventario de productos con las decisiones de ámbito y su rol en cada uno
    Compruebe un producto con el CRA Checker →
    Who the CRA applies to The CRA places obligations on manufacturers, importers and distributors of products with digital elements made available on the EU market, including software and hardware with embedded software. Economic operators Manufacturers Importers Distributors Most obligations fall on the manufacturer Products with digital elements Software products IoT devices Hardware with embedded software The test Is the product made available on the EU market? If so, its manufacturer carries the CRA obligations
  2. 2

    Clasifique cada producto

    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.

    Responsable
    Gestión de producto con cumplimiento
    Evidencias que conservar
    La categoría de cada producto y el razonamiento que la sustenta
  3. 3

    Evalúe los riesgos de ciberseguridad

    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.

    Responsable
    Seguridad con ingeniería
    Evidencias que conservar
    Una evaluación de riesgos documentada por producto
  4. 4

    Fije el periodo de soporte

    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.

    Responsable
    Gestión de producto
    Evidencias que conservar
    El periodo de soporte, publicado donde lo vean los usuarios
  5. 5

    Genere una SBOM de cada build de lanzamiento

    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.

    Responsable
    Ingeniería
    Evidencias que conservar
    Una SBOM por versión en CycloneDX o SPDX

    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.

    An SBOM recorded during the build Packages from npm, PyPI, Cargo, Go, OCI registries and the CI cache pass through a package-aware proxy on the CRACI runner. The job's SBOM lists what was fetched, states its completeness and exports as CycloneDX or SPDX. Package sources npm PyPI Cargo · Go OCI registries CI cache restore Package- aware proxy on the runner Job SBOM express 5.2.1 requests 2.32.3 serde 1.0.219 + transitive deps Declared license on every component Complete Completeness states per job and cache: Complete, Complete with connections, Incomplete, Unavailable, Not recorded CycloneDX · SPDX
  6. 6

    Monitorice lo distribuido y corrija sin demora

    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.

    Responsable
    Seguridad con los equipos responsables de cada producto
    Evidencias que conservar
    Hallazgos, decisiones de triaje, correcciones y las actualizaciones que las distribuyeron

    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.

  7. 7

    Publique una política de divulgación de vulnerabilidades

    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.

    Responsable
    Seguridad
    Evidencias que conservar
    La política publicada, la dirección de contacto y sus avisos de seguridad
  8. 8

    Ensaye el plazo de notificación de 24 horas

    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.

    Responsable
    Seguridad o respuesta a incidentes
    Evidencias que conservar
    Un procedimiento de notificación con responsables designados y los informes presentados

    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.

    CRA notifications, submitted for you When a vulnerability is actively exploited, the CRA sets deadlines: an early warning within 24 hours, a notification within 72 hours and a final report 14 days after a fix is available. CRACI submits them through the CRA Single Reporting Platform to the CSIRT and ENISA on the manufacturer's behalf. Actively exploited vulnerability found Aware 24 hours Early warning 72 hours Notification Fix + 14 days Final report CRACI submits on your behalf Through the CRA Single Reporting Platform to the CSIRT and ENISA and shows which products and releases are affected What stays with you The reporting obligation itself Informing affected users Severe incidents: final report within one month
  9. 9

    Integre los requisitos esenciales en el desarrollo

    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.

    Responsable
    Ingeniería
    Evidencias que conservar
    Resultados de las pruebas de seguridad y comprobaciones de lanzamiento

    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.

  10. 10

    Reúna la documentación y supere la evaluación de la conformidad

    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.

    Responsable
    Cumplimiento con ingeniería
    Evidencias que conservar
    Documentación técnica, la declaración UE de conformidad y el marcado CE

    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.

    Evidence for the conformity assessment CRACI supplies technical evidence: build-time SBOMs, vulnerability and remediation records, provenance and network traces, with SBOMs exported as CycloneDX or SPDX and the rest returned by the API. The manufacturer uses it in the technical documentation, runs the conformity assessment, by self-assessment or with a notified body, draws up the EU declaration of conformity and applies the CE marking. CRACI supplies the evidence Build-time SBOMs Vulnerability records Provenance Network traces The manufacturer's process Technical documentation Conformity assessment: self-assessment or notified body EU declaration of conformity CE marking CRACI does not assess, certify or manage the assessment

Los requisitos y las evidencias que los respaldan

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.

RequisitoDóndeEvidencias que conservarDe 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