Período de soporte CRA: vincula la fecha final a una decisión documentada

El Reglamento de Ciberresiliencia exige determinar un período de soporte para productos con elementos digitales. No es un campo «EOL» rellenado después de los hechos. La decisión determina, entre otras cosas, cuánto debe continuar la gestión eficaz de vulnerabilidades; su fundamento debe incluirse en la documentación técnica.

Como regla general, el período es de al menos cinco años. Si se prevé utilizar el producto menos de cinco años, corresponde a ese tiempo de uso previsto.

Criterios del CRA

El fabricante debe considerar en particular:

• expectativas razonables de usuarios;
• naturaleza del producto;
• finalidad prevista;
• legislación pertinente de la UE que determine la vida útil.

El CRA permite también considerar:

• períodos de productos con funciones similares;
• disponibilidad del entorno operativo;
• períodos de componentes integrados de terceros con funciones esenciales;
• orientaciones pertinentes de la Comisión y ADCO.

Los criterios deben aplicarse proporcionalmente.

No empieces por la fecha

Un proceso débil empieza así:

«Pongamos cinco años porque lo dice CRA».

Uno más sólido empieza por supuestos:

1. ¿Cuánto tiempo esperarán razonablemente los usuarios utilizar el producto?
2. ¿Cuánto tiempo puede darse soporte a dependencias esenciales?
3. ¿Cuál es el ciclo de vida del hardware o entorno operativo?
4. ¿Se utiliza en un entorno industrial u otro donde la vida práctica es mayor?
5. ¿Qué compromisos derivan de contratos y otra legislación aplicable?
6. ¿Puede mantenerse de forma realista el proceso de actualizaciones de seguridad durante ese período?

Aprueba la fecha final solo después de considerar estas preguntas.

Evidencias de la decisión

Un registro mínimo puede incluir:

Campo	Ejemplo de contenido
Producto / versión	identificación única
Fecha de decisión	cuándo se aprobó el período
Fecha final	al menos mes y año
Tiempo previsto de uso	supuesto + fuente
Expectativas de usuarios	contratos, datos del producto, evidencias de mercado
Dependencias esenciales	períodos de soporte de terceros
Entorno operativo	sistemas/plataformas necesarios
Fundamento jurídico/orientaciones	fuentes utilizadas
Aprobador	persona/función responsable
Fecha de revisión	cuándo comprobar otra vez los supuestos

Los usuarios necesitan una fecha final clara

El artículo 13 exige indicar la fecha final del soporte, al menos mes y año, de manera clara y comprensible al comprar, fácilmente accesible y, cuando proceda, en producto, embalaje o formato digital.

Conecta una decisión interna de ciclo de vida con comunicación del producto. Si difieren las fechas en documentación técnica, precios, interfaz y contrato, el problema aparecerá en operaciones normales con clientes mucho antes de auditar.

El período de soporte es compromiso operativo, no solo fecha

Durante ese período, el fabricante debe gestionar eficazmente vulnerabilidades según CRA. El registro debe conectarse por tanto con:

• política de divulgación coordinada de vulnerabilidades;
• triaje y corrección de vulnerabilidades;
• versiones de seguridad;
• componentes de terceros;
• comunicación al usuario;
• monitorización del fin de soporte.

CRA contiene también requisitos de disponibilidad continuada de actualizaciones de seguridad emitidas y conservación documental durante períodos definidos. El ciclo de vida no puede reducirse a un campo de CRM o catálogo.

Cómo gestiona Pulsar la decisión

Pulsar puede conservar decisión, fundamento, personas responsables, acciones y evidencias y conectarlos con riesgos y documentación. En revisiones posteriores se ve qué cambió desde la decisión previa sin reconstruir el fundamento original.

No significa que Pulsar decida autónomamente el período correcto. Supuestos y aprobación siguen siendo responsabilidad del fabricante.

Consulta Pulsar GRC en un ciclo de decisión

Orientaciones relacionadas

• Documentación técnica CRA
• SBOM y dependencias del producto
• Volver a la guía CRA

Método propuesto: justificar soporte antes de comprometer una fecha comercial

Imagina un fabricante de un equipo conectado que espera venderlo a instalaciones industriales. El área comercial quiere anunciar cinco años de soporte porque parece una cifra sencilla. Ingeniería observa que una dependencia esencial dejará de mantenerse antes. Los clientes, en cambio, utilizan equipos semejantes durante períodos más largos. El expediente debe resolver esta diferencia antes de publicar la promesa, no cuando el primer cliente pregunta por una corrección.

Empieza por describir el uso esperado. Identifica quién instala el producto, con qué frecuencia se sustituye y qué función desempeña. Los datos disponibles pueden incluir contratos, información del producto y experiencias documentadas de usuarios. Distingue evidencia existente de una estimación comercial. Si el producto es nuevo, reconoce la incertidumbre y explica cómo se revisará; no inventes una duración de uso para justificar la fecha más cómoda.

Después, prepara un mapa de dependencias esenciales. Para cada una, registra el responsable de mantenimiento, el período anunciado, la fuente y la fecha de comprobación. Una dependencia sin soporte suficiente crea una decisión de diseño o aprovisionamiento. Puede exigir reemplazo, mantenimiento propio permitido o cambios en el producto. No basta trasladar al cliente el problema mediante una nota de condiciones generales.

Diferencia uso previsto, soporte y disponibilidad de actualizaciones

Estos conceptos se relacionan, pero no deben quedar reducidos a una sola fecha. El uso previsto ayuda a fundamentar el período. El soporte determina la gestión de vulnerabilidades que debe mantenerse conforme al reglamento. La disponibilidad de actualizaciones ya emitidas y la conservación de documentación tienen reglas propias. La persona que revisa debe contrastar cada obligación con el texto vigente y las orientaciones aplicables.

Para evitar confusión, utiliza campos separados en el registro del producto. Explica qué evento inicia cada período, qué obligación cubre y qué fuente utiliza. Si un sistema comercial solo admite una fecha de fin, conserva el fundamento detallado en el expediente y define cómo se transmite la información correcta al usuario. Simplificar una interfaz no permite simplificar una obligación.

Revisa también las familias de versiones. Una rama nueva no borra automáticamente los compromisos de una versión anterior que sigue utilizada. El inventario debe mostrar qué versiones mantienen usuarios, qué canales reciben correcciones y qué condiciones de migración existen. Si una migración exige cambiar hardware o interrumpe una función, esa dependencia requiere atención específica.

Construye una previsión de recursos sin prometer ahorros

Una decisión defendible considera la capacidad de mantener el producto. Estima actividades: recepción de avisos, triaje, análisis de componentes, correcciones, pruebas, publicación y comunicación. Asigna responsables y sustitutos. Las cifras son una previsión interna, no una garantía de coste ni de rentabilidad. Documenta los supuestos para que dirección entienda qué cambia si crecen usuarios o ramas soportadas.

La previsión debe incluir dependencias operativas que suelen olvidarse. Por ejemplo, conservar un entorno de compilación reproducible, acceso a dispositivos de prueba, procedimientos de firma y personas capaces de mantener código antiguo. Si solo un empleado sabe publicar una actualización, existe un riesgo de continuidad. El tratamiento puede combinar documentación, formación y ensayos de sustitución; no se resuelve únicamente añadiendo una fecha al catálogo.

Evalúa además los cambios de proveedor. Un contrato que termina antes del soporte comprometido puede afectar a una función remota necesaria. Registra qué alternativa existe, cuánto trabajo exige y quién autoriza la transición. Cuando no haya una respuesta viable, eleva el problema antes de seguir comercializando bajo supuestos incompatibles.

Comprueba coherencia en todos los puntos de comunicación

Selecciona un producto y compara la fecha del expediente con la página comercial, instrucciones, contrato y canal de soporte. Comprueba que todos se refieren a la misma variante y que la información es comprensible al comprar. Guarda la revisión como evidencia, con fecha y persona responsable. Una captura aislada sin contexto puede demostrar un texto, pero no su correspondencia con el producto suministrado.

Si cambia la fecha o el fundamento, define una revisión de comunicaciones. Identifica usuarios afectados, contenido a actualizar y responsable. Conserva las versiones anteriores para explicar qué se anunció en cada momento. No sustituyas silenciosamente una promesa comercial por otra y des por resuelto el problema. El efecto sobre contratos y obligaciones necesita una evaluación propia.

Un ensayo útil consiste en pedir al equipo de atención que responda: «¿Hasta cuándo recibiré soporte de seguridad para este producto concreto?». Debe utilizar una fuente vigente, distinguir modelo y versión cuando sea necesario y saber cuándo escalar una duda. Si la respuesta depende de preguntar al desarrollador que creó el producto, falta un proceso accesible.

Revisa supuestos cuando cambia el ciclo de vida

La revisión puede activarse por un nuevo sistema operativo, una dependencia abandonada, un cambio de hardware o información sobre uso real. Registra el desencadenante y qué parte de la decisión afecta. No es necesario rehacer todo el expediente si una actualización concreta resuelve la diferencia; sí es necesario demostrar que se evaluó su alcance.

Mantén una lista de acciones abiertas relacionada con el soporte: sustitución de componente, adaptación del entorno de prueba, actualización de instrucciones o revisión contractual. Cada acción debe tener un resultado verificable. «Hablar con el proveedor» describe actividad; «obtener y revisar su período de mantenimiento para la versión utilizada» define una salida.

Criterios de aceptación de un expediente de soporte

Otra persona debe poder identificar producto, fundamento de duración, dependencias críticas, fecha comunicada y capacidad de mantenimiento. Debe encontrar las decisiones y comprobar que las fuentes estaban vigentes cuando se aprobaron. Si falta evidencia de expectativas de uso, la carencia se señala expresamente. Un campo lleno no elimina incertidumbre.

Pulsar puede organizar ese expediente y sus acciones. La aprobación final sigue en manos del fabricante. La asistencia de IA puede ayudar a comparar documentos aportados, pero no debe decidir por sí sola cuánto soporte corresponde ni transformar una limitación de presupuesto en una excepción legal. El valor está en dejar visible la decisión y sus consecuencias antes de que aparezca un incidente.

Distingue dejar de vender un producto de terminar su soporte. Una decisión comercial de retirar una oferta no demuestra que hayan desaparecido usuarios ni compromisos relativos a unidades ya suministradas. El inventario debe permitir identificar esas versiones y conservar el proceso pertinente de recepción de avisos, corrección y comunicación. La persona competente contrasta las obligaciones aplicables antes de aprobar cualquier cambio de ciclo de vida.

Como ejercicio propuesto, selecciona una variante retirada del catálogo y pide al equipo localizar su fecha comunicada, dependencias esenciales y responsable actual. Comprueba si conserva entorno de mantenimiento y si el canal publicado sigue dirigiendo avisos a una persona disponible. Cuando una tarea necesita presupuesto o una decisión de dirección, registra esa dependencia sin presentar la capacidad como existente. El resultado puede revelar una carencia que no aparece en el inventario de productos comercializados hoy. Mantener este recorrido visible evita confundir un catálogo actualizado con una evaluación completa de soporte de productos todavía utilizados.

Fuentes

• Reglamento (UE) 2024/2847 — artículo 13 y anexo VII
• Comisión Europea — orientaciones CRA, 27 de julio de 2026

Fuentes comprobadas: 12 de septiembre de 2026.

• Pulsar GRC — acceso, aislamiento de datos y exportación (polaco)