Una obligación concreta, no la aplicación completa del CRA
El 11 de septiembre de 2026 comenzó a aplicarse la obligación de notificación del Cyber Resilience Act (CRA) para fabricantes: deben reportar vulnerabilidades explotadas activamente y determinados incidentes graves que afecten a la seguridad de productos con elementos digitales. La fecha importa, pero conviene describirla con precisión: no significa que todas las obligaciones del reglamento hayan empezado ese día, ni que cualquier problema de seguridad deba comunicarse automáticamente por esta vía. El alcance inmediato es más acotado y depende de que se cumplan las condiciones previstas por la norma.
El CRA es el Reglamento (UE) 2024/2847, un marco europeo sobre requisitos de ciberseguridad para productos con elementos digitales. La Comisión Europea distingue las notificaciones que ya se exigen de otras disposiciones que empezarán a aplicarse más adelante. Por eso, para equipos de producto, seguridad y cumplimiento, la tarea ahora no consiste en dar por hecho que cada obligación futura está activa, sino en identificar los casos sujetos al reporte y establecer un procedimiento para reconocerlos y escalarlos. La fecha inicial abre una obligación específica, no un régimen plenamente aplicable.
A quién se aplica y qué casos deben activar una revisión
La obligación vigente recae en los fabricantes de productos con elementos digitales dentro del ámbito del CRA. La guía de la Comisión describe dos supuestos que deben notificarse: una vulnerabilidad explotada activamente y un incidente grave que tenga un impacto en la seguridad del producto. No basta, por tanto, con equiparar el reporte a una lista general de fallos, alertas o vulnerabilidades potenciales. La organización necesita valorar si los hechos encajan en las categorías legales y conservar una base documentada para esa decisión.
La palabra fabricante tiene un significado regulatorio, no es simplemente sinónimo de cualquier desarrollador o equipo que participe en el software. El texto legal organiza obligaciones según el papel que desempeña cada operador económico, y también contempla disposiciones para custodios de software de código abierto. La Comisión indica que a estos custodios les corresponden obligaciones de reporte desde el 11 de diciembre de 2027, no desde el inicio de esta fase para fabricantes. En situaciones con cadenas de suministro, componentes de terceros o productos construidos sobre software abierto, conviene determinar quién es responsable bajo el reglamento antes de asignar el reporte. La etiqueta técnica de una empresa no sustituye el análisis de su función legal.
Qué plazos fija la notificación
Según la información de la Comisión, el procedimiento contempla una alerta inicial en un máximo de 24 horas desde que el fabricante tiene conocimiento del caso y una notificación completa dentro de las 72 horas. Además, exige un informe final con plazos que varían según el supuesto: para vulnerabilidades explotadas activamente, no más tarde de 14 días después de que haya una medida correctiva disponible; para incidentes graves, dentro del mes siguiente a la notificación de 72 horas. Son hitos distintos, no una única fecha límite calculada desde el descubrimiento.
La referencia al momento en que el fabricante toma conocimiento hace relevante la forma en que la organización detecta, valida y escala las señales. Un proceso interno que espere a cerrar toda la investigación antes de involucrar a las funciones responsables puede dificultar cumplir una alerta temprana; a la vez, la existencia de una primera notificación no elimina la necesidad de completar la información y emitir el informe final cuando corresponda. La norma y las instrucciones oficiales deben guiar la interpretación de los plazos en cada caso. Una respuesta operativa debe separar evaluación inicial, notificación completa y cierre, con responsables y registros para cada etapa.
La plataforma única y el recorrido del aviso
Los fabricantes presentan las notificaciones mediante la CRA Single Reporting Platform (SRP), creada por ENISA en cooperación con la red de CSIRT. El canal está operativo desde el 11 de septiembre de 2026. La Comisión indica que el fabricante presenta una sola vez el aviso: este se dirige al CSIRT del Estado miembro donde el fabricante tiene su establecimiento principal y, salvo circunstancias excepcionales, la información se pone simultáneamente a disposición de ENISA.
El CSIRT receptor comparte la notificación sin demora con los demás CSIRT en cuyo territorio se haya comercializado el producto. La Comisión también señala que, en circunstancias excepcionales y por motivos de ciberseguridad justificados, puede retrasarse la difusión a otros equipos. Así, la plataforma no debe entenderse como una publicación abierta ni como un mecanismo para que una empresa elija individualmente a todos los destinatarios. En términos prácticos, el procedimiento interno debería identificar quién puede preparar el envío, quién lo autoriza y cómo se conserva constancia de la información reportada. ENISA publica materiales de orientación para el uso de la plataforma; esas instrucciones ayudan con el canal, pero no reemplazan la evaluación jurídica del alcance.
Lo que esta fase no permite concluir
Que la obligación esté activa no quiere decir que todas las disposiciones sustantivas del CRA se apliquen ya. La fecha general prevista para la aplicación de la mayor parte del reglamento es el 11 de diciembre de 2027, mientras que la obligación de notificación comenzó antes. El calendario escalonado explica por qué una empresa puede tener que preparar reportes ahora y, a la vez, seguir trabajando en otras obligaciones que todavía no han llegado a su fecha de aplicación.
Tampoco debe interpretarse esta descripción como una conclusión de que toda organización que escriba o distribuya código es fabricante, o de que todo servicio alojado en la nube queda dentro del CRA. El reglamento define el alcance mediante productos con elementos digitales y funciones determinadas, e incluye condiciones específicas para soluciones de procesamiento remoto vinculadas al producto. Este artículo resume la obligación inicial, no resuelve casos particulares de clasificación, excepciones o interacción con otras normas europeas. Cuando el modelo de negocio o el producto esté en el límite del ámbito legal, la respuesta exige revisar el texto normativo y las aclaraciones oficiales aplicables. Una guía general orienta; no sustituye el análisis del caso concreto.
Qué conviene preparar desde ahora
Una preparación útil puede empezar con un inventario de productos que se comercializan en la Unión Europea, sus fabricantes responsables y los canales por los que se reciben reportes de vulnerabilidades e incidentes. Después, la empresa puede definir criterios de escalamiento que permitan revisar con rapidez si un caso podría ser una explotación activa o un incidente grave con impacto en la seguridad del producto. Este trabajo no presupone que cada señal deba notificarse; busca que la decisión llegue a las personas adecuadas a tiempo.
También es razonable asignar funciones para evaluar el caso, reunir información técnica, validar el contenido del aviso y realizar el envío por la SRP. Conviene preparar un registro de cuándo se tuvo conocimiento de los hechos y de las decisiones adoptadas, porque los plazos oficiales se cuentan desde ese conocimiento y las notificaciones siguen varias etapas. Por último, el calendario debe distinguir el hito ya vigente del 11 de septiembre de 2026 y las obligaciones que comienzan el 11 de diciembre de 2027. El punto de partida práctico es verificar el alcance, ensayar el flujo de decisión y consultar las instrucciones oficiales de ENISA; no asumir que el reporte es universal ni esperar al último momento para definir quién responde.