Opinión
La obligación de notificación del Cyber Resilience Act ya está en vigor. En la mayoría de los fabricantes, los procesos siguen siendo puro teatro.
Hoy, 11 de septiembre de 2026, la obligación de notificación del Cyber Resilience Act (CRA) entra en vigor en toda la Unión Europea. No en diciembre de 2027, cuando aterrizan los requisitos esenciales de producto y a todo el mundo le han dicho que espere el verdadero ajuste de cuentas. Hoy. Si fabricas un producto con elementos digitales y lo vendes en la UE, el reloj de tu primera notificación empieza a correr desde este momento, tanto si tu organización marcó la fecha en el calendario como si no.
En julio escribí que el Cyber Resilience Act era el reglamento que nadie estaba vigilando lo suficiente de cerca, el que puede retirar un producto del mercado en lugar de limitarse a multar a la empresa que hay detrás. Aquel artículo se centraba en el gran cuadro del cumplimiento: alcance, categorización, la relación con NIS2. Este trata de la obligación mucho más concreta y mucho más afilada que acaba de entrar en vigor, y de la incómoda distancia que hay entre cuántos fabricantes dicen conocerla y cuántos pueden realmente actuar dentro de las horas que la ley les da.
La fecha que nadie estaba vigilando
La mayor parte de lo que se ha escrito sobre el CRA sigue girando en torno a diciembre de 2027, y es comprensible, porque es cuando se aplican en su totalidad los requisitos esenciales de ciberseguridad y las obligaciones de evaluación de la conformidad. Pero el artículo 14 del reglamento reservó una fecha aparte, anterior, específicamente para la notificación: a partir del 11 de septiembre de 2026, los fabricantes deben notificar las vulnerabilidades explotadas activamente y los incidentes graves que afecten a sus productos, y ese deber se aplica a los productos que ya están en el mercado, no solo a los nuevos lanzamientos.
La Comisión Europea publicó su guía práctica sobre esto el 27 de julio de 2026, apenas unas semanas antes de que la fecha entrara en vigor. Es una ventana muy estrecha para una obligación que lleva asociado un primer plazo de 24 horas. Los requisitos esenciales de diciembre de 2027 dan a los fabricantes unos quince meses de margen desde este momento. La obligación de notificación dio mucho menos.
¿Qué tienes que notificar exactamente?
Esta es la pregunta que hace tropezar a la gente, y merece la pena responderla con precisión en lugar de en términos generales.
Notificas una vulnerabilidad explotada activamente, es decir, que existen pruebas creíbles de que alguien la está usando contra tu producto ahora mismo. Notificas un incidente grave, es decir, algo que compromete realmente la seguridad de tu producto, no una simple debilidad teórica. Lo que no notificas es cada CVE que se asigna a tu código, cada hallazgo de tu propia prueba de penetración o cada envío a través de tu programa de divulgación responsable o de tu bug bounty, a menos que haya pruebas de que se ha explotado de verdad. El webinar que el Ministerio de Asuntos Económicos y Clima de los Países Bajos y el National Cyber Security Centre (NCSC) organizaron el 27 de agosto fue tajante con esta distinción, y con razón: sin ella, los fabricantes o bien ahogarían de ruido a su CSIRT nacional o, peor aún, darían por hecho que cada informe de vulnerabilidad necesita la misma urgencia de 24 horas y quemarían al equipo que se supone que tiene que atender los que sí importan.
Todavía puedes notificar voluntariamente los casos de menor gravedad, y hay buenas razones para crear ese hábito. Pero el deber legal recae específicamente sobre la explotación activa y los incidentes graves, y saber dónde cae esa línea es lo primero que tu proceso de respuesta a incidentes tiene que acertar.
El reloj no se detiene por tu reunión de respuesta a incidentes
Una vez que lo sabes, la cronología está escalonada y no perdona. Una alerta temprana sale en un plazo de 24 horas desde que tienes conocimiento. Una notificación más completa la sigue en un plazo de 72 horas, que cubre lo que sepas para entonces sobre la naturaleza, el impacto y las medidas de mitigación. Un informe final cierra el caso: catorce días después de que se disponga de una medida correctora para una vulnerabilidad, o un mes para un incidente grave, según la guía de la Comisión Europea.
El análisis que Freshfields hace de la nueva obligación plantea una idea que conviene interiorizar: los plazos de notificación empiezan en el momento en que tienes conocimiento, y el reloj no se para ni los fines de semana ni los días festivos. No hay periodo de gracia por el hecho de que tu responsable de seguridad estuviera en un congreso, o por que el incidente ocurriera un viernes por la noche. Si tu organización no tiene ya un proceso definido de quién evalúa un informe, quién decide que supera el umbral y quién lo presenta, estás construyendo ese proceso por primera vez bajo un plazo activo de 24 horas, que es justamente el peor momento para construir nada.
La notificación en sí se canaliza a través de tu CSIRT nacional, el NCSC en los Países Bajos, y de la Single Reporting Platform de ámbito europeo que opera ENISA, de modo que un fabricante de Bélgica, Alemania o cualquier otro lugar de la UE sigue la misma cronología escalonada a través de su propio punto de contacto nacional. La mecánica varía ligeramente según el Estado miembro; la obligación y los plazos no.
¿Por qué son tan malos los números de preparación?
Aquí es donde la afirmación de que “en la mayoría de los fabricantes los procesos son puro teatro” tiene que ganarse su sitio, y los datos de las encuestas la respaldan de forma más rotunda de lo que yo esperaba.
El SME Cyber Resilience Maturity Assessment Model de ENISA, publicado el 13 de julio de 2026 y basado en trabajo de campo con 194 organizaciones de 31 países, encontró una alta concienciación sobre el CRA pero una preparación práctica sistemáticamente débil, con la respuesta a incidentes y la gestión del ciclo de vida del producto como los dos dominios más flojos en general. Ser consciente de que existe una ley no es lo mismo que tener un proceso capaz de actuar dentro de una ventana de 24 horas.
La investigación de preparación ante el CRA de 2026 de la Linux Foundation y OpenSSF, a partir de 843 encuestados, cuenta una historia parecida desde otro ángulo. El sesenta y seis por ciento seguía sin saber qué necesitaba hacer realmente para cumplir, una cifra que apenas se había movido del 62 por ciento del año anterior. Solo el 41 por ciento de los fabricantes esperaba alcanzar el cumplimiento total para el plazo de diciembre de 2027, y solo el 34 por ciento identificó correctamente esa fecha de entrada. Entre los encuestados que conocían el CRA de algún modo, el 54 por ciento seguía sin poder distinguir con claridad entre las obligaciones de un fabricante y las de un steward.
Nada de eso es un reproche a ningún equipo de cumplimiento en concreto. Refleja un reglamento que pasó de lo abstracto a lo operativo más rápido de lo que la mayoría de los procesos organizativos podían seguir. Pero sí significa que una parte considerable de los fabricantes que leen esto cruzaron la línea del 11 de septiembre sin ningún proceso probado detrás, que es exactamente el escenario que la obligación de notificación fue diseñada para pillar en falta.
¿Quién tiene que notificar realmente?
Bajo el CRA, la obligación de notificación recae sobre el fabricante, la entidad que introduce en el mercado de la UE un producto con elementos digitales con su propio nombre o marca, y el tamaño de la organización no te exime. Un importador o distribuidor por lo general no carga con un deber de notificación independiente, salvo que venda con su propia marca o modifique el producto de forma sustancial, en cuyo caso se convierte en la práctica en el fabricante de ese producto. Los stewards de software de código abierto se enfrentan a una versión más ligera del mismo deber, que refleja la relación distinta que tienen con los productos que mantienen. Las pequeñas y microempresas también entran de lleno en el alcance; la única concesión que el NCSC neerlandés ha confirmado es que no hay sanción por incumplir la estricta ventana de 24 horas en esa categoría, lo cual es una mitigación, no una exención.
Un detalle que conviene señalar porque genera confusión de verdad: el CRA en sí no exige ningún registro previo antes de poder notificar. No necesitas una cuenta ni un inicio de sesión para presentar una notificación. Es una decisión de diseño deliberada, distinta del deber de registro que existe bajo la Cyberbeveiligingswet (la transposición neerlandesa de NIS2) para las organizaciones que también quedan bajo esa ley. Las dos obligaciones corren en paralelo, no como un único proceso combinado, y confundirlas es un error fácil de cometer.
¿Qué aspecto tiene realmente estar “preparado”?
Prepararse para la obligación de notificación del CRA no es complicado en principio. Es exigente en la práctica, que es un problema distinto.
Empieza por un inventario honesto de lo que hay realmente dentro de tus productos, idealmente mediante un Software Bill of Materials (SBOM), porque no puedes valorar si una vulnerabilidad notificada te afecta si no sabes qué componentes distribuyes. Fija de antemano tus propios umbrales internos de qué cuenta como explotación activa o incidente grave, para que esa decisión de criterio no se tome por primera vez bajo presión. Construye una cadena de escalado con roles nombrados: quién da la señal, quién decide, quién presenta. Redacta ahora las plantillas de la alerta temprana, de la notificación de 72 horas y del informe final, mientras nadie está contra reloj. Y alinea todo esto con cualquier otra cosa bajo la que ya notifiques, porque un buen número de fabricantes que leen esto también quedan bajo la Cyberbeveiligingswet o la AVG, y llevar tres procesos de notificación descoordinados es un riesgo en sí mismo.
Esta es, y no por casualidad, la misma disciplina que defendí en julio cuando escribí sobre las exigencias de cumplimiento más amplias del CRA: sabe lo que tienes, categorízalo con honestidad y prepara el papeleo antes de que el regulador lo pida. La obligación de notificación simplemente ha movido ese argumento de “algún día” a “ahora”.
Si un cliente te dijera esta mañana que alguien está explotando activamente una vulnerabilidad en tu producto, ¿sabría tu organización, en un plazo de 24 horas, exactamente quién recoge ese informe? Si la respuesta honesta es “ya lo resolveríamos sobre la marcha”, la obligación de notificación no entró en vigor hoy por nada.
Fuentes
- European Commission, Cyber Resilience Act, Reporting obligations, Shaping Europe’s Digital Future: digital-strategy.ec.europa.eu/en/policies/cra-reporting
- ENISA, SME Cyber Resilience Maturity Assessment Model, published 13 July 2026.
- Linux Foundation Research, Linux Foundation Europe, and OpenSSF, “The CRA Readiness Reality: What Changed (and What Didn’t) Between 2025 and 2026?”, June 2026: linuxfoundation.org
- Freshfields, “Cyber Resilience Act reporting obligations take effect on 11 September 2026”: freshfields.com
- Ministry of Economic Affairs and Climate Policy and National Cyber Security Centre (NCSC), Cyber Resilience Act, Themasessie Meldplicht (webinar), 27 August 2026.