Periodo de soporte CRA: regla de 5 años (Artículo 13(8))

El Artículo 13(8) de la Ley de Ciberresiliencia de la UE (Reglamento (UE) 2024/2847) establece un suelo de cinco años para la gestión de vulnerabilidades, anclado a la fecha en que el producto se comercializa en el mercado de la UE. Esta guía explica la mecánica de la duración: cuándo empieza a contar el reloj, cómo funciona la excepción por vida útil reducida, cómo se acumulan los periodos en carteras multiversión y qué deben cubrir los contratos con proveedores upstream. Para la cadencia de entrega, consulta actualizaciones de seguridad del CRA; para la fecha de fin de periodo de soporte que se comunica al usuario, consulta la divulgación del fin de soporte.

Resumen

  • Cinco años es el mínimo. El Artículo 13(8) exige la gestión de vulnerabilidades durante al menos cinco años desde la fecha en que el producto se comercializa en el mercado de la UE.
  • La excepción por vida útil reducida es restrictiva. Debe evaluarse antes de la comercialización, documentarse en la evaluación de riesgos del Anexo I Parte I y comunicarse a los usuarios en la información del Anexo II antes de la compra.
  • El reloj empieza en la comercialización, no en la compra del cliente. El inventario que permanece en un almacén antes de la venta ya ha consumido parte del periodo de soporte.
  • Las carteras multiversión acumulan ventanas superpuestas. Cada versión tiene su propio reloj del Artículo 13(8); los fabricantes pueden adeudar soporte simultáneo para tres o más versiones activas.
  • El riesgo del proveedor upstream es el riesgo del fabricante. El fin de vida de un componente externo no es una defensa; los contratos de suministro deben cubrir el periodo completo del Artículo 13(8).
5y
Periodo mínimo de soporte
Artículo 13(8) desde la comercialización
Free
Actualizaciones de seguridad
Artículo 13(8), sin pago por parches
10y
Conservación del expediente técnico
Artículo 31, desde la comercialización
€15M / 2.5%
Multa máxima
Artículo 64, el importe que sea mayor

Los cuatro números que definen el periodo de soporte del CRA: la duración mínima, la obligación de coste, el suelo de conservación de la documentación y el techo de sanciones.

El periodo de soporte empieza en la comercialización, no en la compra del cliente

El Artículo 13(8) ancla el periodo de cinco años a la fecha en que el producto se comercializa en el mercado de la UE, es decir, la primera vez que se pone a disposición de cualquier canal de distribución o venta. Una unidad que permanece en un almacén durante 18 meses antes de que un cliente la compre ya ha consumido 18 meses de su periodo de soporte. Esto genera un riesgo de inventario: los fabricantes que no registran las fechas de comercialización por versión de producto no pueden demostrar el cumplimiento del Artículo 13(8).

Qué exige el CRA para el periodo de soporte

El Artículo 13(8) de la Ley de Ciberresiliencia establece que el fabricante "deberá garantizar que las vulnerabilidades del producto con elementos digitales se gestionen de forma efectiva durante un periodo de al menos cinco años desde la fecha en que el producto con elementos digitales se comercializa, o durante el periodo de uso previsto del producto, si este fuera menor."

La obligación tiene tres componentes:

Duración

Al menos cinco años. La excepción por "periodo de uso previsto inferior" es restrictiva y debe documentarse y comunicarse antes de la compra. El fabricante no puede invocarla de forma retroactiva. Si la documentación indica cinco años, el fabricante debe cinco años.

Gestión

Las vulnerabilidades deben gestionarse "de forma efectiva" según el Anexo I Parte II: identificarlas y documentarlas, corregirlas sin demora injustificada, divulgarlas una vez resueltas y mantener una política de divulgación coordinada. No basta con enviar parches; es todo el ciclo de vida de la vulnerabilidad.

Sin coste

Las actualizaciones de seguridad deben proporcionarse a los usuarios de forma gratuita. Las actualizaciones de funcionalidades y los niveles de soporte de pago son independientes. Incluir las correcciones dentro de una suscripción de pago no satisface el Artículo 13(8). Consulta actualizaciones de seguridad para la mecánica de entrega.

Cuándo empieza el reloj de los cinco años

El Artículo 13(8) ancla el periodo de soporte a la fecha en que el producto se "comercializa". Según el derecho europeo de productos, la comercialización es la primera vez que el producto se pone a disposición de cualquier parte de la cadena de distribución, no la venta al cliente final.

El reloj empieza: en la fecha en que el fabricante (o un representante autorizado) pone el producto por primera vez a disposición de un distribuidor, minorista o importador con fines de distribución en la UE.

El reloj no empieza en: la compra del cliente, la activación por parte del cliente, el envío de una unidad concreta ni la fecha en que el cliente instala el producto.

Ejemplo práctico:

  1. Enero de 2028. El producto v1.0 se comercializa en el mercado de la UE. Empieza el periodo de soporte de cinco años. El fabricante debe actualizaciones de seguridad hasta al menos enero de 2033.
  2. Junio de 2029. Un cliente compra el v1.0 a un minorista. El cliente tiene aproximadamente 3,5 años de soporte restantes, no cinco años desde la compra.
  3. Enero de 2033. Fin del periodo de soporte. La obligación del fabricante de parchear el v1.0 cesa. El cliente continúa usando el producto bajo su propio riesgo.

Buena práctica: registra las fechas de comercialización por versión de producto, no por unidad individual. Un único registro de fecha de comercialización por SKU es suficiente para el Artículo 13(8).

La excepción por vida útil prevista reducida

El Artículo 13(8) permite que el periodo de soporte sea inferior a cinco años si el periodo de uso previsto del producto es menor. Esta excepción es más restrictiva de lo que parece:

  • El "periodo de uso previsto del producto" se evalúa desde la perspectiva de las expectativas razonables del usuario, en función de la naturaleza del producto, el uso típico de productos similares y lo que comunica el fabricante.
  • El periodo reducido debe documentarse en la evaluación de riesgos del producto (Anexo I Parte I) y comunicarse a los usuarios en la información del Anexo II antes de la compra.
  • El fabricante no puede invocar la excepción después de que se descubra una vulnerabilidad. La evaluación debe realizarse 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 se aplica a productos con una vida útil objetivamente corta, como el hardware de un solo uso o de ciclos limitados, no a productos en los que el fabricante simplemente prefiere una obligación más breve.

Soporte multiversión

La mayoría de fabricantes tiene varias versiones de producto en el mercado simultáneamente, cada una con su propio periodo de soporte del Artículo 13(8).

Los periodos de soporte escalonados generan obligaciones superpuestas:

Tres versiones de producto se superponen durante cuatro años según el Artículo 13(8) Cronograma estilo Gantt. La v1.0 tiene soporte de enero de 2028 a enero de 2033. La v1.1 tiene soporte de julio de 2028 a julio de 2033. La v2.0 tiene soporte de enero de 2029 a enero de 2034. Entre enero de 2029 y enero de 2033, las tres versiones están simultáneamente bajo soporte. Ventana de cuatro años: las tres versiones bajo soporte simultáneo v1.0 v1.1 v2.0 2028 2029 2030 2031 2032 2033 2034
Cada barra representa un periodo de soporte de cinco años del Artículo 13(8) anclado a la fecha de comercialización en la UE de esa versión. La banda sombreada marca la ventana en la que el fabricante debe aplicar parches simultáneos a toda la cartera.
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 (cuatro años), el fabricante debe actualizaciones de seguridad para las tres versiones simultáneamente. Cada versión tiene su propia exposición a CVE, su propio árbol de dependencias y, potencialmente, su propia base de clientes. El retroporte de parches entre versiones principales es técnicamente complejo y costoso.

Estrategias para reducir la carga del soporte multiversión:

  1. Base de código compartida. Siempre que sea posible, mantén un núcleo con parches de seguridad único sobre el que construyan todas las versiones. Las correcciones de seguridad aplicadas una sola vez se propagan a todas las versiones.
  2. Incentivos agresivos de migración. Reducir los lapsos entre clientes en versiones antiguas reduce la matriz de soporte activa. Los precios de actualización, las herramientas de migración gratuitas y los créditos de soporte aceleran la consolidación de versiones.
  3. Calendario explícito de fin de vida por versión. Publica la fecha de fin de soporte de cada versión en el momento de la comercialización. Los clientes que saben que el v1.0 finaliza en enero de 2033 tienen tiempo de planificar la migración sin presión de emergencia.

Obligaciones con proveedores y contratos upstream

El Artículo 13(8) coloca la obligación del periodo de soporte sobre el fabricante. Un fabricante que no puede parchear su producto porque un proveedor de componentes ha discontinuado el soporte sigue incumpliendo el Artículo 13(8). El vacío en el contrato upstream no es una defensa.

Lo que esto implica en la práctica:

  • Si un producto incluye un sistema operativo, middleware o firmware de chipset de terceros, el fabricante debe obtener un acuerdo de suministro que cubra el periodo de soporte completo. Un proveedor upstream que proporciona parches de seguridad durante tres años obliga al fabricante a mantener los parches por su cuenta a partir del tercer año o a dejar de comercializar el producto en la UE tras el fin de vida del upstream.
  • 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 upstream sin conocer el contenido del producto.
  • Los contratos de suministro deben especificar: duración del compromiso de parches upstream, obligaciones de notificación ante vulnerabilidades recién descubiertas, acceso al código fuente o a las herramientas de parcheo si el proveedor upstream discontinúa el componente, y condiciones de indemnización por vulnerabilidades originadas en componentes upstream.

Los importadores que activan el escalado de rol del Artículo 22 (al reetiquetar o modificar sustancialmente un producto) heredan la obligación completa del Artículo 13(8), incluido el riesgo del contrato upstream. Consulta la guía de obligaciones del importador para el flujo de decisión del Artículo 22.

Planificación del fin de vida y transiciones responsables de producto

Cuando finaliza el periodo de soporte del Artículo 13(8), la obligación del fabricante de parchear vulnerabilidades cesa, pero permanece un conjunto de responsabilidades.

Lo que exigen el Artículo 13(8) y las disposiciones relacionadas al fin del soporte:

  • La fecha de fin de periodo de soporte del Anexo II, comunicada antes de la compra, se mantiene como el compromiso adquirido. Los usuarios deben haber recibido un aviso adecuado con antelación suficiente.
  • El expediente técnico debe conservarse durante al menos 10 años desde la fecha de comercialización del producto en el mercado de la UE (Artículo 31), independientemente de cuándo termine el soporte.
  • La Declaración UE de Conformidad debe permanecer accesible para las autoridades de vigilancia del mercado.
  • Si el fabricante tiene conocimiento de una vulnerabilidad crítica y activamente explotada en el producto sin soporte que afecta a una base instalada significativa, no existe obligación de notificación del Artículo 14 una vez finalizado el soporte. La divulgación responsable y la notificación a los usuarios son firmemente recomendables. Consulta notificación de vulnerabilidades para la mecánica de plazos del Artículo 14 aplicable durante el periodo de soporte.

Obligaciones de comunicación al fin del soporte:

El CRA no establece un plazo legal de aviso previo al fin del soporte. El requisito del Anexo II de comunicar la fecha de fin del periodo de soporte antes de la compra implica que los usuarios que adquirieron el producto después de que la divulgación del Anexo II estuviera vigente ya estaban informados. Para productos en los que la divulgación original del Anexo II era inexistente o poco clara, 12 meses de aviso previo es el mínimo estándar del sector.

Tras el fin de vida: el fabricante no está obligado a parchear nuevas vulnerabilidades, pero debería mantener un contacto de seguridad para la divulgación responsable de vulnerabilidades, conservar la documentación del producto accesible y cooperar con cualquier investigación de una autoridad de vigilancia del mercado en virtud del Artículo 58.

Para el manual operativo completo de fin de vida, que incluye plantillas de notificación, marcos de migración, escenarios de productos adquiridos y el calendario de planificación de 18 meses, consulta Planificación del fin de vida del CRA: transiciones responsables de producto.

Errores habituales

No registrar las fechas de comercialización. Sin un registro de fecha de comercialización por versión, el fabricante no puede calcular cuándo empiezan ni cuándo terminan las obligaciones del Artículo 13(8), no puede generar la fecha de fin del periodo de soporte del Anexo II y no puede demostrar el cumplimiento ante las autoridades de vigilancia del mercado.

No planificar el fin de vida upstream. Si un proveedor de chipset, sistema operativo o middleware termina su soporte antes de que expire el periodo del Artículo 13(8) del fabricante, el fabricante debe tener un plan. El descubrimiento reactivo del fin de vida upstream sin un acuerdo de suministro en vigor es un modo de fallo habitual y costoso.

Vincular los parches de seguridad a las publicaciones de funcionalidades. Incluir las correcciones de seguridad en actualizaciones de versión principal obliga a los clientes a aceptar nuevas funcionalidades y una nueva superficie de riesgo para recibir una corrección de seguridad. El Artículo 13(8) exige que las correcciones se entreguen sin demora injustificada. Un ciclo de publicación de seis meses no es "sin demora injustificada" para una vulnerabilidad crítica.

Preguntas frecuentes

¿Cuándo empieza el periodo de soporte de cinco años?

El Artículo 13(8) ancla el periodo de soporte a la fecha en que el producto se comercializa en el mercado de la UE: la primera vez que el fabricante pone el producto a disposición de cualquier parte de la cadena de distribución con fines de distribución en la UE. No empieza en la fecha de compra del cliente, en la activación ni en la fecha de envío de una unidad concreta. Un producto comercializado en enero de 2028 debe actualizaciones de seguridad hasta al menos enero de 2033, independientemente de cuándo lo compre cada cliente individual.

¿Puede el periodo de soporte ser inferior a cinco años?

Sí, mediante la excepción del Artículo 13(8), si el periodo de uso previsto del producto es inferior a cinco años. Sin embargo, el periodo reducido debe determinarse antes de la comercialización, documentarse en la evaluación de riesgos (Anexo I Parte I) y comunicarse a los usuarios en la información del Anexo II antes de la compra. El fabricante no puede invocar la excepción después de que se descubra una vulnerabilidad, y la evaluación debe reflejar las expectativas razonables del usuario, no las preferencias internas de coste. Para la mayoría de dispositivos IoT, hardware conectado y productos de software, cinco años es el mínimo práctico.

¿Se aplica la notificación del Artículo 14 tras el fin del periodo de soporte?

No. Las obligaciones de notificación del Artículo 14 (el aviso temprano de 24 horas, la notificación de 72 horas y el informe final de 14 días para vulnerabilidades activamente explotadas) se aplican al fabricante durante el periodo de soporte. Una vez que el periodo de soporte del Artículo 13(8) expira, el fabricante no tiene obligación de notificación del Artículo 14 por vulnerabilidades descubiertas en esa versión del producto. Las autoridades de vigilancia del mercado conservan la facultad de investigar en virtud del Artículo 58 si un producto sin soporte presenta un riesgo significativo para la ciberseguridad, pero las obligaciones continuas de gestión de vulnerabilidades y notificación de los Artículos 13 y 14 han concluido.

¿Qué ocurre si un proveedor de componentes upstream termina su soporte antes de que expire nuestro periodo del Artículo 13(8)?

El Artículo 13(8) coloca la obligación sobre el fabricante, no sobre los proveedores upstream. Si un proveedor de chipset, sistema operativo o middleware termina el soporte de un componente antes de que expire el periodo de cinco años del fabricante, el fabricante debe mantener los parches de forma independiente, obtener un componente alternativo con soporte o retirar el producto del mercado de la UE. La decisión de fin de vida de un proveedor upstream no es una defensa frente a la constatación de incumplimiento del Artículo 13(8) por parte de una autoridad de vigilancia del mercado. Los contratos de suministro negociados en la fase de diseño del producto deben especificar el periodo de compromiso de parches upstream, el acceso al código fuente o a las herramientas de parcheo, y las obligaciones de notificación, verificados frente al periodo de soporte previsto del producto antes de la comercialización.

Qué hacer antes del 11 de diciembre de 2027

  1. Para cada producto con elementos digitales de tu cartera, registra la fecha de comercialización por versión. Esta es la fecha de inicio del reloj del Artículo 13(8) y el ancla de la divulgación del Anexo II. Sin ella, no puedes calcular ni demostrar la fecha de fin del periodo de soporte.
  2. Evalúa si se aplica el mínimo de cinco años o si la excepción por vida útil prevista reducida es defendible. Documenta la evaluación en la evaluación de riesgos (Anexo I Parte I) y regístrala en el expediente técnico. Si hay dudas, comprométete con cinco años.
  3. Audita las dependencias upstream frente al periodo de soporte. Para cada sistema operativo, firmware de chipset, middleware o biblioteca de terceros incluida en el SBOM, confirma que el compromiso de parches del proveedor upstream cubre el periodo completo del Artículo 13(8). Renegocia o identifica alternativas donde no lo cubra. Consulta la guía del clúster SBOM para el marco de seguimiento de dependencias.
  4. Planifica las comunicaciones de fin de soporte para los productos cuyo periodo del Artículo 13(8) vencerá en la ventana 2028-2033. Los usuarios deben conocer la fecha de fin antes de comprar; deben recibir un aviso previo antes de que termine el soporte. Consulta la guía de planificación del fin de vida para el calendario de comunicación de 18 meses y las plantillas de aviso.
  5. Si gestionar periodos de soporte, monitorización de dependencias y notificación del Artículo 14 en múltiples versiones de producto supera la capacidad del equipo, CRA Evidence realiza el seguimiento de fechas de comercialización y fechas de fin del periodo de soporte por SKU, monitoriza las dependencias SBOM ante CVE recién divulgadas en toda la ventana de soporte y muestra las obligaciones de notificación del Artículo 14 cuando se detectan vulnerabilidades activamente explotadas.