Desde el 11 de septiembre de 2026, un fabricante de productos con elementos digitales que descubre una vulnerabilidad explotada activamente tiene veinticuatro horas para enviar un primer aviso a ENISA y al CSIRT nacional, y setenta y dos para la notificación completa. La obligación alcanza también a los productos ya vendidos. Lo difícil no es la rapidez del aviso: es que en veinticuatro horas tienes que saber si ese componente vulnerable está dentro de tu producto. Y esa es una pregunta de inventario, no de seguridad.
01¿Qué entra en vigor exactamente el 11 de septiembre de 2026?
El Cyber Resilience Act — Reglamento (UE) 2024/2847 — entró en vigor el 10 de diciembre de 2024 y se aplica con carácter general desde el 11 de diciembre de 2027. Pero el reglamento tiene un calendario escalonado, escrito en el artículo 71: «This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026». El artículo 14 es el de las obligaciones de notificación, y es la primera pieza del CRA que se vuelve exigible.
Los sucesos que hay que notificar son dos. Una vulnerabilidad explotada activamente es aquella «para la que existen pruebas fiables de que un actor malicioso la ha explotado en un sistema sin permiso del propietario del sistema» (art. 3, punto 42). Un incidente grave es el que perjudica — o puede perjudicar — la capacidad del producto de proteger la disponibilidad, autenticidad, integridad o confidencialidad de datos o funciones importantes, o que lleva a la ejecución de código malicioso en el producto o en los sistemas de un usuario (art. 14, apdo. 5).
Los plazos, en ambos casos, son estos:
- 24 horas — early warning: «sin demora indebida y en todo caso en el plazo de veinticuatro horas» desde que el fabricante tiene conocimiento. Basta con decir que el hecho existe y en qué Estados miembros está disponible el producto.
- 72 horas — la notificación propiamente dicha: naturaleza del problema, evaluación, y medidas correctoras o mitigadoras adoptadas o disponibles.
- 14 días — el informe final para las vulnerabilidades explotadas activamente, «a más tardar catorce días después de que esté disponible una medida correctora o mitigadora».
- 1 mes — el informe final para los incidentes graves, contado desde la presentación de la notificación de las 72 horas, no desde la disponibilidad del parche: una diferencia que importa al redactar el procedimiento.
El aviso va simultáneamente al CSIRT designado como coordinador y a ENISA, por un canal único: la Single Reporting Platform prevista en el artículo 16, que ENISA opera y mantiene y que entra en funcionamiento el 11 de septiembre de 2026 (ENISA, Single Reporting Platform). Se notifica una sola vez: es la plataforma la que distribuye la información a los CSIRT de los demás Estados miembros donde el producto está disponible.
02¿Se aplica también a los productos ya en el mercado?
Sí, y es la parte que más sorprende. La regla general de transición del CRA (art. 69, apdo. 2) dice que los productos introducidos en el mercado antes del 11 de diciembre de 2027 quedan sujetos al reglamento solo si, a partir de esa fecha, sufren una modificación sustancial. Parece una salida cómoda. El apartado siguiente la cierra: «No obstante lo dispuesto en el apartado 2 del presente artículo, las obligaciones establecidas en el artículo 14 se aplicarán a todos los productos con elementos digitales incluidos en el ámbito de aplicación del presente reglamento que se hayan introducido en el mercado antes del 11 de diciembre de 2027» (art. 69, apdo. 3).
En términos operativos: la maquinaria de conformidad — requisitos esenciales, documentación técnica, marcado CE — afecta a los productos nuevos y arranca en diciembre de 2027. La obligación de notificar arranca antes y afecta a todo el parque instalado. Incluida esa versión publicada hace cuatro años que ya nadie toca pero que un cliente sigue teniendo en producción.
03¿Quién es «fabricante» y qué se arriesga?
El reglamento define fabricante como «la persona física o jurídica que desarrolla o fabrica productos con elementos digitales, o que los hace diseñar, desarrollar o fabricar, y los comercializa con su nombre o marca» (art. 3, punto 13). La consecuencia es tajante: no importa quién escribió el código, importa quién pone el nombre en la caja. Si distribuyes con tu marca un producto que otro ha desarrollado para ti, la obligación de notificar es tuya.
El perímetro de producto es amplio — «producto de software o hardware y sus soluciones de tratamiento de datos a distancia, incluidos los componentes introducidos en el mercado por separado» (art. 3, punto 1) — pero no es ilimitado. El considerando 12 aclara que los servicios en la nube diseñados y desarrollados fuera de la responsabilidad de un fabricante de productos con elementos digitales no entran en el CRA: el SaaS puro está más bien en el perímetro de NIS2. Pero la funcionalidad en la nube sin la cual el producto no funciona es parte del producto.
Sobre la exposición económica el texto es explícito: el incumplimiento de los requisitos esenciales del anexo I y de las obligaciones de los artículos 13 y 14 se sanciona con multas de hasta 15 millones de euros o el 2,5% del volumen de negocios anual mundial, si es superior (art. 64, apdo. 2). Hay, eso sí, una válvula: el apartado 10 del mismo artículo exime de las multas administrativas a microempresas y pequeñas empresas, únicamente en cuanto al incumplimiento del plazo de las veinticuatro horas. Conviene leerla por lo que es: la obligación se mantiene, la notificación de 72 horas y el informe final siguen siendo sancionables. No es un aplazamiento, es un margen de respiro en el primer aviso.
04Por qué veinticuatro horas son un problema de inventario
La escena es siempre la misma. Sale una CVE sobre una biblioteca muy extendida, con evidencia de explotación en curso. La pregunta no es «cómo lo arreglamos» — eso viene después — sino «¿está dentro de alguno de nuestros productos? ¿en qué versión? ¿en qué clientes? ¿en qué países de la UE?». Si la respuesta depende de tres personas abriendo repositorios y leyendo de memoria los ficheros de dependencias, no llega en veinticuatro horas. Y si no llega, no es que notifiques mal: no tienes los datos para notificar.
La dimensión del problema no es una impresión. El informe OSSRA 2026 de Black Duck, construido sobre 947 bases de código comerciales de 17 sectores, mide una media de 581 vulnerabilidades de código abierto por base de código, más del doble que el año anterior (+107%), con el 87% de las bases de código conteniendo al menos una y el número medio de componentes de código abierto creciendo un 30% en doce meses (Black Duck, OSSRA 2026). El software comercial de hoy está, en su mayor parte, ensamblado: la parte escrita en casa es la minoría.
Y la preparación no sigue el ritmo: en la encuesta de ENISA a las PYME europeas (194 organizaciones, 31 países, febrero-marzo de 2026) el área con las puntuaciones más bajas es precisamente la gestión de incidentes y del ciclo de vida del producto (ENISA, 13 de julio de 2026) — exactamente la capacidad que el 11 de septiembre de 2026 se vuelve obligatoria.
05Qué dice de verdad el CRA sobre el SBOM (y qué no dice)
Aquí hace falta precisión, porque alrededor de esta fecha circula bastante confusión comercial. El SBOM — software bill of materials, la lista de materiales del software: el inventario legible por máquina de los componentes que forman un producto — no es una obligación que entre en vigor el 11 de septiembre de 2026. Está en el anexo I, parte II, punto 1, entre los requisitos de gestión de vulnerabilidades, y pide a los fabricantes «identificar y documentar las vulnerabilidades y los componentes contenidos en los productos con elementos digitales, incluso elaborando una lista de materiales de software en un formato de uso común y legible por máquina que cubra al menos las dependencias de primer nivel de los productos».
Tres cosas hay que decirlas con honestidad, porque el texto dice exactamente estas y no más:
- La fecha es el 11 de diciembre de 2027, no septiembre de 2026: el anexo I forma parte de los requisitos esenciales, que se aplican con la aplicación general del reglamento y, según el artículo 69, a los productos introducidos en el mercado desde esa fecha o modificados sustancialmente después.
- El mínimo legal son las dependencias de primer nivel. El texto dice «al menos»: no impone el árbol transitivo completo. Quien promete que el CRA obliga a un SBOM recursivo está vendiendo, no citando.
- El SBOM no se publica. El reglamento no impone su divulgación: se conserva en la documentación técnica y se pone a disposición de las autoridades de vigilancia del mercado a petición (considerando 77).
Por tanto: en septiembre de 2026 nadie te sanciona por no tener un SBOM. Te sanciona, en todo caso, por no haber notificado a tiempo. Y ahí se cierra el círculo: el SBOM no es lo que la ley te pide en septiembre, es lo que hace sobrevivible lo que la ley te pide en septiembre. Construirlo ahora resuelve dos fechas con un solo trabajo — la ventana de las veinticuatro horas hoy, el anexo I en diciembre de 2027.
06¿Y el código escrito por la IA?
Es el punto que cambia la naturaleza del problema, y que casi nadie conecta con el CRA. El propio informe OSSRA registra que alrededor del 85% de las organizaciones usa asistentes de codificación basados en IA — y que el 76% de las que los prohíben admite que sus desarrolladores los usan igualmente — con el número medio de ficheros por base de código creciendo un 74% en un año.
El riesgo más comentado es la dependencia alucinada: un estudio presentado en USENIX Security 2025 generó 576.000 muestras de código con 16 modelos y encontró paquetes inexistentes en el 5,2% de los casos en modelos comerciales y en el 21,7% en los de código abierto, con un total de 205.474 nombres de paquete únicos que nunca existieron (Spracklen et al., USENIX Security 2025). Un nombre inventado que alguien registra de verdad se convierte en una vía de entrada limpia: es el fenómeno que llaman slopsquatting.
Pero la dependencia alucinada es el caso patológico, y también el más fácil de interceptar: un paquete que no existe rompe la build. El caso normal es más silencioso y, para el CRA, más importante: la IA importa paquetes que existen y funcionan, y que nadie ha elegido conscientemente. Nadie los ha evaluado por mantenimiento, licencia, procedencia o historial de vulnerabilidades. Nadie ha decidido asumir la responsabilidad sobre ellos: simplemente aparecieron en el fichero de dependencias junto a una función que hacía falta.
Si el criterio de aceptación de ese código es «funciona», el criterio funciona de maravilla — hasta que tienes que declarar a una autoridad qué hay dentro de tu producto, en veinticuatro horas, con tu nombre en la caja.
No es un argumento contra la IA en desarrollo: la productividad es real. Es un argumento sobre la puerta. Si la generación se acelera diez veces y la puerta sigue siendo «pasan los tests», el inventario se deshace diez veces más rápido. La puerta correcta es trivial de describir y exige disciplina para sostenerla: cada build produce su lista de materiales, cada dependencia nueva aparece en un diff que una persona mira, cada componente tiene un responsable. Quien genera código con IA necesita un SBOM más, no menos.
07Qué llevar al contrato y qué hacer ahora
Hay una asimetría estructural en el CRA con la que las PYME se topan enseguida: la obligación recae sobre quien introduce el producto en el mercado con su nombre, pero el conocimiento de los componentes suele estar en el proveedor de software. El reglamento exige al fabricante actuar con la diligencia debida al integrar componentes de terceros, «de modo que dichos componentes no comprometan la ciberseguridad del producto» (art. 13, apdo. 5) — pero la diligencia debida, en la práctica, se ejerce con el contrato. Son tres cláusulas, y hay que escribirlas antes de necesitarlas:
- Plazos de aviso del proveedor más estrictos que los tuyos. Si tienes veinticuatro horas desde que tienes conocimiento, el proveedor debe avisarte en una fracción de ese tiempo, por un canal y a un destinatario nominados — no una dirección genérica de soporte.
- Entrega del SBOM en cada release, en formato de uso común y legible por máquina, actualizado cuando cambie una dependencia. Es la única forma de que el inventario siga vivo en lugar de ser una foto caducada.
- Cooperación durante la ventana de notificación, con disponibilidad definida y responsabilidades explícitas si el retraso nace aguas arriba. Añade la duración del período de soporte y de las actualizaciones de seguridad: es una variable contractual, no un dato dado.
En lo interno el orden que funciona es este. Primero, el perímetro: qué productos introduces con tu nombre y en qué países de la UE están disponibles — la lista de países es información que el early warning pide expresamente, y suele ser la que falta. Segundo, el inventario de componentes generado automáticamente dentro del pipeline de build: un SBOM hecho a mano ya está caducado al día siguiente. Tercero, un procedimiento de notificación con nombres y números de teléfono, que responda a una sola pregunta — quién decide, a las tres de la madrugada de un sábado, que ese hecho debe notificarse — ensayado al menos una vez en frío. Cuarto, los contratos. En ese orden: el cuarto sin el primero no sirve de nada.
La monitorización técnica continua — correlacionar cada día las nuevas CVE con el inventario — es otra capacidad, y en nuestra casa vive en la familia Fenrir. Pero llega después: sin inventario no hay nada que correlacionar. El trabajo que P3 hace sobre esta fecha es el de aguas arriba, y es el trabajo aburrido: perímetro, lista de materiales, procedimiento, cláusulas. Es el mismo método con el que abordamos NIS2 y DORA — primero la foto, luego las decisiones — y la misma lógica de control que llamamos soberanía operativa: saber qué hay dentro de tus sistemas es el requisito previo de cualquier otra elección, incluidos el software soberano y la evaluación de un proveedor cloud. Si el punto de partida es la foto de red, datos y proveedores, eso es una auditoría on-prem de siete días.