El artículo 69(2) del Cyber Resilience Act, Reglamento (UE) 2024/2847, dice que los productos con elementos digitales introducidos en el mercado antes del 11 de diciembre de 2027 «solo estarán sujetos a los requisitos del presente Reglamento si, a partir de esa fecha, son objeto de modificaciones sustanciales». La obligación de notificación del artículo 14 se les aplica de todos modos, desde el 11 de septiembre de 2026. Todo lo demás, los requisitos esenciales del anexo I, la evaluación de la conformidad, la documentación técnica, el marcado CE, espera a la primera modificación sustancial. Para una empresa de software con un producto ya en el mercado, «qué es una modificación sustancial» es, por tanto, la pregunta que decide si, y cuándo, el Reglamento alcanza ese producto. Y para un producto introducido en el mercado después de esa fecha, decide si una versión necesita una nueva evaluación de la conformidad.

El Reglamento define el término en el artículo 3(30) y lo explica en el considerando 39, y las orientaciones de la Comisión del 27 de julio de 2026, C(2026) 5252, sección 4.3, apartados 103 a 113, lo aplican a las actualizaciones de software, con once ejemplos resueltos. Las secciones 4.4.2 y 5 dicen qué se sigue. Este artículo son esos apartados, leídos para un equipo que publica cada semana.

La prueba es la evaluación de riesgos, no el tamaño del cambio

El apartado 104 reformula el considerando 39: un producto está sustancialmente modificado «cuando un cambio altera el nivel de riesgo de ciberseguridad, y cuando ese riesgo alterado o adicional no ha sido tenido en cuenta por el fabricante en su evaluación de riesgos y, en consecuencia, en su aplicación de los requisitos esenciales». El fabricante «debe, por tanto, evaluar caso por caso si una actualización de software introduce riesgos de ciberseguridad nuevos o mayores, y si esos riesgos ya estaban tratados en su evaluación de riesgos».

De ahí se siguen dos consecuencias, y las orientaciones extraen ambas. Primera, un cambio de la finalidad prevista del producto probablemente lo es: el apartado 105 dice que cuando nuevas funcionalidades «dan lugar a un cambio de la finalidad prevista del producto en su conjunto, es probable que el fabricante no haya tenido en cuenta esos cambios en su evaluación de riesgos», y el ejemplo 40 es un panel de supervisión que adquiere la capacidad de controlar las máquinas que observa. Segunda, el tamaño no es la prueba. Apartado 107: «la evaluación de la modificación sustancial no debe basarse, por tanto, en la escala o complejidad del cambio, sino en su posible efecto adverso sobre el perfil de riesgo de ciberseguridad». El ejemplo 44 es el que todo equipo de producto debería leer: una función de «recordarme» que almacena localmente tokens de autenticación «introduce nuevos riesgos de robo de tokens, acceso no autorizado y secuestro de sesión que no se tuvieron en cuenta en la evaluación de riesgos», y la aplicación «ha sido sustancialmente modificada». El ejemplo 45 es una función de diagnóstico que exporta registros detallados, menor en apariencia, que almacena datos operativos sensibles sin cifrar: sustancialmente modificada.

La otra cara es el apartado 106. Cuando el fabricante «ha previsto el desarrollo de esas funcionalidades, ya ha descrito y evaluado los riesgos asociados, y ha aplicado medidas de mitigación adecuadas», la actualización «no debe considerarse, por tanto» una modificación sustancial. El ejemplo 42 es una aplicación de mensajería cuya evaluación de riesgos original cubría la posterior introducción de la mensajería de grupo, «incluida, por ejemplo, la mayor complejidad del enrutamiento de mensajes»; cuando el chat de grupo se publica con los controles de administración y moderación previstos, nada se ha modificado sustancialmente. El ejemplo 43 es un sistema de supervisión que se entrega con bucles de control presentes pero desactivados y evaluados; activarlos no es una modificación sustancial.

Ese es todo el mecanismo. Una evaluación de riesgos que nombra la hoja de ruta absorbe la hoja de ruta. Una evaluación de riesgos escrita una vez, para el producto tal como era, convierte cada funcionalidad relevante en una modificación sustancial.

Actualizaciones de seguridad: en general no, con dos excepciones

Apartado 108, de nuevo del considerando 39: «las actualizaciones de seguridad no deben considerarse en general modificaciones sustanciales, ya que su finalidad principal es reducir el nivel de riesgo de ciberseguridad». Eso vale «aunque la actualización pueda introducir cambios técnicos significativos», y cubre las funcionalidades «modificadas o restringidas únicamente para mitigar vulnerabilidades identificadas». El ejemplo 46 es la corrección de un error de validación de entrada o de una comprobación de token de sesión. El ejemplo 47 es el endurecimiento: reforzar reglas de cortafuegos, desactivar puertos, cambiar políticas de contraseña por defecto, hacer obligatoria la autenticación multifactor donde ya existía. El ejemplo 48 es sustituir un algoritmo obsoleto por otro más fuerte que el diseño ya admitía.

El apartado 109 da las excepciones: una actualización de seguridad que cambia la finalidad prevista más allá de lo previsto, o que «cambia materialmente los límites o la estructura de dependencias del producto de una manera no prevista en la evaluación de riesgos, por ejemplo alterando materialmente los flujos de datos o añadiendo nuevas interfaces accesibles desde el exterior». El ejemplo 49 sustituye el cifrado local de archivos por un servicio de cifrado remoto operado por el fabricante: el producto ahora hace otra cosa, así que está sustancialmente modificado pese al motivo de seguridad. El ejemplo 50 sustituye un ciclo de vida de claves gestionado internamente por un servicio de gestión de claves de un tercero, añadiendo «nuevas interfaces externas y una dependencia de servicios de terceros no considerada en la evaluación de riesgos»: sustancialmente modificado.

Las cuatro preguntas que hacer a cada versión

El apartado 110 enumera lo que un fabricante «puede considerar», y es lo bastante corto para ponerlo en una plantilla de pull request. ¿La actualización:

a. introduce nuevos vectores de amenaza, como interfaces, canales de comunicación, entornos de ejecución o dependencias externas adicionales a través de los cuales podrían materializarse amenazas; b. permite nuevos escenarios de ataque, incluidas, por ejemplo, nuevas formas en que podría producirse de manera plausible el acceso no autorizado, la manipulación, la interferencia o el uso indebido del producto con elementos digitales o de los datos que trata; c. cambia la probabilidad de escenarios de ataque previamente identificados, por ejemplo reduciendo el esfuerzo o la pericia necesarios para explotarlos, aumentando la exposición a agentes no fiables o debilitando las salvaguardias existentes; d. cambia el impacto potencial de escenarios de ataque previamente identificados, incluidos, por ejemplo, el alcance de los datos o funciones afectados, la gravedad de las consecuencias operativas, de seguridad o económicas, o la capacidad de detectar, contener o recuperarse de un incidente?

Apartado 111: cuatro veces no, «siempre que las hipótesis y las medidas de mitigación en que se basa la evaluación de riesgos sigan siendo válidas y eficaces», significa que «es probable, por tanto, que la actualización no constituya» una modificación sustancial. Apartado 112: cualquier sí significa que «el fabricante debe reevaluar los riesgos de ciberseguridad» y «determinar si se siguen cumpliendo los requisitos esenciales». El apartado 113 añade la obligación que no depende de la respuesta: «con independencia de que las actualizaciones de software constituyan o no modificaciones sustanciales, los fabricantes están obligados a mantener la evaluación de riesgos y la documentación técnica exactas, completas y continuamente actualizadas, de conformidad con los artículos 13(7) y 31(2)».

Qué desencadena la primera modificación sustancial

La sección 4.4.2 trata del fabricante original, que es el caso habitual en software. Apartado 122: el fabricante «sigue siendo el fabricante», pero «el producto con elementos digitales sustancialmente modificado debe considerarse como nuevamente introducido en el mercado». El apartado 123 limita el trabajo: siguiendo la sección 2.1 de la Guía azul, el fabricante «puede reutilizar la documentación y los ensayos existentes para los aspectos del producto con elementos digitales no afectados por la modificación sustancial», la evaluación de la conformidad «debe centrarse en las partes sustancialmente modificadas», y un organismo notificado, cuando intervenga, «debe centrar su evaluación en las partes sustancialmente modificadas».

Para el software ya en el mercado antes del 11 de diciembre de 2027, el apartado 124 es la frase que conservar. Una modificación sustancial por el fabricante original «no exige, en sí misma, que el fabricante ponga todo el producto con elementos digitales introducido en el mercado antes de esa fecha en plena conformidad con el CRA, salvo que la modificación afecte negativamente a la ciberseguridad del producto con elementos digitales en su conjunto. Cuando la modificación no afecte a la ciberseguridad del producto con elementos digitales en su conjunto, las obligaciones del fabricante original respecto de la modificación deben limitarse a las partes sustancialmente modificadas». Así, la primera función de «recordarme» después de diciembre de 2027 coloca la ruta de inicio de sesión, no todo el producto heredado, bajo el anexo I; una reescritura que cambia los límites del producto lo coloca entero.

La sección 5 añade el periodo de soporte. Apartado 128: «cada versión sustancialmente modificada de un producto de software con elementos digitales introducida en el mercado debe tener un periodo de soporte declarado que cumpla el artículo 13(8)», de al menos cinco años salvo que el tiempo de uso previsto sea demostrablemente más corto, y cuando la modificación no cambie los factores que determinaron el tiempo de uso previsto original, «el periodo de soporte original no se ve afectado». El apartado 131, para productos publicados a intervalos cortos: el fabricante debe declarar un periodo de soporte para cada versión sustancialmente modificada, y puede acogerse al artículo 13(10) para dejar de corregir vulnerabilidades en versiones anteriores «una vez que los usuarios puedan actualizar a una versión posterior de forma gratuita y sin incurrir en costes adicionales», lo que el apartado 130 lee como excluyendo «compras obligatorias de nuevo hardware, sustitución de infraestructura o cambios fundamentales del entorno operativo», pero incluyendo el esfuerzo normal de actualización. El artículo sobre el periodo de soporte cubre el resto del artículo 13(8).

Qué significa esto para un equipo que publica cada semana

Tres prácticas se desprenden de los apartados, ninguna de ellas ingeniería nueva.

Escriba la hoja de ruta en la evaluación de riesgos. El apartado 106 y los ejemplos 42 y 43 premian una evaluación de riesgos que nombra las funcionalidades que piensa publicar y las evalúa antes de que existan. Es más barato que una nueva evaluación de la conformidad por funcionalidad, y es la diferencia entre el ejemplo 42 y el ejemplo 44. La evaluación de riesgos del artículo 13 es donde va.

Responda al apartado 110 en cada versión. Cuatro preguntas, cuatro respuestas, una frase cada una, en el registro de la versión. Cuando las cuatro son no, el registro dice por qué la evaluación existente sigue valiendo. Cuando alguna es sí, la versión espera a la reevaluación que exige el apartado 112, y la evaluación de riesgos y la documentación técnica se actualizan conforme al apartado 113, que se debe de todos modos.

Decida la cuestión de los productos heredados una sola vez. Para cada producto en el mercado antes del 11 de diciembre de 2027, registre la versión a esa fecha, para que la primera modificación sustancial posterior sea identificable, y registre con cada versión posterior si lo fue y, conforme al apartado 124, si afectó a la seguridad del producto en su conjunto o solo a una parte.

StandardOS mantiene la documentación técnica del CRA y la evaluación de riesgos como registros vivos y no como documentos, de modo que una versión puede vincularse a las cuatro respuestas y a la evaluación en que se apoya. Si el producto está siquiera en el ámbito va primero.

Fuentes

  • Reglamento (UE) 2024/2847, artículo 3(30), artículo 13(7), (8) y (10), artículo 31(2), artículos 21 y 22, artículo 69(2), considerandos 39 a 42 y 60.
  • Comisión Europea, orientaciones de la Comisión sobre la aplicación del Reglamento (UE) 2024/2847, C(2026) 5252 final de 27 de julio de 2026, anexo, sección 4.3 (apartados 103 a 113, ejemplos 40 a 50), sección 4.4 (apartados 114 a 124), sección 5 (apartados 125 a 131).
  • Comisión Europea, la Guía azul sobre la aplicación de la normativa de la UE relativa a los productos, sección 2.1, tal como la citan las orientaciones.

Esto no es asesoramiento jurídico. Los once ejemplos ocupan dos páginas y están más cerca de la realidad de un equipo de producto que cualquier otra cosa en las orientaciones; léalos con sus diez últimas versiones al lado.