Cyber
ENISA aclara cuándo puede retrasarse la notificación de una vulnerabilidad explotada bajo el CRA
17 min lectura
Imagen generada por IAUna vulnerabilidad explotada activamente no siempre debe difundirse de inmediato a todos los equipos de respuesta. Pero retrasar esa difusión no queda a criterio del fabricante, del responsable de un proyecto open source ni del primer abogado que aparezca en la videollamada de crisis. Requiere encajar en una de las tres situaciones excepcionales previstas por el artículo 16.2, tercer párrafo, del Cyber Resilience Act (CRA).
La guía publicada por ENISA y actualizada el 9 de septiembre de 2026 explica cómo deben utilizar los Authorised Reporters —los usuarios autorizados de la plataforma— la opción de Particular Exceptional Circumstances (PEC) en la Single Reporting Platform (SRP). La función está diseñada para una cosa muy concreta: permitir que la información sobre una vulnerabilidad explotada activamente no se distribuya automáticamente cuando hacerlo pueda generar riesgos adicionales para la seguridad.
La precisión importa porque la excepción aparece justo en el punto más delicado del sistema europeo de notificación. El reportante dispone de una ventana de 72 horas para remitir la notificación correspondiente, pero durante ese intervalo también debe valorar si concurren circunstancias que justifican retrasar la difusión. Marcar PEC no equivale a obtener permiso para incumplir el plazo ni convierte una notificación incompleta en una notificación válida. Solo cambia el estado de distribución y activa una revisión manual.
La novedad práctica no es otra obligación: es el botón que cambia el circuito
La página de ENISA no introduce un nuevo artículo del CRA ni modifica los plazos legales. Su valor está en traducir una cláusula jurídica excepcional a una secuencia operativa dentro de la plataforma.
Cuando un fabricante o un responsable de software de código abierto remite una notificación de 72 horas sobre una Actively Exploited Vulnerability (AEV), debe desplazarse hasta el indicador PEC del formulario y activarlo si considera que se cumple al menos una de las condiciones del artículo 16.2, tercer párrafo. Al hacerlo aparece el campo PEC Delay Reason, en el que se selecciona el motivo del retraso. El sistema ofrece además un campo opcional para explicar la decisión.
El resultado es visible en el estado de la presentación: pasa a figurar como “72h Submitted under PEC”. Esa etiqueta no es cosmética. Indica que la notificación no se ha puesto simultáneamente a disposición de ENISA en su integridad ni se ha difundido automáticamente a los CSIRT afectados.
La decisión posterior corresponde al CSIRT designado como coordinador, conocido en la guía como CDaC. Ese organismo debe valorar si la difusión es necesaria y posible. También puede compartir manualmente la notificación con otros CSIRT concernidos y enviar la notificación completa a ENISA. Mientras tanto, ENISA recibe únicamente la información limitada prevista en el artículo 16.2.
Aquí está el quid: el reportante puede activar PEC, pero no decide unilateralmente que la información quede retenida. La plataforma registra una solicitud de tratamiento excepcional; no concede una dispensa automática.
Qué problema intenta resolver el artículo 16.2
El diseño del CRA parte de una tensión que cualquier equipo de respuesta a incidentes conoce bien. Cuanto antes se comparte una vulnerabilidad explotada, antes pueden protegerse otros productos y servicios. Pero una difusión prematura también puede entregar a un atacante una guía operativa más precisa, revelar que una corrección aún no está disponible o exponer a organizaciones que todavía no han podido aplicar medidas de mitigación.
La respuesta regulatoria europea intenta evitar ambos extremos. Por eso el artículo 16 establece obligaciones de notificación temprana y, al mismo tiempo, contempla circunstancias particularmente excepcionales en las que la difusión puede retrasarse por razones de seguridad. No se trata de proteger la reputación del fabricante, ganar tiempo para preparar un comunicado o evitar titulares incómodos. El criterio es el riesgo que puede generar la propia distribución de la información.
La diferencia es sustancial. Una empresa puede descubrir una vulnerabilidad un viernes por la tarde y necesitar tiempo para coordinar a sus equipos jurídicos, de producto y de comunicación. Eso puede ser una dificultad interna, pero no convierte por sí solo el caso en PEC. Del mismo modo, que el fallo afecte a un producto estratégico, que el parche tarde en llegar o que el incidente tenga impacto comercial no basta para activar la excepción si no concurre una de las condiciones legales del artículo 16.2.
La guía de ENISA no presenta PEC como una herramienta de gestión del calendario corporativo. La presenta como un mecanismo para situaciones en las que compartir la información durante el circuito ordinario podría producir un riesgo de seguridad. Esa distinción debería acabar con una tentación bastante previsible: utilizar el campo de justificación como una carta de “necesitamos más tiempo”. No es para eso.
La ventana de 72 horas tiene dos decisiones, no una
La mayoría de los procedimientos internos tratan una notificación regulatoria como una carrera hacia el envío. En este caso, el proceso exige dos decisiones paralelas.
La primera es determinar si existe una vulnerabilidad explotada activamente que entra en el flujo de notificación previsto por el CRA. La segunda es decidir si la notificación debe presentarse bajo PEC. El equipo no puede esperar a cerrar toda la investigación para plantearse la excepción: ENISA indica que el reportante debe evaluar, cuando proceda, si concurren circunstancias particulares excepcionales durante la primera ventana de 72 horas.
Eso obliga a cambiar el diseño de los procedimientos de respuesta. El formulario de la SRP no puede aparecer al final de un proceso que solo conoce el equipo jurídico. La decisión PEC necesita información técnica suficiente para responder preguntas incómodas y muy concretas:
- ¿Qué parte de la información podría permitir explotar sistemas todavía no protegidos?
- ¿Existe una corrección, una mitigación o una configuración temporal que pueda comunicarse sin aumentar el riesgo?
- ¿Qué destinatarios necesitan conocer el detalle técnico y cuáles solo necesitan una alerta limitada?
- ¿Qué hecho documentable permite afirmar que concurre una condición del artículo 16.2, tercer párrafo?
- ¿Qué información puede remitirse a la plataforma sin revelar detalles cuya difusión inmediata sea peligrosa?
La respuesta no debería redactarse desde cero en la interfaz. Un equipo que llega a la hora 71 sin una cronología, una descripción técnica y una justificación aprobada está intentando hacer compliance con el equivalente digital de una servilleta.
Qué cambia para fabricantes y responsables de proyectos open source
El CRA no limita el reporte de AEV a las grandes empresas tecnológicas con departamentos de seguridad de seis cifras. La guía de ENISA menciona expresamente a los fabricantes y a los open-source software stewards como reportantes. La diferencia organizativa entre ambos puede ser enorme, pero la plataforma les plantea el mismo problema: la persona que envía el aviso debe tener autoridad, acceso y criterio suficiente para activar PEC correctamente.
Los fabricantes suelen contar con un PSIRT, un equipo de producto y una función legal o de compliance. Aun así, muchas decisiones críticas siguen dependiendo de proveedores, distribuidores y unidades de negocio que no están acostumbrados a trabajar con plazos regulatorios medidos en horas. La obligación de reportar una vulnerabilidad explotada no desaparece porque el código afectado proceda de una biblioteca externa ni porque el parche dependa de un tercero.
En el ecosistema open source, el reto puede ser más complejo. Un responsable de proyecto puede conocer el código y la explotación, pero no disponer de una estructura permanente para gestionar identidades, sustituciones, escalados o comunicaciones con CSIRT nacionales. El acceso al panel de la SRP requiere iniciar sesión correctamente y tener un estado de usuario “Active”, además de respetar las restricciones de rol y asociación aplicables. Ese detalle operativo es menor solo hasta que la persona que debía notificar está de vacaciones, ha perdido el acceso o nunca completó el registro.
La guía de PEC no sustituye las instrucciones de registro de usuarios ni el manual de la SRP. Lo que sí deja claro es que el cumplimiento no se agota en saber que existe la plataforma. Hay que verificar previamente quién puede presentar una notificación, quién puede activar PEC y quién puede justificar la selección cuando el responsable técnico no está disponible.
El papel del CSIRT coordinador: ni buzón ni sello de goma
El CDaC ocupa una posición central en el circuito. Cuando se marca PEC, el sistema no distribuye automáticamente la notificación completa a ENISA. El CSIRT coordinador debe decidir si la difusión es necesaria y posible, compartir manualmente la información con otros CSIRT afectados cuando proceda y remitir la notificación completa a ENISA.
Esta arquitectura desplaza una parte relevante del juicio operativo desde el reportante hacia una autoridad coordinadora. También introduce una dependencia temporal que las organizaciones deben reflejar en sus procedimientos. Activar PEC no significa que el asunto quede suspendido indefinidamente; significa que el caso sale del flujo automático y entra en una revisión humana.
Para el reportante, esto tiene tres consecuencias. La primera: la explicación opcional del formulario puede ser decisiva para que el CDaC entienda el riesgo sin tener que reconstruirlo desde datos incompletos. La segunda: la información limitada que se entrega inicialmente debe ser suficiente para que el coordinador pueda valorar el caso, sin convertir la notificación en una filtración técnica prematura. La tercera: el equipo debe permanecer disponible después del envío. El proceso no termina cuando aparece el estado “72h Submitted under PEC”.
La guía tampoco promete una aceptación automática ni fija, en el contenido publicado, un plazo separado para que el CDaC resuelva cada caso PEC. Esa ausencia es relevante. Las organizaciones no deberían construir su plan de respuesta suponiendo que el coordinador aprobará el retraso, que pedirá siempre la misma documentación o que responderá con una cadencia idéntica en todos los Estados miembros.
La prudencia operativa consiste en preparar el caso para dos escenarios: que la excepción se mantenga durante la revisión y que el CDaC considere necesaria la difusión. El equipo debe poder explicar rápidamente qué medidas de mitigación existen, qué usuarios están expuestos y qué información puede hacerse pública o compartir con otros CSIRT sin agravar el riesgo.
La trampa de confundir confidencialidad con PEC
Una notificación de vulnerabilidad puede contener secretos comerciales, código no publicado, información sobre clientes o detalles de una arquitectura crítica. Eso no significa automáticamente que pueda acogerse a PEC.
La confidencialidad protege información cuyo acceso debe limitarse. PEC responde a una situación más estrecha: la difusión, en ese momento, puede crear riesgos de seguridad y concurre una de las condiciones del artículo 16.2, tercer párrafo. Son problemas relacionados, pero no intercambiables.
La distinción importa porque un fabricante puede verse tentado a invocar la excepción para evitar que la información llegue a destinatarios que considera incómodos o para retrasar la exposición pública de un defecto. El mecanismo no está diseñado para eso. Tampoco sirve para impedir que los CSIRT coordinen una respuesta cuando esa coordinación es precisamente la razón de ser del sistema.
La pregunta correcta no es “¿preferimos que esto no circule?”, sino “¿qué daño de seguridad produciría que circulase ahora y por qué encaja en una de las condiciones legales?”. Si el equipo no puede responder a la segunda parte con hechos técnicos, fechas y alcance, probablemente no tiene una justificación PEC; tiene una preocupación legítima que debe gestionarse por otros controles de acceso y confidencialidad.
Qué debe contener una justificación defendible
ENISA califica el campo de justificación como opcional, pero que algo sea opcional en una pantalla no lo convierte en irrelevante para la trazabilidad. En una revisión posterior, la organización tendrá que explicar por qué activó PEC, quién tomó la decisión y qué información estaba disponible en ese momento.
Una justificación útil debería ser breve y factual. No necesita convertirse en un informe de veinte páginas, pero sí debería conectar cuatro elementos: el hecho técnico, el riesgo de difusión inmediata, la condición legal invocada y la medida que permite reducir el riesgo mientras se revisa la notificación.
Por ejemplo, no basta con escribir “la vulnerabilidad es crítica y necesitamos tiempo para preparar el parche”. Esa frase describe gravedad y necesidad interna, no el riesgo de distribución. Una justificación más sólida identificaría qué detalle concreto podría facilitar la explotación, qué población de productos o usuarios sigue expuesta y por qué la difusión coordinada debe retrasarse hasta que el CDaC valore el caso.
Conviene separar la justificación del relato de crisis. El CDaC necesita entender el motivo de PEC, no leer la transcripción completa de todas las discusiones internas. La información adicional puede mantenerse en los registros corporativos, con una referencia cruzada al expediente de la notificación.
El expediente debería conservar, al menos:
- la fecha y hora en que se confirmó la explotación activa;
- la identidad del responsable que decidió activar PEC;
- la versión del formulario remitido y el estado “72h Submitted under PEC”;
- el motivo seleccionado en el campo PEC Delay Reason;
- la evidencia técnica que conecte el caso con el artículo 16.2, tercer párrafo;
- las comunicaciones con el CDaC, los CSIRT concernidos y ENISA;
- la evolución del parche o de las mitigaciones disponibles.
No se trata de crear burocracia por deporte. Es la diferencia entre una decisión excepcional explicable y un botón pulsado durante una crisis cuyo significado nadie puede reconstruir seis meses después.
La conexión con el programa de vulnerabilidades y con NIS2
El flujo del CRA no debería vivir en una carpeta separada del programa general de gestión de vulnerabilidades. La activación de PEC es una decisión de respuesta, pero depende de activos, versiones, productos afectados, explotación observada, inteligencia de amenazas y capacidad de mitigación. Si esos datos están repartidos entre el PSIRT, el SOC y el equipo de producto, la ventana de 72 horas se consume coordinando sistemas que no se hablan.
El CRA también se cruza con NIS2, aunque las obligaciones no sean idénticas ni tengan los mismos sujetos obligados. NIS2 exige medidas de gestión de riesgos de ciberseguridad en su artículo 21 y regula la notificación de incidentes significativos en el artículo 23. Una vulnerabilidad explotada en un producto puede desencadenar obligaciones para el fabricante bajo el CRA y, si afecta a una entidad esencial o importante que utiliza ese producto, activar su propio análisis de incidente bajo NIS2.
Eso no significa que una notificación PEC al amparo del CRA sustituya una notificación NIS2. Tampoco que una comunicación realizada a un CSIRT bajo NIS2 resuelva automáticamente el flujo de la SRP. Son regímenes distintos, con autoridades, umbrales y destinatarios potencialmente diferentes. El error de copiar y pegar un aviso entre marcos regulatorios es especialmente peligroso cuando cada uno exige valorar hechos distintos.
Las entidades financieras tienen además su propio problema de coordinación con DORA. El artículo 17 de DORA regula la gestión y clasificación de incidentes relacionados con las TIC, mientras que el artículo 19 establece la notificación de incidentes graves relacionados con las TIC a la autoridad competente. Un banco que utiliza un producto afectado por una AEV puede necesitar evaluar simultáneamente el impacto operativo bajo DORA, la notificación que corresponda bajo ese reglamento y las comunicaciones de su proveedor conforme al CRA.
La solución no es crear tres equipos que trabajen en paralelo sin hablarse. Es mantener un expediente de hechos común y aplicar después el test jurídico específico de cada régimen. La fecha de descubrimiento, el alcance técnico, el servicio afectado, la mitigación disponible y el impacto observado deberían registrarse una sola vez; las decisiones de notificación, en cambio, deben quedar separadas y justificadas por norma.
Qué deberían cambiar los procedimientos internos ahora
La fecha de actualización de la guía —9 de septiembre de 2026— coincide con un momento especialmente sensible para las empresas sujetas al CRA. Las obligaciones de notificación del reglamento comienzan a aplicarse antes que la aplicación general del CRA, prevista para el 11 de diciembre de 2027. La fecha que las organizaciones no deberían perder de vista es el 11 de septiembre de 2026, cuando empiezan a aplicarse las obligaciones de notificación de vulnerabilidades y de incidentes previstas en el reglamento.
Eso deja poco margen para tratar la SRP como un proyecto futuro. La preparación mínima debería incluir una prueba del acceso de los usuarios autorizados, una simulación de una AEV y una decisión explícita sobre quién puede activar PEC. La simulación debe probar el circuito real, incluida la documentación del motivo, la escalada al CDaC y la capacidad de responder si la excepción no es aceptada.
También debería revisarse el reparto de responsabilidades. El CISO puede aportar el análisis de explotación; el responsable de producto puede conocer las versiones afectadas; legal puede interpretar el artículo 16.2; y el responsable autorizado puede ser la única persona capaz de presentar el formulario. Si nadie tiene la obligación expresa de unir esas piezas antes del vencimiento de la ventana de 72 horas, la organización tiene una laguna de control aunque disponga de excelentes herramientas de detección.
Los ejercicios deben incluir escenarios incómodos. Por ejemplo: explotación confirmada sin parche disponible; vulnerabilidad en una dependencia open source utilizada por varios productos; fabricante que conoce la explotación pero aún no puede delimitar todas las versiones afectadas; o incidente que afecta a un proveedor ICT crítico y a clientes financieros sujetos a DORA. La finalidad no es adivinar el futuro, sino comprobar si las decisiones se toman con información suficiente y si el sistema deja rastro.
Lo que la guía no resuelve
La publicación de ENISA es útil, pero deliberadamente limitada. Explica cómo aplicar PEC en la SRP y quién interviene después. No reemplaza el texto del CRA, no enumera en la página las tres condiciones del artículo 16.2 y advierte expresamente de que la información puede cambiar. Por tanto, una política interna que copie literalmente la guía sin revisar el reglamento corre el riesgo de convertir una orientación operativa en una interpretación jurídica completa.
Tampoco resuelve todas las preguntas de coordinación entre fabricantes, responsables open source, distribuidores, CSIRT nacionales y clientes regulados. ¿Qué ocurre si dos actores notifican la misma vulnerabilidad? ¿Cómo se coordina la decisión cuando el producto se comercializa en varios Estados miembros? ¿Qué nivel de detalle debe intercambiarse durante una mitigación privada? La respuesta no puede deducirse automáticamente del estado de la plataforma.
La recomendación prudente es mantener la guía de ENISA como documento vivo, vinculado a la versión vigente del CRA, a las instrucciones de la SRP y a los procedimientos del CDaC correspondiente. La propia ENISA pide consultar la orientación y la legislación más recientes antes de aplicar estas instrucciones. En regulación tecnológica, esa frase no es una cláusula de estilo: es una advertencia de mantenimiento.
La excepción solo funciona si sigue siendo excepcional
El valor de PEC depende de que no se convierta en la salida cómoda para cualquier vulnerabilidad complicada. Si los reportantes activan el indicador cada vez que no tienen listo un parche, el mecanismo pierde credibilidad y el coordinador tendrá que dedicar tiempo a separar los casos genuinamente peligrosos de los que simplemente están mal preparados.
La disciplina debería ser sencilla de formular, aunque no siempre sencilla de aplicar: primero se cumple la obligación de notificar; después se justifica, con hechos, por qué la distribución inmediata de la información puede aumentar el riesgo; y finalmente se acepta que la decisión sobre la difusión corresponde al CDaC. El reportante no controla el resultado, solo presenta el caso de forma completa y trazable.
La guía de ENISA convierte esa lógica en un flujo reconocible: el botón PEC, el motivo del retraso, la justificación opcional, el estado “72h Submitted under PEC” y la revisión manual del CSIRT coordinador. Ahora corresponde a fabricantes y responsables de software open source comprobar si sus procedimientos reales pueden ejecutar ese flujo dentro de la ventana de 72 horas.
La pregunta que debería plantearse cada organización no es si conoce la existencia de la SRP. Es más incómoda: si mañana confirma una vulnerabilidad explotada, ¿puede decidir en horas si está ante una excepción legal, presentar la notificación, demostrar por qué la activó y seguir coordinando la respuesta cuando el formulario ya está enviado? Si la respuesta depende de una única persona, de un acceso que nadie ha probado o de un comité que se reúne una vez por semana, PEC no será el problema. Será el síntoma.