Planificación del periodo de soporte CRA: 5 años de actualizaciones de seguridad (y lo que realmente significa)

Cinco años. Ese es el mínimo que debes proporcionar actualizaciones de seguridad para tus productos bajo el CRA. Para muchos fabricantes, esto representa un cambio fundamental en cómo piensan sobre el ciclo de vida del producto y los costes de soporte.

Esta guía cubre lo que realmente significa el requisito del período de soporte, cómo planificarlo y cómo gestionar la inevitable transición de fin de soporte.

Lo que el CRA realmente requiere

El Artículo 13 y el Anexo I establecen las obligaciones del período de soporte:

Duración mínima

5 años desde que el producto se coloca en el mercado de la UE, O la vida útil esperada del producto, lo que sea menor.

"Vida útil esperada del producto" se determina por:

• Expectativas razonables del cliente basadas en la naturaleza del producto
• cómo se usan típicamente productos similares
• Lo que comunicas sobre el producto

Para la mayoría del software y productos IoT, 5 años es el mínimo práctico.

Lo que debes proporcionar

Durante el período de soporte, debes:

1. Abordar vulnerabilidades sin demora

   • Proporcionar parches de seguridad para vulnerabilidades conocidas
   • Priorizar según severidad
   • No esperar a "la próxima versión mayor"

2. Entregar actualizaciones de forma segura

   • Actualizaciones automáticas donde sea técnicamente posible
   • Distribución segura (firmadas, verificadas)
   • Capacidad de rollback si las actualizaciones fallan

3. Notificar a clientes

   • Informar sobre actualizaciones de seguridad disponibles
   • Proporcionar instrucciones claras de instalación
   • Comunicar información relevante para la seguridad

4. Proporcionar actualizaciones sin cargo

   • No pagar-para-parchear para actualizaciones de seguridad
   • Las actualizaciones de funciones pueden cobrarse por separado

¿Cuándo empieza el reloj?

El período de soporte comienza cuando el producto se "coloca en el mercado". Es decir, cuando lo pones disponible por primera vez en la UE.

No cuando:

• El cliente lo compra
• El cliente lo activa
• Una unidad específica se envía

Esto crea riesgo de inventario: Si tu producto permanece en distribución durante 18 meses antes de venderse, el soporte aún termina 5 años desde la colocación inicial en el mercado.

Ejemplo de cronograma

Ene 2028: Producto v1.0 colocado en mercado UE
          → Periodo de soporte comienza
          → Debe proporcionar actualizaciones hasta Ene 2033

Jun 2029: Cliente compra v1.0 de distribuidor
          → Cliente tiene 3.5 años de soporte restante

Ene 2033: Periodo de soporte termina
          → Sin mas obligación de parchear v1.0
          → Cliente tiene 18 meses de producto sin soporte

Mejor práctica: Rastrea fechas de comercialización por versión de producto, no por unidad.

Requisitos de entrega de actualizaciones

Actualizaciones automáticas (preferido)

Donde sea técnicamente factible y apropiado, el CRA espera actualizaciones de seguridad automáticas:

REQUISITOS DE ACTUALIZACION AUTOMATICA:

Técnico:
- Canal de descarga seguro (TLS, paquetes firmados)
- verificación de integridad antes de instalación
- Capacidad de rollback si la actualización falla
- Gestión elegante de problemas de conectividad

Control del Usuario:
- Usuario debe poder optar por no recibir (con advertencia clara)
- Usuario debe poder diferir (con limites razonables)
- Actualizaciones criticas pueden anular aplazamiento por seguridad
- Estado de actualización debe ser visible para el usuario

Notificación:
- Informar al usuario cuando las actualizaciones estan disponibles
- Explicar qué aborda la actualización
- Proporcionar instrucciones de instalación si es manual

Actualizaciones manuales (cuando automático no es posible)

Algunos productos no pueden auto-actualizarse: sistemas air-gapped, equipos industriales, dispositivos embebidos sin conectividad.

Para estos:

• Proporcionar paquetes de actualización descargables
• Versionado claro y registro de cambios
• documentación de instalación
• Método de verificación (checksums, firmas)
• Notificación vía canales disponibles (email, portal web, aviso físico)

Firma de actualizaciones

Todas las actualizaciones de seguridad deben estar firmadas criptograficamente:

REQUISITOS DE FIRMA DE ACTUALIZACIONES:

Firma de Código:
- Firmar todos los paquetes de actualización
- Usar clave de firma dedicada (protegida por HSM)
- Incluir verificación de firma en proceso de actualización
- Publicar clave publica para Verificación

Metadatos:
- número de version
- Fecha de lanzamiento
- Referencia de changelog/aviso
- Version base mínima compatible
- Marca de tiempo de firma

Respuesta a vulnerabilidades durante el periodo de soporte

El período de soporte no es solo tener actualizaciones disponibles. Es responder a vulnerabilidades a medida que se descubren.

Expectativas de respuesta

Estos no son plazos obligatorios del CRA, pero reflejan expectativas de la industria y lo que los reguladores considerarán "sin demora."

Seguimiento de vulnerabilidades

Necesitas un proceso para:

1. Recepción de descubrimiento

   • Política CVD y punto de contacto
   • Pipeline de descubrimiento interno
   • Monitorización de dependencias

2. Evaluación

   • ¿Afecta la vulnerabilidad a nuestro producto?
   • ¿Qué versiones están afectadas?
   • ¿Cuál es la severidad en nuestro contexto?

3. Remediación

   • Desarrollar parche
   • Probar parche
   • Lanzar parche

4. Comunicación

   • Notificar a clientes
   • Publicar aviso (si apropiado)
   • Notificar a ENISA (si activamente explotada)

Vulnerabilidades de dependencias

Tu producto incluye componentes de terceros. Cuando tienen vulnerabilidades:

• Dependencias directas: Debes evaluar impacto y actualizar si afectado
• Dependencias transitivas: Misma obligación, más difícil de rastrear
• Vulnerabilidades de SO/plataforma: Puede requerir actualizar o comunicar mitigación

El SBOM es esencial: No puedes rastrear lo que no conoces.

Modelado de costes para el periodo de soporte

Muchos fabricantes subestiman los costes de soporte. Aquí hay un marco:

Costes fijos (por línea de producto)

Costes variables (por año de soporte)

Ejemplo de modelo de costes

MODELO DE COSTES DEL PERIODO DE SOPORTE

Producto: Smart Home Hub v2.0
Periodo de Soporte: 5 años (Ene 2028 - Ene 2033)
Unidades Estimadas: 50,000

COSTES FIJOS (una vez):
- configuración pipeline actualizaciones: 15.000€
- Infraestructura de firma:               5.000€
- Sistema de Notificación:               10.000€
- Plantillas de Documentación:            5.000€
SUBTOTAL:                                35.000€

COSTES ANUALES:
- Ingeniero de seguridad (0.2 FTE):      30.000€/ano
- Monitorización de dependencias:         2.000€/ano
- Infraestructura de pruebas:             5.000€/ano
- Delta soporte al cliente:               3.000€/ano
SUBTOTAL:                      40.000€/ano × 5 = 200.000€

RESERVA DE INCIDENTES (5 años):
- Vulnerabilidades criticas (est. 2):    20.000€
- Parches regulares (est. 15):           30.000€
SUBTOTAL:                                50.000€

COSTE TOTAL DE SOPORTE 5 años:          285.000€
COSTE DE SOPORTE POR UNIDAD:            5,70€

Si se vende a 99€/unidad:
Soporte = 5.8% de ingresos

Perspectiva clave: El coste de soporte por unidad disminuye con el volumen. Los productos de bajo volumen tienen carga de soporte proporcionalmente mayor.

Planificación de fin de soporte

El período de soporte termina. ¿Entonces Qué?

Antes del fin de soporte

12 meses antes:

• Anunciar fecha de fin de soporte
• Comunicar a todos los usuarios registrados
• Publicar en paginas del producto y Documentación
• Ofrecer rutas de actualización/reemplazo

6 meses antes:

• Comunicaciones de recordatorio
• Últimas actualizaciones de funciones (si las hay)
• Congelación de documentación (capturar estado actual)
• Preparar actualización de seguridad final

En el fin de soporte:

• Emitir actualización de seguridad final con todas las correcciones conocidas
• Publicar aviso de fin de soporte
• Actualizar documentación del producto para reflejar estado
• Redirigir canales de soporte a alternativas

Plantilla de comunicación con clientes

AVISO DE FIN DE SOPORTE

Producto: [Nombre del Producto v1.0]
Fecha de Fin de Soporte: [Fecha]

Qué significa esto:
- Las actualizaciones de seguridad ya no se proporcionaran después de [Fecha]
- El soporte técnico para esta version terminará
- El producto continuará funcionando pero puede volverse vulnerable

Qué deberias hacer:
- Opcion 1: Actualizar a [Nombre del Producto v2.0] - [enlace]
- Opcion 2: Reemplazar con [Producto Alternativo] - [enlace]
- Opcion 3: Continuar uso bajo tu propio riesgo (no recomendado)

Cronograma:
- [Fecha - 6 meses]: Última actualización de funciones
- [Fecha - 1 mes]: Última actualización de seguridad
- [Fecha]: Fin de soporte

¿Preguntas? Contacta [canal de soporte]

Después del fin de soporte

Tus obligaciones después del período de soporte:

• Mantener expediente técnico durante 10 años totales (desde última unidad comercializada)
• Responder a solicitudes de vigilancia del mercado
• Sin obligación de parchear nuevas vulnerabilidades

Mejores prácticas (voluntarias):

• Mantener contacto de seguridad para divulgación responsable
• Considerar publicar vulnerabilidades conocidas-pero-no-corregidas
• Mantener infraestructura de actualización disponible para emergencias críticas

Soporte multi-versión

La mayoría de fabricantes tienen múltiples versiones del producto en el mercado simultáneamente.

Periodos de soporte escalonados

CRONOGRAMA DE SOPORTE DE VERSIONES

v1.0: Ene 2028 ─────────────────────────── Ene 2033
v1.1:      Jul 2028 ─────────────────────────── Jul 2033
v2.0:           Ene 2029 ─────────────────────────── Ene 2034

Soporte superpuesto: Ene 2029 - Ene 2033 = 4 años de soporte dual

Ejemplo de matriz de soporte

MATRIZ DE SOPORTE DE PRODUCTO (a partir de Ene 2030)

Version   Lanzada     Soporte Termina  Estado
────────────────────────────────────────────
v1.0      Ene 2028    Ene 2033         Mantenimiento
v1.1      Jul 2028    Jul 2033         Mantenimiento
v2.0      Ene 2029    Ene 2034         Actual
v2.1      Ene 2030    Ene 2035         Actual

Mantenimiento = Solo actualizaciones de seguridad
Actual = Actualizaciones de seguridad + funciones

Reduciendo la carga multi-versión

Estrategias para minimizar soporte superpuesto:

1. Base de código unificada: Compartir código entre versiones donde sea posible
2. Proceso de backport: Backports de seguridad automatizados o semi-automatizados
3. Ciclos de lanzamiento más cortos: Lanzamientos más frecuentes = ventanas de soporte más predecibles
4. Deprecación agresiva: Animar a clientes a actualizar

Consideraciones específicas de industria

Dispositivos IoT

• Muchos tienen vidas útiles esperadas de 7-10 años
• Los mecanismos de actualización pueden ser limitados
• La alcanzabilidad del cliente es desafiante
• Considera: capacidad de actualización remota, monitorización de heartbeat

Software B2B

• Los clientes enterprise esperan soporte más largo
• Los contratos de soporte pueden ya exceder 5 años
• La complejidad de integración afecta el despliegue de actualizaciones
• Considera: tiers de soporte extendido, servicios profesionales

Electrónica de consumo

• El canal minorista complica la comunicación con clientes
• Los usuarios finales pueden no registrar productos
• Compitiendo con cultura de obsolescencia planificada
• Considera: notificaciones de actualización en producto, actualizaciones basadas en app

Equipos industriales

• Vidas útiles esperadas de 15-20 años comunes
• El tiempo de inactividad para actualizaciones es costoso
• Instalaciones air-gapped
• Considera: despliegues escalonados, pruebas de compatibilidad, servicios de despliegue profesional

Errores comunes

Acoplar seguridad a actualizaciones de funciones

Problema: Parches de seguridad solo disponibles en lanzamientos mayores.

Por qué está mal: Los clientes no deberían necesitar aceptar nuevas funciones (y potenciales nuevos bugs) para obtener correcciones de seguridad.

Solución: Mantener track de actualizaciones solo-seguridad para versiones soportadas.

Ignorar actualizaciones de dependencias

Problema: El código del producto se mantiene pero las dependencias se pudren.

Por qué está mal: La mayoría de vulnerabilidades vienen de dependencias.

Solución: Incluir actualizaciones de dependencias en tu alcance de mantenimiento de seguridad.

Sin verificación de actualizaciones

Problema: Las actualizaciones están disponibles pero los clientes no pueden verificar autenticidad.

Por qué está mal: Los atacantes pueden distribuir "actualizaciones" falsas.

Solución: Firmar todas las actualizaciones, publicar procedimientos de verificación.

Fin de soporte no claro

Problema: El soporte simplemente... se detiene. Sin comunicación.

Por qué está mal: Los clientes quedan con productos vulnerables que no saben que no tienen soporte.

Solución: Proceso proactivo y documentado de fin de soporte.

Periodo de soporte no en precios

Problema: Producto con precio sin considerar coste de soporte de 5 años.

Por qué está mal: El soporte se convierte en centro de coste que consume márgenes.

Solución: Modela costes de soporte antes de fijar precios. Considera el soporte como coste de bienes vendidos.

Lista de verificación del periodo de soporte

LISTA DE verificación DE planificación DEL PERIODO DE SOPORTE

ANTES DE COMERCIALIZACION:

Infraestructura:
[ ] Pipeline de build de actualizaciones establecido
[ ] Mecanismo de entrega de actualizaciones seguro
[ ] Infraestructura de firma de código
[ ] Sistema de Notificación a clientes

Planificación:
[ ] Periodo de soporte determinado (min 5 años)
[ ] Fecha de fin de soporte calculada
[ ] Modelo de costes completado
[ ] Dotacion de soporte planificada
[ ] Seguimiento de dependencias establecido

Documentación:
[ ] Periodo de soporte declarado en info del producto
[ ] Proceso de actualización documentado
[ ] Plantillas de Notificación a clientes listas

DURANTE EL PERIODO DE SOPORTE:

Monitorización:
[ ] Monitorización de vulnerabilidades activa
[ ] Actualizaciones de dependencias rastreadas
[ ] Canales de feedback del cliente monitorizados

Respuesta:
[ ] Proceso de triaje de vulnerabilidades
[ ] Flujo de trabajo de desarrollo de parches
[ ] Proceso de pruebas y lanzamiento
[ ] Proceso de Notificación a clientes

Notificación:
[ ] Integración de notificación a ENISA (si explotación)
[ ] Proceso de publicación de avisos
[ ] Seguimiento de métricas de soporte

FIN DE SOPORTE:

Comunicación:
[ ] Aviso con 12 meses de anticipacion enviado
[ ] Recordatorio de 6 meses enviado
[ ] Aviso final en fin de soporte
[ ] documentación actualizada

Transición:
[ ] Ruta de actualización documentada
[ ] Actualización de seguridad final lanzada
[ ] Canales de soporte redirigidos
[ ] Expediente técnico archivado (retención 10 años)

Guías relacionadas

• Planificación de Fin de Vida CRA: Transiciones de Producto Responsables
• Estimación de Costes de Cumplimiento CRA
• Guía del Expediente Técnico CRA (Anexo VII)

Cómo ayuda CRA Evidence

CRA Evidence proporciona gestión del período de soporte:

• Seguimiento del ciclo de vida de versiones: Fechas de comercialización, fechas de fin de soporte
• Monitorización de dependencias: Alertas de vulnerabilidades basadas en SBOM
• Notificación a clientes: Plantillas y seguimiento de distribución
• Documentación: Registros de fin de soporte para expediente técnico
• Dashboard de cumplimiento: Estado del período de soporte entre productos

Planifica tus periodos de soporte con craevidence.com.

Este artículo es solo para fines informativos y no constituye asesoramiento legal. Para orientación específica sobre cumplimiento, consulta con asesores legales cualificados.