ENISA integra sus primeras CNAs: qué significa para el Artículo 14 del CRA
ENISA incorpora nuevas CNAs europeas como CVE Root. Descubre cómo esto refuerza el flujo de notificación del Artículo 14 del CRA y la gestión de vulnerabilidades en la UE.
En este artículo
El reloj de 24 horas del Artículo 14 del CRA arranca en el momento en que tienes indicios razonables de que una vulnerabilidad está siendo explotada activamente. Ese reloj presupone que existe una cadena de identificación de vulnerabilidades que funciona. ENISA acaba de hacer esa cadena más directa.
El 6 de mayo de 2026, ENISA anunció que cuatro nuevas organizaciones se han incorporado al Programa CVE como Autoridades de Numeración CVE (CNAs) bajo el paraguas de ENISA Root. Además, siete CNAs europeas ya existentes han pasado de MITRE Root a ENISA Root. Para cualquier fabricante que se prepara para cumplir con el Artículo 14 del CRA, esto significa que la columna vertebral operativa está empezando a funcionar de verdad.
Este anuncio tiene más peso del que parece. El CRA no existe de forma aislada. Define obligaciones legales, pero esas obligaciones dependen de una infraestructura que tiene que existir y funcionar antes del 11 de septiembre de 2026. El desarrollo del CVE Root de ENISA forma parte de esa infraestructura. Y el hecho de que esté ocurriendo ahora, con el plazo del CRA tan cerca, resulta a la vez tranquilizador y un recordatorio de que la UE todavía está montando la maquinaria mientras el reloj avanza.
Resumen
- ENISA es un CVE Root para entidades europeas. Se convirtió en Root en noviembre de 2025 y comenzó a incorporar sus primeras CNAs en mayo de 2026.
- 4 nuevas CNAs se han unido al Programa CVE bajo ENISA Root, formadas e incorporadas directamente por ENISA. 7 CNAs europeas ya existentes han transferido su adscripción desde MITRE Root.
- Más de 90 CNAs europeas pueden transferirse voluntariamente a ENISA Root. Europa ya representa casi una quinta parte de las 510 CNAs distribuidas en 42 países a nivel global.
- El Artículo 14 del CRA obliga a los fabricantes a notificar las vulnerabilidades explotadas activamente en un plazo de 24 horas a través de la Plataforma Única de Notificación de ENISA (SRP), operativa desde el 11 de septiembre de 2026.
- Los IDs CVE son el identificador común para esa notificación. Con ENISA como CVE Root, Europa asigna ahora IDs CVE directamente, sin pasar por MITRE.
- La aceleración de la IA es un factor expresamente reconocido. Hans de Vries, de ENISA, señaló que los modelos de IA de frontera comprimen el tiempo entre el descubrimiento de una vulnerabilidad y su explotación.
- La Ley de Ciberseguridad 2 propone recursos operativos adicionales para ENISA, acordes al creciente volumen de trabajo.
Fuente: anuncio de ENISA, 6 de mayo de 2026.
Por qué los IDs CVE importan para tu notificación del Artículo 14
Cuando el Artículo 14 del CRA te obliga a notificar una vulnerabilidad explotada activamente, la notificación tiene que identificar la vulnerabilidad con precisión. Los IDs CVE son el estándar global para esa identificación. Los usa la Base de Datos Europea de Vulnerabilidades (EUVD) de ENISA. Los esperará la Plataforma Única de Notificación de ENISA.
Obtener un ID CVE asignado requiere una CNA. Si ninguna CNA europea cubría la categoría de tu software, tenías que acudir a MITRE, con sede en EE.UU. La coordinación funcionaba, pero añadía latencia. Con un plazo de 24 horas, la latencia es un riesgo de cumplimiento.
ENISA como CVE Root cambia el enrutamiento. Las CNAs europeas coordinan ahora la asignación de CVE directamente con ENISA. Para la mayoría de los fabricantes, esto pasa desapercibido en el día a día. No es necesario ser una CNA. Pero el investigador de seguridad que encuentra un fallo en tu producto, o el CSIRT que gestiona tu proceso de divulgación, opera ahora bajo una autoridad raíz geográficamente alineada con la agencia a la que notificas en virtud del Artículo 14.
Esa es la infraestructura de la que depende tu plazo de 24 horas.
La cadena de notificación en el Artículo 14 del CRA
El Artículo 14(1) del CRA obliga a los fabricantes a notificar al CSIRT coordinador y a ENISA de forma simultánea, a través de la Plataforma Única de Notificación de ENISA. Se presenta una única notificación y ambos la reciben.
Pero la SRP necesita un ID CVE para anclar el informe. El papel de ENISA como CVE Root significa que el paso de identificación y el paso de notificación están ahora bajo la misma agencia. El organismo que da nombre a la vulnerabilidad es el mismo al que notificas. Esto cierra una brecha de coordinación que existía cuando las dos funciones corrían a cargo de organizaciones distintas en continentes diferentes.
ENISA asigna ahora IDs CVE a entidades europeas y recibe las notificaciones del Artículo 14 a través de la SRP. La agencia que nombra la vulnerabilidad es la misma a la que notificas en virtud del CRA.
Consulta la guía de notificación del Artículo 14 para ver el calendario completo de 24 h, 72 h y 14 días, y qué cubre el envío a la SRP.
El problema de la aceleración de la IA
Hans de Vries, Director de Ciberseguridad y Operaciones de ENISA, fue directo sobre por qué esto importa ahora:
En un momento en que los modelos de IA de frontera están acelerando el descubrimiento y la explotación de vulnerabilidades, la capacidad europea de gestión de vulnerabilidades debe estar a la altura y ofrecer apoyo operativo de confianza a la comunidad de ciberseguridad en general.
Las herramientas de IA comprimen el tiempo entre que se detecta un fallo y que alguien lo explota. La ventana entre «un investigador lo descubre» y «tu reloj de 24 horas del Artículo 14 empieza» se está acortando. De aquí se derivan dos consecuencias. Primera: tu proceso interno de clasificación tiene que adaptarse a una línea temporal de amenazas más rápida. Segunda: el paso de asignación del CVE en la cadena necesita la misma velocidad. ENISA está construyendo esa capacidad ahora. La Ley de Ciberseguridad 2 propone recursos operativos adicionales para ENISA específicamente orientados a esta función.
Lo que no necesitas hacer
No necesitas convertirte en una CNA. El estatus de Autoridad de Numeración CVE es para organizaciones que descubren y publican registros de vulnerabilidades. La mayoría de los fabricantes no son CNAs y el CRA no lo exige.
Lo que sí exige el Anexo I, Parte II del CRA es una política de divulgación coordinada de vulnerabilidades (CVD). Esa política describe cómo tu organización recibe, gestiona y divulga vulnerabilidades. Bajo esa política, colaboras con CNAs o CSIRTs que se encargan de la asignación de CVE. Con ENISA como CVE Root, esos socios operan ahora bajo una estructura de autoridad europea más directa.
Revisa tu política CVD con estas tres preguntas antes del 11 de septiembre de 2026:
- ¿Nombra la vía de notificación? La política debe hacer referencia a la SRP de ENISA como canal de envío para las notificaciones del Artículo 14.
- ¿Especifica cómo gestionas las notificaciones entrantes? Cuando un investigador te notifica una vulnerabilidad, la política debe describir tu plazo de respuesta y el proceso de solicitud de CVE.
- ¿Identifica tu CSIRT coordinador? El Artículo 14(7) obliga a los fabricantes a designar un CSIRT coordinador. Esa designación debe quedar recogida en la política.
Consulta la plantilla de política CVD para un punto de partida estructurado.
Nuestra valoración
La postura de «reforzar, no fragmentar» es la correcta. El riesgo de cualquier infraestructura específicamente europea es la fragmentación. Un silo CVE europeo que divergiera de MITRE perjudicaría a todos, incluidos los fabricantes europeos que trabajan con cadenas de suministro globales. El anuncio es explícito: ENISA trabaja con CISA y MITRE dentro de un compromiso compartido con el programa global.
El mensaje más importante para los fabricantes es de calendario. La infraestructura se está montando al mismo tiempo que se supone que debes cumplir con ella. La SRP aún no está en producción. El CVE Root tiene 11 CNAs de las más de 90 elegibles. Esas piezas estarán listas en septiembre de 2026, pero tú también tienes que estarlo, y construir tu proceso sobre una infraestructura que todavía está llegando es más difícil que hacerlo sobre terreno estable.
Preguntas frecuentes
¿El hecho de que ENISA sea CVE Root cambia mis obligaciones de notificación del Artículo 14?
No. Tus obligaciones en virtud del Artículo 14 no cambian. Sigues teniendo que notificar las vulnerabilidades explotadas activamente en un plazo de 24 horas a través de la SRP de ENISA desde el 11 de septiembre de 2026. Lo que cambia es la infraestructura que hay detrás de la plataforma. ENISA gestiona ahora directamente la asignación de IDs CVE para entidades europeas, lo que reduce la latencia de coordinación entre la identificación de la vulnerabilidad y el paso de notificación. Consulta la guía de notificación del Artículo 14 para ver todos los detalles de la obligación.
¿Necesito convertirme en Autoridad de Numeración CVE para cumplir con el CRA?
No. El estatus de CNA es para organizaciones que descubren y publican registros de vulnerabilidades. El CRA exige una política de divulgación coordinada de vulnerabilidades en virtud del Anexo I, Parte II, y la notificación del Artículo 14 a través de la SRP de ENISA. Estas obligaciones son independientes de ser miembro de una CNA. La mayoría de los fabricantes cumplen trabajando con CNAs o CSIRTs ya existentes, sin necesidad de tener ellos mismos ese estatus.
¿Cuándo se convirtió ENISA en CVE Root y qué significa en la práctica?
ENISA se convirtió en CVE Root para entidades europeas en noviembre de 2025. Como Root, incorpora, forma y gestiona las CNAs dentro de su ámbito, y coordina la asignación de IDs CVE y la publicación de registros para entidades europeas. Las primeras incorporaciones de CNAs bajo ENISA Root se anunciaron el 6 de mayo de 2026: cuatro nuevas CNAs y siete que se transfieren desde MITRE Root. En la práctica, significa que las CNAs europeas coordinan ahora la asignación de CVE directamente con ENISA en lugar de canalizar la solicitud a través de la organización MITRE, con sede en EE.UU.
¿Qué es la Base de Datos Europea de Vulnerabilidades y cómo se conecta con ENISA Root?
ENISA gestiona la Base de Datos Europea de Vulnerabilidades (EUVD), que cataloga vulnerabilidades usando los IDs CVE como identificador común. Como CVE Root, ENISA controla ahora la asignación de esos IDs para entidades europeas. La base de datos y la autoridad de asignación están alineadas bajo una misma agencia. Los fabricantes pueden usar la EUVD para verificar si una vulnerabilidad ya ha sido registrada antes de presentar una notificación del Artículo 14 a través de la SRP.
¿Por qué es relevante el argumento de la aceleración de la IA para mi preparación ante el CRA?
El Director de Ciberseguridad y Operaciones de ENISA señaló que los modelos de IA de frontera comprimen el tiempo entre el descubrimiento de una vulnerabilidad y su explotación. Una ventana más corta entre descubrimiento y explotación significa menos margen entre el momento en que un investigador detecta un fallo y el inicio de tu reloj de 24 horas del Artículo 14. Tu proceso interno de clasificación tiene que estar preparado para ese ritmo. Realiza un ejercicio de simulación sobre el plazo de 24 horas antes del 11 de septiembre de 2026 para verificar que tu proceso aguanta.
¿Cuál es la diferencia entre MITRE Root y ENISA Root para las CNAs europeas?
MITRE es la organización con sede en EE.UU. que históricamente ha actuado como raíz global del CVE. Las CNAs europeas bajo MITRE Root coordinaban la asignación de CVE a través de MITRE. Con ENISA Root, esas CNAs coordinan directamente con ENISA. El formato del ID CVE y las reglas del Programa CVE no cambian. La diferencia está en la autoridad raíz: con sede en la UE, con mandato europeo e integrada con la SRP de ENISA y la EUVD a través de las que los fabricantes sujetos al CRA presentan sus notificaciones.
Este artículo tiene únicamente carácter informativo y no constituye asesoramiento jurídico. Para orientación específica sobre cumplimiento normativo, consulta con un abogado cualificado.
Artículos Relacionados
¿Se aplica el CRA a tu producto?
Responde 6 preguntas sencillas para saber si tu producto está dentro del ámbito del Reglamento de Ciberresiliencia de la UE. Obtén tu resultado en menos de 2 minutos.
¿Listo para lograr el cumplimiento del CRA?
Empieza a gestionar tus SBOMs y documentación de cumplimiento con CRA Evidence.