CRA notificación de vulnerabilidades: ENISA SRP 24h/72h/14d

El Reglamento de Ciberresiliencia de la UE (Reglamento (UE) 2024/2847) convierte la notificación de vulnerabilidades en una obligación legal sujeta a plazos fijos para todo fabricante de un producto con elementos digitales. A partir del 11 de septiembre de 2026, el Artículo 14 exige notificar las vulnerabilidades activamente explotadas y los incidentes graves a través de la ENISA Single Reporting Platform (SRP) con una cadencia de 24 horas / 72 horas / 14 días, respaldada por una política de divulgación coordinada de vulnerabilidades (CVD) obligatoria en virtud del Anexo I Parte II. Esta página es la referencia canónica: qué exige la ley, cuándo arranca cada reloj, qué debe contener una política CVD conforme, cómo VEX respalda la obligación de "ninguna vulnerabilidad explotable conocida" y qué multas del Artículo 64 se aplican cuando la notificación falla.

¿Qué exige el CRA en materia de notificación de vulnerabilidades?

El Artículo 14 del Reglamento de Ciberresiliencia es el núcleo operativo del régimen de gestión de incidentes del reglamento. Impone tres obligaciones a todo fabricante de un producto con elementos digitales comercializado en el mercado de la UE:

1. Notificar cualquier vulnerabilidad activamente explotada en el producto simultáneamente al CSIRT coordinador y a ENISA, con la cadencia de 24 h / 72 h / 14 d (Art. 14(1), 14(2)).
2. Notificar cualquier incidente grave que afecte a la seguridad del producto con la cadencia de 24 h / 72 h / 1 mes (Art. 14(3), 14(4)).
3. Informar a los usuarios del producto afectado sobre la vulnerabilidad o el incidente y sobre cualquier medida correctora, sin demora indebida (Art. 14(8)).

El Artículo 14 se acompaña de otras dos obligaciones que esta página también cubre: la política CVD obligatoria del Anexo I Parte II y el requisito de "ninguna vulnerabilidad explotable conocida" del Anexo I Parte I, que es la razón por la que VEX importa en un producto conforme con el CRA. Ninguna de estas obligaciones tiene un umbral de tamaño. Las pymes se benefician de un alivio puntual de sanciones en el reloj de 24 horas (véase más abajo), pero no están exentas de notificar.

La ENISA Single Reporting Platform (SRP)

La SRP es el canal único por el que fluye cada notificación del Artículo 14. Existe porque el Artículo 14(1) exige al fabricante notificar simultáneamente al CSIRT coordinador y a ENISA, y 27 envíos separados serían inviables. El Artículo 16(1) encomienda a ENISA la responsabilidad operativa de la plataforma: "las operaciones cotidianas de dicha plataforma única de notificación serán gestionadas y mantenidas por ENISA."

Cómo funciona en la práctica:

• Se envía una sola vez, utilizando el punto de conexión electrónico del CSIRT designado como coordinador en virtud del Artículo 14(7).
• El envío llega simultáneamente al CSIRT coordinador y a ENISA.
• El CSIRT coordinador difunde después la notificación a los CSIRTs de los demás Estados miembros donde el producto se comercializa (Art. 16). Esa difusión secundaria es responsabilidad del CSIRT, no del fabricante.
• El Artículo 16(2) permite a un CSIRT retrasar la difusión en circunstancias especialmente excepcionales. El Artículo 16(6) permite un retraso durante la divulgación coordinada con el consentimiento del fabricante.

Estado a mayo de 2026: la SRP está prevista para estar operativa el 11 de septiembre de 2026, según la página de la ENISA SRP. La implementación fue licitada bajo ENISA/2025/OP/0001 (contrato de 4 años) con la licitación cerrada en marzo de 2025. El proveedor no ha sido divulgado públicamente. No se ha publicado ninguna URL de registro. Se espera un periodo de pruebas antes del lanzamiento; no se han anunciado fechas concretas. Los actos de ejecución del Artículo 14 que establecen los formatos y la estructura de las notificaciones estaban pendientes en el momento de redactar este artículo.

Qué deben hacer los fabricantes ahora: identificar el CSIRT coordinador en virtud del Artículo 14(7), redactar y preapprobar plantillas de informe para los envíos de 24 h, 72 h y 14 d, y definir una rotación de guardia fuera de horario. Las plantillas y los procesos no pueden redactarse mientras el reloj de 24 horas está en marcha.

Plazos de notificación en detalle

Tanto las vulnerabilidades como los incidentes graves siguen un modelo de notificación escalonado. Los relojes difieren en el tramo del informe final.

Calendario de notificación del Artículo 14

Etapa	Vulnerabilidad (Art. 14(2))	Incidente grave (Art. 14(4))	Ancla del reloj
Alerta temprana	24 horas	24 horas	El fabricante tiene conocimiento
Notificación detallada	72 horas	72 horas	El fabricante tiene conocimiento
Informe final	14 días desde que se dispone de medida correctora o paliativa	1 mes desde la notificación de incidente de 72 horas	Ancla distinta para cada vía
Información a usuarios	Sin demora indebida	Sin demora indebida	Conforme al Art. 14(8)

Qué contiene cada envío

Alerta temprana (24 horas). Información mínima para alertar a las autoridades: identidad del fabricante, producto afectado y versión, descripción breve, severidad inicial, si la explotación está confirmada o sospechada, e indicación del alcance de impacto. La alerta temprana es una señal de aviso, no un análisis.

Notificación detallada (72 horas). En esta etapa conviven dos obligaciones distintas. La notificación de vulnerabilidad de 72 horas del Artículo 14(2)(b) se aplica a las vulnerabilidades activamente explotadas. La notificación de incidente de 72 horas del Artículo 14(4)(b) se aplica a los incidentes graves. En ambos casos el envío amplía la alerta temprana con detalles técnicos, versiones y configuraciones afectadas, método de explotación (si se conoce), estado actual de mitigación, calendario de remediación, alcance de usuarios afectados conocido y cualquier coordinación en curso con terceros.

Informe final. Para las vulnerabilidades, el reloj de 14 días comienza "a más tardar 14 días después de que se disponga de una medida correctora o paliativa" (Art. 14(2)(c)), no desde el descubrimiento ni desde la notificación de 72 horas. Para los incidentes graves, el reloj de 1 mes se ancla a la notificación de incidente de 72 horas del Artículo 14(4)(c). El informe final cubre la causa raíz, la descripción técnica completa, las acciones de remediación adoptadas, las medidas de prevención implementadas y la evaluación de impacto confirmada.

1. Conocimiento del fabricante. El reloj de 24 horas arranca en el momento en que se forma una creencia razonable de explotación activa.
2. + 24 horas. Alerta temprana enviada a través de la ENISA SRP (Art. 14(2)(a)).
3. + 72 horas. Notificación detallada enviada con detalles técnicos, versiones afectadas y estado de mitigación (Art. 14(2)(b)).
4. Medida correctora o paliativa disponible. El reloj de 14 días para el informe final comienza aquí, no en el descubrimiento.
5. + 14 días. Informe final enviado: causa raíz, descripción técnica completa, remediación, impacto confirmado (Art. 14(2)(c)).

¿Qué activa la obligación de notificación?

El Artículo 14 contempla dos categorías de activación.

1. Vulnerabilidades activamente explotadas

Una vulnerabilidad en el producto que:

• es conocida por el fabricante (descubierta internamente o notificada externamente),
• ha sido utilizada por un actor malicioso, y
• afecta o podría afectar a los usuarios del producto.

El CRA define una vulnerabilidad activamente explotada como aquella en la que "un actor malicioso hace uso de una falla." Esto no equivale a divulgación pública, un PoC publicado o un investigador que demuestra la explotabilidad. El activador es el uso malicioso real.

2. Incidentes graves

Incidentes de seguridad que impactan la seguridad del producto, comprometen el entorno de desarrollo de forma que afecta a la seguridad del producto, causan una interrupción generalizada del servicio a los usuarios, o resultan en un compromiso generalizado.

Escenarios notificables frente a no notificables

Escenario	¿Notificable?	Por qué
Investigador notifica una vulnerabilidad de forma privada	No	Sin evidencia de explotación; gestionar mediante CVD
PoC publicado en GitHub	No	La publicación no es explotación
Cliente notifica actividad compatible con la vulnerabilidad	Sí	Umbral de creencia razonable alcanzado
Vulnerabilidad detectada siendo explotada activamente	Sí	Uso malicioso activo
Componente en el SBOM tiene un CVE explotado conocido	Evaluar	Solo notificable si la explotación afecta al producto (aquí importa VEX)
El producto es objetivo de actores de amenaza concretos	Sí	Evidencia directa de explotación
Malware genérico usa la clase de vulnerabilidad del producto	Evaluar	Solo si la implementación específica está afectada

El criterio de "creencia razonable"

No se requiere prueba forense de explotación. El criterio del Artículo 14 es la creencia razonable basada en la evidencia disponible: patrones de acceso inusuales compatibles con técnicas de explotación conocidas, informes de clientes sobre compromiso, inteligencia de amenazas que indique que el producto es objetivo, o detección de código de explotación diseñado para el producto. Ante la duda, se debe notificar. Una alerta temprana prematura que resulta infundada es mucho mejor que un plazo incumplido por explotación real, y la notificación de 72 horas puede actualizar la evaluación.

Política de divulgación coordinada de vulnerabilidades (CVD): la conexión con el artículo 14

El Anexo I, Parte II, apartado 5 del CRA exige a los fabricantes "establecer y aplicar una política de divulgación coordinada de vulnerabilidades". La política CVD es el mecanismo operativo que convierte los informes externos de investigadores en un flujo de triaje estructurado y, cuando ese triaje detecta explotación activa, dispara en paralelo el reloj de notificación del artículo 14. La obligación se aplica a todo producto con elementos digitales, sin umbral por tamaño ni exención para pymes. La entrega mínima es una URL pública más un archivo security.txt en /.well-known/security.txt (RFC 9116), para que los informes sean localizables por los investigadores a quienes el reglamento pretende dar voz.

Para la política CVD en sí (contenidos exigidos, ventanas de divulgación, cláusula de puerto seguro y plantillas de comunicación con investigadores), consulta la guía dedicada de divulgación coordinada CRA. Para encajar la CVD en el resto de las obligaciones del Anexo I Parte II (SBOM, remediación, actualizaciones seguras, entrega gratuita), consulta la gestión de vulnerabilidades del CRA. Esta página se centra en la cadencia de notificación del artículo 14 que se activa cuando el triaje confirma la explotación activa.

VEX: comunicar la aplicabilidad de vulnerabilidades

El Anexo I Parte I exige que los productos CRA se comercialicen sin vulnerabilidades explotables conocidas y con una configuración segura por defecto. El análisis de SBOMs produce largas listas de CVEs en componentes, la mayoría de los cuales no son realmente explotables en el producto específico. VEX (Vulnerability Exploitability eXchange) es el mecanismo que convierte esos resultados de análisis en bruto en una posición defendible de "no afectado / afectado / corregido / bajo investigación" por CVE, que es lo que esperan el reglamento, las normas armonizadas en desarrollo y la contratación pública alemana bajo BSI TR-03183 Parte 3.

Qué es VEX

VEX es una declaración estructurada y legible por máquina sobre si una vulnerabilidad en un componente afecta realmente a un producto específico. Responde a: "CVE-XXXX existe en nuestro SBOM. ¿Afecta a nuestro producto, por qué o por qué no, y qué debe hacer el usuario?" Los cuatro estados principales son:

Estado	Significado
not_affected	La vulnerabilidad existe en el componente pero no afecta a este producto (ruta de código vulnerable inalcanzable, función no llamada, configuración que mitiga, etc.). Se espera una justificación.
affected	La vulnerabilidad afecta a este producto. Se espera acción y recomendación.
fixed	La vulnerabilidad estaba presente y ha sido corregida en esta versión.
under_investigation	Estado no determinado aún; evaluación en curso.

Conexión con el CRA

VEX no se nombra en el texto del CRA, pero es la herramienta operativa detrás de tres cláusulas del reglamento:

• Anexo I Parte I, ninguna vulnerabilidad explotable conocida. Una declaración VEX not_affected con una justificación documentada es la evidencia de que se ha evaluado un CVE y se ha concluido que no aplica. Sin ella, todo CVE en el SBOM es una presunta responsabilidad.
• Anexo I Parte II, gestión de vulnerabilidades. VEX es la pista de auditoría de cómo cada CVE pasó de under_investigation a not_affected, affected o fixed a lo largo del tiempo.
• Artículo 14, activadores de notificación. Una vulnerabilidad marcada como affected y con evidencia de explotación activa es exactamente el activador que inicia el reloj de 24 horas. Una vulnerabilidad marcada como not_affected con justificación sólida no lo es.

Formatos VEX

Dos formatos son relevantes en la práctica. CycloneDX VEX se incrusta directamente en un SBOM CycloneDX bajo vulnerabilities[].analysis. CSAF VEX es un documento independiente en CSAF 2.0 (el formato que BSI TR-03183 Parte 3 exige para los avisos de seguridad, y el formato que los CERT alemanes publican y consumen por defecto). Ambos son legibles por máquina y ambos satisfacen el mismo papel operativo.

Una afirmación VEX mínima en CycloneDX:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "vulnerabilities": [
    {
      "id": "CVE-2027-XXXXX",
      "source": { "name": "NVD" },
      "analysis": {
        "state": "not_affected",
        "justification": "code_not_reachable",
        "detail": "The vulnerable function is not called in our implementation."
      },
      "affects": [{ "ref": "pkg:generic/openssl@3.0.12" }]
    }
  ]
}

La especificación CycloneDX 1.5 define seis estados de análisis (in_triage, exploitable, not_affected, false_positive, resolved, resolved_with_pedigree), un vocabulario más granular que los cuatro de OpenVEX (not_affected, affected, fixed, under_investigation), sobre los que se proyecta. BSI TR-03183 Parte 3 espera declaraciones VEX junto a los SBOMs para productos alineados con el CRA. Para el panorama completo de SBOM y BSI TR-03183, consulta la guía del clúster SBOM.

Exenciones para pymes y obligaciones reducidas

El Artículo 64(10) prevé un alivio puntual de sanciones para los fabricantes más pequeños. No exime a nadie de notificar.

Microempresas y pequeñas empresas (definidas como menos de 50 empleados y una facturación anual o balance de hasta 10 millones de EUR; microempresas: menos de 10 empleados, 2 millones de EUR) están exentas de multas específicamente por incumplir los plazos de alerta temprana de 24 horas del Artículo 14(2)(a) y del Artículo 14(4)(a). El alivio cubre únicamente las multas por el plazo de 24 horas.

Obligaciones que siguen siendo exigibles, sin alivio para pymes:

• La notificación detallada de 72 horas (Art. 14(2)(b) y 14(4)(b)).
• El informe final de 14 días para vulnerabilidades y el informe final de 1 mes para incidentes graves.
• La política CVD del Anexo I Parte II.
• Todas las demás obligaciones del CRA, incluido el requisito de "ninguna vulnerabilidad explotable conocida" del Anexo I Parte I.

Las medianas empresas (hasta 250 empleados) no están cubiertas en absoluto por el alivio para pymes. La exención es un alivio puntual de sanciones, no un régimen de notificación reducido.

Errores habituales

• Esperar certeza forense antes de iniciar el reloj. El Artículo 14 aplica un criterio de creencia razonable. Esperar prueba hace que se pierda el plazo.
• Confundir CVD con la notificación del Artículo 14. El informe de un investigador es una entrada al proceso CVD; la notificación del Artículo 14 se activa cuando hay evidencia de explotación activa. La política CVD debe contener una puerta explícita para esto.
• Escalación con punto único de fallo. Una sola persona autorizada para notificar, ilocalizable un viernes por la noche. El reloj de 24 horas no se pausa.
• Primer contacto con el CSIRT coordinador durante un incidente. Hay que establecer la relación y el enrutamiento ahora, mientras no hay ningún reloj en marcha.
• Sin política CVD publicada. La obligación del Anexo I Parte II no se satisface con un documento interno.
• Sin declaraciones VEX. Todo CVE en el SBOM se presume explotable hasta que se diga lo contrario. El Anexo I Parte I es mucho más difícil de defender sin VEX.
• Tratar el lanzamiento de la SRP como un problema futuro. Las plantillas, las rotaciones de escalación y las relaciones con los CSIRT deben estar en marcha antes de septiembre de 2026, no construirse después.