Resumen

  • Los fabricantes de productos con elementos digitales cubiertos por el Cyber Resilience Act deben notificar desde el 11 de septiembre de 2026 las vulnerabilidades explotadas activamente y los incidentes graves de seguridad. El aviso inicial vence dentro de las 24 horas desde que toman conocimiento y la notificación ampliada, dentro de las 72.
  • La Single Reporting Platform permite presentar una vez, pero mantiene repartidas las decisiones: un CSIRT nacional coordina y distribuye, ENISA opera el portal y las autoridades de vigilancia del mercado reciben lo necesario para hacer cumplir la norma. La versión inicial solo está en inglés, carece de API y aún no admite informes voluntarios ni activa los deberes de los responsables de software abierto.

Europa ha puesto en marcha primero el timbre de alarma y ha dejado para después buena parte de la obra del edificio.

Las obligaciones principales del Cyber Resilience Act sobre diseño seguro, gestión de vulnerabilidades, conformidad y comercialización serán aplicables con carácter general el 11 de diciembre de 2027. Sin embargo, el artículo 14 empezó a regir el 11 de septiembre de 2026. La cronología oficial de la European Commission no deja ese escalonamiento a la interpretación.

El primer aviso debe enviarse sin demora indebida y, en todo caso, antes de que transcurran 24 horas desde que el fabricante conoce una vulnerabilidad explotada activamente o un incidente con impacto grave en la seguridad del producto. A las 72 horas se exige una notificación con más información y una evaluación inicial. La explicación de la European Commission añade dos cierres diferentes: catorce días después de que exista una medida correctora para la vulnerabilidad explotada, o un mes después de la notificación de 72 horas para el incidente grave.

La diferencia de fechas convierte 2026-2027 en algo más que un periodo de preparación. Un producto que ya está en el mercado europeo puede originar hoy un deber de reporte aunque las obligaciones generales sobre ese producto lleguen más tarde. No hace falta esperar al marcado, a una auditoría o a una actuación sancionadora. Basta con que se materialice el tipo de conocimiento definido por el artículo 14.

La plataforma única conserva fronteras nacionales

La Single Reporting Platform administrada por ENISA resuelve un problema evidente: un incidente transfronterizo no obliga a repetir el mismo formulario ante cada Estado miembro. Para una vulnerabilidad o un incidente concretos se presenta una sola notificación, incluso cuando el grupo empresarial tiene varias filiales o sucursales en la UE o una matriz fuera de ella.

Pero la empresa no entrega el expediente a una nube institucional sin dueño. Debe seleccionar el CSIRT designado como coordinador, normalmente a partir del establecimiento principal del fabricante. Es responsable de acertar. La lista de coordinadores nacionales publicada por ENISA forma parte, por tanto, de la ruta de cumplimiento.

En el circuito ordinario, la notificación queda disponible para el coordinador y para ENISA. El CSIRT inicial la transmite sin demora a los CSIRT de otros Estados miembros en cuyo territorio esté disponible el producto. También puede comunicar información a las autoridades de vigilancia del mercado cuando sea necesaria para sus competencias de ejecución.

El resultado no es un superregulador paneuropeo. Es una entrada común conectada a responsabilidades diferentes. El fabricante domina los hechos internos y la identificación del producto. El CSIRT nacional valora y encamina. ENISA mantiene la infraestructura y ve el flujo común. La autoridad de mercado investiga o exige correcciones cuando corresponde.

Esa separación importa al leer un justificante. Que la plataforma haya aceptado el envío no demuestra que la selección del coordinador fuese correcta ni que todos los receptores posteriores hayan recibido idéntico contenido. La FAQ de ENISA advierte de que una elección errónea puede invalidar la notificación y obligar a presentarla de nuevo.

Una excepción solicitada por la empresa y decidida por el CSIRT

Difundir rápidamente información sobre una vulnerabilidad que ya está siendo explotada puede, en casos excepcionales, agravar el riesgo. El sistema prevé las Particularly Exceptional Circumstances, conocidas como PEC, dentro de la notificación de 72 horas sobre ese tipo de vulnerabilidad.

El procedimiento de ENISA no permite que la empresa cierre la circulación por sí sola. El representante marca la posible excepción y puede exponer la razón. El CSIRT coordinador decide si procede retrasar la difusión. Cuando acepta, ENISA recibe inicialmente información limitada y el coordinador conserva la responsabilidad de compartir después el expediente completo.

La gobernanza se apoya en dos actos distintos: pedir y autorizar. Un registro serio debe conservar quién activó el indicador, qué fundamento invocó, quién tomó la decisión y cuándo dejó de ser necesario el retraso. Sin esas huellas, una medida prudente de divulgación coordinada puede confundirse con una omisión.

Tampoco conviene ampliar la excepción por comodidad. La guía operativa la sitúa en el flujo de 72 horas de una vulnerabilidad explotada activamente, no en cualquier evento incómodo o en toda comunicación de seguridad.

El portal nace con límites visibles

La primera versión no pretende cubrir todo lo que la ley permitirá algún día. Admite las notificaciones obligatorias de fabricantes por vulnerabilidades activamente explotadas e incidentes graves. La vía voluntaria del artículo 15 llegará en una fase posterior. Quien no sea fabricante debe dirigirse, por ahora, al CSIRT nacional pertinente.

Los deberes de reporte para los responsables de software de código abierto empiezan el 11 de diciembre de 2027, no ahora. Esta fecha evita convertir una descripción futura de la plataforma en una obligación actual para comunidades que todavía están fuera del artículo 24(3).

La interfaz de lanzamiento está solo en inglés. No ofrece API. Los fabricantes pueden automatizar la preparación interna, pero el paso formal se completa en la interfaz. Esa limitación añade trabajo humano precisamente cuando el tiempo disponible es más corto.

La identidad del remitente también es humana. Los representantes asignados acceden con cuentas personales de EU Login y autenticación multifactor. El coordinador valida el vínculo con el fabricante, aunque la validación avanza en paralelo y no impide el primer reporte urgente. Un representante no verificado puede presentar hasta veinte notificaciones para ese fabricante antes de que la confirmación sea obligatoria. El manual de registro convierte esa preparación en un control de resiliencia: las credenciales, sustitutos y entidad jurídica deben resolverse antes de una crisis.

El plazo empieza en el hecho, no en el recordatorio

La transparencia de ENISA sobre el contador actual merece atención. La plataforma calcula la fecha visible de la notificación de 72 horas sumando 48 horas al envío del aviso inicial. La regla jurídica, en cambio, cuenta desde la toma de conocimiento. Si el primer aviso se presentó pronto, la pantalla puede mostrar un vencimiento anterior al final real de las 72 horas. ENISA anuncia que actualizará la lógica para usar el campo de conocimiento.

El problema no reduce ni amplía el plazo legal. Expone la distancia entre norma y software. Un fabricante debería guardar por separado la hora de conocimiento, la prueba que la sustenta, el envío inicial, su propio cálculo de 72 horas, el valor mostrado por la plataforma y cada acuse.

También debe documentar cualquier indisponibilidad sin sacar conclusiones generales. ENISA indica que, si el portal cae temporalmente, se espere a su recuperación y se presente después. Cuando la urgencia lo justifique se puede contactar directamente al CSIRT, pero la comunicación no sustituye el envío posterior por la plataforma.

Una bitácora pública sin exponer vulnerabilidades

La supervisión del mecanismo no requiere publicar fallos activos ni identificar fabricantes. Requiere saber qué versión operativa estaba disponible cuando corrió el plazo.

ENISA podría mantener una bitácora pública y respetuosa con la confidencialidad que indique periodos de disponibilidad, clases de remitentes admitidas, tipos de informe, idiomas, estado de la API, versión del contador y hora efectiva de los cambios. Esa bitácora permitiría auditar la infraestructura sin convertirla en una base de datos de objetivos.

Es una recomendación editorial mía, no una obligación vigente ni una promesa de ENISA. Sigue la cadena de autoridad de The Policy Mirror, la prueba de implementación de Running Code Primary y la separación entre registro y defensa institucional de Why BTW Media Exists.

El portal unifica la puerta. El CRA conserva repartidas las llaves. La calidad del nuevo régimen dependerá de que cada actor deje constancia de cuándo tomó y entregó la suya.

Fuentes