Technology, Media and Telecommunications (TMT)

La Comisión Europea publica nuevas directrices sobre el Reglamento de Ciberresiliencia

Publicado el 23 de septiembre de 2026

Bruselas publica pautas operativas y herramientas para facilitar el cumplimiento del CRA en las empresas europeas

Data structure abstract

El marco regulatorio de la Unión Europea en materia de seguridad digital dio un paso definitivo con la entrada en vigor, en diciembre de 2024, del Reglamento de Ciberresiliencia (Reglamento (UE) 2024/2847) −conocido como Cyber Resilience Act o "CRA"−. Esta normativa horizontal establece requisitos obligatorios de ciberseguridad a lo largo de todo el ciclo de vida de los productos con elementos digitales comercializados en el mercado único, abarcando desde dispositivos del Internet de las Cosas (IoT) de consumo hasta soluciones de software complejo y equipos de red industrial. Para mitigar la incertidumbre jurídica y facilitar una aplicación homogénea por parte del tejido empresarial, la Comisión Europea aprobó el 27 de julio de 2026 las orientaciones oficiales previstas en el artículo 26 del reglamento.

El documento, elaborado tras amplias consultas públicas y debates con el grupo de expertos en ciberseguridad de productos digitales, consta de unas 80 páginas estructuradas para responder a las dudas operativas más recurrentes de los fabricantes. Esta iniciativa se enmarca dentro de la agenda de simplificación administrativa de la Comisión, alineándose con el Ómnibus Digital presentado en noviembre de 2025 para prevenir cargas burocráticas desproporcionadas. La guía presta una atención prioritaria a las microempresas y a las pequeñas y medianas empresas (PYME), incorporando 67 ejemplos prácticos, casos de uso y diagramas explicativos que traducen los mandatos legales en pautas operativas concretas.

Delimitación precisa del alcance

Uno de los apartados de mayor calado técnico en las orientaciones aprobadas radica en la delimitación del alcance material del CRA, especialmente en relación con las soluciones de procesamiento de datos en remoto y el software libre y de código abierto. La rápida evolución de las arquitecturas híbridas en la nube exigía clarificar hasta qué punto los componentes lógicos situados fuera del dispositivo físico se encuentran sometidos al régimen de requisitos esenciales del Anexo I del reglamento.

La Comisión aclara la situación del procesamiento de datos en remoto y las soluciones en la nube, estableciendo un test tripartito: el servicio queda sujeto al reglamento si el procesamiento se realiza de forma remota, su ausencia impediría al producto ejecutar una de sus funciones y el software fue diseñado bajo la responsabilidad del fabricante. Respecto al software libre y de código abierto, se detalla un régimen aligerado en el cual el software desarrollado fuera del ámbito mercantil queda excluido, activándose las obligaciones únicamente cuando existe una actividad comercial traducida en cobro de precios, monetización de servicios conexo o solicitudes de datos personales por razones distintas a la mejora de la seguridad, compatibilidad o interoperabilidad del software.

Evaluación de riesgos de ciberseguridad 

El CRA exige a los fabricantes llevar a cabo una evaluación de riesgos de ciberseguridad, con el fin de identificar los riesgos relevantes, evaluar su impacto potencial sobre el producto e implementar las medidas necesarias para abordarlos. A diferencia de lo que ocurre en la gestión de riesgos organizativos, donde los riesgos se evalúan atendiendo a los criterios internos de riesgo de la propia empresa, el CRA exige que el riesgo residual de ciberseguridad se evalúe en función del nivel de seguridad adecuado del producto, teniendo en cuenta su propósito y su uso razonable previsible. 

Las orientaciones son taxativas a este respecto: ni la tolerancia interna al riesgo del fabricante ni su estrategia comercial constituyen justificación válida para dejar un riesgo identificado sin tratar. En la misma línea, la Comisión descarta expresamente la transferencia de responsabilidad en materia de ciberseguridad a los usuarios o a terceros como vía para suplir deficiencias de diseño. La obligación de comercializar un producto seguro y acreditar la conformidad con el CRA recae, en todo caso, sobre el fabricante.

Las orientaciones introducen asimismo una simplificación de alcance práctico notable para fabricantes con líneas de productos similares. Cuando distintas variantes comparten arquitectura, diseño relevante para la seguridad y propósito previsto, y están expuestas a los mismos riesgos de ciberseguridad, el fabricante puede apoyarse en una única evaluación de riesgos, un único conjunto de documentación técnica y un único procedimiento de evaluación de conformidad para cubrir el conjunto de variantes −siempre que las diferencias entre ellas no sean relevantes para la ciberseguridad del producto−.

Dinámica del ciclo de vida: modificaciones sustanciales y periodo de soporte

Otro de los bloques centrales de la guía aborda cuándo una modificación de un producto ya comercializado obliga a repetir la evaluación de la conformidad. Siguiendo el considerando 39 y el artículo 3.30 del reglamento, la Comisión aclara que una modificación es "sustancial" cuando altera el nivel de riesgo de ciberseguridad de un modo que el fabricante no había contemplado en su evaluación de riesgos inicial , o bien cuando modifica el uso previsto del producto para el que fue evaluado. El criterio relevante no es la magnitud técnica del cambio, sino su impacto sobre el perfil de riesgo: nuevos vectores de ataque, nuevos escenarios de amenaza o una variación en la probabilidad o el impacto de un incidente.

En este sentido, la guía aporta certidumbre para un caso especialmente frecuente: las actualizaciones de seguridad no constituyen, por regla general, una modificación sustancial, siempre que no alteren la finalidad prevista del producto ni introduzcan nuevos riesgos, puesto que su propósito es precisamente reducir el riesgo existente. Cuando sí se produce una modificación sustancial, el producto se considera "nuevamente puesto en el mercado" y, si el cambio lo introduce un operador distinto del fabricante original, este asume las obligaciones de fabricante respecto de la parte modificada.

Sobre el periodo de soporte −el tiempo durante el cual deben gestionarse las vulnerabilidades del producto−, la guía confirma que los cinco años previstos en el artículo 13.8 constituyen el mínimo legal exigible para productos cuya vida útil prevista alcance ese umbral. Para los demás, el periodo debe calibrarse en función del tiempo durante el que el producto pueda razonablemente permanecer en uso: será inferior a cinco años cuando la vida útil del producto sea más breve, y deberá superarlos cuando su vida útil previsible así lo exija.

Comentario Osborne Clarke

La publicación de las primeras orientaciones de la Comisión Europea sobre la aplicación del CRA constituye un hito relevante en el proceso de maduración regulatoria del reglamento, al ofrecer a los operadores económicos un marco interpretativo concreto sobre algunas de las cuestiones que mayor incertidumbre habían generado desde su entrada en vigor. Si bien las orientaciones carecen de carácter vinculante, su valor práctico es indudable: por primera vez, los fabricantes cuentan con criterios oficiales sobre cómo entender conceptos clave del reglamento, como la delimitación del perímetro del producto en entornos cloud, el alcance de la evaluación de riesgos y el software libre y de código abierto, lo que reduce significativamente la inseguridad jurídica asociada al cumplimiento.

En este contexto, conviene no perder de vista el calendario de aplicación: las obligaciones de notificación de vulnerabilidades e incidentes son exigibles desde el 11 de septiembre de 2026, mientras que el grueso de los requisitos esenciales de ciberseguridad no será plenamente aplicable hasta el 11 de diciembre de 2027.

* This article is current as of the date of its publication and does not necessarily reflect the present state of the law or relevant regulation.

Interested in hearing more from Osborne Clarke?