El anexo I parte II del Reglamento (UE) 2024/2847 establece ocho deberes numerados que todo fabricante de un producto con elementos digitales debe cumplir durante todo el período de soporte: identificación anclada en el SBOM, remediación sin demora, pruebas periódicas, divulgación pública de las correcciones, una política de divulgación coordinada de vulnerabilidades, un canal externo de notificación, distribución segura de actualizaciones y actualizaciones de seguridad gratuitas. Esta página recorre cada deber y muestra dónde termina la gestión del anexo I y dónde empieza la notificación del artículo 14.
Resumen
- El anexo I parte II es la especificación de ingeniería para la gestión de vulnerabilidades conforme al CRA, aplicable a todo fabricante para todo producto con elementos digitales.
- Ocho deberes numerados: identificar (con SBOM), remediar sin demora, probar periódicamente, divulgar públicamente las vulnerabilidades corregidas, operar una política CVD, facilitar la notificación de vulnerabilidades, distribuir actualizaciones de forma segura, suministrar actualizaciones de seguridad gratuitas.
- La gratuidad no es negociable: las actualizaciones de seguridad deben suministrarse de forma gratuita conforme al anexo I parte II punto 8, con la única excepción de los productos a medida para usuarios profesionales.
- La política CVD es obligatoria, no opcional: el anexo I parte II punto 5 convierte la divulgación coordinada de vulnerabilidades en una obligación del marcado CE, no en una buena práctica.
- La gestión de vulnerabilidades se aplica durante todo el período de soporte definido en el artículo 3(20) y el artículo 13(8); el mínimo es de cinco años desde la introducción en el mercado.
- La gestión de vulnerabilidades no es la notificación del artículo 14: la gestión es el proceso de ingeniería del día a día; la notificación es la cadencia 24h/72h/14d que solo se activa por vulnerabilidades activamente explotadas o incidentes graves (véase notificación del artículo 14 del CRA).
Los cuatro anclajes que enmarcan la gestión de vulnerabilidades del CRA: alcance, duración, regla de coste y techo de sanción.
Las ocho deberes Anexo I parte II
El anexo I parte II del Reglamento (UE) 2024/2847 enumera ocho deberes numerados. No son una lista de comprobación: describen un ciclo de vida continuo que se aplica durante todo el período de soporte. La agrupación siguiente los organiza por la fase operativa en la que se ejecuta cada uno.
Puntos 1, 6. Identificación basada en SBOM de componentes y vulnerabilidades conocidas, junto con un canal de contacto público que permita a terceros notificar lo que sus escáneres pasaron por alto.
Puntos 2, 3. Remediación sin demora (escalada por gravedad, no SLA fijo) y pruebas periódicas eficaces del código y de sus dependencias.
Puntos 7, 8. Canal de actualización seguro (firmado, autenticado, automático cuando proceda), con actualizaciones de seguridad separables de las funcionalidades y gratuitas, salvo en productos B2B a medida.
Puntos 4, 5. Una política de divulgación coordinada de vulnerabilidades vigente y aplicada, junto con avisos públicos una vez disponible la corrección, con un margen estrecho de demora "debidamente justificada".
Qué significa cada deber en la práctica
| # | Deber | Qué exige realmente |
|---|---|---|
| 1 | Identificar y documentar vulnerabilidades y componentes | Un SBOM en CycloneDX o SPDX que cubra al menos las dependencias de primer nivel. El SBOM es el índice que hace posible la correlación con CVE: no se puede remediar lo que no se ha catalogado. |
| 2 | Remediar sin demora, separadamente de las funcionalidades | Sin SLA fijo; la velocidad esperada se escala con la gravedad. Las ramas de seguridad deben ser separables de las ramas de funcionalidades para que los usuarios no puedan posponer un parche posponiendo una versión. |
| 3 | Pruebas eficaces y periódicas | Análisis estático, pruebas dinámicas, escaneo de dependencias contra fuentes de vulnerabilidades y pruebas de penetración. "Periódicas" debe ajustarse al riesgo y al ritmo de cambio del código. |
| 4 | Divulgación pública de las vulnerabilidades corregidas | Una vez disponible la corrección, publicar la descripción, el producto afectado, el impacto, la gravedad y la remediación. Solo se puede demorar "en casos debidamente justificados" hasta que los usuarios puedan aplicar el parche. CVE más CSAF es el soporte de facto. |
| 5 | Política de divulgación coordinada de vulnerabilidades | Una política CVD escrita y aplicada, con canal de recepción, SLA de respuesta y condiciones de divulgación. ISO/IEC 29147 y 30111 ofrecen un marco formal. |
| 6 | Facilitar la notificación externa de vulnerabilidades | Una dirección de contacto para notificar problemas en el producto y en sus componentes de terceros. security.txt conforme a RFC 9116 satisface el requisito de canal. |
| 7 | Distribución segura de actualizaciones | Actualizaciones firmadas y autenticadas, automáticas cuando proceda. Los productos sin canal de actualización deben construir uno o documentar por qué la automatización no es aplicable. Véase actualizaciones de seguridad. |
| 8 | Gratuitas, con mensajes de aviso | Las actualizaciones de seguridad deben distribuirse sin demora y de forma gratuita (única excepción: productos a medida para usuarios profesionales cuando las partes hayan acordado otra cosa). Cada actualización debe llevar un mensaje de aviso que describa el problema y la acción que el usuario debe realizar. Una barrera de mantenimiento de pago, o un parche silencioso sin aviso, incumple el punto 8. |
La gestión de vulnerabilidades y el período de soporte
Los requisitos del anexo I parte II se aplican durante todo el período de soporte definido en el artículo 3(20) y exigido por el artículo 13(8). El período de soporte es de al menos cinco años desde la fecha de introducción del producto en el mercado de la UE, o el período de uso previsto del producto si fuera menor y se hubiera comunicado. La fecha de fin del período de soporte debe figurar en la información del producto conforme al anexo II. Una vez finalizado el período de soporte, los deberes del anexo I parte II decaen para esa versión del producto, pero la obligación de conservación documental conforme al artículo 31 (diez años desde la introducción en el mercado) continúa. Véase período de soporte del CRA.
La gestión de vulnerabilidades no es notificación del artículo 14
El CRA distingue dos obligaciones que operan sobre superficies y destinatarios distintos:
- La gestión de vulnerabilidades del anexo I parte II es el proceso de ingeniería: SBOM, remediación, política CVD, divulgación pública, actualizaciones seguras. Se aplica a todas las vulnerabilidades, en todo momento, durante todo el período de soporte. Se ejecuta a través de la organización de seguridad del producto del fabricante.
- La notificación del artículo 14 es la notificación regulatoria activada por una vulnerabilidad activamente explotada (artículo 3(42)) o un incidente grave que afecte a la seguridad del producto. Se realiza a través de la ENISA Single Reporting Platform con una cadencia de 24h / 72h / 14d hacia ENISA y el CSIRT designado como coordinador. Para la mecánica de incorporación al SRP, véase incorporación al SRP de ENISA.
Un equipo de producto puede cumplir plenamente con el anexo I parte II sin presentar nunca un informe del artículo 14, porque la mayoría de las vulnerabilidades se remedian antes de ser activamente explotadas. El artículo 14 solo se activa cuando la remediación todavía no ha alcanzado a la explotación activa. Véase notificación del artículo 14 del CRA.
Sanciones por incumplimiento
El incumplimiento de los requisitos esenciales del anexo I, incluida la gestión de vulnerabilidades de la parte II, se encuadra en el tramo superior de sanciones administrativas del artículo 64(2): hasta 15.000.000 EUR o el 2,5% de la facturación mundial anual total, el importe que sea mayor. La obligación se aplica desde el 11 de diciembre de 2027 a los productos introducidos en el mercado a partir de esa fecha.
Preguntas frecuentes
¿El SBOM del anexo I parte II punto 1 debe cubrir las dependencias transitivas?
El texto literal exige "al menos las dependencias de primer nivel", que es el suelo regulatorio. Los componentes transitivos no están exigidos por el punto 1, pero sí lo están en la práctica por el punto 2: no se pueden "abordar y remediar vulnerabilidades sin demora" para un CVE en un componente transitivo que nunca se ha catalogado. La mayoría de los reguladores y clientes esperan un SBOM profundo conforme a BSI TR-03183 o guía equivalente. Tanto CycloneDX como SPDX se consideran formatos "ampliamente utilizados y legibles por máquina". Véase requisitos de SBOM del CRA.
¿Qué significa "sin demora" en la práctica para la remediación conforme al punto 2?
El CRA no fija un SLA de remediación específico. "Sin demora" se escala con el riesgo de ciberseguridad: una vulnerabilidad crítica con explotación activa en circulación exige una corrección en días, mientras que un problema de gravedad baja puede esperar al siguiente ciclo regular. La gravedad se establece con CVSS, se afina con datos de probabilidad de explotación de EPSS y se confirma con la evidencia del catálogo CISA KEV cuando la vulnerabilidad figura en la lista de CISA de vulnerabilidades activamente explotadas. Véase puntuación de gravedad para la escala operativa que las autoridades de mercado aplican al juzgar si un fabricante remedió "sin demora".
¿Pueden cobrarse las actualizaciones de seguridad en algún caso?
Solo existe una excepción: el anexo I parte II punto 8 permite un acuerdo de pago para los productos a medida suministrados a un usuario profesional cuando el fabricante y el usuario profesional hayan acordado otra cosa. Para cualquier otro producto, incluidos todos los productos de consumo y todo el SaaS o el hardware B2B estándar, las actualizaciones de seguridad deben ser gratuitas durante todo el período de soporte. Condicionar un parche de seguridad a un nivel de mantenimiento de pago supone un incumplimiento directo del punto 8 y expone al fabricante a las multas del tramo superior del artículo 64(2).
¿Continúan los deberes del anexo I parte II tras finalizar el período de soporte?
No. Los ocho deberes del anexo I parte II se aplican durante todo el período de soporte conforme al artículo 13(8) y decaen para esa versión del producto cuando el período de soporte termina. Dos obligaciones sobreviven al período de soporte: la conservación de la documentación técnica conforme al artículo 31 (diez años desde la introducción en el mercado), y cualquier notificación del artículo 14 que ya estuviera en curso en el momento de la finalización. Las nuevas vulnerabilidades descubiertas tras el fin de soporte no necesitan remediarse para esa versión, pero el fabricante debe haber publicado una fecha clara de fin de soporte en la información del producto para que los usuarios puedan migrar. Véase período de soporte y divulgación del fin de soporte.
¿Cuándo una entrada de CVD se convierte en un activador del artículo 14?
El activador es "activamente explotada" conforme al artículo 3(42), no "notificada" ni "explotable". Una prueba de concepto funcional adjunta a un informe de CVD no es por sí sola un activador del artículo 14; lo es cuando existe creencia razonable de que un actor malicioso ha utilizado el fallo contra un objetivo real. Una vez superado ese umbral, arranca el aviso temprano de 24 horas a ENISA y al CSIRT coordinador, seguido de la notificación de 72 horas y un informe final en los 14 días posteriores a que una medida correctora esté disponible. Véase notificación del artículo 14 del CRA.