El Reglamento de Ciberresiliencia de la UE convierte la planificación del periodo de soporte en una decisión de lanzamiento, no en algo que se resuelve después. El fabricante tiene que decidir durante cuánto tiempo los usuarios pueden esperar que se gestionen las vulnerabilidades, publicar la fecha de fin de soporte en el momento de la compra y mantener disponibles las actualizaciones de seguridad durante el periodo exigido. Esta guía cubre la mecánica de duración: cuándo empieza el reloj, cómo funciona la excepción por uso previsto más corto, cómo se solapan las carteras con varias versiones y qué deben cubrir los contratos con proveedores aguas arriba. Para la cadencia de entrega, consulta actualizaciones de seguridad CRA; para la fecha de fin de soporte de cara al usuario, consulta comunicación de fin de soporte.
Resumen
- Cinco años es el mínimo. El CRA exige gestión de vulnerabilidades durante al menos cinco años, salvo que se espere que el producto se use durante menos tiempo.
- La excepción por uso previsto más corto es estrecha. Debe evaluarse antes de la comercialización, documentarse en la documentación técnica y comunicarse a los usuarios antes de la compra.
- El reloj empieza con la comercialización, no con la compra del cliente. El inventario que permanece en almacén antes de venderse ya ha consumido parte de la ventana de soporte.
- Las carteras con varias versiones pueden apilar ventanas solapadas. Una ruta limitada para software permite corregir solo la versión más reciente, pero solo si los usuarios de versiones anteriores pueden migrar gratis y sin costes de entorno.
- El riesgo del proveedor aguas arriba es riesgo del fabricante. El fin de vida de un componente no es una defensa; los contratos de suministro deben cubrir todo el periodo de soporte.
Las cuatro señales que definen la planificación del soporte: duración mínima, coste de las actualizaciones, conservación documental y exposición sancionadora.
Qué exige el CRA para el periodo de soporte
El periodo de soporte es la ventana durante la cual el fabricante debe mantener vivo el proceso de gestión de vulnerabilidades del producto. Cubre el producto y sus componentes, empieza con la comercialización en la UE y debe ser suficiente para ajustarse a cómo los usuarios pueden esperar razonablemente que se use el producto. El fabricante debe fijarlo a partir de pruebas prácticas: tipo de producto, finalidad prevista, productos comparables, normas de la Unión sobre vida útil, disponibilidad del entorno operativo, soporte de componentes esenciales de terceros y orientaciones de ADCO o de la Comisión. El resultado práctico es sencillo: el soporte debe definirse antes del lanzamiento y mantenerse durante toda la ventana declarada.
La obligación tiene tres componentes:
| Componente | Regla operativa | Pruebas a conservar |
|---|---|---|
| DuraciónCuánto dura el soporte | Usa al menos cinco años salvo que el periodo previsto de uso del producto sea más corto. | Justificación del periodo de soporte en la documentación técnica y una fecha clara de fin de soporte en la compra. |
| GestiónQué debe seguir activo | Mantén el ciclo de vulnerabilidades en marcha: documentar hallazgos, corregir sin demora, divulgar problemas corregidos, operar CVD y distribuir actualizaciones de forma segura. | Registros de vulnerabilidades, marcas temporales de corrección, política CVD, pruebas de distribución de actualizaciones y avisos a usuarios. |
| Actualizaciones de seguridadCoste y disponibilidad | Difunde las actualizaciones de seguridad disponibles sin demora y gratis, salvo la excepción estrecha para productos empresariales hechos a medida. | Registros de versiones que muestren cuándo estuvieron disponibles las correcciones y que los arreglos básicos de seguridad no quedaron tras niveles de pago. |
Cuándo empieza el reloj de cinco años
El reloj de soporte empieza cuando el producto entra en el mercado de la UE, no cuando el cliente final lo compra. En derecho de productos de la UE, eso es la primera puesta a disposición del producto en el mercado de la Unión para distribución o uso. Para planificar el soporte, la fecha de comercialización es la fecha que importa.
El reloj empieza: La fecha en que el producto se pone por primera vez a disposición de un distribuidor, minorista, importador o usuario para su distribución o uso en el mercado de la UE.
El reloj no empieza con: la compra del cliente, la activación del cliente, el envío de una unidad concreta o la fecha en que un cliente instala el producto.
Ejemplo práctico:
- Enero de 2028. El producto v1.0 se comercializa en la UE. Empieza el periodo de soporte de cinco años. El fabricante debe actualizaciones de seguridad al menos hasta enero de 2033.
- Junio de 2029. Un cliente compra v1.0 a un minorista. Le quedan aproximadamente 3,5 años de soporte, no cinco años desde la compra.
- Enero de 2033. Termina el periodo de soporte. Finaliza el compromiso básico de gestión de vulnerabilidades para v1.0. Cualquier aviso a usuarios o interacción regulatoria posterior dependerá de los hechos.
Buena práctica: Registra fechas de comercialización por versión de producto, no por unidad individual. Un único registro de fecha de comercialización por SKU suele ser la base práctica para calcular fechas de fin de soporte.
La excepción por uso previsto más corto
El mínimo de cinco años solo puede acortarse cuando se espere de verdad que el producto se use durante menos de cinco años. Esa excepción es más estrecha de lo que parece y procede del artículo del periodo de soporte:
- El periodo previsto de uso del producto se evalúa desde las expectativas razonables del usuario, según la naturaleza del producto, cómo se usan productos similares y qué comunica el fabricante.
- El periodo más corto debe documentarse en la documentación técnica y comunicarse a los usuarios en la compra, incluido al menos el mes y el año de la fecha de fin de soporte.
- El fabricante no puede invocar la excepción después de descubrir una vulnerabilidad. La evaluación debe hacerse antes de la comercialización y quedar registrada en el expediente técnico.
- Para la mayoría de productos de software, dispositivos IoT y hardware conectado, cinco años es el mínimo práctico. La excepción encaja con productos de vida útil objetivamente corta, como hardware de un solo uso o de ciclo limitado, no con productos donde el fabricante simplemente prefiere una obligación más corta.
Soporte multiversión
La mayoría de fabricantes tienen varias versiones de producto en el mercado al mismo tiempo. Los productos de hardware y las versiones de software mantenidas de forma independiente pueden crear ventanas de soporte solapadas. Los productos de software también tienen una vía limitada de solo última versión para versiones posteriores modificadas sustancialmente, pero solo si los usuarios de versiones anteriores pueden pasar a la última versión gratis y sin costes adicionales de hardware o entorno de software.
Los periodos de soporte escalonados crean obligaciones solapadas:
| Versión | Comercialización | Fin de soporte (5 años) |
|---|---|---|
| v1.0 | Ene 2028 | Ene 2033 |
| v1.1 | Jul 2028 | Jul 2033 |
| v2.0 | Ene 2029 | Ene 2034 |
De enero de 2029 a enero de 2033, durante cuatro años, el fabricante puede deber actualizaciones de seguridad para las tres versiones al mismo tiempo salvo que aplique una vía de software elegible de solo última versión. Cada versión tiene su propia exposición a CVE, su propio árbol de dependencias y posiblemente su propia base de clientes. Llevar parches hacia atrás entre versiones mayores es técnicamente complejo y caro.
Estrategias para reducir la carga multiversión:
- Base de código común. Cuando sea posible, mantén un núcleo único con parches de seguridad en el que se apoyen todas las versiones. Las correcciones aplicadas una vez se propagan a todas las versiones.
- Incentivos de migración agresivos. Cuanto menor sea la brecha con clientes en versiones antiguas, menor será la matriz activa de soporte. Precios de actualización, herramientas gratuitas de migración y créditos de soporte aceleran la consolidación.
- Calendario explícito de EOL por versión. Publica la fecha de fin de soporte de cada versión en la comercialización. Los clientes que saben que v1.0 termina en enero de 2033 pueden planificar la migración sin urgencias.
- Ruta de última versión para software admisible. Si usas esta ruta, documenta cómo reciben la última versión los usuarios de versiones anteriores, gratis y sin costes de ajuste del entorno.
Obligaciones con proveedores y contratos aguas arriba
El fabricante responde de la obligación del periodo de soporte incluso cuando la vulnerabilidad procede de un componente aguas arriba. Si el producto no puede parchearse porque un proveedor de componentes ha terminado su soporte, el fabricante sigue necesitando una vía de corrección. La brecha contractual aguas arriba no es una defensa bajo la regla del periodo de soporte.
Qué significa en la práctica:
- Si un producto incluye un sistema operativo, middleware o firmware de chipset de terceros, el fabricante debe asegurar un acuerdo de suministro que cubra todo el periodo de soporte. Un proveedor aguas arriba que entrega parches de seguridad durante tres años obliga al fabricante a mantener los parches por su cuenta después del tercer año o a dejar de comercializar la configuración afectada en la UE tras el EOL aguas arriba.
- El seguimiento de dependencias basado en SBOM, consulta la guía del clúster SBOM, es el mecanismo operativo: el fabricante no puede monitorizar vulnerabilidades aguas arriba sin saber qué contiene el producto.
- Los contratos de suministro deben especificar: duración del compromiso de parches aguas arriba, obligaciones de aviso ante nuevas vulnerabilidades, acceso a código fuente o herramientas de parcheo si el proveedor abandona el componente, e indemnizaciones por vulnerabilidades originadas en componentes aguas arriba.
Los importadores y distribuidores que comercialicen un producto con su propio nombre o marca, o modifiquen sustancialmente un producto ya comercializado, se tratan como fabricantes y heredan las obligaciones del fabricante, incluido el riesgo contractual aguas arriba. Consulta la guía de obligaciones del importador para el flujo de cambio de rol.
Planificación de fin de vida y transiciones responsables
Cuando termina el periodo de soporte, termina el compromiso básico de gestión de vulnerabilidades para esa versión del producto, pero siguen existiendo responsabilidades.
Qué queda al final del soporte:
- La fecha de fin de soporte comunicada en la compra queda como compromiso visible para el usuario.
- La documentación técnica y la declaración UE de conformidad deben conservarse durante al menos 10 años desde la comercialización o durante el periodo de soporte, lo que sea más largo.
- La información e instrucciones para usuarios deben seguir disponibles durante al menos 10 años desde la comercialización, o durante el periodo de soporte si este fuera mayor.
- Cuando sea técnicamente viable, el fabricante debe notificar a los usuarios cuando el producto alcanza el fin de su periodo de soporte.
- Las vulnerabilidades de productos sin soporte siguen necesitando una gestión cuidadosa. El CRA no contiene una frase general de puerto seguro para toda cuestión de notificación de incidentes al llegar el EOL, y las autoridades de vigilancia del mercado pueden actuar cuando un producto presenta un riesgo significativo de ciberseguridad. La exposición sancionadora se trata en la guía de sanciones y enforcement.
Obligaciones de comunicación al final del soporte:
El CRA no fija un plazo legal de preaviso para el fin del soporte. La comunicación de la fecha de fin de soporte en la compra significa que los usuarios que compraron el producto después de que esa información estuviera disponible ya estaban avisados. Para productos donde la comunicación original faltaba o no era clara, el preaviso es un control operativo de riesgo, no un plazo numerado del CRA.
Después del EOL: el fabricante debe mantener un contacto de seguridad para divulgación responsable de vulnerabilidades, conservar accesible la documentación del producto y cooperar con cualquier investigación de una autoridad de vigilancia del mercado.
Errores comunes
-
No registrar fechas de comercialización. Sin una fecha de comercialización por versión, el fabricante no puede calcular cuándo empiezan o terminan las obligaciones de soporte, no puede generar la fecha de fin de soporte de cara al usuario y no puede demostrar cumplimiento ante las autoridades de vigilancia del mercado.
-
No planificar el EOL aguas arriba. Si un proveedor de chipset, sistema operativo o middleware termina su soporte antes de que expire el periodo de soporte del fabricante, el fabricante necesita un plan. Descubrir tarde el EOL aguas arriba sin un acuerdo de suministro es un fallo habitual y caro.
-
Vincular parches de seguridad a versiones funcionales. Agrupar correcciones de seguridad en grandes actualizaciones obliga a los clientes a aceptar nuevas funciones y nueva superficie de riesgo para recibir un arreglo de seguridad. Las correcciones de seguridad deben entregarse como correcciones de seguridad, sin forzar niveles de pago ni grandes actualizaciones funcionales.
Preguntas frecuentes
¿Cuándo empieza el periodo de soporte de cinco años?
Empieza cuando el producto se comercializa en la UE, no cuando un cliente lo compra o activa. La comercialización es la primera puesta a disposición del producto en el mercado de la Unión, así que el tiempo en almacén o en distribución puede consumir parte de la ventana de soporte. Un producto comercializado en enero de 2028 normalmente necesita gestión de vulnerabilidades al menos hasta enero de 2033, aunque un cliente concreto lo compre más tarde.
¿Puede el periodo de soporte ser inferior a cinco años?
Sí, pero solo cuando se espere que el producto se use durante menos de cinco años. El periodo de soporte debe reflejar expectativas razonables de los usuarios, naturaleza y finalidad prevista del producto, Derecho de la Unión aplicable, productos comparables, disponibilidad del entorno operativo, soporte de componentes esenciales de terceros y orientaciones de ADCO o de la Comisión. La información usada para fijarlo pertenece a la documentación técnica, y la fecha final debe estar clara en la compra.
¿La notificación aplica después de terminar el periodo de soporte?
No trates el fin del soporte como un puerto seguro general frente a la notificación de incidentes. La regla del periodo de soporte define la ventana de gestión de vulnerabilidades, mientras que el deber de notificación de incidentes exige por separado avisar de vulnerabilidades activamente explotadas e incidentes graves de los que el fabricante tenga conocimiento. Para un producto sin soporte, documenta la determinación jurídica antes de decidir no notificar, y aun así considera avisar a los usuarios cuando el riesgo sea material.
¿Qué pasa si un proveedor de componentes termina su soporte antes?
El fabricante sigue siendo responsable de la obligación del periodo de soporte. La regla del periodo de soporte cubre vulnerabilidades en el producto y sus componentes, y la regla de diligencia debida sobre componentes exige cuidado al integrar componentes de terceros. Si un proveedor de chipset, sistema operativo, middleware o biblioteca sale antes de tiempo, el fabricante necesita otra vía: mantener parches, sustituir el componente o dejar de comercializar la configuración afectada en la UE.