El Cyber Resilience Act no se aplica en su totalidad hasta el 11 de diciembre de 2027. La mayoría de los equipos lo ha archivado en consecuencia, en algún punto de la columna 2027 de una hoja de ruta. Ese archivo lleva ya quince meses de retraso: el artículo 14, la obligación de notificar, se aplica desde el 11 de septiembre de 2026.
Es una obligación estrecha y rápida. Si usted fabrica un producto con elementos digitales introducido en el mercado de la Unión y tiene conocimiento de que se está explotando activamente una vulnerabilidad suya, dispone de 24 horas para presentar una alerta temprana. No una corrección, no un análisis: una notificación, a través de la plataforma única de notificación, al CSIRT designado como coordinador y a ENISA.
A quién alcanza, incluidos quienes no se ven como fabricantes
La palabra «fabricante» evoca hardware, y esa lectura es el primer error. Un producto con elementos digitales es cualquier producto de software o hardware, y sus soluciones de tratamiento remoto de datos, introducido en el mercado como una oferta comercial diferenciada. Una plataforma SaaS vendida como producto, una aplicación móvil, una imagen de firmware, una biblioteca distribuida comercialmente, un controlador embebido: todos dentro del ámbito.
Hay dos casos más que sorprenden a menudo.
Usted le pone su nombre. Un distribuidor o importador que comercializa un producto con su propio nombre o marca pasa a ser el fabricante a efectos del reglamento, con la obligación de notificar incluida.
Usted lo ha modificado sustancialmente. Tome un componente de código abierto o un producto de terceros, modifíquelo de forma que afecte a sus propiedades de seguridad e introduzca el resultado en el mercado: las obligaciones siguen a la modificación.
El código abierto desarrollado y suministrado fuera de una actividad comercial queda fuera. La frontera es la actividad comercial, no la licencia, y es más fina de lo que se supone: un mantenedor que vende soporte o correcciones prioritarias está en el lado equivocado.
Los tres informes, y el reloj de cada uno
La obligación no es una presentación única. Es una secuencia, y cada paso tiene su plazo, que corre desde el momento del conocimiento.
En 24 horas, la alerta temprana. Cuál es la vulnerabilidad, que se está explotando y qué Estados miembros cree usted afectados, si lo sabe. Es deliberadamente escueta. Existe para que los coordinadores puedan empezar, no para que usted sea exhaustivo.
En 72 horas, la notificación de vulnerabilidad. Información general sobre el producto, la naturaleza de la explotación y las medidas correctoras o de mitigación adoptadas o disponibles.
En 14 días desde que hay una medida correctora disponible, el informe final. Descripción de la vulnerabilidad, su gravedad e impacto, y la corrección.
La misma forma se aplica a los incidentes graves que afectan a la seguridad del producto, con la misma alerta a las 24 horas y un informe final al mes.
Dos puntos prácticos. El reloj arranca con el conocimiento, y el conocimiento es un hecho organizativo, no una decisión: un ingeniero de soporte que ve una explotación en los registros de un cliente un viernes por la tarde ya lo ha puesto en marcha. Y el informe de 24 horas no está condicionado a que usted entienda la vulnerabilidad: notifica lo que sabe y después vuelve a notificar.
Lo que falla de verdad
Hemos ensayado este escenario con equipos de producto cuatro veces este año, como ejercicio de mesa con el reloj a la vista. Nadie incumplió el plazo por no saber redactar el informe. Los plazos se incumplieron, o se rozaron, por las mismas cuatro razones.
Nadie es dueño del disparador. La explotación la detecta el soporte, un cliente, un investigador, la inteligencia de amenazas o un aviso del proveedor: cinco puntos de entrada, y en todos los casos quien lo vio no sabía que acababa de arrancar un reloj regulatorio de 24 horas. Es lo más rentable de arreglar, y es una tarde de trabajo: una regla escrita sobre qué aspecto tiene una «explotación activa» en su empresa, y un único circuito desde cualquiera de los cinco puntos de entrada hasta quien puede presentar.
El inventario de producto no es un inventario regulatorio. Las empresas saben qué venden. No tienen la lista que responde a: cuáles son productos con elementos digitales, introducidos en qué mercados, bajo qué nombre, con qué periodo de soporte declarado. Esa lista es la que dice si una explotación concreta es notificable, y no se construye bajo un plazo de 24 horas.
La cuenta en la plataforma no existe. La notificación pasa por la plataforma única. Una cuenta, las personas adecuadas en ella y un envío de prueba no se resuelven en la tercera hora de un incidente.
El reflejo jurídico es esperar. El instinto de confirmar antes de notificar es correcto en casi cualquier otro contexto y equivocado aquí. Veinticuatro horas no admiten un ciclo de revisión. La alerta temprana está diseñada para revisarse; el plazo, no.
Si no ha empezado
Cuatro días de trabajo, repartidos en quince, cierran la brecha:
- Una nota de alcance que nombre sus productos con elementos digitales, sus mercados y quién es el fabricante de cada uno. Una página por producto, no un proyecto.
- Una definición escrita del disparador y un único circuito interno desde cualquier punto de entrada hasta quien presenta. Póngala donde el soporte la vea, no solo en la wiki del equipo de seguridad.
- La cuenta en la plataforma, aprovisionada, con dos personas nombradas y un simulacro.
- Un ejercicio de mesa, con reloj. Una hora, una vez. Ahí es donde el circuito que falta se hace evidente.
Nada de esto es el trabajo de diciembre de 2027: la evaluación de la conformidad, la documentación técnica, los requisitos de seguridad desde el diseño, el periodo de soporte declarado y el proceso de tratamiento de vulnerabilidades. Ese es un programa de verdad, y debe planificarse ahora. Pero no es lo que vence hoy. Lo que vence hoy es una llamada que llegue a la persona adecuada dentro del día, y un formulario en el que alguien ya haya entrado una vez.
La pregunta que conviene hacer a su equipo esta semana
No «¿cumplimos el CRA?» — nadie lo cumple, y la pregunta no tiene respuesta hasta dentro de un año. Pregunte en cambio: si esta noche un cliente escribe a nuestra dirección de soporte diciendo que le están atacando a través de nuestro producto, ¿quién presenta la alerta temprana, y para cuándo?
Si la respuesta ocupa más de una frase, ahí está la brecha, y es la más barata de cerrar de todo el reglamento.