El Reglamento de Ciberresiliencia de la UE (Reglamento (UE) 2024/2847) exige a los fabricantes gestionar las vulnerabilidades durante el periodo de soporte y, cuando haya actualizaciones de seguridad disponibles, difundirlas sin demora y de forma gratuita. Esta página cubre la mecánica de entrega de actualizaciones en arquitecturas embebidas, 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 funcionales. Un cambio que corrige una vulnerabilidad sigue las obligaciones de actualización de seguridad; una nueva funcionalidad no.
- Las correcciones de seguridad no deben quedar detrás de planes de pago. Las actualizaciones de seguridad disponibles deben difundirse sin demora y gratis, salvo acuerdo distinto para productos a medida destinados a usuarios empresariales.
- Automáticas donde proceda. Las actualizaciones automáticas de seguridad son el diseño predeterminado cuando tienen sentido, con mecanismos seguros de distribución, controles claros para el usuario y mensajes informativos que indiquen al usuario qué corrige la actualización y qué acción debe tomar.
- Los objetivos de parcheo deben seguir la gravedad. Los objetivos operativos habituales son días para problemas críticos explotados activamente, 30 días para gravedad alta, 90 días para media y el siguiente ciclo regular para baja.
- La arquitectura cambia el modelo de entrega. Firmware embebido, software independiente, SaaS y productos híbridos tienen mecánicas de actualización distintas que deben documentarse en el expediente técnico.
- La notificación interactúa con el ciclo de actualización. Cuando se detecta una vulnerabilidad explotada activamente, el aviso temprano de 24 horas al CSIRT coordinador y a ENISA corre en paralelo al proceso de parcheo; el mecanismo de actualización debe alimentar el flujo de notificación.
Los cuatro anclajes del cumplimiento de actualizaciones de seguridad CRA: regla de coste, preferencia de distribución, disponibilidad de actualizaciones y modelo sancionador.
Para los tramos sancionadores, consulta la guía de sanciones y enforcement.
Qué cuenta como actualización de seguridad
El deber de actualización parte de la evaluación de riesgos de ciberseguridad del producto y de las propiedades de seguridad aplicables. La configuración segura por defecto, la confidencialidad, la integridad y la disponibilidad determinan si un cambio es relevante para seguridad. Después, el fabricante debe gestionar eficazmente las vulnerabilidades durante el periodo de soporte.
Una actualización de seguridad 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. Distinguirla de una actualización funcional importa por dos razones: las actualizaciones de seguridad disponibles deben ser gratuitas y difundirse sin demora; las actualizaciones funcionales no tienen esas obligaciones.
| Tipo de actualización | Obligación de actualización de seguridad | ¿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 de 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 no está definido con un plazo numérico en el Reglamento. Aun así, los fabricantes deben fijar objetivos operativos por gravedad para que las decisiones de parcheo sean coherentes, documentadas y explicables. El diagrama muestra una ventana práctica de parcheo por nivel de gravedad, medida desde que el fabricante conoce la vulnerabilidad:
| Gravedad | Objetivo operativo práctico |
|---|---|
| Crítica (explotada activamente) | Días, no semanas |
| Alta (explotable remotamente con facilidad) | En 30 días |
| Media | En 90 días |
| Baja | Incluida en el siguiente ciclo regular |
No son plazos obligatorios del CRA. Son objetivos internos que ayudan al fabricante a demostrar que la demora fue controlada, basada en el riesgo y documentada.
Cómo entregar actualizaciones de seguridad del CRA
Actualizaciones automáticas
Cuando sea técnicamente viable y adecuado, las actualizaciones automáticas de seguridad son el diseño preferido. Un modelo automático conforme debe activar las actualizaciones de seguridad por defecto, ofrecer un mecanismo claro de desactivación, notificar las actualizaciones disponibles, permitir aplazamientos temporales cuando proceda y distribuir las actualizaciones de forma segura.
Un mecanismo automático robusto debería proporcionar:
- Canal de descarga seguro (TLS, paquetes firmados)
- Verificación de integridad antes de la instalación
- Capacidad de reversión si falla la actualización
- Gestión tolerante de problemas de conectividad
- Visibilidad del estado de actualización para el usuario
El usuario debe conservar la posibilidad de desactivar las actualizaciones automáticas, con una advertencia clara sobre las consecuencias de seguridad. Para actualizaciones críticas, el fabricante debe documentar cualquier diseño no aplazable en la evaluación de riesgos y en el expediente técnico.
Actualizaciones manuales
Los productos que no pueden recibir actualizaciones automáticas (sistemas industriales aislados, dispositivos embebidos sin conectividad, ciertos equipos médicos o de seguridad crítica) necesitan un proceso manual de entrega:
- Paquetes descargables con versionado claro
- Firmas criptográficas y claves públicas publicadas para verificación
- Documentación de instalación
- Notificación por todos los canales disponibles (e-mail, portal web, interfaz del producto, aviso físico si es necesario)
Embebido y SaaS: modelos de actualización distintos
El mecanismo de entrega cambia de forma sustancial según la arquitectura del producto:
| Tipo de producto | Modelo de actualización | Consideración CRA clave |
|---|---|---|
| Firmware embebido (IoT, industrial) | El fabricante entrega firmware firmado; el cliente lo aplica | Debe tener OTA o un proceso manual documentado; las vidas útiles largas pueden exigir soporte más allá de cinco años |
| Software independiente (escritorio, servidor) | El fabricante publica un paquete; el cliente lo instala | Se prefiere un agente de actualización automático; el versionado fijo en empresas crea carga de soporte multiversión |
| SaaS / alojado en la nube | El fabricante controla el entorno; las actualizaciones son transparentes para el usuario | Primero hay que confirmar si el servicio está en el ámbito como producto con elementos digitales o solución de tratamiento de datos a distancia |
| Híbrido (agente local + backend cloud) | El fabricante controla las actualizaciones del agente; el backend se actualiza de forma transparente | Cada componente tiene su propio reloj de soporte; el agente es el producto con elementos digitales que marca ese reloj |
Para la gestión de vulnerabilidades más allá de la entrega de actualizaciones (política CVD, divulgación pública, notificación a terceros), consulta la guía de gestión de vulnerabilidades.
Obligaciones de notificación durante la entrega de actualizaciones
La notificación CRA impone obligaciones con plazo para vulnerabilidades explotadas activamente e incidentes graves que afecten a la seguridad del producto. El proceso de actualización debe recoger los datos necesarios para esas notificaciones, porque el informe final debe incluir detalles de la actualización de seguridad u otras medidas correctoras disponibles.
La interacción operativa es esta:
| Activador | Deber del flujo de actualización |
|---|---|
| Vulnerabilidad explotada activamente | Capturar hora de conocimiento, productos afectados, hechos de explotación, estado de mitigación y detalles de la actualización para la secuencia de 24 h, 72 h e informe final. |
| Incidente grave | Capturar impacto, posible causa ilícita o maliciosa, evaluación inicial, medidas de mitigación y acciones correctoras para usuarios. |
| Notificación a usuarios | Preparar instrucciones claras de mitigación y corrección para usuarios afectados y, cuando proceda, para todos los usuarios. |
No trates la notificación como una tarea posterior separada. Lo que se detecte en soporte, PSIRT, telemetría, atención al cliente o despliegue debe llegar rápido al responsable de notificación cuando pueda alcanzarse un umbral notificable.
Para la mecánica completa de plazos, incluido el contenido de cada notificación y la diferencia entre los dos flujos, consulta la guía de notificación de vulnerabilidades.
Disponibilidad de actualizaciones de seguridad tras la publicación
Poner un parche a disposición una vez no basta. Cada actualización de seguridad puesta a disposición de los usuarios durante el periodo de soporte debe seguir disponible durante al menos 10 años desde su publicación, o durante el resto del periodo de soporte, lo que sea más largo. Esto cambia la operación de releases: paquetes antiguos, avisos, firmas, hashes e instrucciones de instalación necesitan alojamiento duradero y trazabilidad de versiones.
La información pública para usuarios también debe indicar qué tipo de soporte técnico de seguridad ofrece el fabricante y la fecha de fin del periodo de soporte durante el cual pueden esperar que se gestionen vulnerabilidades y reciban actualizaciones. Para el modelo de divulgación precompra, consulta divulgación de fin de soporte.
Errores habituales
Ignorar dependencias transitivas. La mayoría de vulnerabilidades en productos conectados procede de bibliotecas y componentes de terceros, no del código propio. La obligación de gestión de vulnerabilidades cubre todo el producto, incluidos sus componentes. El SBOM es el requisito previo. Consulta la guía del clúster SBOM para el marco de seguimiento de dependencias.
Cobrar por actualizaciones de seguridad. Incluir correcciones de seguridad en un nivel de asistencia de pago entra en conflicto con el modelo básico de actualizaciones CRA salvo que aplique la excepción de producto empresarial a medida. Los parches básicos de seguridad deben ser gratuitos.
Preguntas frecuentes
¿Deben ser siempre gratuitas las actualizaciones de seguridad?
Sí, las actualizaciones de seguridad disponibles deben ser gratuitas salvo que aplique la excepción estrecha para productos empresariales a medida. Un fabricante no puede incluir una corrección de vulnerabilidad en una suscripción de pago, un nivel premium o una actualización mayor de pago y tratarlo como cumplimiento normal del CRA. Las actualizaciones funcionales, nuevas funcionalidades y servicios profesionales pueden cobrarse por separado. La línea está en si el cambio corrige un problema de seguridad identificado en el producto.
¿Con qué rapidez debe publicar un fabricante una actualización de seguridad conforme al CRA?
El CRA no fija un plazo de parcheo, así que los fabricantes necesitan objetivos documentados por gravedad. Las vulnerabilidades críticas explotadas activamente deben tratarse en días, las de gravedad alta en unos 30 días, las medias en unos 90 días y las bajas en el siguiente ciclo regular, salvo que la evaluación de riesgos justifique otro objetivo. Registra el tiempo real hasta el parche por vulnerabilidad para que la demora sea visible, basada en el riesgo y explicable.
¿Exige el CRA actualizaciones automáticas?
No en todos los casos. Las actualizaciones automáticas de seguridad son obligatorias donde proceda, y el producto también debe notificar las actualizaciones disponibles y permitir un aplazamiento temporal. En productos de consumo con conectividad fiable, suelen ser el diseño esperado. En sistemas industriales aislados, determinados productos sanitarios o equipos de seguridad crítica, puede justificarse un proceso manual documentado. El expediente técnico debe explicar el enfoque elegido y las instrucciones para usuarios deben explicar cómo desactivar la instalación automática.
¿Tiene un producto SaaS un periodo de soporte del CRA?
Depende de si el servicio está en el ámbito como producto con elementos digitales o solución de tratamiento de datos a distancia. Un SaaS puro e independiente que no esté ligado a hardware, software descargable o tratamiento remoto bajo responsabilidad del fabricante queda generalmente fuera de este modelo de actualizaciones. Si la oferta incluye un agente local, cliente descargable, pasarela de hardware o tratamiento remoto cubierto, mapea el periodo de soporte y el mecanismo de actualización del componente en el ámbito. La información para usuarios sigue necesitando el tipo de soporte y la fecha de fin.
¿Qué ocurre con las actualizaciones de seguridad tras el fin del periodo de soporte del CRA?
La obligación ordinaria de gestión de vulnerabilidades está ligada al periodo de soporte, pero las actualizaciones ya publicadas deben seguir disponibles. Cada actualización de seguridad puesta a disposición durante el periodo de soporte debe permanecer disponible al menos 10 años desde su publicación o durante el resto del periodo de soporte, lo que sea más largo. Los fabricantes deben comunicar el fin de soporte con antelación y mantener disponibles las instrucciones para usuarios durante el periodo exigido. Evita afirmar que la notificación puede ignorarse tras el fin de soporte sin una revisión jurídica caso por caso.