.png)
TL;DR
La CRA (Ley de Ciberresiliencia) hace que la seguridad sea obligatoria para todo lo «digital» que se venda en la UE: aplicaciones, firmware, IoT, software.
Requiere seguridad desde el diseño, aplicación de parches, SBOMs y divulgación de vulnerabilidades a lo largo del ciclo de vida de un producto.
Comienza en diciembre de 2027. ¿No cumples? Espera multas de más de 15 millones de euros o prohibiciones de mercado.
Resumen del Cuadro de Mando de la Ley de Ciberresiliencia de la UE (CRA):
- Esfuerzo del desarrollador: Alto (Requiere la integración de la seguridad en todo el ciclo de vida del producto: diseño seguro, codificación segura, pruebas rigurosas, implementación de procesos de gestión de vulnerabilidades, provisión de actualizaciones seguras, mantenimiento de SBOMs).
- Coste de Herramientas: Moderado a Alto (Requiere herramientas SDLC seguras - SAST/SCA/DAST, herramientas de generación de SBOM, plataformas de gestión de vulnerabilidades, y potencialmente infraestructura de actualización segura - plataformas OTA).
- Impacto en el mercado: Muy alto (Obligatorio para casi todos los productos de hardware/software vendidos en la UE; establece una nueva base global para las expectativas de ciberseguridad de los productos).
- Flexibilidad: Moderada (Define requisitos esenciales pero permite diferentes rutas de evaluación de la conformidad basadas en la clasificación de riesgo del producto).
- Intensidad de la auditoría: Moderada a Alta (Requiere evaluaciones de conformidad - autoevaluación para productos estándar, evaluación de terceros para productos críticos; las autoridades de vigilancia del mercado harán cumplir).
¿Qué es la Ley de Ciberresiliencia de la UE (CRA)?
La Ley de Ciberresiliencia de la UE (CRA) es una regulación que establece requisitos armonizados de ciberseguridad para los «productos con elementos digitales» (PDE) disponibles en el mercado de la Unión Europea. Su objetivo es abordar el problema generalizado de los productos de hardware y software inseguros y la falta de actualizaciones de seguridad oportunas.
El CRA se aplica ampliamente a casi cualquier producto de software o hardware que pueda conectarse directa o indirectamente a otro dispositivo o red, con algunas excepciones (por ejemplo, dispositivos médicos, aviación, automóviles ya cubiertos por legislación específica, SaaS a menos que sea crítico). Esto incluye dispositivos IoT de consumo, equipos de red, componentes de control industrial, sistemas operativos, aplicaciones móviles, software de escritorio y más.
Pilares clave de la CRA:
- Requisitos esenciales de ciberseguridad (Anexo I): Los fabricantes deben asegurar que los PDE cumplan objetivos de seguridad específicos a lo largo de su ciclo de vida. Esto cubre:
- Seguridad por Diseño y por Defecto: Los productos deben ser diseñados, desarrollados y producidos para asegurar un nivel adecuado de ciberseguridad. Deben entregarse con una configuración predeterminada segura.
- Gestión de Vulnerabilidades: Los fabricantes deben disponer de procesos para identificar y remediar vulnerabilidades durante toda la vida útil esperada del producto o un mínimo de cinco años, incluyendo la provisión de actualizaciones de seguridad «sin demora» y de forma gratuita.
- Protección de datos: Protección de la confidencialidad, integridad y disponibilidad de los datos procesados por el producto.
- Control de acceso: Prevención de acceso no autorizado.
- Resiliencia: Capacidad para resistir y recuperarse de incidentes.
- Minimizar la superficie de ataque: Limitar las superficies de ataque y mitigar el impacto de los incidentes.
- Obligaciones para los Operadores Económicos:
- Fabricantes: Asumen la responsabilidad principal de garantizar el cumplimiento de la CRA: diseño seguro, evaluación de la conformidad, documentación técnica (incluido el SBOM), gestión de vulnerabilidades, notificación de incidentes/vulnerabilidades, suministro de actualizaciones e instrucciones claras. Esto se aplica incluso si tienen su sede fuera de la UE.
- Importadores/Distribuidores: Tienen la obligación de verificar el cumplimiento del fabricante (por ejemplo, marcado CE, documentación) antes de introducir productos en el mercado.
- Gestión y notificación de vulnerabilidades: Los fabricantes deben establecer procesos para gestionar las vulnerabilidades de forma eficaz y notificar las vulnerabilidades activamente explotadas a ENISA (Agencia de la UE para la Ciberseguridad) en un plazo de 24 horas desde que tengan conocimiento de ellas. También deben informar a los usuarios sobre las vulnerabilidades corregidas y las actualizaciones disponibles.
- Evaluación de Conformidad y Marcado CE: Los PDE deben someterse a un proceso de evaluación de conformidad (que va desde la autoevaluación del fabricante hasta la certificación por terceros, dependiendo de la criticidad del producto) para demostrar el cumplimiento antes de recibir el marcado CE y ser introducidos en el mercado de la UE.
- Vigilancia del mercado: Designa a las autoridades nacionales de vigilancia del mercado para hacer cumplir la CRA, investigar el incumplimiento e imponer sanciones o exigir la retirada/recuperación del producto.
El CRA entró en vigor a finales de 2024, y la mayoría de las obligaciones serán aplicables 36 meses después (alrededor de diciembre de 2027), mientras que las obligaciones de notificación de los fabricantes se aplican antes (alrededor de septiembre de 2026).
¿Por qué es importante?
El CRA es una legislación histórica con implicaciones significativas:
- Traslada la responsabilidad: Recae la responsabilidad de la seguridad del producto directamente en los fabricantes, en lugar de dejarla principalmente en manos de los usuarios finales.
- Eleva la seguridad de referencia: Establece estándares mínimos obligatorios de ciberseguridad para una amplia gama de productos conectados vendidos en la UE.
- Seguridad de la cadena de suministro de software: Aborda las vulnerabilidades originadas por componentes de terceros mediante requisitos como los SBOM y la gestión de vulnerabilidades a lo largo del ciclo de vida.
- Protege a Consumidores y Empresas: Su objetivo es reducir el número de productos inseguros explotados por atacantes, protegiendo a los usuarios de brechas de datos, pérdidas financieras y riesgos de seguridad.
- Armoniza Requisitos: Crea un conjunto único de reglas en toda la UE, reemplazando enfoques nacionales potencialmente fragmentados en materia de ciberseguridad de productos.
- Impacto Global: Dado el tamaño del mercado de la UE, la CRA establece efectivamente un estándar global, influyendo en los fabricantes de todo el mundo que desean vender productos en Europa.
- Complementa otras regulaciones: Funciona junto con NIS2 (asegurando servicios críticos), GDPR (protegiendo datos personales) y DORA (resiliencia financiera) para crear un panorama de ciberseguridad de la UE más completo.
Para los fabricantes de software y hardware conectado, el cumplimiento de la CRA se convertirá en un requisito fundamental para el acceso al mercado en la UE.
Qué y cómo implementar (Técnico y de Políticas)
La implementación del CRA requiere integrar sus requisitos esenciales (Anexo I) a lo largo de todo el ciclo de vida del producto:
- Diseño y desarrollo seguros (Seguridad por diseño):
- Modelado de Amenazas: Identificar amenazas potenciales y diseñar controles de seguridad desde el principio.
- Prácticas de Codificación Segura: Formar a los desarrolladores y hacer cumplir los estándares de codificación segura (p. ej., OWASP ASVS, estándares de codificación CERT). Utilizar herramientas SAST.
- Minimizar la superficie de ataque: Limitar las funcionalidades, los puertos abiertos y los privilegios al mínimo necesario.
- Valores Predeterminados Seguros: Asegurar que los productos se entreguen con configuraciones seguras (p. ej., sin contraseñas por defecto, servicios innecesarios deshabilitados). Implementar funcionalidad de restablecimiento seguro.
- Protección de datos: Implemente cifrado para los datos en reposo y en tránsito cuando sea apropiado. Proteja la integridad de los datos.
- Control de acceso: Implementar mecanismos robustos de autenticación y autorización.
- Gestión de vulnerabilidades:
- Análisis de Componentes (SBOM): Generar y mantener una lista de materiales de software (SBOM) precisa que identifique todos los componentes (incluidas las bibliotecas de código abierto). Utilizar herramientas SCA para encontrar vulnerabilidades conocidas en las dependencias.
- Pruebas de Seguridad: Implementar escaneo de vulnerabilidades regular (SAST, DAST, SCA, IaC), fuzz testing y pruebas de penetración durante el desarrollo y después del lanzamiento.
- Proceso de gestión de vulnerabilidades: Establecer procedimientos claros para la recepción de informes de vulnerabilidades (internos/externos), su análisis, el desarrollo de parches y la distribución de actualizaciones "sin demora".
- Parches/Actualizaciones: Proporcionar actualizaciones de seguridad gratuitas durante el ciclo de vida esperado del producto (mín. 5 años). Implementar un mecanismo de actualización seguro (p. ej., actualizaciones OTA seguras con comprobaciones de integridad).
- Transparencia y documentación:
- Documentación Técnica: Mantener documentación técnica detallada que demuestre el cumplimiento de los requisitos esenciales. Incluir el SBOM.
- Información para el usuario: Proporcione a los usuarios instrucciones claras sobre el uso seguro, la configuración, las actualizaciones y el ciclo de vida del soporte del producto.
- Divulgación de vulnerabilidades: Establecer una política y un punto de contacto para la recepción de informes de vulnerabilidades; divulgar públicamente las vulnerabilidades corregidas.
- Evaluación de la Conformidad:
- Clasificación de Riesgos: Determine si el producto se encuadra en las categorías por defecto, "importante" (Clase I) o "crítica" (Clase II) según el Anexo III.
- Procedimiento de Evaluación: Seguir el procedimiento requerido (por ejemplo, control interno/autoevaluación para clases predeterminadas, evaluación/certificación de terceros para clases importantes/críticas).
- Declaración y Marcado CE: Elabore una Declaración de Conformidad de la UE y coloque el marcado CE una vez demostrada la conformidad.
- Obligaciones de informes:
- Vulnerabilidades explotadas activamente: Informar a ENISA en un plazo de 24 horas desde que se tenga conocimiento.
- Incidentes Significativos: Informar a ENISA sobre incidentes que afecten la seguridad del producto.
La implementación exige integrar la seguridad en la cultura de ingeniería, los procesos y las herramientas desde el diseño hasta el mantenimiento.
Errores comunes a evitar
Los fabricantes que se preparan para la CRA deben evitar estos errores comunes:
- Subestimar el alcance: Creer que la CRA solo se aplica a dispositivos IoT complejos y no a software estándar o hardware más simple con elementos digitales. El alcance es muy amplio.
- Retrasar la Acción: Esperar hasta acercarse a la fecha límite de 2027, subestimando los cambios significativos necesarios en los procesos de diseño, desarrollo, pruebas, gestión de vulnerabilidades y actualización.
- Tratar la seguridad como una ocurrencia tardía: No integrar la seguridad desde la fase de diseño ("Security by Design") e intentar añadirla posteriormente, lo cual es menos efectivo y más costoso.
- Gestión de Vulnerabilidades Inadecuada: Carencia de procesos o herramientas robustas (SCA, SAST, DAST) para identificar vulnerabilidades, o no proporcionar actualizaciones de seguridad oportunas y gratuitas durante el ciclo de vida requerido.
- Inexactitud/Negligencia del SBOM: No generar un SBOM completo o no mantenerlo actualizado a medida que cambian los componentes, lo que dificulta la gestión de vulnerabilidades.
- Ignorar los Mecanismos de Actualización Seguros: No disponer de una forma fiable y segura (como una plataforma OTA robusta) para entregar actualizaciones "sin demora". Las actualizaciones manuales probablemente no serán suficientes.
- Documentación Insuficiente: No mantener la documentación técnica requerida, la SBOM y las pruebas de evaluación de la conformidad necesarias para la vigilancia del mercado.
- Centrarse Únicamente en el Desarrollo: Descuidar los requisitos continuos post-comercialización para el manejo de vulnerabilidades y las actualizaciones a lo largo del ciclo de vida del producto.
Qué podrían preguntar los evaluadores/autoridades (Enfoque en el desarrollador)
Los organismos de evaluación de la conformidad (para productos críticos) o las autoridades de vigilancia del mercado podrían hacer preguntas relacionadas con los requisitos de la CRA que afectan al desarrollo:
- (Anexo I) Diseño Seguro: "¿Cómo se tuvo en cuenta la seguridad durante la fase de diseño? ¿Puede mostrar modelos de amenazas o documentos de arquitectura de seguridad?"
- (Anexo I) Gestión de vulnerabilidades: "¿Qué herramientas y procesos se utilizan para identificar vulnerabilidades en el código propio y en los componentes de terceros (SAST, SCA) durante el desarrollo?"
- (Anexo I) Codificación Segura: "¿Qué estándares de codificación segura se siguen? ¿Cómo se garantiza el cumplimiento (p. ej., linters, revisiones de código, formación)?"
- (Anexo I) Pruebas de Seguridad: "Muestre evidencia de las pruebas de seguridad (p. ej., pruebas de penetración, fuzz testing) realizadas antes del lanzamiento."
- (Anexo I) Actualizaciones Seguras: "Describa el mecanismo para la entrega de actualizaciones de seguridad. ¿Cómo se garantiza la integridad y autenticidad de las actualizaciones?"
- (Art. 10) SBOM: "Proporcione la lista de materiales de software (SBOM) para esta versión del producto."
- (Art. 10) Gestión de Vulnerabilidades: "Describa el proceso para gestionar una vulnerabilidad reportada, desde la recepción hasta el lanzamiento del parche."
- (Anexo I) Configuración Segura por Defecto: "¿Cómo garantiza el producto una configuración segura de fábrica?"
Requerirán evidencia de las fases de diseño, desarrollo, pruebas y mantenimiento, incluyendo documentación, informes de herramientas, descripciones de procesos y, potencialmente, acceso a la revisión de código.
Victorias rápidas para equipos de desarrollo
Aunque el cumplimiento total de CRA lleva tiempo, los equipos de desarrollo pueden empezar a sentar las bases:
- Implementar la generación de SBOM: Integrar herramientas para generar automáticamente una SBOM como parte del proceso de compilación.
- Integrar SCA y SAST: Asegurar que el análisis de composición de software y las pruebas de seguridad de aplicaciones estáticas se ejecuten de forma fiable en la pipeline de CI/CD.
- Adoptar modelado básico de amenazas: Empiece a discutir posibles amenazas durante las reuniones de diseño para nuevas características o productos.
- Revisar Configuraciones por Defecto: Evalúe y refuerce activamente las configuraciones por defecto de los productos antes de su lanzamiento. Elimine las credenciales por defecto.
- Documentar el Proceso de Actualización: Documente claramente el proceso actual para construir y lanzar actualizaciones de software, incluso si es manual inicialmente.
- Establecer un proceso de recepción de vulnerabilidades: Crear una forma sencilla y documentada para que los equipos internos o investigadores externos informen sobre posibles vulnerabilidades (por ejemplo, una dirección de correo electrónico o un formulario dedicado).
Ignora esto y... (Consecuencias del incumplimiento)
El incumplimiento de la CRA puede acarrear graves consecuencias impuestas por las autoridades nacionales de vigilancia del mercado:
- Multas Elevadas: Las multas administrativas pueden ascender hasta 15 millones de euros o el 2,5% del volumen de negocio anual mundial total del fabricante del ejercicio financiero anterior, la cantidad que sea mayor, por el incumplimiento de los requisitos esenciales. Las infracciones menores conllevan multas de hasta 10M/2% o 5M/1%.
- Retirada/Recuperación del mercado: Las autoridades pueden exigir que los productos no conformes sean retirados del mercado de la UE o recuperados de los usuarios finales.
- Prohibición/Restricción de Venta: La comercialización de productos no conformes puede ser prohibida o restringida.
- Daño reputacional: La divulgación pública de incumplimientos, retiradas de productos o vulnerabilidades significativas daña la confianza en la marca y la percepción del mercado.
- Pérdida de acceso al mercado: El incumplimiento de los requisitos de la CRA bloquea eficazmente el acceso a todo el mercado único de la UE para los productos cubiertos.
Preguntas frecuentes
¿Qué productos están cubiertos por la CRA?
Los "productos con elementos digitales" (PDE) cuyo uso previsto o razonablemente previsible incluye una conexión de datos lógica o física directa o indirecta a un dispositivo o red. Esto incluye la mayoría del software (autónomo, móvil, embebido) y hardware con conectividad (dispositivos IoT, routers, electrodomésticos inteligentes, componentes industriales, etc.). Existen exclusiones específicas (p. ej., dispositivos médicos, automóviles, aviación, ciertos SaaS).
¿Cuándo son obligatorios los requisitos de la CRA?
La mayoría de las obligaciones, incluidas las evaluaciones de conformidad y los requisitos esenciales, se aplican 36 meses después de la entrada en vigor del CRA (alrededor de diciembre de 2027). Sin embargo, la obligación de notificación del fabricante para vulnerabilidades e incidentes explotados activamente se aplica antes, 21 meses después de la entrada en vigor (alrededor de septiembre de 2026).
¿La CRA se aplica al software libre y de código abierto (FOSS)?
El FOSS independiente desarrollado o suministrado fuera de una actividad comercial generalmente está excluido. Sin embargo, el FOSS integrado en un producto comercial sí está cubierto, y el fabricante del producto final es responsable. Los proyectos FOSS con estructuras formales (por ejemplo, fundaciones) que monetizan el soporte o las versiones también podrían estar sujetos a algunas obligaciones de la CRA (los detalles aún se debaten).
¿Qué es el marcado CE en el contexto del CRA?
Al igual que otras normativas de productos de la UE, los fabricantes deben colocar el marcado CE en los PDE conformes para indicar que cumplen los requisitos esenciales del CRA antes de introducirlos en el mercado de la UE. Esto requiere una evaluación de conformidad exitosa.
¿Qué es una SBOM y por qué es necesaria?
Una lista de materiales de software (SBOM) es un registro formal que contiene los detalles y las relaciones de la cadena de suministro de varios componentes utilizados en la construcción de software. La CRA exige a los fabricantes que generen y mantengan una SBOM para sus productos con el fin de mejorar la transparencia y facilitar la gestión de vulnerabilidades en toda la cadena de suministro.
¿Durante cuánto tiempo deben los fabricantes proporcionar actualizaciones de seguridad según la CRA?
Los fabricantes deben proporcionar actualizaciones de seguridad durante la vida útil esperada del producto o por un período mínimo de cinco años desde la comercialización del producto, lo que sea más corto. La vida útil esperada debe considerarse durante el diseño. Las actualizaciones deben ser gratuitas y oportunas («sin demora»).
¿Cómo se relaciona la CRA con NIS2 o GDPR?
- NIS2: Se centra en la seguridad de las redes y sistemas utilizados por los proveedores de servicios esenciales/importantes. CRA se centra en la seguridad de los productos en sí mismos que podrían ser utilizados por esos proveedores o consumidores.
GDPR: Se centra en proteger los datos personales. CRA se centra en la ciberseguridad del producto. Un producto seguro bajo CRA ayuda a proteger los datos personales procesados por él (apoyando el GDPR), pero el alcance de CRA es más amplio que solo los datos personales. Son partes complementarias de la estrategia de seguridad digital de la UE.
