Quién responde cuando falla un producto digital

La Unión Europea ha identificado el problema en dos planos. Por un lado, muchos productos digitales no ofrecen un nivel insuficiente de ciberseguridad o no reciben correcciones de seguridad a tiempo. Por otro, compradores y usuarios no siempre tienen información clara para saber qué productos son realmente seguros ni para configurarlos correctamente sin conocimientos especializados. El resultado es una dificultad práctica: incluso las organizaciones que quieren hacer bien las cosas tienen problemas para evaluar, exigir y mantener la seguridad de forma consistente.

Aquí es donde entra el Cyber Resilience Act (CRA), Reglamento (UE) 2024/2847. Este marco fija requisitos de ciberseguridad para los productos con elementos digitales que se comercializan en la Unión Europea y establece obligaciones durante todo su periodo de soporte. No se limita al diseño inicial: también regula cómo deben notificarse las vulnerabilidades explotadas y los incidentes graves, con un procedimiento de notificación definido.

El CRA convierte el mantenimiento seguro en una obligación regulatoria. La Comisión explica que la seguridad debe estar integrada en el producto y mantenerse mediante gestión de vulnerabilidades y actualizaciones durante su vida útil.

Este reglamento se despliega por fases. Se adoptó el 23 de octubre de 2024 y entró en vigor el 10 de diciembre de 2024. El grueso de las obligaciones se aplicará desde el 11 de diciembre de 2027, pero antes de esa fecha se adelantan dos bloques. Las disposiciones sobre notificación de organismos de evaluación de la conformidad se aplicarán desde el 11 de junio de 2026 y las obligaciones de reporte de vulnerabilidades explotadas e incidentes graves desde el 11 de septiembre de 2026.

Cómo se gobierna el mantenimiento

El CRA obliga a tratar la seguridad como una parte estructural del producto y de su gestión. El marco cubre diseño, actualización y mantenimiento con el objetivo de proteger a los usuarios durante todo su uso. Esta idea, trasladada al funcionamiento real del fabricante o empresa que pone el producto en el mercado, obliga a dejar de pensar en el mantenimiento como un servicio accesorio y a gestionarlo como parte del propio producto.

Ese modo de operar exige que las áreas de la empresa se alineen porque las decisiones que afectan a la seguridad no viven en un único departamento. Un parche crítico compite con lanzamientos, mejoras y compromisos comerciales. Una actualización puede exigir pruebas extra para no romper compatibilidades. Y si una corrección depende de un tercero, la rapidez ya no depende solo del equipo interno, también depende del soporte pactado y de la capacidad real de desplegar la medida correctora.

El reglamento busca cerrar una brecha muy concreta. Si el mercado no puede identificar con facilidad qué productos son ciberseguros ni configurarlos bien, no basta con reforzar los mensajes comerciales o añadir más documentación. La diferencia está en que el producto pueda mantenerse seguro en el día a día, con actualizaciones, soporte constante y medidas que el cliente pueda aplicar sin complejidad excesiva. Si ese mantenimiento pasa a ser obligatorio, el fabricante también debe poder demostrar que funciona como un proceso real, no como una promesa.

En ese punto aparece el Reglamento de Ejecución (UE) 2025/2392. Al definir descripciones técnicas y categorías de productos importantes y críticos, obliga a las empresas a traducir esa clasificación en decisiones internas concretas: qué se documenta, qué pruebas se exigen, qué registros se conservan y qué controles se activan.

Desde el punto de vista del buen gobierno, ese mapa interno aterriza responsabilidades y obliga a poder reconstruir decisiones, cambios y correcciones con trazabilidad, soporte y evidencias.

Reportar con plazos 

Las obligaciones de reporte son uno de los primeros hitos operativos que pondrán a prueba a los fabricantes, porque empiezan antes que la aplicación general del reglamento.

El sistema exige un aviso temprano en 24 horas desde que el fabricante tiene conocimiento, una notificación completa en 72 horas y un informe final con plazos distintos según el caso. En vulnerabilidades explotadas, el informe final debe presentarse como máximo 14 días después de que exista una medida correctora. En incidentes graves, el informe final debe presentarse en el plazo de un mes.

Con esos plazos, hace falta criterio para clasificar eventos, un circuito de escalado que funcione con rapidez y una validación que no se bloquee cuando todavía hay incertidumbre técnica. También hace falta consistencia en lo que se comunica, porque el esquema está pensado para operar con hechos trazables y comparables, no con relatos cambiantes.

El canal institucional está igualmente especificado. El reporte se hace a través de la Single Reporting Platform del CRA, conocida como SRP (plataforma única de notificación). La notificación se dirige al CSIRT (Computer Security Incident Response Team, equipo nacional de respuesta a incidentes de ciberseguridad) del país donde el fabricante tiene su establecimiento principal y, salvo casos excepcionales, la información se pone a disposición simultáneamente de ENISA (European Union Agency for Cybersecurity, Agencia de la Unión Europea para la Ciberseguridad).

Además, el CSIRT que recibe inicialmente la notificación la comparte sin demora con otros CSIRT de los Estados miembros donde el producto se ha puesto a disposición.

El sistema prevé situaciones excepcionales en las que la difusión de la información puede retrasarse por motivos justificados de ciberseguridad, conforme a las condiciones que fije un acto delegado. Esa posibilidad plantea un dilema real: compartir información demasiado pronto puede complicar una respuesta en curso, pero retrasarla demasiado puede ampliar el daño.

Gobernar a los terceros como parte del producto

En muchos productos, el software se desarrolla e integra con componentes de terceros. Ese modelo hace que la respuesta ante vulnerabilidades dependa a menudo de actores externos y de su capacidad de soporte. La consecuencia se nota en situaciones muy concretas: una corrección que depende de un tercero con sus propios tiempos, un componente que cambia sin aviso previo, o un soporte que se reduce a correos sin una vía real para elevar el incidente.

En este terreno, el reto no es solo técnico, es contractual y operativo. La relación con proveedores críticos deja de poder basarse en fórmulas genéricas y pasa a necesitar compromisos verificables, como canales de contacto que funcionen en incidentes, tiempos de respuesta definidos, coordinación en la entrega de correcciones y claridad sobre quién asume qué parte del problema cuando hay impacto en clientes. En el momento en que el marco europeo obliga a reportar determinados eventos y a dar seguimiento con informes, lo que no esté previsto en esas relaciones se convierte en fricción interna y en demora externa.

Además, cuando un producto integra componentes externos, cada actualización puede introducir incertidumbre si no existe un mecanismo estable para revisar, probar y autorizar lo que se incorpora. Basta con que una corrección llegue sin contexto suficiente, o que una modificación menor tenga efectos colaterales, para que la organización pierda capacidad de explicar qué ha cambiado y por qué. En un entorno regulado, esa explicación tiene que poder reconstruirse con registros y decisiones trazables.

La clasificación técnica de productos importantes y críticos empuja todavía más en esa dirección. Cuando el marco europeo establece categorías y descripciones técnicas, lo que se está haciendo es elevar el estándar de control esperado en los casos de mayor sensibilidad. Eso obliga a revisar qué dependencias se aceptan, con qué garantías, y qué documentación debe estar lista para sostener la gestión del producto en el tiempo.

Este giro encaja con un contexto europeo en el que la ciberseguridad se está tratando cada vez más como un asunto de coordinación y capacidad institucional, no solo como una responsabilidad aislada de cada compañía. Un análisis del Servicio de Estudios del Parlamento Europeo (EPRS) sobre el marco europeo de ciberseguridad refleja esa expansión regulatoria y la presión asociada a coordinación y recursos.

En la práctica, eso reduce el margen para gestionar dependencias críticas como un simple asunto de compras. Si forman parte del producto, también deben gobernarse como parte del producto.