El Artículo 13(8) de la Ley de Ciberresiliencia de la UE (Reglamento (UE) 2024/2847) exige a los fabricantes entregar las actualizaciones de seguridad de forma gratuita y sin demora injustificada durante todo el periodo de soporte. Esta página cubre la mecánica de entrega de actualizaciones en arquitecturas embebidas, de software independiente, SaaS e híbridas. Para la mecánica de duración, consulta las bases del periodo de soporte; para la divulgación previa a la compra, consulta la divulgación del fin de soporte.
Resumen
- Las actualizaciones de seguridad no son actualizaciones de funcionalidades. Un cambio que corrige una vulnerabilidad está sujeto a las reglas de coste y cadencia del Artículo 13(8); un cambio que añade nueva funcionalidad no lo está.
- Gratuitas conforme al Artículo 13(8). Los fabricantes no pueden incluir las correcciones de seguridad dentro de suscripciones de pago, niveles premium o actualizaciones de versión principal.
- Automáticas donde sea viable conforme al Anexo I Parte II. La letra 7) exige mecanismos de distribución seguros con entrega automática donde proceda; la letra 8) exige la difusión sin demora.
- "Sin demora injustificada" depende de la gravedad. Las expectativas del sector son: días para problemas críticos activamente explotados, 30 días para gravedad alta, 90 días para gravedad media y el siguiente ciclo regular para gravedad baja.
- La arquitectura determina el modelo de entrega. El firmware embebido, el software independiente, el SaaS y los productos híbridos tienen cada uno una mecánica de actualización distinta que el expediente técnico debe documentar.
- La notificación del Artículo 14 interactúa con el ciclo de vida de actualización. Cuando se detecta una vulnerabilidad activamente explotada, el aviso temprano de 24 horas a ENISA corre en paralelo con el proceso de parcheo; el mecanismo de actualización debe estar integrado en el flujo de notificación.
Los cuatro pilares del cumplimiento de las actualizaciones de seguridad del CRA: regla de coste, preferencia de distribución, expectativa de cadencia y techo de sanciones.
Cobrar por las actualizaciones de seguridad es una de las vías más directas hacia una constatación de incumplimiento. Si una corrección que soluciona una vulnerabilidad solo está disponible para clientes con un nivel de soporte de pago, tras una suscripción premium o dentro de una actualización de versión principal con precio de nueva versión, ese esquema no satisface el Artículo 13(8). Los parches de seguridad básicos deben estar disponibles para todos los usuarios del producto tal como se comercializó, sin coste adicional, durante toda la duración del periodo de soporte. Las publicaciones de funcionalidades, los servicios profesionales y las capacidades opcionales pueden seguir siendo de pago. La línea divisoria es si el cambio corrige una vulnerabilidad.
Qué cuenta como actualización de seguridad
El Artículo 13(2) del CRA exige a los fabricantes diseñar y producir productos que sean "seguros por defecto" y que garanticen "la confidencialidad, integridad y disponibilidad de los datos." El Artículo 13(8) exige a continuación que las vulnerabilidades descubiertas tras la comercialización se gestionen durante toda la duración del periodo de soporte.
Una actualización de seguridad conforme al CRA es un cambio que corrige una vulnerabilidad, es decir, una debilidad del producto que podría explotarse para comprometer la confidencialidad, la integridad o la disponibilidad. La distinción respecto a una actualización de funcionalidades importa por dos razones: las actualizaciones de seguridad deben ser gratuitas y entregarse sin demora injustificada, mientras que las de funcionalidades no conllevan ninguna de las dos obligaciones.
| Tipo de actualización | Obligación del Artículo 13(8) | ¿Puede cobrarse? |
|---|---|---|
| Parche que corrige un CVE conocido | Sí (actualización de seguridad) | No |
| Cambio de endurecimiento que reduce la superficie de ataque | Sí (actualización de seguridad) | No |
| Nueva funcionalidad sin relevancia para la seguridad | No | Sí |
| Versión principal con nuevas capacidades | No (salvo que incluya correcciones de seguridad) | Sí |
| Actualización de dependencia para eliminar una vulnerabilidad conocida | Sí (actualización de seguridad) | No |
| Cambio de configuración para cerrar una brecha de seguridad | Sí (actualización de seguridad) | No |
"Sin demora injustificada" no se define numéricamente en el reglamento, pero las expectativas generales de las autoridades de vigilancia del mercado y la orientación de ENISA se alinean con la práctica del sector. El diagrama siguiente muestra la ventana de parcheo por nivel de gravedad, medida desde el momento en que se divulga la vulnerabilidad (T0):
| Gravedad | Expectativa estándar del sector |
|---|---|
| Crítica (activamente explotada) | Días, no semanas |
| Alta (fácilmente explotable de forma remota) | En 30 días |
| Media | En 90 días |
| Baja | Incluida en el siguiente ciclo regular de actualización |
Estos no son plazos obligados por el CRA, pero representan el estándar con el que se evaluará "sin demora injustificada" en los procedimientos de ejecución.
Cómo entregar actualizaciones de seguridad del CRA
Actualizaciones automáticas
Donde sea técnicamente viable y adecuado, el Artículo 13(8) y el Anexo I Parte II favorecen las actualizaciones de seguridad automáticas. El producto debe ser capaz de recibir y aplicar actualizaciones sin necesidad de que el usuario realice ninguna acción manual.
Requisitos para un mecanismo de actualización automática conforme:
- Canal de descarga seguro (TLS, paquetes firmados)
- Verificación de integridad antes de la instalación
- Capacidad de reversión si una actualización falla
- Gestión ordenada de problemas de conectividad
- Visibilidad del usuario sobre el estado de la actualización
El usuario debe conservar la capacidad de desactivar las actualizaciones automáticas, con una advertencia clara sobre las consecuencias de seguridad de hacerlo. Para las actualizaciones de seguridad críticas, el fabricante puede diseñar el sistema para aplicar la actualización sin posibilidad de aplazamiento. El Artículo 13(8) respalda esto cuando el riesgo lo justifica.
Actualizaciones manuales
Los productos que no pueden recibir actualizaciones automáticas (sistemas industriales sin conexión a redes externas, dispositivos embebidos sin conectividad, ciertos equipos médicos o de seguridad crítica) requieren un proceso de entrega de actualizaciones manual:
- Paquetes de actualización descargables con versiones claramente indicadas
- Firmas criptográficas y claves públicas publicadas para su verificación
- Documentación de instalación
- Notificación a través de todos los canales disponibles (correo electrónico, portal web, interfaz del producto, aviso físico si fuera necesario)
Embebido y SaaS: modelos de actualización distintos
El mecanismo de entrega de actualizaciones difiere sustancialmente según la arquitectura del producto:
| Tipo de producto | Modelo de actualización | Consideración clave del CRA |
|---|---|---|
| Firmware embebido (IoT, industrial) | El fabricante envía el firmware firmado; el cliente lo aplica | Debe contar con capacidad OTA o un proceso manual documentado; los largos ciclos de vida de los dispositivos pueden acercar el periodo previsto en uso a los cinco años |
| Software independiente (escritorio, servidor) | El fabricante publica el paquete; el cliente lo instala | Se prefiere un agente de actualización automática; la fijación de versión por parte de clientes empresariales genera una carga de soporte multiversión |
| SaaS / alojado en la nube | El fabricante controla el entorno; las actualizaciones son transparentes para el usuario | El reloj sigue comenzando en la comercialización; el periodo de soporte es relevante principalmente para los componentes locales o híbridos; el versionado de la API crea sus propios compromisos de soporte |
| Híbrido (agente local + backend en la nube) | Las actualizaciones del agente son controladas por el fabricante; las del backend son transparentes | Cada componente tiene su propio reloj del periodo de soporte; el agente es el producto con elementos digitales y ese reloj es el que rige |
Para la gestión de vulnerabilidades del Anexo I Parte II más allá de la entrega de actualizaciones (política de divulgación coordinada de vulnerabilidades, divulgación pública, notificación por terceros), consulta la guía de gestión de vulnerabilidades.
Obligaciones de notificación de vulnerabilidades durante y después del periodo de soporte
El Artículo 14 impone obligaciones de notificación con plazos definidos a los fabricantes para las vulnerabilidades activamente explotadas y los incidentes graves. Estas obligaciones se aplican durante el periodo de soporte.
La interacción clave:
| Fase | Obligación de notificación del Artículo 14 |
|---|---|
| Durante el periodo de soporte | El Artículo 14 se aplica íntegramente: aviso temprano de 24 h, notificación de 72 h e informe final de 14 días para vulnerabilidades activamente explotadas; 24 h / 72 h / 1 mes para incidentes graves. A través de la plataforma única de notificación de ENISA. |
| Tras el fin del periodo de soporte | No existe obligación de notificación del Artículo 14 para vulnerabilidades descubiertas después del fin de vida. Si el fabricante tiene conocimiento de una vulnerabilidad crítica y activamente explotada en un producto sin soporte que afecta a una base instalada amplia, no existe obligación de notificación. La divulgación responsable y la notificación a los usuarios son firmemente recomendables por razones de reputación y cooperación con las autoridades de vigilancia del mercado. |
La fecha de fin del periodo de soporte es también el horizonte del Artículo 14. Una vez que el periodo de soporte expira, el fabricante no tiene obligación de investigar, parchear ni notificar vulnerabilidades descubiertas en esa versión del producto. Las autoridades de vigilancia del mercado pueden seguir investigando en virtud del Artículo 58 si el producto presenta un riesgo significativo para la ciberseguridad, pero la obligación continua de gestión de vulnerabilidades del Artículo 13(8) ha concluido.
Para la mecánica completa de plazos del Artículo 14, incluido el contenido de cada informe y las diferencias entre los dos flujos de notificación (vulnerabilidades activamente explotadas e incidentes graves), consulta la guía de notificación de vulnerabilidades.
Errores habituales
Ignorar las dependencias transitivas. La mayoría de vulnerabilidades en productos conectados se originan en bibliotecas y componentes de terceros, no en el código propio del fabricante. La obligación del Artículo 13(8) cubre el producto completo, no solo el código que el fabricante escribió. Un SBOM es el prerrequisito. Consulta la guía del clúster SBOM para el marco de seguimiento de dependencias que hace operativa la monitorización de vulnerabilidades transitivas.
Cobrar por las actualizaciones de seguridad. Incluir las correcciones de seguridad en un nivel de soporte de pago viola el Artículo 13(8). Los parches de seguridad básicos deben ser gratuitos.
Preguntas frecuentes
¿Deben ser siempre gratuitas las actualizaciones de seguridad?
Sí. El Artículo 13(8) exige que las actualizaciones de seguridad se proporcionen de forma gratuita. Un fabricante no puede incluir una corrección de seguridad dentro de una suscripción de pago, un nivel de soporte premium o una actualización de versión principal y alegar el cumplimiento del Artículo 13(8). Las actualizaciones de funcionalidades, las nuevas funcionalidades y los servicios profesionales de pago son independientes y pueden cobrarse con normalidad. La obligación se limita a las actualizaciones que corrigen vulnerabilidades: cambios que subsanan una debilidad de seguridad del producto tal como fue comercializado.
¿Con qué rapidez debe publicar un fabricante una actualización de seguridad conforme al CRA?
El Artículo 13(8) del CRA exige las actualizaciones de seguridad "sin demora injustificada", pero no define numéricamente un plazo. Las autoridades de vigilancia del mercado y la orientación de ENISA se alinean con la práctica del sector vinculada a la gravedad: las vulnerabilidades críticas activamente explotadas deben parchearse en días, las de gravedad alta en aproximadamente 30 días, las medias en 90 días y las bajas, incluidas en el siguiente ciclo regular de actualización. Estos no son plazos obligados por el CRA, pero representan el estándar con el que se evaluará "sin demora injustificada" en la ejecución. Los fabricantes deben registrar el tiempo real de parcheo por CVE para que las desviaciones de esta referencia sean visibles y puedan justificarse.
¿Exige el CRA las actualizaciones automáticas?
No en todos los casos. La letra 7) del Anexo I Parte II exige a los fabricantes proporcionar mecanismos de distribución seguros con entrega automática "donde proceda". Para productos con conectividad fiable y sin razón operativa para aplazar, las actualizaciones automáticas son el valor predeterminado esperado. Para sistemas industriales sin conexión a redes externas, ciertos dispositivos médicos o equipos de seguridad crítica donde la instalación automática de parches podría interrumpir las operaciones, un proceso de actualización manual documentado es aceptable. El expediente técnico del Anexo VII debe justificar el enfoque elegido. Los usuarios deben conservar la capacidad de desactivar las actualizaciones automáticas con advertencias claras sobre las consecuencias de seguridad, salvo cuando el riesgo justifique una corrección crítica no aplazable.
¿Tiene un producto SaaS un periodo de soporte del CRA?
Depende de si el producto SaaS entra en el ámbito del CRA como producto con elementos digitales. Los servicios SaaS puros que no van acompañados de un componente de hardware ni de un agente de software descargable quedan generalmente fuera del ámbito de aplicación en virtud del Artículo 2(1). Cuando un producto SaaS incluye un agente local, un cliente descargable o una pasarela de hardware que se comercializa en el mercado de la UE, ese componente está dentro del ámbito de aplicación y su reloj del periodo de soporte del Artículo 13(8) comienza en la comercialización. El backend alojado en la nube, cuando está bajo el control del fabricante y se actualiza de forma continua, satisface típicamente la obligación de parcheo "sin demora injustificada" a través de despliegues transparentes, pero el fabricante debe igualmente documentar el compromiso de soporte en la información del Anexo II para el componente dentro del ámbito de aplicación.
¿Qué ocurre con las actualizaciones de seguridad tras el fin del periodo de soporte del CRA?
Las obligaciones del Artículo 13(8) terminan con el periodo de soporte. Una vez que la fecha de fin divulgada pasa, el fabricante no tiene obligación del CRA de investigar, parchear ni distribuir actualizaciones de seguridad para esa versión del producto, y las obligaciones de notificación del Artículo 14 también expiran, pues se aplican únicamente durante el periodo de soporte. Las autoridades de vigilancia del mercado pueden seguir investigando en virtud del Artículo 58 si el producto presenta un riesgo significativo para la ciberseguridad tras el fin de vida, pero la obligación cotidiana de gestión de vulnerabilidades ha concluido. Los fabricantes deben comunicar con antelación el fin del soporte a los usuarios; la divulgación de la fecha de fin de la letra k) del Anexo II es el instrumento orientado al usuario para ello. Continuar proporcionando parches de buena voluntad tras el fin de vida está permitido pero no es obligatorio.