Cyber Resilience Act: la cuenta atrás real ya ha empezado en Europa

Durante años hemos convivido con una idea bastante cómoda: la ciberseguridad del producto era importante, sí, pero muchas veces seguía tratándose como un añadido, una capa más, algo que se reforzaba cuando aparecía el problema. Un parche por aquí, una actualización urgente por allá, y a seguir.

Ese margen se está acabando.

Con el Cyber Resilience Act, Europa ha decidido meter la seguridad en el corazón del producto digital, desde el diseño hasta el final de su vida útil. Y no hablo solo de grandes fabricantes de hardware o de sistemas industriales. Hablo también de software, dispositivos conectados, actualizaciones, gestión de vulnerabilidades y tiempos de respuesta que ya no van a depender únicamente de la buena voluntad del fabricante.

Lo interesante de este reglamento no es solo su carga jurídica. Lo verdaderamente importante es el cambio de mentalidad que arrastra: la ciberseguridad deja de ser una promesa comercial o un simple criterio de calidad técnica, y pasa a convertirse en una obligación exigible. Ahí está el verdadero salto.

En este artículo vamos a desgranar qué es realmente el Cyber Resilience Act, por qué su calendario importa más de lo que parece y qué consecuencias puede tener para fabricantes, desarrolladores, organizaciones públicas y usuarios. Porque esta vez la cuenta atrás no es teórica. Ya ha empezado.

1. Qué es realmente el Cyber Resilience Act

El Cyber Resilience Act no va de “buenas prácticas” ni de checklists voluntarios. Va de poner reglas obligatorias a los productos con elementos digitales que se venden o se ponen a disposición en el mercado de la UE. Jurídicamente, es el Reglamento (UE) 2024/2847, y su lógica es horizontal: no se queda en un sector concreto, sino que cubre hardware y software con conexión o capacidad de interacción con dispositivos o redes. Entró en vigor el 10 de diciembre de 2024, pero su aplicación fuerte llega en fases: notificación de organismos de evaluación desde el 11 de junio de 2026, obligaciones de reporte desde el 11 de septiembre de 2026 y aplicación principal desde el 11 de diciembre de 2027.

Lo importante, para mí, es entender el cambio de enfoque. Hasta ahora, la UE había regulado muchas capas de la ciberseguridad, pero el CRA ataca un punto especialmente incómodo: el hecho de que demasiados productos digitales llegan al mercado con vulnerabilidades, soporte pobre o actualizaciones irregulares. El reglamento busca justo eso: que la seguridad se incorpore desde el diseño, el desarrollo, la producción y el mantenimiento, y que además el usuario tenga información suficiente para saber qué está comprando y durante cuánto tiempo va a recibir soporte.

2. El alcance: a qué productos afecta de verdad

El concepto clave aquí es el de “product with digital elements”. La Comisión lo resume como un producto de software o hardware, junto con sus soluciones de tratamiento remoto de datos, incluyendo también componentes que se comercializan por separado. Esto es importante porque el CRA no mira solo el aparato físico o la aplicación aislada: también puede alcanzar funcionalidades remotas si son necesarias para que el producto cumpla una de sus funciones.

Dicho de otra forma: si un producto se pone en el mercado y su uso previsto —o razonablemente previsible— implica una conexión lógica o física, directa o indirecta, con un dispositivo o una red, entra en la órbita del CRA. Por eso el reglamento puede abarcar desde software autónomo y firmware hasta routers, sistemas operativos, aplicaciones móviles, dispositivos IoT o componentes hardware. En cambio, un SaaS puramente independiente, desarrollado fuera de la responsabilidad del fabricante de un producto, no es por sí mismo un “producto con elementos digitales” a efectos del CRA; ahora bien, si ese tratamiento remoto de datos forma parte funcional del producto, entonces sí puede caer dentro del alcance.

También conviene despejar una duda frecuente: no todo entra. Quedan fuera, entre otros, productos cubiertos por normativa específica de la UE como los productos sanitarios, los dispositivos médicos de diagnóstico in vitro, ciertos vehículos de motor, productos certificados bajo la normativa de aviación civil, equipos de marina y algunos vehículos de dos o tres ruedas y cuadriciclos excluidos por acto delegado. Además, el CRA no se aplica a productos desarrollados o modificados exclusivamente para fines de defensa o seguridad nacional, ni a los diseñados específicamente para tratar información clasificada. Eso sí: en materias como maquinaria, la lógica no es de exclusión automática, sino de convivencia normativa; un mismo producto puede tener que cumplir tanto el CRA como el Reglamento de Máquinas.

3. El núcleo duro: seguridad a lo largo de todo el ciclo de vida

Aquí está la verdadera sustancia del reglamento. Las obligaciones principales recaen sobre el fabricante, entendido en sentido amplio: quien desarrolla o fabrica el producto, o lo manda desarrollar/fabricar y lo comercializa con su nombre o marca, incluso si lo ofrece gratuitamente. Antes de poner el producto en el mercado, el fabricante debe hacer una evaluación de riesgos de ciberseguridad y usarla como base para implementar los requisitos esenciales. Esa evaluación no se limita al momento del lanzamiento: debe informar la planificación, el diseño, el desarrollo, la producción, la entrega y el mantenimiento.

Además, el fabricante tiene que ejercer diligencia debida cuando integra componentes de terceros, incluidos componentes de software libre que ni siquiera estén sujetos al CRA. Esta parte me parece especialmente relevante porque rompe una excusa clásica del sector: “la vulnerabilidad estaba en una librería externa”. Bajo el CRA, integrar terceros no elimina responsabilidad. De hecho, la propia FAQ de la Comisión deja claro que esa diligencia puede traducirse en revisar el historial de actualizaciones, consultar bases públicas de vulnerabilidades, hacer análisis de composición software, revisar la SBOM del componente cuando exista, o incluso realizar pruebas adicionales como fuzzing, pentesting o análisis de firmware.

Todo eso tiene que quedar reflejado en la documentación técnica. Y si el resultado de la evaluación de conformidad es favorable, el fabricante debe emitir la declaración UE de conformidad, colocar el marcado CE y acompañar el producto de la información necesaria para su uso seguro. Entre esa información debe figurar algo que, a mi juicio, va a ser uno de los grandes puntos de fricción comercial en los próximos años: la fecha de fin del período de soporte.

4. Annex I: lo que Europa le va a pedir al producto

El Anexo I del CRA es el corazón técnico del reglamento. Está dividido en dos bloques. La Parte I se centra en las propiedades del producto: cómo debe estar diseñado, desarrollado y producido para ofrecer un nivel adecuado de ciberseguridad. La Parte II se centra en la gestión de vulnerabilidades durante el período de soporte. La clave no es memorizar cada inciso aislado, sino entender la filosofía general: producto seguro por diseño, superficie de ataque reducida, mecanismos para proteger la confidencialidad, integridad y disponibilidad, y capacidad real de corrección cuando aparezcan fallos.

En la práctica, eso se traduce en obligaciones muy concretas sobre actualizaciones de seguridad. La Comisión aclara que el fabricante debe prever mecanismos para distribuirlas de forma segura y a tiempo; cuando proceda, especialmente en productos de consumo, esas actualizaciones deben poder instalarse automáticamente por defecto, con mecanismo claro de opt-out y posibilidad de aplazamiento temporal. También deben ir acompañadas de mensajes de aviso e información útil para el usuario. Y, salvo excepciones muy concretas para productos a medida en entorno B2B, las actualizaciones de seguridad que corrigen problemas identificados deben facilitarse sin demora y gratuitamente.

5. El período de soporte: una de las piezas más serias del CRA

Aquí ya no vale eso de vender rápido y desaparecer. El fabricante tiene que fijar un support period que refleje el tiempo durante el cual cabe esperar razonablemente que el producto siga en uso, y esa fecha final —mes y año— debe mostrarse de forma clara en el momento de la compra. La Comisión añade un dato muy relevante: el período de soporte será como mínimo de cinco años, salvo que el producto esté razonablemente destinado a usarse menos tiempo; si su vida esperable supera esos cinco años, el soporte también debería prolongarse más allá.

Esto tiene consecuencias muy serias. Un router, un sistema operativo, una herramienta de edición de vídeo o un equipo industrial no encajan bien en una lógica de soporte corto. Y, por tanto, el CRA empuja a los fabricantes a justificar técnicamente por qué un producto tendría un soporte inferior, o a asumir períodos más largos si el uso esperado así lo exige. La FAQ incluso pone ejemplos extremos: una app de rastreo vinculada a una pandemia podría tener una vida útil corta; en cambio, productos industriales o de red suelen requerir horizontes bastante más largos.

Hay otra matización que me parece muy interesante: cuando existen varias versiones de un producto software, el fabricante no siempre estará obligado a mantener todas indefinidamente. Puede concentrar la corrección de vulnerabilidades en la última versión puesta en el mercado, siempre que el usuario pueda pasar a ella gratis y sin tener que asumir costes adicionales de hardware o software. Pero esa flexibilidad no elimina el resto de obligaciones de gestión de vulnerabilidades.

6. Evaluación de conformidad: no todos los productos tienen los mismos controles

Otro error frecuente es pensar que todos los productos van a someterse al mismo nivel de control previo. No es así. La regla general es que muchos productos podrán seguir una autoevaluación del fabricante. La Comisión pone como ejemplos de esa categoría por defecto cosas como chips de memoria, apps móviles, altavoces inteligentes o videojuegos.

Pero cuando el producto entra en las categorías de productos importantes o críticos, la exigencia sube. En productos importantes de clase I, el fabricante solo podrá quedarse en la autoevaluación si ha aplicado normas armonizadas, especificaciones comunes o, en su caso, un esquema europeo de certificación que permita presumir conformidad; si no, necesitará intervención de un notified body. Para los productos importantes de clase II y los críticos, la participación de un tercero es obligatoria, salvo que en el futuro exista un esquema europeo de certificación aplicable que cubra ese supuesto.

Y aquí interesa aterrizarlo con ejemplos porque ayuda mucho a fijar ideas. La Comisión menciona como productos importantes sistemas operativos, antivirus, routers o firewalls; y como críticos, por ejemplo, smart cards, secure elements o smart meter gateways. Además, en noviembre de 2025 la Comisión adoptó el Reglamento de Ejecución (UE) 2025/2392, que concreta la descripción técnica de estas categorías.

7. Las normas armonizadas van a ser decisivas

En el CRA, las normas armonizadas no son un adorno burocrático. Son la vía práctica para demostrar conformidad y beneficiarse de la presunción de conformidad con los requisitos esenciales. Por eso el trabajo de estandarización se ha convertido en una pieza central de la implementación. La Comisión adoptó la solicitud de normalización M/606, con 41 estándares de apoyo al CRA, combinando normas horizontales y verticales o específicas por producto.

La propia hoja de ruta oficial de implementación ya anticipa que los primeros entregables de normalización deberían llegar en Q3 de 2026. Esto, para mí, es importante porque explica por qué 2026 no es un año “de espera”, sino un año de aterrizaje: organismos, fabricantes, laboratorios, autoridades y normalizadores ya están corriendo para que el sistema esté operativo antes de septiembre de 2026 y, sobre todo, antes de diciembre de 2027.

8. El software libre no queda ignorado, pero tampoco se trata igual

El CRA ha intentado hilar fino con el software libre y de código abierto. Si ese software no se pone a disposición en el mercado en el curso de una actividad comercial, queda fuera del reglamento. Ahora bien, la Comisión ha tenido que aclarar muchos matices porque la frontera entre comunidad, sostenibilidad y explotación comercial no siempre es nítida. Precisamente por eso, el 3 de marzo de 2026 publicó un borrador de guía centrado, entre otras cosas, en remote data processing, open source, períodos de soporte e interacción con otras normas de la UE, abriendo consulta hasta el 31 de marzo de 2026.

Además, el CRA introduce la figura del open-source software steward: una persona jurídica que presta apoyo sostenido al desarrollo de productos open source destinados a actividades comerciales y asegura su viabilidad. Estos stewards tienen ciertas obligaciones —por ejemplo, política de ciberseguridad, cooperación con autoridades y ciertas obligaciones de reporte—, pero el resumen oficial de la Comisión subraya que no están sujetos a sanciones por infracciones del CRA.

9. Donde la cuenta atrás ya es real: el régimen de reporte desde septiembre de 2026

Aquí está, en mi opinión, el verdadero motivo por el que hablar del CRA ahora tiene sentido. Desde el 11 de septiembre de 2026, los fabricantes estarán obligados a notificar las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad de sus productos. No habrá que esperar a diciembre de 2027 para eso.

Los plazos son exigentes y están pensados para forzar reacción temprana: 24 horas para el aviso inicial, 72 horas para la notificación principal, y después un informe final en un máximo de 14 días desde que exista una medida correctora o mitigadora para vulnerabilidades explotadas activamente, o dentro de un mes desde la notificación principal en caso de incidente grave. Todo ello se canalizará a través de la CRA Single Reporting Platform, que ENISA debe tener operativa precisamente para esa fecha y con un período previo de pruebas.

Además, este régimen de reporte no se limita a los productos nuevos. La Comisión deja claro que estas obligaciones también afectan a productos con elementos digitales que ya se hubieran puesto a disposición del mercado antes del 11 de diciembre de 2027. Dicho de otra manera: aunque la aplicación plena del reglamento llegue más tarde, el deber de reportar empieza antes y también alcanza al parque ya existente en el mercado.

10. Aplicación, vigilancia y relación con NIS2

Los Estados miembros no son meros espectadores. Deben designar autoridades de notificación para los organismos de evaluación antes del 11 de junio de 2026, y también una o varias autoridades de vigilancia del mercado responsables de hacer cumplir el reglamento. Esas autoridades podrán pedir documentación, evaluar productos y ordenar medidas correctoras o restrictivas cuando detecten riesgos significativos de ciberseguridad.

Yo suelo resumir la relación con NIS2 de una forma muy simple: NIS2 mira a la entidad; el CRA mira al producto. La propia Comisión dice que el CRA complementa a NIS2, y la página oficial de NIS2 recuerda que esa directiva establece un marco común de ciberseguridad para 18 sectores críticos. No compiten entre sí: se solapan en la estrategia europea, pero atacan problemas distintos. Uno busca endurecer la ciberseguridad organizativa y la resiliencia de sectores esenciales; el otro pretende que el software y el hardware lleguen al mercado con menos defectos y con obligaciones claras de soporte, actualización y reporte.

11. La idea de fondo que no conviene perder

Si me quedo solo con lo esencial, diría esto: el CRA obliga a pasar de una cultura de “parchear cuando estalla el problema” a una cultura de responsabilidad continua del fabricante. Riesgo antes del lanzamiento, diligencia con componentes de terceros, documentación técnica, marcado CE, soporte visible, gestión de vulnerabilidades, actualizaciones sin demora, reporte rápido y supervisión pública. No es un reglamento ornamental. Es una reorganización del ciclo de vida del producto digital en clave regulatoria.

Conclusión

Si algo me deja claro el Cyber Resilience Act, es que Europa ya no quiere limitarse a recomendar prudencia técnica o a publicar marcos de buenas prácticas. Ahora exige responsabilidades concretas sobre el producto digital: seguridad desde el diseño, soporte visible, gestión de vulnerabilidades, actualizaciones y trazabilidad. Y, además, con calendario real. El reglamento entró en vigor el 10 de diciembre de 2024, las obligaciones de reporte arrancan el 11 de septiembre de 2026 y la aplicación principal llegará el 11 de diciembre de 2027.

Para mí, ahí está el verdadero giro. Ya no basta con lanzar software o dispositivos al mercado y corregir después sobre la marcha. El CRA obliga a pensar en todo el ciclo de vida del producto, también cuando aparecen vulnerabilidades, cuando toca actualizar y cuando hay que explicar al usuario hasta cuándo va a estar cubierto. Eso cambia la conversación entre fabricantes, distribuidores, desarrolladores, responsables de cumplimiento y también clientes.

Y hay un detalle que no deberíamos infravalorar: el reloj ya corre. Desde septiembre de 2026 entran en juego las obligaciones de notificación, con una Single Reporting Platform que ENISA debe tener operativa para esa fecha. Es decir, la fase en la que “todavía falta mucho” empieza a quedarse atrás.

Mi impresión es que el CRA va a obligar a madurar a una parte del mercado que durante demasiado tiempo ha vivido cómoda con soportes ambiguos, actualizaciones irregulares y cadenas de suministro opacas. Habrá quien lo vea como carga regulatoria. Yo creo que también es una oportunidad para separar a quienes construyen tecnología seria de quienes simplemente la empaquetan deprisa.

Y aquí es donde me interesa leerte.

¿Crees que el Cyber Resilience Act va a mejorar de verdad la seguridad de los productos digitales, o acabará convirtiéndose en otro marco duro de aplicar y fácil de maquillar? ¿Está preparada la industria para asumir soporte prolongado, actualizaciones por defecto y reportes en plazos tan exigentes?

Te leo en comentarios. Me interesa especialmente saber cómo lo ves si trabajas en desarrollo, infraestructura, compliance, ciberseguridad, sector público o fabricación de producto.