Reglamento de Ciberresiliencia: notificación 24 h vía ENISA SRP

El Reglamento de Ciberresiliencia (Cyber Resilience Act, Reglamento (UE) 2024/2847) convierte la notificación de vulnerabilidades e incidentes en una obligación legal con plazos fijos para los fabricantes. A partir del 11 de septiembre de 2026, el Artículo 14 del CRA exige notificar vulnerabilidades activamente explotadas e incidentes graves en 24 horas, con una escalada a notificación detallada en 72 horas, informe final en 14 días para vulnerabilidades (desde que se disponga de una medida correctora o paliativa) e informe final en un mes para incidentes graves. El canal de notificación es la ENISA Single Reporting Platform (SRP), cuya entrada en funcionamiento está prevista para el 11 de septiembre de 2026, y que enruta tu envío simultáneamente al CSIRT coordinador designado y a ENISA. Incumplir el plazo expone al fabricante a las sanciones del Artículo 64 del CRA, de hasta 15.000.000 EUR o el 2,5% de la facturación mundial anual, lo que sea mayor (Art. 64).

Qué es la ENISA SRP en el contexto del CRA

El CRA necesitaba un canal único porque el Artículo 14(1) exige a los fabricantes notificar "simultáneamente al CSIRT designado como coordinador, de conformidad con el apartado 7 del presente artículo, y a ENISA." Sin la SRP, eso implicaría presentar el mismo informe ante múltiples CSIRTs nacionales. El Artículo 16 resuelve esa tensión: ENISA establece y opera la plataforma, y "las operaciones cotidianas de dicha plataforma única de notificación serán gestionadas y mantenidas por ENISA" (Art. 16(1)).

La arquitectura es sencilla. Envías una sola vez a la SRP utilizando el punto de conexión electrónico de tu CSIRT coordinador. Tanto el CSIRT como ENISA reciben la notificación simultáneamente. Bajo el Artículo 16, el CSIRT coordinador es responsable de difundir la notificación a los CSIRTs de los demás Estados miembros donde tu producto se comercialice. La difusión secundaria es responsabilidad del CSIRT, no del fabricante.

La SRP está prevista para estar operativa el 11 de septiembre de 2026, según la FAQ de ENISA sobre la SRP. Se espera un periodo de pruebas antes de esa fecha; no se han publicado fechas concretas del periodo de pruebas. ENISA licitó la implementación 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. Consulta la página de la ENISA SRP para obtener actualizaciones.

Qué activa la obligación de notificación al CRA

El Reglamento de Ciberresiliencia 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 una interrupción generalizada del servicio a los usuarios
• Resultan en un compromiso generalizado

Ambas categorías activan el mismo requisito de alerta temprana, pero tienen ventanas distintas para el informe final.

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

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

Esto no equivale a:

• Una vulnerabilidad que ha sido divulgada públicamente
• Una prueba de concepto publicada
• Un investigador que demuestra explotabilidad

Significa uso malicioso real.

Escenarios notificables frente a no notificables

El criterio de "creencia razonable"

No necesitas prueba forense de explotación. El criterio es creencia razonable basada en la evidencia disponible:

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

Ante la incertidumbre: inclínate hacia notificar. Una alerta temprana prematura que resulta infundada es mucho mejor que un plazo incumplido por explotación real.

Plazos de notificación

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

Plazo para vulnerabilidades activamente explotadas

DESCUBRIMIENTO → 24 HORAS → 72 HORAS → PARCHE DISPONIBLE → 14 DÍAS
      |              |           |              |               |
      |              |           |              |               \-- Informe Final
      |              |           |              \-- Reloj reinicia
      |              |           \-- Notificación Detallada
      |              \-- Alerta Temprana
      \-- Reloj inicia

Plazo para incidentes graves

DESCUBRIMIENTO → 24 HORAS → 72 HORAS → 1 MES
      |              |           |          |
      |              |           |          \-- Informe Final
      |              |           \-- Notificación de Incidente
      |              \-- Alerta Temprana
      \-- Reloj inicia

Para los incidentes graves, el plazo de un mes se ancla a la notificación de incidente de 72 horas, no al descubrimiento (Art. 14(4)(c)).

Qué contiene cada notificación

Alerta temprana (24 horas)

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

• Tu identidad (fabricante)
• Identificación del producto o productos afectados
• Descripción breve de la vulnerabilidad o del 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 grave está ocurriendo.

Notificación detallada (72 horas)

A las 72 horas se aplican dos obligaciones separadas. La notificación de vulnerabilidad de 72 horas (Art. 14(2)(b)) se aplica a vulnerabilidades activamente explotadas; la notificación de incidente de 72 horas (Art. 14(4)(b)) se aplica a incidentes graves. Información ampliada para la 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 del plazo de remediación
• Usuarios afectados o alcance conocido
• Coordinación con otras partes (otros fabricantes, CSIRTs)

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

Para vulnerabilidades activamente explotadas, el plazo de 14 días empieza "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. Análisis completo tras 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.)

La base legal del CRA: artículos 14, 16 y 64

Artículo 14 del CRA: la obligación de notificación

El Artículo 14 establece la obligación de notificación y los plazos para todos los fabricantes de productos con elementos digitales. En su parte pertinente dice: "Un fabricante notificará cualquier vulnerabilidad que esté siendo activamente explotada y que esté contenida en el producto con elementos digitales de la que tenga conocimiento, simultáneamente al CSIRT designado como coordinador, de conformidad con el apartado 7 del presente artículo, y a ENISA." (Art. 14(1)).

El Artículo 14(7) establece la regla de enrutamiento. El envío se realiza al CSIRT del Estado miembro donde tu organización tenga su establecimiento principal, es decir, donde se toman principalmente las decisiones sobre la ciberseguridad del producto. Para fabricantes no establecidos en la UE, la cadena es: el Estado miembro de tu representante autorizado, luego el de tu importador, luego el de tu distribuidor, y finalmente el país con mayor concentración de usuarios. Para fabricantes con más de un representante autorizado, la cadena escoge el Estado miembro en que el representante cubre el mayor número de productos.

Artículo 16 del CRA: el mandato de la plataforma

El Artículo 16(1) obliga a ENISA a establecer la SRP y gestionar sus operaciones cotidianas. Los Estados miembros también pueden crear puntos de acceso nacionales que se conecten a la SRP (Art. 16(1)). Bajo el Artículo 16(2), los CSIRTs pueden retrasar la difusión de notificaciones a otros Estados miembros en circunstancias excepcionalmente específicas para proteger operaciones de seguridad en curso, pero esta es prerrogativa del CSIRT, no del fabricante. El Artículo 16(5) exige a ENISA y a la Red de CSIRTs desarrollar conjuntamente las especificaciones técnicas de la SRP. El Artículo 16(6) aborda la interacción con la divulgación coordinada: una vulnerabilidad sometida a divulgación coordinada puede tener la difusión retrasada con el consentimiento del fabricante.

Dónde enviar una notificación bajo el Artículo 14 del CRA

ENISA Single Reporting Platform (SRP)

La SRP no está operativa a fecha de abril de 2026. La plataforma está prevista para estar operativa el 11 de septiembre de 2026 (según la FAQ de ENISA). Se espera un periodo de pruebas antes de esa fecha; no se han publicado fechas concretas. No se ha publicado ninguna URL de registro. Consulta la página de la ENISA SRP para obtener actualizaciones.

Lo que está confirmado:

• Plataforma web para envíos
• Formularios de notificación estandarizados
• El envío vía la ENISA SRP llega simultáneamente al CSIRT coordinador designado y a ENISA (Art. 14(1))

Lo que los fabricantes pueden hacer ahora:

• Redactar plantillas de notificación usando la estructura que se detalla a continuación
• 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 de la SRP al CSIRT del Estado miembro donde tu organización tenga su establecimiento principal. Establecimiento principal significa donde se toman principalmente las decisiones sobre la ciberseguridad del producto.

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

No es necesario notificar a cada CSIRT de cada país donde vendes el producto. Bajo el Artículo 16, ENISA enruta la notificación hacia los CSIRTs de los países de mercado una vez que realizas el envío. Ese paso no es responsabilidad del fabricante.

Para productos en varios Estados miembros

Un único envío a la SRP cubre tu obligación de notificación. Es posible que recibas seguimiento de varias autoridades nacionales, pero hay un único punto de envío.

Cómo prepararse para la notificación bajo el Artículo 14 del CRA

No esperes a septiembre de 2026. Construye tus procesos ahora.

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 notificación a ENISA?
   - Si es sí, iniciar reloj de 24 horas

3. Rutas de escalación

Define quién puede activar la notificación externa:

Principio clave: la persona que descubre una posible explotación debe poder escalar inmediatamente, 24/7.

4. Cobertura fuera de horario

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

Opciones:

• Rotación de guardia para el 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 las 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 la 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 curso
[ ] 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 de 2026:

Escenario 1: Viernes a las 17 h. Un investigador de seguridad notifica una vulnerabilidad crítica con PoC.

• ¿Con qué rapidez puedes evaluar el riesgo de explotación?
• ¿Quién toma la decisión de notificación durante el fin de semana?

Escenario 2: Un cliente notifica actividad sospechosa que sugiere que tu producto fue el punto de entrada.

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

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

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

Errores habituales en la notificación CRA

Esperar certeza

Problema: querer prueba forense antes de notificar.

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

Solución: notifica pronto. 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 al CRA

Problema: tratar las notificaciones de investigadores como notificaciones a ENISA.

Realidad: la divulgación coordinada de vulnerabilidades y la notificación del Artículo 14 del CRA son procesos separados.

• CVD: cómo gestionas las notificaciones de investigadores y acuerdas plazos de divulgación
• Notificación CRA: obligación de notificación cuando se produce la explotación

Solución: tu proceso CVD debe incluir una puerta: "¿Hay evidencia de explotación?" Si la respuesta es sí, activa la notificación del Artículo 14 del CRA en paralelo al CVD.

Punto único de fallo

Problema: solo una persona puede autorizar notificaciones y está ilocalizable.

Realidad: la explotación puede descubrirse en cualquier momento. Fines de semana. Festivos. Las 3 de la madrugada.

Solución: múltiples responsables de notificación autorizados, delegación clara, cadena de contacto de emergencia.

Sin relación con los CSIRTs

Problema: el primer contacto con tu CSIRT nacional se produce durante un incidente.

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

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

Exenciones para microempresas y pequeñas empresas

Las microempresas y las pequeñas empresas cuentan con cierto alivio bajo el Artículo 64(10) sobre alivio para pymes:

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 conllevar multas independientemente del tamaño de la empresa.

Siguen siendo obligatorias:

• La notificación (solo sin sanción por el plazo de 24 horas)
• Todas las demás obligaciones del CRA
• Los informes finales

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

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

Integración con los 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 24 h
    |                               |       Enviar alerta temprana
Investigación                       |
    |                               |
Remediación ----------------->  Notificación detallada 72 h
    |
Recuperación
    |
Lecciones Aprendidas -------->  Informe final 14 d / 1 mes

Si tienes obligaciones NIS 2

Algunas organizaciones tienen tanto obligaciones NIS 2 como CRA:

• NIS 2: incidentes a nivel de organización o servicio
• CRA: vulnerabilidades e incidentes a nivel de producto

Estos pueden solaparse. Un único incidente podría requerir ambos:

• Notificación NIS 2 a la autoridad competente
• Notificación CRA a ENISA/CSIRT vía la SRP

La interacción entre los canales de notificación de NIS 2 y del Artículo 14 del CRA no ha sido confirmada en orientación definitiva. Cualquier afirmación de que la SRP gestiona el enrutamiento para ambos regímenes debe tratarse como no confirmada hasta que ENISA o la Comisión publiquen orientación definitiva (véase "Qué sigue pendiente" más abajo).

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

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

ANTES DE SEPTIEMBRE DE 2026:

CANALES Y CONTACTOS
[ ] security.txt publicado y actualizado
[ ] Formulario de notificación de vulnerabilidades disponible
[ ] Email de seguridad monitorizado (definir SLA: ____ horas)
[ ] Contacto del CSIRT nacional identificado
[ ] Registro en la 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 explotada?
[ ] Hora de inicio del reloj documentada: ____________
[ ] Escalación al 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 procede)

DENTRO DE 14 DÍAS DESDE QUE SE DISPONE DE MEDIDA CORRECTORA/PALIATIVA (vulnerabilidad, Art. 14(2)(c)) / UN MES (incidente)
[ ] Informe final enviado
[ ] Lecciones aprendidas documentadas
[ ] Mejoras de proceso identificadas

Qué sigue pendiente

Varios aspectos que afectan al funcionamiento práctico de la notificación del Artículo 14 del CRA siguen sin resolverse en el momento de redactar este artículo:

Cómo CRA Evidence gestiona la notificación del Artículo 14 del CRA

CRA Evidence está construido en torno al ciclo de notificación del Artículo 14. Los datos clave que requieren tus envíos a la SRP ya están estructurados en la plataforma en el momento en que se identifica una vulnerabilidad o un incidente.

• Marca de tiempo de conocimiento del Artículo 14 del CRA: cada vulnerabilidad se registra contra un producto con la marca de tiempo de conocimiento, el disparador que inicia el reloj de 24 horas bajo el Artículo 14. El campo discovered_at alimenta los campos de plazo de ENISA, de modo que el inicio del reloj queda capturado en el momento en que la vulnerabilidad entra en el sistema.
• Mapeo de versión de producto vinculado al SBOM: los CVEs entrantes y la evidencia de explotación se asocian a versiones específicas del producto a través del pipeline de ingesta de SBOM, de modo que el campo de versiones afectadas en una notificación del Artículo 14 del CRA se pre-rellena a partir de los componentes ya incluidos en tu SBOM.
• Pre-preparación de campos del informe CRA: el expediente técnico (Anexo VII), los datos del fabricante (nombre legal, dirección, contacto), la clase de producto (Por defecto / Importante Clase I y II / Crítico) y el periodo de soporte ya están estructurados en el sistema, listos para rellenar los campos de alerta temprana y de notificación de 72 horas de la SRP.
• Pista de auditoría de evidencias CRA: cada paso desde el triaje interno hasta la notificación CRA externa queda registrado con actor y marca de tiempo, que es lo que solicitan las revisiones de aplicación. Las transiciones de triaje y las notificaciones a ENISA (alerta temprana, notificación detallada, informe final) están todas cubiertas.
• Datos de enrutamiento al CSIRT en el perfil del fabricante: el Estado miembro del CSIRT y los datos del representante autorizado (nombre, dirección, Estado miembro) están almacenados en el perfil del fabricante, de modo que los datos clave para el enrutamiento al CSIRT del Artículo 14 del CRA y la representación de fabricantes no pertenecientes a la UE están disponibles en el momento de la notificación.

Descubre cómo la plataforma gestiona los plazos del Artículo 14: CRA Evidence ENISA Reporting.

Próximos pasos

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.