Saltar al contenido
folhas.io
secure by design para productos conectados· Artículos

Artículos

Período de soporte: la promesa más cara que el CRA obliga a hacer

El CRA obliga a cada fabricante a declarar durante cuánto tiempo da soporte al producto: como mínimo, por regla general, cinco años. Es una decisión de ingeniería, de contratos y de proveedores disfrazada de campo en un formulario.

Publicado
Actualizado

Nota de actualización (23 oct 2026). Hemos corregido la regla de disponibilidad de las actualizaciones de seguridad, cuyos diez años se cuentan desde la emisión de cada una, hemos añadido la fecha a partir de la cual se aplica el artículo 13 y el ejemplo de los runtimes corregidos en octubre de 2026, y pasamos a citar las orientaciones de la Comisión de 27 jul 2026, publicadas después de la primera versión de este texto.

De todos los requisitos del CRA, el período de soporte es el que parece más administrativo y es el que más compromete. El artículo 13 obliga al fabricante a determinar un período durante el cual asegura la gestión eficaz de vulnerabilidades del producto, y a declararlo, porque el usuario tiene que saber, en el momento de la compra, hasta cuándo puede contar con actualizaciones de seguridad.

La regla

El período de soporte refleja el tiempo de utilización previsible del producto, y no puede ser inferior a cinco años, salvo que el producto esté destinado a usarse durante menos tiempo, en cuyo caso cubre ese tiempo de utilización. En la determinación entran, entre otros factores, la expectativa razonable del usuario, la naturaleza del producto y el período de soporte de productos comparables en el mercado. La fecha de fin de soporte se indica de forma clara, incluyendo, como mínimo, mes y año. Las orientaciones de la Comisión de 27 jul 2026, C(2026) 5252, recuerdan que los cinco años son una salvaguarda mínima: un producto que se espera usar durante más tiempo debe tener un período de soporte más largo.

Dos obligaciones accesorias que pasan desapercibidas:

  • Las actualizaciones de seguridad puestas a disposición durante el soporte deben permanecer disponibles durante al menos diez años tras la emisión de cada una, o durante el resto del período de soporte, si este es más largo. La cuenta se hace por actualización: una corrección emitida el cuarto año queda disponible, como mínimo, hasta el decimocuarto. Un parche publicado no puede desaparecer del servidor dos años después.
  • La documentación técnica, incluida la fundamentación de la duración elegida, se conserva durante, como mínimo, diez años tras la introducción del producto en el mercado o durante el período de soporte, el que sea más largo, y las autoridades de vigilancia del mercado pueden pedir los datos que fundamentaron la decisión.

Por qué esto es una decisión de ingeniería

Prometer cinco años de gestión de vulnerabilidades no es prometer buena voluntad; es prometer que, dentro de cinco años, todavía existe un camino técnico para corregir y entregar. Eso tira de decisiones que se toman ya en el primer mes del proyecto:

  • Alineación con los proveedores. Si el SoC elegido tiene fin de vida anunciado para dentro de tres años, o el BSP del proveedor deja de recibir parches, la promesa de cinco años se queda sin camino técnico de corrección para los años que faltan. El período de soporte del producto tiene que reconciliarse con el ciclo de vida de cada componente crítico de la SBOM y, en los contratos de suministro, con cláusulas de soporte correspondientes.
  • Capacidad de actualización duradera. El mecanismo de actualización (OTA o local) tiene que seguir funcionando durante todo el período: claves de firma gestionadas y rotables, espacio de flash reservado para imágenes futuras más grandes, infraestructura de distribución presupuestada como coste recurrente.
  • Compatibilidad de build a cinco años. Reconstruir el firmware en 2031 con la toolchain de 2026 exige builds reproducibles y entornos archivados. Sin eso, el primer CVE serio en un componente antiguo se transforma en un proyecto de arqueología.
Gráfico de barras temporales: el compromiso CRA del producto dura al menos cinco años; una actualización emitida el cuarto año queda disponible diez años desde su emisión, hasta el decimocuarto; un SoC con fin de vida a los tres años perfora el compromiso, un OS embebido con cuatro también.
Cada barra que termina antes de los cinco años es un hueco que cerrar componente a componente: sustitución planificada, soporte ampliado contratado al proveedor o mitigación propia documentada.

Y una decisión de contratos

El período declarado entra en la información al usuario y, en la práctica, en los contratos con clientes B2B, que frecuentemente pedirán más que el mínimo. Vale la pena separar dos cosas que los contratos tienden a fundir: el período de soporte CRA (gestión de vulnerabilidades y actualizaciones de seguridad, obligación legal) y el soporte comercial (nuevas funcionalidades, SLA, asistencia), que es negociable. Vender la distinción al cliente evita que una obligación legal de cinco años se transforme, por arrastre contractual, en una promesa de roadmap de cinco años.

Qué significa esto para quien fabrica

En nuestro propio producto, la decisión que tomamos fue tratar el período de soporte como restricción de diseño de primer orden, al nivel del coste unitario: ningún componente entra en la BOM sin fecha de fin de vida conocida y compatible con el período objetivo, y el presupuesto del producto incluye el coste anual de la infraestructura de actualización durante todo el período.

Una salvedad de calendario: el artículo 13, incluido el período de soporte, solo se aplica a partir del 11 de diciembre de 2027. Los productos introducidos en el mercado antes de esa fecha solo quedan sujetos si sufren una modificación sustancial después (art. 69, apartado 2). Pero la introducción en el mercado se cuenta unidad a unidad: las unidades de un modelo actual introducidas en el mercado a partir del 11 de diciembre de 2027 tienen que cumplir, con período de soporte declarado. La notificación del artículo 14, en cambio, se aplica desde el 11 de septiembre de 2026 a todos los productos, incluidos los ya introducidos en el mercado (art. 69, apartado 3), y sigue aplicándose cuando termina el período de soporte.

Para quien ya tiene producto en el mercado y lo va a seguir vendiendo después de diciembre de 2027, el ejercicio es el inverso: listar los componentes cuyo fin de vida cae dentro del período de soporte que tendrá que declarar y decidir, para cada uno, entre sustitución planificada, soporte ampliado contratado al proveedor o mitigación propia documentada.

Los runtimes y las bibliotecas de software también son componentes de la SBOM, con un fin de vida tan concreto como el de un SoC, y las correcciones del 21 oct 2026 a PHP y a Node.js lo mostraron bien. PHP 8.1, sin soporte desde el 31 dic 2025, no tuvo versión corregida, solo backports mínimos en código fuente, sin número de versión nuevo. Node 20, sin soporte desde el 30 abr 2026, se quedó sin corrección. PHP 8.2 sí la recibió, pero el proyecto deja de darle soporte el 31 dic 2026. Ninguna línea de estos dos runtimes tiene cinco años de soporte del proyecto, así que cumplir el período declarado exige una de las tres vías: migraciones de versión mayor planificadas de antemano, soporte ampliado contratado a una distribución o a un proveedor LTS, o correcciones propias, que el art. 13, apartado 6, obliga a compartir con quien mantiene el componente. El caso está desarrollado en el artículo 09. El kernel Linux y Python tienen también fines de vida fijados por rama, tratados en el artículo 10.

Fuentes