Cyber Resilience Act: desde el 11 de septiembre tienes 24 horas para avisar de una vulnerabilidad explotada
Si pones en el mercado europeo un producto con elementos digitales y descubres que alguien está explotando activamente una vulnerabilidad, ahora tienes 24 horas para dar el primer aviso a las autoridades. Una app móvil cuenta como producto con elementos digitales. Esta parte del Cyber Resilience Act (CRA) está en vigor desde el 11 de septiembre de 2026. El resto del reglamento, el marcado CE y los requisitos de seguridad de producto, no llega hasta el 11 de diciembre de 2027.
La distinción importa porque cambia lo que tienes que hacer esta semana frente a lo que puedes planificar con calma. Casi todo lo que se escribe sobre el CRA habla de 2027. La obligación que ya te puede caer encima es la de notificación, y depende de que detectes el problema, no de una fecha de certificación.
Qué ha entrado en vigor y qué sigue esperando
El CRA se aplica por fases. Desde el 11 de septiembre de 2026 son exigibles las obligaciones de notificación del artículo 14: reportar vulnerabilidades que se estén explotando de forma activa e incidentes graves que afecten a la seguridad de tu producto. Nada más de momento.
El grueso del reglamento (los requisitos esenciales de ciberseguridad, la evaluación de conformidad y el marcado CE que acredita que un producto los cumple) se vuelve obligatorio el 11 de diciembre de 2027. Hasta entonces no tienes que rediseñar tu proceso de desarrollo para pasar una auditoría de conformidad. Sí tienes que saber a quién llamas y en cuánto tiempo si algo se explota.
Una precisión que se pasa por alto: la obligación de notificar aplica también a productos que ya estaban en el mercado antes de septiembre. No hay periodo de gracia por antigüedad. Si tu app lleva tres años publicada y mañana detectas explotación activa, el reloj de 24 horas corre igual.
A quién aplica (y a quién no)
El CRA habla de "productos con elementos digitales": hardware y software cuyo uso previsto implica una conexión de datos, directa o indirecta, con un dispositivo o una red. Una app móvil entra. Un backend que forma parte del producto entra. El firmware de un cargador o de un sensor entra.
Quedan fuera, a grandes rasgos, los servicios SaaS puros que no son parte integral de un producto (esos caen bajo NIS2, no bajo el CRA) y las categorías ya reguladas por su propia normativa, como los productos sanitarios bajo el MDR o la automoción. La zona gris son las "soluciones de procesamiento remoto de datos": si tu app depende de un servicio que tú mismo operas para funcionar, ese servicio se considera parte del producto y entra con él.
Aquí está el matiz que se menciona poco y que a ti, si externalizas desarrollo, te afecta de lleno. La obligación recae en el "fabricante": quien pone el producto en el mercado bajo su nombre o su marca. Si tu empresa publica la app en las tiendas con tu marca, el fabricante eres tú, no la agencia que la programó. Tu proveedor de desarrollo puede darte el proceso técnico y la capacidad de reacción, pero la responsabilidad legal de notificar en plazo es tuya. Conviene que eso esté escrito en el contrato de mantenimiento antes de que haga falta usarlo, no después.
Los tres relojes
El artículo 14 define un proceso escalonado, no un único informe. Cuando detectas una vulnerabilidad explotada activamente o un incidente grave, empiezan a correr tres plazos.
| Plazo | Qué entregas |
|---|---|
| 24 horas | Aviso temprano: notificas que existe el problema, aunque todavía no tengas el detalle completo |
| 72 horas | Notificación: descripción técnica, gravedad, impacto y, si los tienes, indicadores de compromiso y medidas correctoras |
| 14 días / 1 mes | Informe final: para vulnerabilidades, hasta 14 días después de que haya una medida correctora disponible; para incidentes graves, en el plazo de un mes desde la notificación de las 72 horas |
Las notificaciones van a la plataforma única de reporte que opera ENISA, dirigidas al CSIRT del país donde tienes tu establecimiento principal, con copia simultánea a ENISA. No es un correo a un buzón genérico ni un formulario que rellenas cuando puedas: es un canal concreto con un destinatario concreto.
"Explotación activa" tiene un significado preciso. No es que exista una vulnerabilidad ni que se pueda explotar en teoría. Es que hay pruebas fiables de que alguien la está usando contra un sistema sin permiso de su responsable. Esa diferencia marca cuándo arranca el reloj de 24 horas.
Qué tienes que tener montado esta semana
Esto no exige un rediseño. Exige que, el día que pase, no improvises. Lo mínimo:
- Un responsable con nombre y apellidos que decida si un hallazgo cuenta como explotación activa o incidente grave. Sin dueño, las 24 horas se van en reenviar correos.
- El dato de a quién notificar ya localizado: el CSIRT coordinador de tu país y el acceso a la plataforma de ENISA. Averiguarlo el día del incidente es perder medio reloj.
- Un canal para que alguien de fuera te avise de una vulnerabilidad. Muchas explotaciones las descubre un tercero antes que tú; si no tienes dónde recibir el aviso, te enteras tarde.
- Telemetría suficiente para saber si algo se está explotando. Sin trazas de tu backend y de tu app, la palabra "activa" es indemostrable en un sentido y en el otro.
- Saber qué llevas dentro. Si no tienes un inventario de dependencias, cuando salga un CVE en una librería que usas no vas a poder decir en horas si te afecta.
Ninguno de estos cinco puntos es nuevo para un equipo que ya trata la seguridad en serio. La novedad es el plazo legal y la multa detrás: hasta 15 millones de euros o el 2,5 % de la facturación anual mundial, lo que sea mayor, y la notificación está clasificada como obligación central, de las que se sancionan arriba.
Qué puede esperar a 2027
Todo lo demás. Los requisitos esenciales de seguridad del producto, la gestión de vulnerabilidades a lo largo del ciclo de vida, la documentación técnica, la evaluación de conformidad y el marcado CE son obligatorios desde diciembre de 2027. Es trabajo real y conviene empezarlo con tiempo, pero no es lo que te expone hoy.
Nuestra lectura: si dedicas el último trimestre de 2026 a montar el proceso de notificación y a dejar el inventario de dependencias en orden, llegas a 2027 con la mitad del camino hecho, porque buena parte de los requisitos esenciales se apoyan en lo mismo.
Cómo lo vemos
Para quién es urgente de verdad: si vendes o distribuyes en la UE un producto conectado (una app con backend propio, un dispositivo con firmware, un wearable, un cargador, un sensor), la obligación de notificar ya es tuya y el coste de no tenerla montada es un plazo de 24 horas que no vas a cumplir. Para quién puede respirar: si tu producto está claramente fuera de scope, como un SaaS puro o un producto sanitario ya regulado por el MDR, revisa el encaje una vez y sigue.
No te recomendamos montar un comité ni contratar una consultoría de cumplimiento para esto. Es desproporcionado. Lo que sí recomendamos es dedicar una tarde a tres cosas: nombrar al responsable, dejar localizados el CSIRT y la plataforma de ENISA, y comprobar que tienes telemetría e inventario de dependencias. Con eso cubres la parte que te puede caer encima mañana. El resto, el de 2027, lo planificas.
El coste honesto de todo esto no es dinero, es disciplina: alguien tiene que hacerse dueño del proceso y mantener el inventario al día. Si tu equipo ya hace gestión de incidentes, es formalizar lo que ya hace. Si no la hace, el CRA es la excusa para empezar, y es una buena excusa.
Si quieres que revisemos si tu producto entra en scope y cómo dejar montado el proceso de notificación sin sobreingeniería, hablamos. Llevamos desde 2011 construyendo y manteniendo apps y backends en producción, y la gestión de vulnerabilidades es parte del mantenimiento, no un extra.
