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

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.

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 introducción del producto en el mercado, o durante el resto del período de soporte, si este es más largo. 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 o 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 en el primer mes del proyecto, no en el último:

  • 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 asienta sobre arena. 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 y las actualizaciones publicadas quedan disponibles diez; un SoC con fin de vida a los tres años perfora el compromiso, un OS embebido con cuatro también.
La promesa y lo que la sostiene: cualquier componente que muera antes del compromiso transforma la promesa en arena.

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. Es más fácil diseñar para cinco años que remendar para ellos.

Para quien ya tiene producto en el mercado, el ejercicio inverso: listar los componentes cuyo fin de vida cae dentro del período de soporte declarado y decidir, para cada uno, entre sustitución planificada, soporte ampliado contratado al proveedor, o mitigación propia documentada.

Fuentes