Notificación de vulnerabilidades ENISA: el reloj de 24 horas arranca el 11 de septiembre de 2026

11 de septiembre de 2026. A partir de esa fecha, tienes 24 horas para notificar vulnerabilidades activamente explotadas a ENISA. Incumplir ese plazo puede acarrear sanciones.

Esta guía cubre qué activa la notificación, qué significa realmente "activamente explotada" y cómo preparar el proceso interno antes de que llegue el plazo.

Qué activa la notificación CRA

El CRA define dos categorías que requieren notificación obligatoria:

1. Vulnerabilidades activamente explotadas

Una vulnerabilidad en tu producto que:

• Es conocida por ti (descubierta internamente o notificada externamente)
• Ha sido explotada por un actor malicioso
• Afecta o podría afectar a usuarios de tu producto

2. Incidentes graves

Incidentes de seguridad que:

• Impactan la seguridad de tu producto
• Comprometen tu entorno de desarrollo de formas que afectan la seguridad del producto
• Causan interrupción significativa del servicio a usuarios
• Resultan en compromiso generalizado

Ambas categorías activan los mismos plazos de notificación pero tienen diferentes ventanas para el informe final.

¿Qué significa "activamente explotada" según el CRA?

El CRA define una vulnerabilidad activamente explotada como aquella donde "un actor malicioso hace uso de una falla."

Esto no es lo mismo que:

• Una vulnerabilidad siendo divulgada públicamente
• Una prueba de concepto siendo publicada
• Un investigador demostrando explotabilidad

Significa uso malicioso real.

Escenarios notificables vs no notificables

El estándar de "creencia razonable"

No necesitas prueba forense de explotación. El estándar es creencia razonable basada en evidencia disponible:

• Patrones de acceso inusuales consistentes con técnicas de explotación conocidas
• Avisos de clientes sobre compromiso
• Inteligencia de amenazas indicando que tu producto es objetivo
• Detección de código de explotación diseñado para tu producto

Cuando hay incertidumbre: Inclínate hacia notificar. Una alerta temprana prematura que resulta infundada es mucho mejor que un plazo perdido para explotación real.

Plazos de notificación

Tanto vulnerabilidades como incidentes siguen un modelo de notificación escalonado:

Plazo de vulnerabilidad activamente explotada

DESCUBRIMIENTO → 24 HORAS → 72 HORAS → PARCHE DISPONIBLE → 14 DIAS
      │             │           │              │              │
      │             │           │              │              └── Informe Final
      │             │           │              └── Reloj reinicia
      │             │           └── Notificación Detallada
      │             └── Alerta Temprana
      └── Reloj inicia

Plazo de incidente grave

DESCUBRIMIENTO → 24 HORAS → 72 HORAS → 1 MES
      │             │           │         │
      │             │           │         └── Informe Final
      │             │           └── Notificación Detallada
      │             └── Alerta Temprana
      └── Reloj inicia

Qué contiene cada informe

Alerta temprana (24 horas)

Información mínima para alertar a las autoridades:

• Tu identidad (fabricante)
• Identificación de producto(s) afectado(s)
• Descripción breve de la vulnerabilidad/incidente
• Evaluación inicial de severidad
• Si la explotación está confirmada o sospechada
• Indicación del alcance de impacto potencial

Esto no es un análisis completo. Es una alerta de que algo serio está ocurriendo.

Notificación detallada (72 horas)

Información expandida para evaluación:

• Detalles técnicos de la vulnerabilidad
• Versiones y configuraciones afectadas
• Método de explotación (si se conoce)
• Estado actual de mitigación
• Estimación de cronograma de remediación
• Usuarios/alcance afectados conocidos
• Coordinación con otras partes (otros vendedores, CSIRTs)

Informe final (14 días para vulns / un mes para incidentes)

Análisis completo después de la remediación:

• Análisis de causa raíz
• Descripción técnica completa
• Acciones de remediación tomadas
• Lecciones aprendidas
• Medidas de prevención implementadas
• Evaluación de impacto (usuarios afectados confirmados, exposición de datos, etc.)

¿Dónde se notifica una vulnerabilidad a ENISA?

Plataforma Única de Notificación (SRP) de ENISA

El SRP no está operativo a fecha de abril de 2026. ENISA ha contratado a un proveedor y la plataforma está prevista para abrirse el 11 de septiembre de 2026, cuando comiencen las obligaciones de notificación. Está planificado un período de pruebas antes de esa fecha. No se ha publicado ninguna URL de registro. Consulta la página SRP de ENISA para actualizaciones: https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp

Lo que está confirmado:

• Plataforma web para envíos
• Formularios de notificación estandarizados
• Un único envío enrutado al CSIRT nacional relevante

Lo que los fabricantes pueden hacer ahora:

• Redactar plantillas de informes con la estructura indicada más abajo
• Identificar tu CSIRT coordinador (ver más abajo)
• Definir rutas de escalación internas y responsables de notificación autorizados

CSIRTs nacionales

Conforme al Artículo 14(7) del Reglamento (UE) 2024/2847, el envío se realiza una sola vez a través del SRP al CSIRT del Estado miembro donde tu organización tenga su establecimiento principal. Establecimiento principal significa donde se toman principalmente las decisiones sobre ciberseguridad del producto.

Si estás establecido fuera de la UE, el CSIRT relevante es el del representante autorizado en la UE. Si no tienes representante autorizado, la cadena se traslada al importador, luego al distribuidor, y a continuación al país con mayor concentración de usuarios.

No es necesario notificar a cada CSIRT de cada país donde se vende el producto. Conforme al Artículo 16, ENISA se encarga de enrutar la notificación a los CSIRTs de los países de mercado una vez que has enviado. Ese paso no es responsabilidad del fabricante.

Para productos en múltiples estados miembros

Un único envío al SRP cubre la obligación de notificación. Puedes recibir seguimiento de varias autoridades nacionales, pero hay un único punto de envío.

Lista de verificación de preparación interna

Empieza a construirlos ya.

1. Canales de recepción de vulnerabilidades

Establece rutas claras para la notificación de vulnerabilidades:

Archivo security.txt:

# https://tuproducto.com/.well-known/security.txt
Contact: mailto:security@tuempresa.com
Contact: https://tuempresa.com/security/report
Expires: 2027-01-01T00:00:00.000Z
Preferred-Languages: es, en
Canonical: https://tuempresa.com/.well-known/security.txt
Policy: https://tuempresa.com/security/policy

Formulario web para notificaciones estructuradas

Email dedicado monitorizado 24/7 (o con SLA claro)

2. Proceso de triaje interno

Define cómo se evalúan las notificaciones:

TRIAJE DE RECEPCIÓN DE VULNERABILIDADES

1. Recepción inicial (< 4 horas)
   - Confirmar recepción
   - Asignar a miembro del equipo de seguridad
   - Verificación inicial de validez

2. Triaje técnico (< 24 horas)
   - Confirmar que la vulnerabilidad existe
   - Determinar versiones afectadas
   - Evaluar explotabilidad
   - Verificar evidencia de explotación activa

3. Evaluación de severidad (< 24 horas)
   - Puntuación CVSS (o equivalente)
   - Evaluación de impacto empresarial
   - Probabilidad de explotación

4. Decisión de notificación (INMEDIATA si se confirma explotación)
   - ¿Requiere esto notificación a ENISA?
   - Si es sí, iniciar reloj de 24 horas

3. Rutas de escalación

Define quién puede activar notificación externa:

Principio clave: La persona que descubre explotación potencial debe poder escalar inmediatamente, 24/7.

4. Cobertura fuera de horario

El reloj de 24 horas no se pausa por fines de semana o festivos.

Opciones:

• Rotación de guardia para equipo de seguridad
• Servicio de monitorización con autoridad de escalación
• Cadena de contacto fuera de horario clara
• Responsables de notificación pre-autorizados que pueden enviar alertas tempranas

5. Plantillas de notificación

Prepara plantillas antes de necesitarlas:

Plantilla de alerta temprana:

ALERTA TEMPRANA CRA ENISA

Fabricante: [Nombre de la Empresa]
Fecha del Informe: [Fecha/Hora UTC]
Tipo de Informe: [ ] Vulnerabilidad Activamente Explotada [ ] Incidente Grave

PRODUCTO(S) AFECTADO(S):
- Nombre del Producto:
- Versión(es):
- Categoría del Producto:

RESUMEN DE VULNERABILIDAD/INCIDENTE:
[Descripción breve - 2-3 oraciones]

ESTADO DE EXPLOTACIÓN:
[ ] Explotación confirmada
[ ] Explotación sospechada
Evidencia: [Descripción breve de evidencia]

EVALUACIÓN INICIAL DE SEVERIDAD:
[ ] Crítica [ ] Alta [ ] Media [ ] Baja
Base: [Puntuación CVSS u otra justificación]

ALCANCE DE IMPACTO POTENCIAL:
- Usuarios afectados estimados:
- Alcance geográfico:
- Datos en riesgo:

ESTADO ACTUAL:
[ ] Bajo investigación
[ ] Mitigación en progreso
[ ] Parche en desarrollo

CONTACTO PARA SEGUIMIENTO:
Nombre:
Email:
Teléfono:

Esta es una alerta temprana. Notificación detallada a seguir en 72 horas.

6. Prueba tu proceso

Ejecuta ejercicios de mesa antes de septiembre 2026:

Escenario 1: Viernes 5pm - Investigador de seguridad notifica vulnerabilidad crítica con PoC

• ¿Qué tan rápido puedes evaluar el riesgo de explotación?
• ¿Quién toma la decisión de notificación durante el fin de semana?

Escenario 2: Cliente notifica actividad sospechosa sugiriendo que tu producto fue punto de entrada

• ¿Cómo recopilas evidencia para confirmar/negar explotación?
• ¿Cuál es tu umbral para "creencia razonable"?

Escenario 3: Inteligencia de amenazas indica que tu producto está siendo objetivo de grupo APT

• ¿Tienes visibilidad sobre explotación real?
• ¿Cómo coordinas con proveedores externos de inteligencia de amenazas?

Errores comunes

Esperar certeza

Problema: Querer prueba forense antes de notificar.

Realidad: El reloj de 24 horas inicia cuando tienes creencia razonable. Si esperas certeza, perderás el plazo.

Solución: Notifica temprano. Puedes actualizar con "ya no se cree que esté explotada" en la notificación detallada si la evidencia no lo respalda.

Confundir CVD con notificación

Problema: Tratar notificaciones de investigadores como notificaciones a ENISA.

Realidad: La divulgación coordinada de vulnerabilidades y la notificación a ENISA son procesos separados.

• CVD: cómo gestionas notificaciones de investigadores, acuerdas plazos de divulgación
• ENISA: notificación obligatoria cuando ocurre explotación

Solución: El proceso CVD debe incluir una puerta: "¿Hay evidencia de explotación?" Si es sí, activar notificación a ENISA en paralelo a CVD.

Punto único de fallo

Problema: Solo una persona puede autorizar notificaciones, y está inalcanzable.

Realidad: La explotación puede descubrirse en cualquier momento. Fines de semana. Festivos. 3am.

Solución: Múltiples responsables de notificación autorizados. Delegación clara. Cadena de contacto de emergencia.

Sin relación con CSIRTs

Problema: Primer contacto con tu CSIRT nacional es durante un incidente.

Realidad: Construir relaciones de antemano hace la respuesta a incidentes más fluida.

Solución: Involucra a tu CSIRT nacional ahora. Entiende sus procesos. Únete a cualquier programa de alcance a fabricantes.

Exenciones para microempresas y pequeñas empresas

Las microempresas y pequeñas empresas tienen algo de alivio conforme al Artículo 64(10)(a):

Exención de plazos de notificación: Exentas de multas por incumplir el plazo de alerta temprana de 24 horas de los Artículos 14(2)(a) y 14(4)(a). El plazo de 72 horas para la notificación detallada (Artículos 14(2)(b) y 14(4)(b)) no está cubierto. Incumplirlo puede resultar en multas independientemente del tamaño de la empresa.

Aún se requiere:

• Notificación (solo sin penalización por el plazo de 24 horas)
• Todas las demás obligaciones del CRA
• Informes finales

Definición (Artículo 64(10)(a)): Se aplica a microempresas (menos de 10 empleados, facturación anual o balance ≤ 2 millones EUR) y pequeñas empresas (menos de 50 empleados, facturación anual o balance ≤ 10 millones EUR). Las medianas empresas (hasta 250 empleados) no están cubiertas por esta exención.

Esta exención cubre únicamente la penalización por la alerta temprana de 24 horas. Todos los fabricantes, incluidas las microempresas, deben establecer capacidades de notificación.

Integración con procesos existentes

Si ya tienes respuesta a incidentes

Mapea la notificación CRA a tu proceso existente:

PROCESO IR EXISTENTE          INTEGRACIÓN CRA
─────────────────────────────────────────────
Detección
    │
Triaje ──────────────────→  Verificar: ¿Explotación de producto CRA?
    │                             │
Contención                        ├─ SÍ: Activar reloj de 24h
    │                             │       Enviar alerta temprana
Investigación                     │
    │                             │
Remediación ──────────────→  Notificación detallada 72h
    │
Recuperación
    │
Lecciones Aprendidas ────→  Informe final 14d/1 mes

Si tienes obligaciones NIS 2

Algunas organizaciones tienen obligaciones tanto NIS 2 como CRA:

• NIS 2: Incidentes a nivel de organización/servicio
• CRA: Vulnerabilidades e incidentes a nivel de producto

Estos pueden superponerse. Un solo incidente podría requerir ambos:

• Notificación NIS 2 a autoridad competente
• Notificación CRA a ENISA/CSIRT

ENISA ha indicado que el SRP gestionará el enrutamiento para ambos regímenes donde aplique. Esto no ha sido confirmado en orientación definitiva.

Lista de verificación de preparación para notificación a ENISA

LISTA DE VERIFICACIÓN DE PREPARACIÓN PARA NOTIFICACIÓN A ENISA

ANTES DE SEPTIEMBRE 2026:

CANALES Y CONTACTOS
[ ] security.txt publicado y actual
[ ] Formulario de notificación de vulnerabilidades disponible
[ ] Email de seguridad monitorizado (definir SLA: ____ horas)
[ ] Contacto de CSIRT nacional identificado
[ ] Registro en SRP de ENISA (cuando esté disponible)

PROCESO INTERNO
[ ] Criterios de triaje documentados
[ ] Lista de verificación de evaluación de explotación creada
[ ] Ruta de escalación definida (nombres, contactos)
[ ] Responsables de notificación autorizados identificados
[ ] Cobertura fuera de horario establecida

DOCUMENTACIÓN
[ ] Plantilla de alerta temprana preparada
[ ] Plantilla de notificación detallada preparada
[ ] Plantilla de informe final preparada
[ ] Materiales de briefing interno listos

PRUEBAS
[ ] Ejercicio de mesa completado
[ ] Escalación fuera de horario probada
[ ] Revisión de plantillas completada

CUANDO SE DETECTA EXPLOTACIÓN:

INMEDIATO (dentro de 4 horas)
[ ] Evaluación inicial: ¿Está activamente explotado?
[ ] Hora de inicio del reloj documentada: ____________
[ ] Escalación a responsable de notificación autorizado

DENTRO DE 24 HORAS
[ ] Alerta temprana enviada al SRP de ENISA
[ ] Confirmación de envío recibida
[ ] Partes interesadas internas notificadas

DENTRO DE 72 HORAS
[ ] Notificación detallada enviada
[ ] Estado de mitigación actualizado
[ ] Comunicación con clientes iniciada (si apropiado)

DENTRO DE 14 DÍAS (vulnerabilidad) / UN MES (incidente)
[ ] Informe final enviado
[ ] Lecciones aprendidas documentadas
[ ] Mejoras de proceso identificadas

Próximos pasos

¿Gestiona el cumplimiento del CRA para varios productos? CRA Evidence realiza un seguimiento de los plazos y proporciona plantillas de informes predefinidas para las divulgaciones de vulnerabilidades de cada producto.

Una vez que tu proceso de triaje esté en marcha, configura la recepción de vulnerabilidades con nuestra plantilla de política CVD. Consulta la guía de sanciones para entender las consecuencias si se incumplen los plazos.

Este artículo es solo para fines informativos y no constituye asesoramiento legal. Para orientación específica sobre cumplimiento, consulta con asesores legales cualificados familiarizados con las regulaciones de productos de la UE.