Planificación del Periodo de Soporte CRA: 5 años de Actualizaciones de Seguridad (Y Lo Qué Realmente Significa)

Cinco años. Ese es el mínimo Qué 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 Qué realmente significa el requisito del periodo de soporte, Cómo planificarlo y Cómo manejar la inevitable transicion de fin de soporte.

Lo Qué el CRA Realmente Requiere

El Articulo 13 y el Anexo I establecen las obligaciones del periodo de soporte:

Duracion Minima

5 años desde Qué el producto se coloca en el mercado de la UE, O la vida util esperada del producto, lo Qué sea menor.

"Vida util esperada del producto" se determina por:

• Expectativas razonables del cliente basadas en la naturaleza del producto
• Cómo se usan tipicamente productos similares
• Lo Qué comunicas sobre el producto

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

Lo Qué Debes Proporcionar

Durante el periodo de soporte, debes:

1. Abordar vulnerabilidades sin demora

   • Proporcionar parches de seguridad para vulnerabilidades conocidas
   • Priorizar segun severidad
   • No esperar a "la proxima version mayor"

2. Entregar actualizaciones de forma segura

   • Actualizaciones automaticas donde sea tecnicamente posible
   • Distribucion segura (firmadas, verificadas)
   • Capacidad de rollback si las actualizaciones fallan

3. Notificar a clientes

   • Informar sobre actualizaciones de seguridad disponibles
   • Proporcionar instrucciones claras de instalacion
   • Comunicar informacion 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

¿Cuando Empieza el Reloj?

El periodo 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 especifica se envia

Esto crea riesgo de inventario: Si tu producto permanece en distribucion durante 18 meses antes de venderse, el soporte aun termina 5 años desde la colocacion 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 obligacion de parchear v1.0
          → Cliente tiene 18 meses de producto sin soporte

Mejor práctica: Rastrea fechas de comercializacion por version de producto, no por unidad.

Requisitos de Entrega de Actualizaciones

Actualizaciones Automaticas (Preferido)

Donde sea tecnicamente factible y apropiado, el CRA espera actualizaciones de seguridad automaticas:

REQUISITOS DE ACTUALIZACION AUTOMATICA:

Tecnico:
- Canal de descarga seguro (TLS, paquetes firmados)
- Verificación de integridad antes de instalacion
- Capacidad de rollback si la actualizacion falla
- Manejo 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 actualizacion debe ser visible para el usuario

Notificación:
- Informar al usuario cuando las actualizaciones estan disponibles
- Explicar Qué aborda la actualizacion
- Proporcionar instrucciones de instalacion si es manual

Actualizaciones Manuales (Cuando Automatico No Es Posible)

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

Para estos:

• Proporcionar paquetes de actualizacion descargables
• Versionado claro y registro de cambios
• Documentación de instalacion
• Metodo de Verificación (checksums, firmas)
• Notificación via canales disponibles (email, portal web, aviso fisico)

Firma de Actualizaciones

Todas las actualizaciones de seguridad deben estar firmadas criptograficamente:

REQUISITOS DE FIRMA DE ACTUALIZACIONES:

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

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

Respuesta a Vulnerabilidades Durante el Periodo de Soporte

El periodo de soporte no es solo tener actualizaciones disponibles. Es responder a vulnerabilidades a medida Qué se descubren.

Expectativas de Respuesta

Estos no son plazos obligatorios del CRA, pero reflejan expectativas de la industria y lo Qué los reguladores consideraran "sin demora."

Seguimiento de Vulnerabilidades

Necesitas un proceso para:

1. Recepcion de descubrimiento

   • Política CVD y punto de contacto
   • Pipeline de descubrimiento interno
   • Monitoreo de dependencias

2. Evaluación

   • ¿Afecta la vulnerabilidad a nuestro producto?
   • ¿Qué versiones estan afectadas?
   • ¿Cual es la severidad en nuestro contexto?

3. Remediacion

   • Desarrollar parche
   • Probar parche
   • Lanzar parche

4. Comunicacion

   • Notificar a clientes
   • Publicar aviso (si apropiado)
   • Reportar 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 obligacion, mas dificil de rastrear
• Vulnerabilidades de SO/plataforma: Puede requerir actualizar o comunicar mitigacion

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

Modelado de Costes para el Periodo de Soporte

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

Costes Fijos (Por Linea de Producto)

Costes Variables (Por Ano 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
- Monitoreo 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 periodo 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 actualizacion/reemplazo

6 meses antes:

• Comunicaciones de recordatorio
• Ultimas actualizaciones de funciones (si las hay)
• Congelacion de Documentación (capturar estado actual)
• Preparar actualizacion de seguridad final

En el fin de soporte:

• Emitir actualizacion 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 Comunicacion 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 despues de [Fecha]
- El soporte tecnico para esta version terminara
- El producto continuara 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]: Ultima actualizacion de funciones
- [Fecha - 1 mes]: Ultima actualizacion de seguridad
- [Fecha]: Fin de soporte

¿Preguntas? Contacta [canal de soporte]

Despues del Fin de Soporte

Tus obligaciones despues del periodo de soporte:

• Mantener expediente tecnico durante 10 años totales (desde ultima unidad comercializada)
• Responder a solicitudes de vigilancia del mercado
• Sin obligacion de parchear nuevas vulnerabilidades

Mejores practicas (voluntarias):

• Mantener contacto de seguridad para Divulgación responsable
• Considerar publicar vulnerabilidades conocidas-pero-no-corregidas
• Mantener infraestructura de actualizacion disponible para emergencias criticas

Soporte Multi-Version

La mayoria de fabricantes tienen multiples versiones del producto en el mercado simultaneamente.

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-Version

Estrategias para minimizar soporte superpuesto:

1. Base de codigo unificada: Compartir codigo entre versiones donde sea posible
2. Proceso de backport: Backports de seguridad automatizados o semi-automatizados
3. Ciclos de lanzamiento mas cortos: Lanzamientos mas frecuentes = ventanas de soporte mas predecibles
4. Deprecacion agresiva: Animar a clientes a actualizar

Consideraciones Especificas de Industria

Dispositivos IoT

• Muchos tienen vidas utiles esperadas de 7-10 años
• Los mecanismos de actualizacion pueden ser limitados
• La alcanzabilidad del cliente es desafiante
• Considera: capacidad de actualizacion remota, monitoreo de heartbeat

Software B2B

• Los clientes enterprise esperan soporte mas 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

Electronica de Consumo

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

Equipos Industriales

• Vidas utiles 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é esta mal: Los clientes no deberian necesitar aceptar nuevas funciones (y potenciales nuevos bugs) para obtener correcciones de seguridad.

Solucion: Mantener track de actualizaciones solo-seguridad para versiones soportadas.

Ignorar Actualizaciones de Dependencias

Problema: El codigo del producto se mantiene pero las dependencias se pudren.

Por Qué esta mal: La mayoria de vulnerabilidades vienen de dependencias.

Solucion: Incluir actualizaciones de dependencias en tu alcance de mantenimiento de seguridad.

Sin Verificación de Actualizaciones

Problema: Las actualizaciones estan disponibles pero los clientes no pueden verificar autenticidad.

Por Qué esta mal: Los atacantes pueden distribuir "actualizaciones" falsas.

Solucion: Firmar todas las actualizaciones, publicar procedimientos de Verificación.

Fin de Soporte No Claro

Problema: El soporte simplemente... se detiene. Sin comunicacion.

Por Qué esta mal: Los clientes quedan con productos vulnerables Qué no saben Qué no tienen soporte.

Solucion: 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é esta mal: El soporte se convierte en centro de coste Qué consume margenes.

Solucion: Modela costes de soporte antes de fijar precios. Considera el soporte Cómo 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 codigo
[ ] 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 actualizacion documentado
[ ] Plantillas de Notificación a clientes listas

DURANTE EL PERIODO DE SOPORTE:

Monitoreo:
[ ] Monitoreo de vulnerabilidades activo
[ ] 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

Reporte:
[ ] Integración de reporte a ENISA (si explotacion)
[ ] Proceso de publicacion de avisos
[ ] Seguimiento de metricas de soporte

FIN DE SOPORTE:

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

Transicion:
[ ] Ruta de actualizacion documentada
[ ] Actualizacion de seguridad final lanzada
[ ] Canales de soporte redirigidos
[ ] Expediente tecnico archivado (retencion 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 gestion del periodo de soporte:

• Seguimiento del ciclo de vida de versiones: Fechas de comercializacion, fechas de fin de soporte
• Monitoreo de dependencias: Alertas de vulnerabilidades basadas en SBOM
• Notificación a clientes: Plantillas y seguimiento de distribucion
• Documentación: Registros de fin de soporte para expediente tecnico
• Dashboard de cumplimiento: Estado del periodo de soporte entre productos

Planifica tus periodos de soporte con app.craevidence.com.

Este articulo es solo para fines informativos y no constituye asesoramiento legal. Para orientacion especifica sobre cumplimiento, consulta con asesores legales cualificados.