ENISA cambia el parte de vulnerabilidades del CRA: el nuevo glosario convierte el reporte en una prueba de trazabilidad

El fabricante que todavía trate una vulnerabilidad explotada como un asunto exclusivamente técnico se está preparando para el examen equivocado. La versión 1.3 del glosario de la Single Reporting Platform (SRP) del Cyber Resilience Act, actualizada por ENISA el 10 de septiembre de 2026, baja la obligación de reporte al terreno donde suelen aparecer los problemas: nombres de producto inconsistentes, versiones mal identificadas, distribución geográfica incompleta y equipos que no pueden reconstruir qué sabían en cada momento.

La novedad no es una nueva sanción ni una interpretación revolucionaria del Reglamento (UE) 2024/2847. Es más incómoda: ENISA está mostrando cómo espera que se rellenen los avisos sobre actively exploited vulnerabilities (AEV) y severe incidents (SI). El documento convierte una obligación jurídica abstracta en una secuencia de campos, formatos y actualizaciones. Y cada campo puede acabar funcionando como evidencia de la diligencia —o de la desorganización— del fabricante.

La plataforma no pide únicamente “qué ha pasado”. Pide identificar el producto exacto, sus versiones afectadas, los Estados miembros donde está disponible, su clasificación CRA, la categoría del producto y el estado de las medidas de mitigación. En el aviso inicial habrá información incompleta, por supuesto. El problema no es no saberlo todo a las 24 horas. El problema es no saber qué se sabía, qué se desconocía y qué cambió después.

El glosario llega cuando el reporte ya deja de ser una promesa

El CRA entró en vigor el 10 de diciembre de 2024 y su régimen general de aplicación está previsto para el 11 de diciembre de 2027. Pero las obligaciones de notificación del artículo 14 empiezan antes: el 11 de septiembre de 2026. Por eso la actualización de ENISA del 10 de septiembre no es material de biblioteca. Llega en la víspera del inicio operativo del régimen de reporte.

El artículo 14 exige que los fabricantes notifiquen a través de la plataforma única las vulnerabilidades explotadas activamente en productos con elementos digitales y los incidentes graves que afecten a la seguridad de esos productos. La arquitectura temporal es deliberadamente incómoda: el aviso temprano debe presentarse en 24 horas desde que el fabricante tiene conocimiento de la vulnerabilidad explotada o del incidente grave; la notificación del incidente debe completarse después, dentro del plazo de 72 horas previsto por el régimen. El informe final llega más tarde, cuando existe información suficiente sobre la causa, las medidas adoptadas y la resolución.

La consecuencia práctica es que el primer aviso no puede esperar a que el equipo de ingeniería prepare el informe perfecto. Tampoco puede ser un mensaje vacío de contenido. El propio glosario fija campos obligatorios en la fase de Early Warning: tipo de notificación, título, resumen, fabricante, Estados miembros concernidos, nombre del producto y versión. La organización necesita, por tanto, una capacidad de identificación y escalado preparada antes de que aparezca el incidente.

Hay un detalle que merece más atención de la que suele recibir: la plataforma permite actualizar la información en los pasos de 72 horas y del informe final, y copia por defecto muchos datos del aviso anterior. Esto reduce trabajo administrativo, pero también crea una trampa de control. Si el primer aviso contiene un nombre comercial y el final utiliza un identificador técnico distinto, la entidad tendrá que explicar la relación entre ambos. La plataforma conserva una historia de notificaciones; el fabricante debería conservar también la historia de sus decisiones.

AEV y SI no son dos etiquetas intercambiables

El primer campo del glosario obliga a seleccionar entre “Vulnerability” e “Incident”. No es una cuestión cosmética. La diferencia separa dos situaciones regulatorias con lógicas de investigación diferentes.

Una AEV es una vulnerabilidad que está siendo explotada activamente. El fabricante puede no tener todavía constancia de un impacto amplio sobre sus clientes, pero sí debe actuar porque la explotación real cambia la prioridad y el riesgo. Un SI, por su parte, es un incidente grave con impacto en la seguridad de un producto con elementos digitales. En este caso, la notificación debe describir el acontecimiento, sus efectos conocidos y la respuesta desplegada.

El glosario ofrece una señal útil para los equipos de respuesta: el resumen debe incluir los hechos disponibles, el producto afectado, el impacto conocido y el estado actual de la mitigación. No pide una narración especulativa. Pide separar hechos confirmados de hipótesis operativas. Esa distinción debería reflejarse en el procedimiento interno: una sección para evidencias verificadas, otra para incertidumbres y otra para acciones en curso.

El título admite un máximo de 255 caracteres y no debe incluir detalles técnicos confidenciales que no sean necesarios para identificar el problema. El resumen tiene un máximo de 4.000 caracteres. Son límites sencillos, pero obligan a preparar una taxonomía interna de nombres y una plantilla de comunicación. El SOC puede hablar de un identificador interno; el equipo de producto, de una versión comercial; el regulador necesita una descripción entendible y estable.

Un flujo eficaz debería responder a cuatro preguntas antes de enviar el primer aviso:

1. ¿Qué hecho activa la clasificación como AEV o SI?
2. ¿Quién registra la hora exacta en la que el fabricante adquiere conocimiento?
3. ¿Qué evidencia permite afirmar que una versión concreta está afectada?
4. ¿Qué información puede comunicarse sin divulgar secretos innecesarios ni bloquear la respuesta?

La primera pregunta pertenece al SOC y al equipo de producto. La segunda es de gobierno y auditoría. La tercera requiere inventario técnico. La cuarta exige coordinación entre seguridad, legal, privacidad y comunicación. Cuando una organización responde a estas preguntas en reuniones improvisadas, las 24 horas desaparecen con una velocidad casi admirable.

La identificación del producto será el cuello de botella

Los campos 6 y 7 del glosario —nombre del producto y versión— parecen obvios hasta que se aplican a carteras reales. El nombre debe coincidir con la documentación técnica o con la información de mercado. La versión debe identificar la versión, release, build, modelo o revisión de firmware afectada, y puede incluir un rango si hay varias versiones comprometidas.

Eso excluye respuestas del tipo “la plataforma IoT” o “versiones antiguas”. El portal espera algo que permita reconocer el producto y acotar el universo afectado. Un fabricante que distribuya el mismo componente con marcas distintas tendrá que decidir si reporta el producto base, cada marca comercial o ambos, y documentar la correspondencia. El glosario no resuelve ese problema de arquitectura empresarial; sí deja claro que el producto no puede quedar identificado de forma ambigua.

La versión 1.3 también indica que deben consignarse todos los identificadores afectados: releases, builds, modelos o revisiones de firmware. Para un producto físico con software embebido, la combinación modelo-firmware puede ser más útil que el número comercial. Para un servicio conectado que se actualiza continuamente, el fabricante tendrá que conservar una fotografía reproducible del estado del producto en la fecha del descubrimiento.

La implicación operativa es directa: el inventario de activos del fabricante debe vincular tres capas que con frecuencia viven separadas:

• el nombre comercial y la documentación dirigida al cliente;
• el identificador técnico utilizado por ingeniería, repositorios y pipelines de despliegue;
• la versión realmente distribuida en cada mercado o canal.

Sin esa relación, el equipo de cumplimiento puede completar el campo del portal, pero no puede demostrar que la notificación cubre todas las variantes. El riesgo no está solo en olvidar una versión. También está en incluir tantas versiones que el aviso deje de ser operativo para los CSIRT concernidos.

El glosario recomienda utilizar identificadores exactos y señalar claramente el rango cuando haya varias versiones afectadas. Una buena práctica es que el sistema de gestión de vulnerabilidades genere una lista de versiones directamente desde el inventario de configuración, con revisión humana antes del envío. Copiar una descripción de un ticket de ingeniería no es un control; es una apuesta.

El mapa de distribución entra en el expediente técnico

El campo 5 solicita los Estados miembros en cuyo territorio el fabricante sabe que el producto afectado ha sido puesto a disposición. La finalidad es determinar los CSIRT concernidos. La plataforma muestra automáticamente el CDaC del fabricante, pero permite seleccionar otros Estados miembros cuando el producto está disponible allí. El glosario pone como ejemplo una empresa con Bélgica como CDaC que añade Grecia e Italia según la distribución conocida.

Este campo cambia el alcance del proceso. El equipo que reporta una vulnerabilidad ya no puede limitarse a preguntar dónde tiene su sede la empresa. Debe saber dónde se comercializa el producto, aunque la venta se haga mediante distribuidores, integradores, marketplaces o filiales. Si la información de distribución se actualiza después del primer aviso, el glosario indica que la selección debe actualizarse.

Aquí aparece una conexión poco visible con la gestión de terceros. Los contratos de distribución deberían permitir obtener con rapidez datos de mercado: país de entrega, producto, versión y fecha de disponibilidad. No hace falta convertir cada distribuidor en una extensión del SOC, pero sí exigirle una obligación de cooperación en incidentes y vulnerabilidades. Un acuerdo que solo cubre ventas y garantías puede ser insuficiente para responder al artículo 14.

El mapa de distribución también afecta a la priorización del aviso. Un producto no disponible en la Unión Europea puede no activar el mismo recorrido operativo que uno vendido en varios Estados miembros. Pero esa conclusión debe basarse en datos, no en la intuición del responsable de producto. El fabricante debería conservar la consulta o fuente utilizada para determinar los países concernidos y registrar cualquier limitación conocida.

Para los grupos internacionales, la pregunta crítica es quién tiene la visión consolidada. Una filial puede conocer sus clientes; la sede puede conocer el producto; el distribuidor puede conocer el país. El reporte CRA exige juntar las tres piezas con rapidez. El hecho de que la plataforma autocomplemente determinados datos no sustituye la responsabilidad del fabricante de comprobarlos.

La clasificación CRA no puede ser un campo decorativo

Los campos 8, 9 y 10 introducen la clasificación regulatoria del producto: categoría por defecto, importante o crítica; clase I o clase II cuando procede; y categoría de producto conforme a los anexos III y IV del CRA. El glosario recuerda que la clasificación “important” o “critical” solo debe seleccionarse cuando el producto encaje en las categorías relevantes. Para los productos importantes, la clase aplicable puede ser I o II; si no existe clasificación de clase, el campo debe quedar vacío.

La clasificación importa por dos motivos. Primero, determina parte del tratamiento de evaluación de conformidad. Segundo, aporta contexto de riesgo en la notificación. Seleccionar “critical” porque el producto es comercialmente importante, porque tiene muchos usuarios o porque el incidente suena grave sería un error conceptual. La categoría debe descansar en la funcionalidad y en los anexos aplicables, no en la alarma del momento.

El campo de categoría exige mirar la función principal del producto y no solo su marca. El glosario menciona, entre otros ejemplos, dispositivos de hardware con cajas de seguridad y pasarelas de contadores inteligentes dentro de sistemas de medición avanzada, además de dispositivos destinados a funciones de seguridad o criptoprocesamiento. La lección es clara: un producto que se presenta como “hub”, “gateway” o “módulo” puede tener una clasificación distinta según lo que hace realmente.

Esto exige que el análisis de clasificación forme parte del expediente de producto desde diseño, no una tarea que aparece por primera vez durante una crisis. Ingeniería debe describir funciones; producto debe mapearlas a la taxonomía; legal y compliance deben validar la conclusión. Si la clasificación no está documentada, el campo del portal se convierte en una opinión improvisada bajo presión.

Hay además un efecto sobre las adquisiciones. Si una compañía incorpora un producto de un tercero y lo comercializa bajo su propia marca, puede asumir la condición de fabricante a efectos del CRA. El campo 4 del glosario define al fabricante como la persona física o jurídica que desarrolla o fabrica el producto, lo manda diseñar o fabricar y lo comercializa bajo su nombre o marca, incluso gratuitamente o mediante monetización. La plataforma rellena automáticamente el nombre del fabricante a partir del registro, pero ese automatismo no corrige una mala asignación de responsabilidades.

El dato que falta también debe gobernarse

El glosario permite actualizar información en las fases posteriores. Eso encaja con la realidad de un incidente: a las 24 horas quizá se conoce el producto y el vector, pero no el número de usuarios afectados; a las 72 horas puede haberse confirmado el impacto; en el informe final ya debería existir una explicación de la corrección y del estado de la vulnerabilidad.

La actualización progresiva, sin embargo, no significa que todo valga en el aviso inicial. El resumen debe contener la información factual disponible y el estado de mitigación. Si se desconoce el impacto, debe indicarse que está en investigación. Si existe una solución temporal, debe describirse con precisión suficiente para que el lector entienda su alcance. Si se está preparando una actualización de seguridad, no conviene presentarla como disponible antes de que lo esté.

La organización debería distinguir entre tres estados de información:

• Confirmado: probado mediante logs, análisis de código, reproducción técnica o evidencia de explotación.
• Probable: respaldado por indicios, pero pendiente de validación.
• Desconocido: no puede determinarse todavía y requiere una acción concreta de investigación.

Esta clasificación no aparece como un campo autónomo en el glosario, pero resulta esencial para redactar un resumen fiable y para evitar contradicciones entre las versiones de 24 horas, 72 horas y final. También protege frente a un problema habitual: convertir una hipótesis del investigador en un hecho regulatorio porque alguien necesitaba cerrar el formulario.

El registro interno debería incluir la hora de detección, la hora de clasificación como AEV o SI, la hora de conocimiento atribuible al fabricante, el responsable de la decisión, la versión enviada y las modificaciones posteriores. Esa trazabilidad será especialmente relevante cuando el incidente se solape con otras obligaciones. Una filtración de datos personales puede activar el artículo 33 del GDPR, que fija el plazo de 72 horas para notificar a la autoridad de protección de datos cuando proceda. Un incidente que afecte a una entidad financiera puede requerir además coordinación con DORA, incluida la clasificación y notificación de incidentes graves relacionados con las TIC. Mismo hecho, varios relojes regulatorios.

El CRA no convierte esos plazos en uno solo. Obliga a coordinar procesos sin perder el origen de cada decisión. La pregunta correcta no es “¿hemos enviado la notificación?”, sino “¿qué obligación activó cada envío, con qué hechos y en qué momento?”.

Qué debería cambiar en SOC, producto y compliance

La publicación de ENISA permite traducir el requisito en controles concretos. El primero es un procedimiento de triage que conecte vulnerabilidad, explotación e incidente. No todos los hallazgos de un análisis SAST son AEV; no todo incidente de disponibilidad es necesariamente un SI bajo el CRA. La clasificación debe aplicar definiciones regulatorias y criterios técnicos documentados.

El segundo es un registro de productos con elementos digitales que pueda responder, sin búsquedas manuales interminables, a seis preguntas: quién es el fabricante, qué producto está afectado, qué versiones existen, en qué Estados miembros se comercializó, qué categoría CRA tiene y qué equipos pueden aprobar una notificación.

El tercero es una matriz de autoridad. El SOC puede detectar la explotación, pero no siempre puede afirmar cuál es el nombre legal del fabricante. Producto puede conocer la versión, pero no el alcance geográfico. Legal puede aprobar el texto, pero no debería ser la única fuente de información técnica. El procedimiento debe asignar propietarios por campo del SRP y suplentes para los periodos fuera de horario.

El cuarto es una biblioteca de evidencias. Para el título y el resumen bastan datos de identificación y hechos; para la clasificación y el alcance serán necesarios documentos más sólidos: SBOM, registros de release, evidencias de distribución, análisis de impacto, tickets de mitigación, comunicaciones con distribuidores y resultados de pruebas de la corrección. No todos se envían a ENISA. Todos pueden resultar necesarios para demostrar cómo se llegó a la información enviada.

El quinto es probar el flujo. Un ejercicio útil no simula únicamente el ataque. Simula la obligación de cumplimentar el formulario con una build afectada, dos nombres comerciales, distribución en varios Estados miembros y una mitigación provisional. Si el equipo no puede decidir quién completa el campo 7 o cómo se demuestra el campo 5, el problema no está en la interfaz del portal.

El fabricante debe prepararse para la coherencia entre versiones

El diseño del SRP favorece que la información del aviso temprano se copie a las notificaciones de 72 horas y al informe final. Para el fabricante, esto tiene una ventaja y un coste. La ventaja es que no parte de cero. El coste es que un dato inicial incorrecto puede viajar por todo el expediente si nadie lo revisa.

El control adecuado no consiste en bloquear el primer envío hasta alcanzar certeza absoluta. Consiste en revisar cada actualización como una nueva afirmación regulatoria. ¿Sigue siendo correcto el producto? ¿Se han añadido versiones? ¿Han cambiado los Estados miembros concernidos? ¿La clasificación inicial era adecuada? ¿El resumen distingue lo que se confirmó de lo que se descartó?

La coherencia no significa mantener errores para que las versiones coincidan. Si el primer aviso decía que estaban afectadas las versiones 4.0 a 4.2.1 y el análisis posterior descubre que la 4.1 no es vulnerable, el informe posterior debe corregirlo y explicar internamente la causa. La plataforma puede copiar datos; la gobernanza debe decidir cuándo sustituirlos.

Una organización madura utilizará un identificador único de caso que conecte el ticket de seguridad, el registro de producto, la notificación SRP, los avisos a clientes y, cuando proceda, las notificaciones GDPR, DORA o NIS2. No para crear una gigantesca base de datos ceremonial, sino para evitar que cinco equipos describan el mismo producto de cinco maneras distintas.

La consecuencia para 2026: el cumplimiento empieza antes del incidente

La versión 1.3 del glosario de ENISA no cambia la naturaleza del CRA. Hace algo más útil: revela el nivel de granularidad con el que se evaluará la capacidad de respuesta. Un fabricante puede tener un programa de gestión de vulnerabilidades técnicamente excelente y seguir fallando si no puede localizar sus productos por versión, reconstruir su distribución o explicar cuándo adquirió conocimiento de la explotación.

El 11 de septiembre de 2026 marca el inicio de las obligaciones de notificación del artículo 14; la actualización del 10 de septiembre llega, por tanto, con una pregunta práctica para cada fabricante: ¿puede completar hoy los campos obligatorios del aviso temprano con datos consistentes? No dentro de un año, cuando el CRA sea aplicable en su totalidad. Hoy.

La respuesta debería salir de una prueba, no de una presentación de compliance. Selecciona un producto con software embebido, identifica sus builds, reconstruye dónde se vendió, asigna su categoría CRA y simula una explotación activa. Mide cuánto tardas en obtener los datos, quién aprueba el envío y qué información cambia después de 72 horas. Si el ejercicio se atasca en el nombre del producto, ya tienes el diagnóstico.

La lección final es sencilla y poco glamourosa: la resiliencia regulatoria depende de la calidad del inventario. El SRP no va a arreglar una taxonomía de productos deficiente, un mapa de distribución incompleto ni un proceso de escalado sin dueño. Solo hará que esas carencias sean visibles —y que queden registradas con fecha y hora.