Glosario · Ciberseguridad de la UE Cyber Resilience Act (CRA)
Regulación europea de 2024 que establece requisitos de ciberseguridad para los productos con elementos digitales a lo largo de todo su ciclo de vida, plenamente aplicable en 2027.
## Qué hace realmente la Cyber Resilience Act
La Cyber Resilience Act (Reglamento (UE) 2024/2847) es la regulación de la UE que establece requisitos de ciberseguridad para los **productos con elementos digitales**. Adoptada en octubre de 2024, con plena aplicabilidad desde diciembre de 2027, impone obligaciones a los fabricantes a lo largo del ciclo de vida del producto.
Donde NIS2 aborda la ciberseguridad de las organizaciones que operan servicios críticos, la CRA aborda la ciberseguridad de los productos en sí: software, hardware, dispositivos IoT y cualquier producto que contenga componentes digitales.
## Qué significa "productos con elementos digitales"
La CRA cubre un alcance extremadamente amplio. "Productos con elementos digitales" incluye:
- **Productos de software**: sistemas operativos, aplicaciones, bibliotecas de software
- **Hardware con software embebido**: dispositivos IoT, routers, electrodomésticos inteligentes
- **Productos conectados**: cualquier cosa con conectividad de red
- **Componentes y software integrado**: tanto elementos digitales independientes como integrados
El alcance es deliberadamente amplio. El razonamiento de la Comisión: los fallos de ciberseguridad en cualquier producto conectado pueden afectar a la seguridad del ecosistema más amplio.
Se aplican algunas exclusiones estrechas: los productos cubiertos por regulaciones sectoriales específicas de ciberseguridad (dispositivos médicos bajo MDR, automoción bajo marcos específicos) tienen vías alternativas de cumplimiento. El software de código abierto desarrollado en contexto no comercial tiene obligaciones más ligeras.
## Obligaciones esenciales
La CRA impone obligaciones a lo largo del ciclo de vida del producto:
### Obligaciones previas a la comercialización
Antes de poner productos en el mercado de la UE:
- **Evaluación de riesgos**: identificar riesgos de ciberseguridad a lo largo del ciclo de vida del producto
- **Seguridad por diseño**: implementar medidas técnicas y organizativas de seguridad adecuadas
- **Gestión de vulnerabilidades**: establecer procesos para identificar y remediar vulnerabilidades
- **Evaluación de la conformidad**: verificar que el producto cumple los requisitos de la CRA (puede requerir evaluación por terceros para productos de mayor riesgo)
- **Documentación**: documentación técnica completa, incluida la arquitectura de seguridad
- **Marcado CE**: los productos deben llevar marcado CE indicando conformidad
### Obligaciones poscomercialización
Tras la venta:
- **Actualizaciones de seguridad**: proporcionar actualizaciones durante el periodo de soporte (por defecto 5 años, mayor para algunas categorías)
- **Notificación de vulnerabilidades**: reportar vulnerabilidades activamente explotadas a ENISA en 24 horas
- **Notificación de incidentes**: reportar incidentes graves de seguridad a las autoridades
- **Divulgación coordinada de vulnerabilidades**: colaborar con investigadores de seguridad
- **Información a operadores y usuarios**: información clara de seguridad para los usuarios
### Obligaciones continuas
A lo largo del ciclo de vida del producto:
- **Configuración segura por defecto**: línea base mínima de seguridad
- **Mecanismos de autenticación**: autenticación fuerte donde proceda
- **Soporte de cifrado**: para productos que manejan datos sensibles
- **Controles de acceso**: mecanismos de autorización adecuados
- **Registro y supervisión**: registro de eventos relevantes para la seguridad
## Clasificación de productos basada en riesgo
La CRA clasifica los productos en categorías con distintos requisitos de evaluación de la conformidad:
### Categoría por defecto
La mayoría de los productos caen en la categoría por defecto, que requiere autoevaluación de conformidad. Los fabricantes completan la evaluación y aplican el marcado CE.
### Categoría importante (Clase I y Clase II)
Los productos con mayores riesgos de ciberseguridad afrontan requisitos más estrictos:
**Clase I**: productos como sistemas de gestión de identidad, gestores de contraseñas, software antivirus, herramientas de seguridad de red, hipervisores genéricos y soluciones VPN. Autoevaluación con verificación opcional por terceros.
**Clase II**: sistemas operativos para servidores y estaciones de trabajo, tarjetas inteligentes y cargadores de arranque certificados, sistemas de gestión de claves para infraestructuras críticas. Evaluación obligatoria por terceros.
### Categoría crítica
Los productos con los mayores riesgos requieren la evaluación más exigente, incluidos los productos que apoyan infraestructura crítica y aplicaciones clave de soberanía.
## Estructura sancionadora
Las sanciones de la CRA son sustanciales:
- **Hasta 15 millones de euros o el 2,5 % de la facturación anual mundial** (lo que sea mayor) por incumplimiento de los requisitos clave
- **Hasta 10 millones de euros o el 2 % de la facturación** por incumplimiento de otras obligaciones
- **Hasta 5 millones de euros o el 1 % de la facturación** por suministrar información incorrecta o engañosa
Para pymes, las multas se limitan a umbrales proporcionalmente más bajos.
## Por qué la CRA importa para la tecnología europea
La CRA crea implicaciones significativas:
### Los productos de software pasan a ser productos regulados
Históricamente, el software ha estado regulado de forma menos rigurosa que los productos físicos con elementos digitales. La CRA cambia esto: los productos de software afrontan requisitos básicos de ciberseguridad similares a los del hardware.
Para las empresas europeas de software, esto crea sobrecoste de cumplimiento pero también oportunidad competitiva. Las empresas europeas que incorporen el cumplimiento CRA en la arquitectura desde el principio tienen ventajas frente a la adaptación retroactiva.
### Tratamiento del código abierto
La CRA incluye disposiciones que reducen la carga sobre el software de código abierto desarrollado en contexto no comercial. Las distribuciones de código abierto comerciales y las empresas que utilizan componentes de código abierto afrontan obligaciones plenas.
Esto ha sido controvertido. Los defensores de la comunidad de código abierto pidieron un trato más ligero; los defensores de la seguridad pidieron cobertura plena. El marco final exige a los fabricantes que utilicen componentes de código abierto que esos componentes cumplan los requisitos de la CRA al integrarse.
### Reconfiguración del mercado de productos IoT
Los mercados de productos conectados afrontan un sobrecoste de cumplimiento sustancial. Los dispositivos IoT baratos de fabricantes que no puedan o no quieran cumplir saldrán del mercado de la UE. Esto:
- Aumenta los precios de los productos conectados
- Reduce la variedad en el extremo bajo del mercado
- Crea oportunidad competitiva para fabricantes de la UE que construyan productos conformes con la CRA
### Implicaciones en la cadena de suministro de software
Los fabricantes que utilizan componentes de software de terceros deben asegurarse de que esos componentes cumplen los requisitos de la CRA. Esto crea presión en la cadena de suministro:
- Los proveedores de software afrontan obligaciones de cumplimiento ante sus clientes fabricantes
- Los componentes de código abierto utilizados en productos comerciales afrontan un escrutinio más estricto
- Los inventarios de software (SBOM) cobran más importancia
## Calendario y estado actual
Implementación escalonada de la CRA:
- **Diciembre de 2024**: el reglamento entra en vigor
- **Septiembre de 2026**: se aplican las obligaciones de notificación de vulnerabilidades
- **Diciembre de 2027**: aplicabilidad plena de todas las obligaciones
Estamos en fase de transición. Los fabricantes se preparan para la notificación de vulnerabilidades de septiembre de 2026 y el cumplimiento pleno de diciembre de 2027.
## Relación con otras regulaciones de la UE
La CRA encaja en la regulación europea más amplia de ciberseguridad y digital:
**vs NIS2**: NIS2 aborda organizaciones que operan servicios críticos. La CRA aborda productos. Juntos cubren ciberseguridad organizativa y de productos.
**vs Data Act**: la Data Act aborda acceso y portabilidad de datos. La CRA aborda la ciberseguridad de los productos que generan esos datos. Marcos complementarios.
**vs AI Act**: el AI Act aborda los riesgos de los sistemas de IA (seguridad, equidad, derechos fundamentales). La CRA aborda la ciberseguridad de los productos, incluidos los sistemas de IA. Ambos se aplican a productos de IA.
**vs RGPD**: el RGPD aborda la protección de datos personales. La CRA aborda la ciberseguridad de los productos en general. Complementarias en el contexto de datos personales.
Para productos cubiertos por múltiples regulaciones, el cumplimiento requiere mapeo explícito.
## Qué traen 2026-2027
- **Plazo de notificación de vulnerabilidades de septiembre de 2026**: primer hito operativo importante
- **Aplicabilidad plena en diciembre de 2027**: comienza la aplicación integral
- **Primeras grandes acciones de aplicación** probables en 2027-2028
- **Actos de ejecución y normas armonizadas** que continúan desarrollándose
- **Orientación específica del sector** para diversas categorías de productos
La CRA es la regulación de ciberseguridad más ambiciosa de la UE por alcance. La implementación dará forma sustancialmente a los mercados europeos de software y hardware durante 2028 y más allá.
## Qué significa para las empresas europeas
Para las empresas europeas de software y hardware:
### 1. El cumplimiento de la CRA es una característica competitiva
Los productos hechos en la UE con una postura sólida de cumplimiento CRA se posicionan favorablemente frente a alternativas más baratas no conformes. Documenta el trabajo de cumplimiento.
### 2. El uso de código abierto requiere cuidado
El uso de componentes de código abierto en productos comerciales requiere asegurar que esos componentes cumplen los requisitos de la CRA. Audita tu cadena de suministro de software.
### 3. La seguridad por diseño como predeterminada
Construir productos sin una arquitectura de seguridad alineada con la CRA crea deuda técnica que habrá que pagar antes de diciembre de 2027. El nuevo desarrollo de productos debe incorporar los requisitos de la CRA desde el principio.
### 4. SBOM y gestión de vulnerabilidades como requisitos operativos
Los inventarios de software, los procesos de gestión de vulnerabilidades y los programas de divulgación coordinada ya no son opcionales para los productos en el mercado de la UE.
### 5. Los periodos de soporte de actualizaciones importan
Los productos deben soportar actualizaciones de seguridad por periodos por defecto de 5 años. Esto afecta a la economía del ciclo de vida del producto, especialmente para fabricantes IoT que venden dispositivos baratos con periodos de soporte históricamente cortos.
Para los compradores tecnológicos europeos, la CRA crea mejoras estructurales de calidad en los productos disponibles en los mercados de la UE. Los productos conectados baratos pero inseguros estarán menos disponibles; las alternativas correctamente diseñadas serán más competitivas.
¿Te resultó útil?
¡Gracias por tu opinión!