Un router sigue funcionando, pero ya no recibe parches. Una cámara conectada sigue siendo accesible desde Internet aunque su fabricante haya abandonado su software. Estos productos no están necesariamente averiados: se han vuelto difíciles de proteger. El Cyber Resilience Act (CRA), el Reglamento europeo de Ciberresiliencia, pretende cambiar esta situación. Su principio: vender un objeto o un software conectado ya no basta; también hay que organizar su seguridad a lo largo del tiempo. En septiembre de 2026, esta promesa entra en una primera fase operativa, antes de la aplicación general prevista para finales de 2027.
Septiembre de 2026: un primer plazo, no el gran cambio
Adoptado en 2024, el CRA entró en vigor el 10 de diciembre de ese año. Su calendario distingue varias etapas. Las disposiciones relativas a la notificación de los organismos de evaluación de la conformidad se aplican desde el 11 de junio de 2026. Las obligaciones de notificación de vulnerabilidades explotadas activamente y de incidentes graves entran en vigor el 11 de septiembre de 2026. La mayor parte de los requisitos aplicables a los productos lo hará el 11 de diciembre de 2027. Por tanto, sería engañoso presentar todos los dispositivos vendidos al finalizar el verano de 2026 como si ya estuvieran sujetos a la totalidad del marco normativo.
Esta aplicación gradual deja tiempo, pero obliga a anticiparse. Un equipo diseñado hoy puede seguir comercializándose después del plazo general. Sobre todo, crear un equipo de respuesta a vulnerabilidades, inventariar los componentes de software y proteger la distribución de los parches no se hace en unas semanas. El análisis prospectivo es bastante claro: los fabricantes que esperen hasta 2027 para organizarse podrían descubrir que su principal reto no es jurídico, sino técnico y humano.
El producto digital se convierte en una responsabilidad duradera
El texto abarca ampliamente los productos con elementos digitales: software, equipos y componentes cuyo uso previsto o razonablemente previsible implique una conexión directa o indirecta a un dispositivo o a una red. Esto puede afectar tanto a una cerradura conectada como a un sistema industrial. Existen exclusiones, especialmente para determinados productos ya cubiertos por normas sectoriales. No todos los servicios en línea están incluidos automáticamente, pero algunas funciones de procesamiento remoto indispensables para el producto pueden entrar en su ámbito de aplicación.
El cambio central está en el ciclo de vida. El fabricante debe evaluar los riesgos, diseñar un producto con un nivel de ciberseguridad adecuado y gestionar sus vulnerabilidades durante el período de soporte. La seguridad ya no puede limitarse a una auditoría realizada antes del lanzamiento. Se convierte en una actividad continua: recibir una alerta, comprobar qué modelos están afectados, desarrollar un parche, probarlo y permitir después que los usuarios lo instalen sin convertir su equipo en un pisapapeles.
Una vulnerabilidad ya no debe acabar en un buzón de correo olvidado
La historia reciente explica esta prioridad. La vulnerabilidad Log4Shell, divulgada en diciembre de 2021 en la biblioteca Java Log4j, recordó hasta qué punto un componente discreto podía estar presente en multitud de programas. Para corregirla, primero había que saber dónde se utilizaba. El CRA exige, entre otras cosas, documentación sobre los componentes, con una lista de materiales de software en un formato de uso habitual y legible por máquinas. Este inventario no es una garantía absoluta; es una condición para investigar con rapidez.
Otro requisito fundamental es disponer de una política de divulgación coordinada de vulnerabilidades y facilitar su notificación. En la práctica, un investigador no debería tener que recurrir al departamento comercial para advertir de que un termostato expone credenciales. Detrás del punto de contacto debe haber un procedimiento capaz de evaluar el problema, dialogar con quien lo haya comunicado y preparar su subsanación. La verdadera prueba no será tanto la existencia de una dirección de correo electrónico como la capacidad de responder de forma útil.
Notificar con rapidez, sin confundir todos los fallos
A partir del 11 de septiembre de 2026, el calendario normativo prevé una alerta temprana en las 24 horas siguientes a tener conocimiento de una vulnerabilidad explotada activamente, y después una notificación más completa en un plazo de 72 horas. El sistema implica a los CSIRT designados como coordinadores y a ENISA, la Agencia de la Unión Europea para la Ciberseguridad. También se establecen obligaciones para los incidentes graves que afecten a la seguridad del producto. Por tanto, no toda vulnerabilidad descubierta exige automáticamente una alerta reglamentaria en un plazo de 24 horas. Esta distinción evita confundir la gestión cotidiana con una emergencia constatada.
El soporte se convierte en una característica del producto
¿Durante cuánto tiempo debe un fabricante dar soporte a su producto? El reglamento obliga a determinar un período de soporte que tenga en cuenta, entre otros factores, su vida útil prevista. Este período debe ser de al menos cinco años, salvo que se prevea utilizar el producto durante menos tiempo. Pero cinco años no constituyen un límite máximo universal: para los equipos destinados a permanecer mucho tiempo en servicio, puede ser necesario un período superior. El fabricante debe poner la fecha de finalización del soporte claramente a disposición del comprador.
Esta información podría llegar a ser tan decisiva como la autonomía o la capacidad de almacenamiento. ¿Sigue siendo interesante un dispositivo rebajado si su soporte está a punto de terminar? ¿Puede una empresa comprar sensores destinados a funcionar diez años sin conocer su plan de mantenimiento? A largo plazo, los compradores podrían comparar el coste de un uso seguro en lugar de un simple precio de adquisición. Esta evolución sigue siendo una perspectiva de futuro, pero el reglamento ofrece una referencia concreta para plantear la pregunta antes de firmar.
Actualizaciones gratuitas, pero nunca gratuitas de producir
El CRA prevé, en principio, la distribución gratuita de las actualizaciones de seguridad, con una excepción regulada para determinados acuerdos específicos entre profesionales relativos a productos a medida. También exige mecanismos de distribución seguros. El reto no consiste únicamente en publicar un archivo: hay que impedir que un atacante sustituya el parche, informar a los usuarios y facilitar su despliegue. Una actualización de seguridad también debería poder distinguirse, cuando sea técnicamente posible, de una mejora funcional.
Para los fabricantes, esta continuidad tiene un coste: conservar personal especializado, mantener infraestructuras y probar varias generaciones de equipos. Podría favorecer arquitecturas más sencillas y gamas menos dispersas. Por el contrario, un cumplimiento puramente documental dejaría los problemas intactos. El uso de componentes de código abierto tampoco elimina la responsabilidad del fabricante: debe conocer sus dependencias y organizar su seguimiento, sin equiparar a todos los colaboradores voluntarios con fabricantes sujetos a las mismas obligaciones.
La confianza se medirá después del lanzamiento
El CRA no promete productos invulnerables. Establece un marco de conformidad, vigilancia del mercado y sanciones para que la seguridad sea menos opcional. Su eficacia dependerá también de los recursos de las autoridades y de la calidad de las evaluaciones. Para el usuario, las señales tangibles serán sencillas: una fecha de fin de soporte comprensible, alertas útiles y parches realmente disponibles.
¿Y ahora qué? De aquí a la aplicación general de diciembre de 2027, a los fabricantes les conviene tratar el mantenimiento como un componente del producto, presupuestado desde su diseño. Los distribuidores y compradores ya pueden exigir compromisos precisos. Si el reglamento cumple su promesa, la mejor pregunta ya no será solo «¿es seguro hoy?», sino «¿quién cuidará de su seguridad mañana?»
