.png)
TL;DR
La CRA (Cyber Resilience Act) obliga a garantizar la seguridad de todo lo "digital" que se venda en la UE: aplicaciones, firmware, IoT, software.
Requiere seguridad por diseño, parches, SBOM y divulgación de vulnerabilidades a lo largo del ciclo de vida de un producto.
Comienza en diciembre de 2027. ¿Se salta la norma? Multas de más de 15 millones de euros o prohibiciones de comercialización.
Resumen de la tarjeta de puntuación de la Ley de Ciberresiliencia (CRA) de la UE:
- Esfuerzo del desarrollador: Alto (Requiere integrar la seguridad en todo el ciclo de vida del producto: diseño seguro, codificación segura, pruebas rigurosas, implantación de procesos de gestión de vulnerabilidades, provisión de actualizaciones seguras, mantenimiento de SBOM).
- Coste de las herramientas: Moderado a alto (requiere herramientas SDLC seguras - SAST/SCA/DAST, herramientas de generación SBOM, plataformas de gestión de vulnerabilidades, infraestructura de actualización potencialmente 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 línea de base mundial para las expectativas de ciberseguridad de los productos).
- Flexibilidad: Moderada (Define los requisitos esenciales pero permite diferentes vías de evaluación de la conformidad en función de la clasificación del riesgo del producto).
- Intensidad de la auditoría: Moderada a alta (Requiere evaluaciones de conformidad -autoevaluación para productos estándar, evaluación por terceros para productos críticos; las autoridades de vigilancia del mercado harán cumplir la normativa).
¿Qué es la Ley de Ciberresiliencia (CRA) de la UE?
La Ley de Ciberresiliencia (CRA) de la UE es un reglamento 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 atajar el problema generalizado de la inseguridad de los productos de hardware y software y la falta de actualizaciones de seguridad oportunas.
La 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 una 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, etc.
Pilares clave de la CRA:
- Requisitos esenciales de ciberseguridad (Anexo I): Los fabricantes deben garantizar que los PDE cumplen objetivos de seguridad específicos a lo largo de su ciclo de vida. Esto abarca:
- Seguridad por diseño y por defecto: Los productos deben diseñarse, desarrollarse y producirse para garantizar un nivel adecuado de ciberseguridad. Deben entregarse con una configuración segura por defecto.
- Gestión de vulnerabilidades: Los fabricantes deben disponer de procesos para identificar y corregir las vulnerabilidades durante toda la vida útil prevista del producto o un mínimo de cinco años, incluido el suministro de actualizaciones de seguridad "sin demora" y gratuitas.
- 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 accesos no autorizados.
- 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 de 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 la conformidad del fabricante (por ejemplo, marcado CE, documentación) antes de comercializar los productos.
- Gestión y notificación de vulnerabilidades: Los fabricantes deben establecer procesos para gestionar eficazmente las vulnerabilidades e informar a ENISA (Agencia de Ciberseguridad de la UE) de las vulnerabilidades activamente explotadas en un plazo de 24 horas desde que se tiene conocimiento de ellas. También deben informar a los usuarios sobre las vulnerabilidades corregidas y las actualizaciones disponibles.
- Evaluación de la conformidad y marcado CE: Los PDE deben someterse a un proceso de evaluación de la conformidad (que va desde la autoevaluación del fabricante a la certificación por terceros en función de la criticidad del producto) para demostrar su cumplimiento antes de recibir el marcado CE y ser comercializados en la UE.
- Vigilancia del mercado: Designa a las autoridades nacionales de vigilancia del mercado para hacer cumplir la ACC, investigar el incumplimiento e imponer sanciones o exigir la retirada/recuperación del producto.
La CRA entró en vigor a finales de 2024, y la mayoría de las obligaciones serán aplicables 36 meses después (en torno a diciembre de 2027), mientras que las obligaciones de información de los fabricantes se aplicarán antes (en torno a septiembre de 2026).
¿Por qué es importante?
La CRA es una ley histórica con importantes implicaciones:
- Cambia la responsabilidad: Hace recaer la responsabilidad de la seguridad de los productos directamente en los fabricantes, en lugar de dejarla principalmente en manos de los usuarios finales.
- Aumenta la seguridad básica: Establece normas mínimas obligatorias 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 en 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 los atacantes, protegiendo a los usuarios de las filtraciones de datos, las pérdidas económicas y los riesgos para la seguridad.
- Armoniza los requisitos: Crea un conjunto único de normas en toda la UE, que sustituye a los enfoques nacionales potencialmente fragmentados de la ciberseguridad de los productos.
- Impacto mundial: Dado el tamaño del mercado de la UE, la CRA establece efectivamente una norma mundial que influye en los fabricantes de todo el mundo que desean vender productos en Europa.
- Complementa otras normativas: Funciona junto con NIS2 (aseguramiento de servicios críticos), GDPR (protección de 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 del ACC se convertirá en un requisito fundamental para acceder al mercado de la UE.
Qué y cómo aplicar (técnica y política)
La aplicación de la ACC exige integrar sus requisitos esenciales (anexo I) a lo largo de todo el ciclo de vida del producto:
- Diseño y desarrollo seguros (Security by Design):
- Modelado de amenazas: Identifique las amenazas potenciales y diseñe controles de seguridad desde el principio.
- Prácticas de codificación seguras: Formar a los desarrolladores y aplicar normas de codificación segura (por ejemplo, OWASP ASVS, normas de codificación CERT). Utilice herramientas SAST.
- Minimizar la superficie de ataque: Limite las funcionalidades, los puertos abiertos y los privilegios al mínimo necesario.
- Valores predeterminados seguros: Asegúrese de que los productos se entregan con configuraciones seguras (por ejemplo, sin contraseñas por defecto, servicios innecesarios desactivados). Implemente una función de restablecimiento seguro.
- Protección de datos: Aplique el cifrado a los datos en reposo y en tránsito cuando proceda. Proteger la integridad de los datos.
- Control de acceso: Implantar mecanismos robustos de autenticación y autorización.
- Gestión de vulnerabilidades:
- Análisis de componentes (SBOM): Genere y mantenga una lista de materiales de software (SBOM) precisa que identifique todos los componentes (incluidas las bibliotecas de código abierto). Utilice herramientas de SCA para encontrar vulnerabilidades conocidas en las dependencias.
- Pruebas de seguridad: Realización periódica de análisis de vulnerabilidades (SAST, DAST, SCA, IaC), pruebas fuzz y pruebas de penetración durante el desarrollo y después del lanzamiento.
- Proceso de gestión de vulnerabilidades: Establecer procedimientos claros para recibir informes de vulnerabilidad (internos/externos), analizarlos, desarrollar parches y distribuir actualizaciones "sin demora"."
- Parches/actualizaciones: Proporcione actualizaciones de seguridad gratuitas durante el ciclo de vida previsto del producto (mínimo 5 años). Implemente un mecanismo de actualización seguro (por ejemplo, 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. Incluye el SBOM.
- Información al usuario: Proporcione a los usuarios instrucciones claras sobre el uso seguro, la configuración, las actualizaciones y la vida útil del producto.
- Divulgación de vulnerabilidades: establecer una política y un punto de contacto para recibir informes sobre vulnerabilidades; divulgar públicamente las vulnerabilidades corregidas.
- Evaluación de la conformidad:
- Clasificación del riesgo: Determinar si el producto entra en las categorías por defecto, "importante" (Clase I) o "crítico" (Clase II) según el Anexo III.
- Procedimiento de evaluación: Siga el procedimiento requerido (por ejemplo, control interno/autoevaluación por defecto, evaluación/certificación por terceros para clases importantes/críticas).
- Declaración y marcado CE: Redacte una declaración de conformidad de la UE y coloque el marcado CE una vez demostrada la conformidad.
- Obligaciones de notificación:
- Vulnerabilidades explotadas activamente: Informar a ENISA en un plazo de 24 horas desde que se tenga conocimiento de ellas.
- Incidentes significativos: Notificar a ENISA los incidentes que afecten a la seguridad de los productos.
La implantación exige integrar la seguridad en la cultura, los procesos y las herramientas de ingeniería, desde el diseño hasta el mantenimiento.
Errores comunes que hay que 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 sencillo con elementos digitales. El ámbito de aplicación es muy amplio.
- Retrasar la acción: Esperar hasta más cerca de la fecha límite de 2027, subestimando los importantes cambios necesarios en los procesos de diseño, desarrollo, pruebas, gestión de vulnerabilidades y actualización.
- Tratar la seguridad a posteriori: No integrar la seguridad desde la fase de diseño ("seguridad por diseño") y tratar de atornillarla después, lo que resulta menos eficaz y más costoso.
- Gestión inadecuada de la vulnerabilidad: Carecer de procesos o herramientas sólidas (SCA, SAST, DAST) para identificar vulnerabilidades, o no proporcionar actualizaciones de seguridad oportunas y gratuitas para el ciclo de vida requerido.
- Inexactitud/descuido del SBOM: No se genera un SBOM completo ni se mantiene actualizado a medida que cambian los componentes, lo que dificulta la gestión de vulnerabilidades.
- Ignorar los mecanismos seguros de actualización: No disponer de un medio fiable y seguro (como una plataforma OTA robusta) para entregar actualizaciones "sin demora". Es probable que las actualizaciones manuales no sean suficientes.
- Documentación insuficiente: No mantener la documentación técnica requerida, el 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 posteriores a la comercialización para la gestión de vulnerabilidades y las actualizaciones a lo largo del ciclo de vida del producto.
Lo que pueden preguntar los asesores y las autoridades (Enfoque en el promotor)
Los organismos de evaluación de la conformidad (para productos críticos) o las autoridades de vigilancia del mercado podrían formular preguntas relacionadas con los requisitos de las ACC 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 de origen y en los componentes de terceros (SAST, SCA) durante el desarrollo?"
- (Anexo I) Codificación segura: "¿Qué normas de codificación segura se siguen? ¿Cómo se vela por su cumplimiento (por ejemplo, linters, revisiones de código, formación)?"
- (Anexo I) Pruebas de seguridad: "Mostrar pruebas de las pruebas de seguridad (por ejemplo, pruebas de penetración, pruebas fuzz) realizadas antes de la liberación".
- (Anexo I) Actualizaciones seguras: "Describa el mecanismo de 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 de gestión de una vulnerabilidad notificada, desde la admisión hasta la publicación del parche".
- (Anexo I) Configuración segura por defecto: "¿Cómo garantiza el producto una configuración segura de fábrica?".
Exigirán pruebas de las fases de diseño, desarrollo, pruebas y mantenimiento, incluida documentación, informes de herramientas, descripciones de procesos y, potencialmente, acceso a la revisión del código.
Ganancias rápidas para los equipos de desarrollo
Aunque el cumplimiento total de la CRA lleva tiempo, los equipos de desarrollo pueden empezar a sentar las bases:
- Implementar la generación de SBOM: Integre herramientas para generar automáticamente un SBOM como parte del proceso de compilación.
- Integrar SCA y SAST: Asegúrese de que el análisis de la composición del software y las pruebas estáticas de seguridad de las aplicaciones se ejecutan de forma fiable en la canalización CI/CD.
- Adopte un modelo básico de amenazas: Comience a debatir las posibles amenazas durante las reuniones de diseño de nuevas funciones o productos.
- Revise las configuraciones por defecto: Evalúe y refuerce activamente la configuración por defecto de los productos antes de su envío. Elimine las credenciales por defecto.
- Documente el proceso de actualización: Documente claramente el proceso actual de creación y publicación de actualizaciones de software, aunque al principio sea manual.
- Establezca una entrada de vulnerabilidades: Cree una forma sencilla y documentada para que los equipos internos o los investigadores externos informen de posibles vulnerabilidades (por ejemplo, una dirección de correo electrónico o un formulario específico).
Ignore esto y... (Consecuencias del incumplimiento)
El incumplimiento de la ACC puede acarrear graves consecuencias aplicadas por las autoridades nacionales de vigilancia del mercado:
- Multas cuantiosas: Las multas administrativas pueden alcanzar hasta 15 millones de euros o el 2,5% del volumen de negocios total anual del fabricante en todo el mundo durante el ejercicio financiero anterior, si esta cifra es superior, por incumplimiento de los requisitos esenciales. Las infracciones menores conllevan multas de hasta 10 millones de euros/2% o 5 millones de euros/1%.
- Retirada 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 ventas: La comercialización de productos no conformes puede prohibirse o restringirse.
- Daños a la reputación: La divulgación pública de incumplimientos, retiradas 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 ERC bloquea de hecho el acceso de los productos cubiertos a todo el mercado único de la UE.
PREGUNTAS FRECUENTES
¿Qué productos están cubiertos por la CRA?
"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 (independiente, móvil, integrado) y hardware con conectividad (dispositivos IoT, routers, electrodomésticos inteligentes, componentes industriales, etc.). Hay exclusiones específicas (por ejemplo, dispositivos médicos, automóviles, aviación, determinados SaaS).
¿Cuándo se convierten en obligatorios los requisitos de las ACC?
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 ACC (alrededor de diciembre de 2027). Sin embargo, la obligación del fabricante de informar sobre vulnerabilidades e incidentes explotados activamente se aplica antes, 21 meses después de la entrada en vigor (en torno a septiembre de 2026).
¿Se aplica la CRA al software libre y de código abierto (FOSS)?
El software libre independiente desarrollado o suministrado al margen de una actividad comercial suele estar excluido. Sin embargo, el software libre integrado en un producto comercial sí está cubierto, y el responsable es el fabricante del producto final. Los proyectos de software libre 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 (aún se debaten los detalles).
¿Qué es el marcado CE en el contexto de la ACC?
Al igual que ocurre con otras normativas de la UE sobre productos, los fabricantes deben colocar el marcado CE en los PDE conformes para indicar que cumplen los requisitos esenciales de la ACC antes de comercializarlos en la UE. Para ello es necesario superar una evaluación de la conformidad.
¿Qué es un SBOM y por qué es necesario?
Una lista de materiales de software (SBOM, por sus siglas en inglés) es un registro formal que contiene los detalles y las relaciones de la cadena de suministro de varios componentes utilizados en la creació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 la vulnerabilidad a lo largo de la cadena de suministro.
¿Durante cuánto tiempo deben los fabricantes proporcionar actualizaciones de seguridad en virtud de la CRA?
Los fabricantes deben proporcionar actualizaciones de seguridad durante la vida útil prevista del producto o durante un período mínimo de cinco años a partir de la comercialización del producto, según cuál sea el plazo más corto. La vida útil prevista debe tenerse en cuenta durante el diseño. Las actualizaciones deben ser gratuitas y puntuales ("sin demora").
¿Qué relación guarda la ACC con el NIS2 o el GDPR?
- NIS2: se centra en la seguridad de las redes y sistemas utilizados por proveedores de servicios esenciales/importantes. CRA: se centra en la seguridad de los propios productos que puedan utilizar dichos proveedores o consumidores.
GDPR: Se centra en la protección de los datos personales. La CRA se centra en la ciberseguridad de los productos. Un producto seguro con arreglo al CRA ayuda a proteger los datos personales que procesa (en apoyo del GDPR), pero el ámbito del CRA es más amplio que los datos personales. Son partes complementarias de la estrategia de seguridad digital de la UE.
