Cyber Resilience Act: 24 horas para avisar, y el reloj no arranca con el CVE

El Cyber Resilience Act lleva dos años en el calendario de todo el mundo con una fecha escrita: 11 de diciembre de 2027. Lo que casi nadie tenía apuntado es que hoy empieza a aplicarse un artículo suelto, el 14, y que ese artículo es el único que el propio reglamento estira hacia atrás para que alcance a todo lo que ya vendiste. A partir de esta mañana, un fabricante tiene 24 horas para dar el primer aviso de una vulnerabilidad que le estén explotando. Y el plazo no empieza cuando se publica el CVE ni cuando sale la noticia: empieza cuando tú te enteras. Que es un asunto de abogados solo en parte. Lo demás es quién lee qué, y a qué hora. Y arranca un viernes.

Qué arranca hoy, y qué no

El artículo 71 del Reglamento (UE) 2024/2847 dice tres cosas en dos líneas: el reglamento se aplica desde el 11 de diciembre de 2027, el artículo 14 desde el 11 de septiembre de 2026 y el capítulo IV (organismos notificados) desde el 11 de junio de 2026. Nada más. Hoy no te obliga el marcado CE, ni los requisitos esenciales del anexo I, ni la declaración de conformidad, ni el periodo de soporte. Hoy te obliga una cosa: contar lo que te está pasando, a quien toca y en plazo.

El único artículo que mira hacia atrás

Aquí está el detalle que nos parece el más importante del día y que apenas hemos visto comentado. El artículo 69.2 contiene la buena noticia que todo el mundo repite: lo que pusiste en el mercado antes del 11 de diciembre de 2027 no queda sujeto al reglamento, salvo que a partir de esa fecha lo modifiques sustancialmente. Es el párrafo que ha tranquilizado a mucha gente con catálogo antiguo. El párrafo siguiente, el 69.3, arranca con la fórmula «como excepción a lo dispuesto en el apartado 2 del presente artículo» y dice que las obligaciones del artículo 14 se aplican a todos los productos con elementos digitales dentro del ámbito que se hayan puesto en el mercado antes del 11 de diciembre de 2027.

Traducido: aquella versión que vendiste en 2019 y que sigue instalada en catorce clientes no tiene que cumplir un solo requisito técnico del CRA. Pero si alguien la está explotando y te enteras a partir de hoy, tienes 24 horas. Conviene añadir el límite, porque también lo han tenido que aclarar: si ya sabías antes de hoy que te la estaban explotando, no hay que notificar hacia atrás. Lo que dispara el reloj es enterarse, y punto. El legislador puso primero el sensor y después la norma de producto. Sin el sensor, nadie sabe qué está pasando ahí fuera.

El reloj: 24, 72 y 14

• 24 horas — aviso temprano. Sin demora indebida y en todo caso dentro de las 24 horas desde que el fabricante tiene conocimiento. Contenido mínimo: indicar, cuando proceda, en qué Estados miembros está disponible tu producto. Ese campo, que parece burocrático, es el que descubre a mucha gente que no tiene la lista.
• 72 horas — notificación. Información general del producto, naturaleza del exploit y de la vulnerabilidad, medidas correctoras o mitigadoras tomadas y las que puede aplicar el usuario, más una indicación de lo sensible que consideras la información notificada.
• 14 días — informe final. Y aquí hay un matiz que se cuenta mal en casi todas partes: los 14 días no cuentan desde el aviso, cuentan desde que hay una medida correctora o mitigadora disponible. Si no la hay, ese plazo no ha empezado. Los otros dos sí.
• Incidente grave: mismo 24 y 72, pero el informe final va a un mes desde la notificación de las 72 horas. Y el CSIRT puede pedirte, si lo ve necesario, un informe intermedio por el camino.

Dos expresiones deciden si te toca

La primera está en el artículo 3. El reglamento define por separado «vulnerabilidad explotable» —la que tiene el potencial de ser usada por un adversario en condiciones operativas prácticas— y «vulnerabilidad explotada activamente», que es aquella respecto de la cual hay pruebas fiables de que un actor malicioso la ha explotado en un sistema sin permiso del propietario del sistema. Solo la segunda dispara el reloj. Y fíjate en qué descansa la diferencia: en «pruebas fiables». No en una sospecha, no en un titular; en evidencia. Si tu producto no genera registros que permitan afirmar o descartar eso, lo que tienes no es tranquilidad. Es que no lo ves.

La segunda expresión está en el apartado 5, el que define cuándo un incidente es «grave»: cuando afecta negativamente o es capaz de afectar negativamente a la capacidad del producto de proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones sensibles o importantes; o cuando ha llevado o es capaz de llevar a la introducción o ejecución de código malicioso. Es decir: el reglamento no mide el daño consumado, mide la capacidad. El incidente que casi sale mal también cuenta. Esa es la frase que va a sorprender a más de uno la primera vez que tenga que decidir a las once de la noche si aquello «fue nada».

El apartado 8, que casi nadie ha leído

Toda la cobertura de estos días va de los tres plazos hacia la administración. El artículo 14 tiene un apartado más, el 8, y es el que más nos interesa a los que vivimos de que las cosas funcionen: después de tener conocimiento, el fabricante informará a los usuarios afectados —y cuando proceda, a todos— de la vulnerabilidad o el incidente y, si hace falta, de las medidas que pueden aplicar; cuando corresponda, en un formato estructurado y legible por máquina. Y luego viene la frase: «cuando el fabricante no informe a los usuarios a tiempo, los CSIRT notificados podrán facilitar dicha información a los usuarios» si lo consideran proporcionado y necesario.

Nuestra lectura, que no es la del reglamento: esa frase pesa más que la multa. Una sanción tarda años y la ve tu asesoría. Que sea el CSIRT quien avise a tus clientes de un problema tuyo que tú no les habías contado se sabe la misma tarde, y se nota en la siguiente renovación. Si tienes que elegir por dónde empezar a montar esto, empieza por ahí: por cómo avisas tú, no por cómo rellenas el formulario.

Hemos abierto el formulario

La notificación no se manda por correo: va por la plataforma única de notificación que establece el artículo 16 y que opera ENISA. Hemos entrado hoy a las 17:05 (hora peninsular): portal.cra-srp.enisa.europa.eu responde. Llega puntual, cosa que en verano parecía dudosa. Lo que hay al otro lado, según las preguntas frecuentes que publica la propia ENISA, conviene saberlo antes y no con el reloj corriendo:

• Se entra con cuenta EU Login con doble factor, y las cuentas son personales: quien notifica usa la suya. Hay un representante asignado principal y secundarios, con permisos distintos.
• La asociación entre el representante y el fabricante la valida el CSIRT designado, y ENISA avisa de que el procedimiento y el tiempo de tramitación varían entre CSIRT y son responsabilidad de cada uno. La verificación va en paralelo y no impide notificar mientras está pendiente.
• No hay API en la versión inicial: se notifica a mano, por la interfaz. Y el reporte voluntario del artículo 15 tampoco está disponible todavía; llegará en una fase posterior.
• Si eliges mal el CSIRT coordinador, la notificación puede quedar invalidada y hay que volver a presentarla ante el correcto. Con un plazo de 24 horas, eso no es un detalle administrativo.
• El contador de las 72 horas está mal en esta versión, y lo dice ENISA sin rodeos: muestra el vencimiento 48 horas después de que presentes el aviso temprano, de modo que una notificación puede aparecer como fuera de plazo antes de que hayan pasado las 72 horas de verdad. Lo arreglarán más adelante calculándolo desde la fecha en que te enteraste. Mientras tanto, el plazo bueno es el tuyo, no el del semáforo de la pantalla.
• Si la plataforma no está disponible, ENISA dice que esperes a que vuelva; puedes contactar directamente con tu CSIRT si la urgencia lo pide, pero la notificación hay que presentarla igualmente por la plataforma cuando vuelva.

Y una recomendación de ENISA con la que discrepamos a medias. Para no saturar de trabajo de validación a los CSIRT, aconseja registrarse e iniciar la validación solo cuando haga falta notificar. Se entiende por qué lo dice, y añade que con la cuenta EU Login activa el alta tarda unos minutos. Pero el día que haga falta notificar tendrás 24 horas, una sala llena de gente nerviosa y, con bastante probabilidad, a la persona con la cuenta de fuera. La cuenta EU Login con doble factor, al menos de dos personas, sí la haríamos hoy. Es gratis y no da trabajo a nadie.

¿A quién notifica una empresa española?

Al CSIRT designado como coordinador del Estado miembro donde el fabricante tenga su establecimiento principal en la Unión. Y ojo a cómo define eso el apartado 7, porque no es el domicilio fiscal: es el Estado miembro donde se toman predominantemente las decisiones relativas a la ciberseguridad de sus productos. Si no se puede determinar, el del establecimiento con más empleados en la Unión. Si no hay establecimiento en la Unión, hay una cascada de cuatro criterios: representante autorizado, importador, distribuidor y, en último término, dónde están la mayoría de los usuarios. Para un grupo con desarrollo repartido entre dos países, esa es una pregunta real que conviene tener contestada por escrito antes, no a las tres de la madrugada.

Para España, la lista de CSIRT coordinadores que publica ENISA remite a INCIBE-CERT, con dos direcciones distintas: la de respuesta a incidentes y la de coordinación de vulnerabilidades. Es coherente con el reparto que ya conocemos —INCIBE-CERT para entidades privadas, CCN-CERT para el sector público— y llega, por cierto, con la transposición de NIS2 todavía en trámite parlamentario. El CRA es un reglamento y no espera a nadie: se aplica directamente. Ya escribimos sobre esa asimetría cuando lo que llegaba era el cuestionario de proveedor de NIS2, y vuelve a pasar lo mismo.

¿Y si no soy fabricante?

El reglamento llama fabricante a quien desarrolla o hace desarrollar un producto con elementos digitales y lo comercializa bajo su nombre o marca, y añade una coletilla que a muchos les cambia la respuesta: «ya sea a cambio de pago, de monetización o de forma gratuita». El plugin que regalas también cuenta. Y «producto con elementos digitales» incluye, por definición, sus soluciones de tratamiento remoto de datos: la parte en la nube sin la cual el producto no podría realizar una de sus funciones. Ahí es donde muchas empresas de software descubren que su servicio no es tan «SaaS puro» como creían, y también donde otras confirman que están fuera. Esa raya la traza un abogado con tu contrato delante, no nosotros.

Si no eres fabricante y solo compras software, hoy no te obliga nada. Pero te cambian dos cosas. La primera: vas a recibir más avisos y antes, algunos de productos que ya habías dado por olvidados, y alguien tiene que leerlos y decidir. La segunda: tus proveedores tienen desde hoy una obligación nueva y concreta, y eso se puede meter en un contrato con una línea. Nosotros la escribiríamos así: «en caso de vulnerabilidad explotada activamente o incidente grave con impacto en la seguridad del producto, el proveedor informará a everyWAN en un plazo máximo de X horas desde que tenga conocimiento, en los términos del artículo 14.8 del Reglamento (UE) 2024/2847». Es la misma pregunta que ya hacía el cuestionario de NIS2, pero ahora con una norma detrás que la respalda.

La multa que circula y su letra pequeña

El número que ha salido estos días en prensa es correcto y conviene ponerlo en contexto. El artículo 64.2 mete el incumplimiento del artículo 14 en el tramo más alto, el mismo que los requisitos esenciales del anexo I: hasta 15 millones de euros o el 2,5% de la facturación mundial anual, la cantidad que sea mayor. Dicho de otro modo: no avisar a tiempo está tarifado igual que fabricar inseguro. Ahora la letra pequeña, que también está en el propio artículo: las reglas concretas de sanción las ponen los Estados miembros, y el apartado 10 exime a microempresas y pequeñas empresas de las multas por incumplir el plazo de las 24 horas —solo ese; el de 72 y el informe final no aparecen en la excepción—. Curiosamente, esa exención está redactada como excepción a los apartados 3 a 9, y las multas del artículo 14 están en el 2. No somos abogados y no vamos a interpretar eso: si tu plan depende de esa exención, que te lo mire uno que sí lo sea.

Lo que montaríamos, por orden

1. Escribir qué significa «tener conocimiento» en tu empresa, y quién lo declara. Es la pieza que no da nadie hecha y de la que cuelga todo lo demás. Nosotros lo aterrizamos en algo prosaico: un ticket con hora. El momento en que se abre es el momento en que arrancó el reloj, y esa marca de tiempo es tu prueba. Sin eso, dentro de un año nadie sabrá decir si el aviso llegó en 20 horas o en 40.
2. Una sola puerta de entrada, y que esté vigilada. Un buzón de seguridad publicado, una política de divulgación en tu web y una guardia real detrás. La mitad de las veces el aviso no llega por tu telemetría: llega por un correo de alguien de fuera. Si ese correo aterriza en una bandeja compartida que se lee los lunes, tu plazo de 24 horas es ficción.
3. La lista de qué vendes y dónde. El aviso de las 24 horas pide los Estados miembros en los que el producto está disponible. Versiones vivas, clientes por país, qué componente de terceros lleva cada una. Si esto no existe, la primera hora de la crisis se va en reconstruirlo, y esa hora salía del plazo.
4. Dos cuentas EU Login con doble factor, hechas hoy. Cuestan cero y quitan de en medio el trámite que peor sienta con un incidente encima. Y con ellas, decidido y por escrito, cuál es tu CSIRT coordinador según el criterio del artículo 14.7 —dónde se toman de verdad las decisiones de ciberseguridad de tu producto—, no el de tu domicilio social.
5. Telemetría que permita decir «pruebas fiables» sin cruzar los dedos. Registros que sobrevivan al incidente, en un sitio donde el atacante no pueda borrarlos, y suficiente señal para distinguir explotada de explotable. Sin eso, la notificación se acaba escribiendo con conjeturas.
6. Ensayarlo un martes cualquiera. Una hora, un supuesto inventado y el cronómetro en marcha: quién declara el conocimiento, quién redacta, quién entra en la plataforma, quién escribe a los clientes. Lo que no se ensaya no existe, y ya lo hemos escrito con otras palabras hablando de el plan de continuidad que nadie ha ensayado. Un procedimiento de notificación sin simulacro es exactamente lo mismo: un documento.

Fíjate en que de los seis puntos, cuatro no son de ciberseguridad: son de organización. Pasa lo mismo con casi toda la normativa europea de estos dos años. Cuando escribimos sobre lo que de verdad aplicaba del AI Act el 2 de agosto acabamos en el mismo sitio: lo difícil llega después, y es tener escrito quién decide qué y en cuánto tiempo.

Lo que no afirmamos

No somos abogados ni damos asesoramiento jurídico: todo lo de arriba es lectura directa del texto del reglamento, que es público y cualquiera puede contrastar, más la documentación operativa de ENISA. No hemos presentado ninguna notificación por la plataforma —no tenemos ninguna que presentar, afortunadamente—, así que lo único que podemos afirmar de ella es que hoy responde y lo que dicen sus preguntas frecuentes. No sabemos cuántas empresas españolas quedan dentro del ámbito y no lo estimamos. Tampoco decimos que la plataforma vaya a fallar: decimos que el reglamento no condiciona los plazos a que funcione, y que eso lo ha resuelto ENISA por escrito diciendo que esperes y notifiques igualmente después. Y una advertencia sobre nosotros mismos: everyWAN vende servicios de cumplimiento y continuidad, así que tenemos un interés evidente en que esto te preocupe. Por eso hemos citado artículo por artículo: para que compruebes el texto y no nos creas a nosotros.

Nota de fuentes

Todos los datos de este post se han contrastado el 11 de septiembre de 2026 contra el texto del Reglamento (UE) 2024/2847 (Cyber Resilience Act), leído artículo por artículo: artículo 3 (definiciones 1, 2, 13, 41 y 42), artículo 14 completo (los tres plazos de vulnerabilidad explotada y de incidente grave, el contenido mínimo de cada notificación, el informe intermedio del apartado 6, el criterio de establecimiento principal y la cascada del apartado 7, y la obligación de informar a los usuarios del apartado 8), artículo 16 (plataforma única, difusión y sus excepciones), artículo 64 (tramos de sanción y la exención del apartado 10 para microempresas y pequeñas empresas), artículo 69 (apartados 2 y 3, régimen transitorio) y artículo 71 (fechas de aplicación: 11 de diciembre de 2027 con carácter general, artículo 14 desde el 11 de septiembre de 2026 y capítulo IV desde el 11 de junio de 2026). La parte operativa procede de la documentación publicada por ENISA: la página de la plataforma única de notificación y sus preguntas frecuentes (registro por EU Login con doble factor, representantes asignados principal y secundario, validación por el CSIRT designado con tiempos que varían entre CSIRT, verificación en paralelo que no impide notificar, ausencia de API en la versión inicial, reporte voluntario del artículo 15 no disponible al lanzamiento, invalidación de la notificación si se elige el CSIRT equivocado, qué hacer si la plataforma no está disponible y el consejo de registrarse solo al necesitar notificar) y su lista de CSIRT designados como coordinadores, que para España remite a INCIBE-CERT. La fecha de entrada en aplicación y la operatividad de la plataforma figuran además en la página de obligaciones de notificación del CRA de la Comisión Europea. El Reglamento Delegado (UE) 2026/881, de 11 de diciembre de 2025, es el que desarrolla los motivos para retrasar la difusión de las notificaciones previstos en el artículo 16.2. La comprobación de que portal.cra-srp.enisa.europa.eu responde es nuestra, hecha hoy a las 17:05 hora peninsular. Es lectura NUESTRA y no de las fuentes: que el artículo 14 sea el único que el reglamento estira hacia atrás y lo que eso implica para el catálogo antiguo; que el apartado 8 pese más que la multa; que la definición de «pruebas fiables» convierta el cumplimiento en un problema de telemetría; la discrepancia con el consejo de ENISA sobre cuándo registrarse; la cláusula de contrato propuesta; y los seis puntos de la lista. La fotografía de portada es «Echo Wall Clock», de bfishadow, publicada bajo licencia Creative Commons CC BY 2.0.