Guía paso a paso para el cumplimiento de la Ley de Ciberresiliencia (CRA)

Introducción

La Ley de Ciberresiliencia (Reglamento (UE) 2024/2847) es una ley de la Unión Europea que establece normas de ciberseguridad para los productos que incluyen cualquier componente digital, que puede ser hardware o software.

La Ley de Ciberresiliencia (CRA) se basa en un principio: solo se debe permitir la entrada al mercado de la UE de productos que sean seguros.

Para implementar este principio, Artículo 6 El Reglamento establece dos pilares fundamentales de cumplimiento:

1. Los productos deben ser seguros por diseño y uso (Anexo I, Parte I))

Un producto sólo podrá considerarse conforme si:

Cumple con los requisitos esenciales de ciberseguridad enumerados en Anexo I, Parte I.

• Está correctamente instalado, mantenido y actualizado por el usuario u operador.

En otras palabras, el producto debe ser fundamentalmente seguro y seguir funcionando de forma segura cuando se utiliza según lo previsto.

Hay cuatro categorías de productos bajo la CRA, como se detalla a continuación:

• Categoría predeterminadaEsto incluye la mayoría de los productos que no figuran explícitamente en otras categorías (alrededor del 90 % de todos los productos con componentes digitales). Algunos ejemplos son los productos electrónicos de consumo de uso general, como altavoces inteligentes, discos duros y software básico de edición de fotos.
• Productos importantes Clase I:Estos productos realizan funciones críticas para la ciberseguridad, como sistemas de gestión de identidad, navegadores web, administradores de contraseñas, software VPN y dispositivos de seguridad domésticos inteligentes (por ejemplo, cerraduras inteligentes, cámaras).
• Productos importantes Clase II:Esta clase incluye productos de mayor riesgo que la Clase I, como firewalls, sistemas de detección/prevención de intrusiones para uso industrial, hipervisores y microprocesadores a prueba de manipulaciones.
• Productos críticosEstos son los productos de mayor riesgo, considerados críticos porque las entidades esenciales dependen de ellos y su vulnerabilidad podría causar importantes interrupciones. Algunos ejemplos incluyen elementos seguros en tarjetas inteligentes y pasarelas de medidores inteligentes.

2. Los fabricantes deben seguir procesos seguros de desarrollo y ciclo de vida (Anexo I, Parte II)

El cumplimiento no se trata solo del dispositivo final; se trata de cómo se fabrica y se le da soporte. Según Anexo I, Parte IILos fabricantes deben:

• Contar con un proceso de gestión de vulnerabilidades, que incluya la recepción, evaluación y tratamiento de problemas de seguridad.
• Siga prácticas de desarrollo seguras durante todo el ciclo de vida del producto.
• Proporcionar actualizaciones y mantener la seguridad del producto a lo largo del tiempo.

La CRA va más allá de verificar un producto una sola vez antes de su lanzamiento al mercado. Requiere seguridad continua durante toda su vida útil. Por lo tanto, el producto debe construirse de forma segura y el fabricante debe brindarle soporte continuo con actualizaciones de seguridad, monitoreo y mejoras.

Por lo tanto, el cumplimiento de la CRA no es algo que se establece y se olvida, sino una iniciativa estratégica y táctica a largo plazo para garantizar que la seguridad esté incorporada tanto en el producto como en los procesos detrás de él.

¿Quién debe cumplir con la CRA?

Cuando dice “cualquier fabricante, ya sea de la UE o de fuera de la UE, que venda productos con elementos digitales en Europa”, significa:

• Fabricantes de la UE

  Empresas con sede dentro de la UE que fabrican productos con software/firmware y los venden en la UE.

• Fabricantes no pertenecientes a la UE

  Empresas con sede fuera de la UE (por ejemplo, en EE. UU., China, etc.) que:

  • vender directamente en el mercado de la UE, o
  • Vender a través de distribuidores/importadores de la UE.

Si el producto llega al mercado de la UE, se aplica la CRA, independientemente de la ubicación de la empresa. Por lo tanto, no puede evitar la CRA solo porque su sede esté fuera de la UE o venda a través de plataformas en línea; si los clientes de la UE pueden comprarlo, está dentro del alcance.

Tipos de productos cubiertos

La CRA cubre el software y el firmware que se ejecutan en dispositivos conectados o se suministran con ellos. Esto incluye sistemas operativos, firmware integrado, aplicaciones móviles para controlar productos IoT, herramientas de gestión de escritorios e interfaces en la nube que interactúan con estos dispositivos. Si el software forma parte de la funcionalidad del producto o afecta a su seguridad, está sujeto a los requisitos de la CRA.

La CRA incluye IoT y dispositivos integrados, que son productos que contienen software o firmware y se utilizan normalmente en hogares, entornos sanitarios y entornos industriales.

También se aplica a los equipos de control y automatización industrial, que desempeñan un papel fundamental en las fábricas y la infraestructura crítica.

Otra categoría importante es la electrónica de consumo, que incluye dispositivos inteligentes de uso diario, como wearables, electrodomésticos inteligentes, sistemas de entretenimiento para el hogar y soluciones de seguridad conectadas.

El tiempo avanza para los fabricantes

Dado que la CRA se aplica con un cronograma estricto, los fabricantes y proveedores deben asegurarse de estar al día. A continuación, se presenta un breve resumen de los hitos clave.

10 de diciembre de 2024, la CRA entra en vigor

En esta fecha, la Ley de Protección al Consumidor (CRA) se convirtió oficialmente en ley. Esto significa que No Esto significa que todos los requisitos deben cumplirse de inmediato, pero marca el inicio de la cuenta regresiva. A partir de este momento, se espera que fabricantes, importadores y distribuidores comiencen a preparar sus procesos, documentación y sistemas para el cumplimiento.

11 de septiembre de 2026: comienzan las obligaciones de notificación de vulnerabilidades

Casi dos años después, comienzan las primeras obligaciones obligatorias:

• Los fabricantes deben comenzar a informar a las autoridades de la UE sobre las vulnerabilidades e incidentes explotados activamente dentro de los plazos requeridos.
• Deben tener ya implementado un proceso básico de gestión y divulgación de vulnerabilidades.
• Esta fase se centra en la transparencia y la alerta temprana, incluso antes de que se requiera la conformidad total del producto.

Este es esencialmente el “inicio suave” de la CRA, donde las organizaciones deben demostrar que pueden gestionar y comunicar los problemas de seguridad adecuadamente.

11 de diciembre de 2027, se requiere pleno cumplimiento

Esta es la fecha límite definitiva. Para esta fecha, todos los productos con elementos digitales comercializados en la UE deben cumplir plenamente con los requisitos de la Agencia de Regulación de la Competencia (CRA), entre ellos:

• Desarrollo seguro por diseño y seguro por defecto
• Creación y mantenimiento de SBOM
• Procesos adecuados de gestión de vulnerabilidades
• Mecanismos de actualización de seguridad
• Documentación y marcado CE relacionados con la ciberseguridad

A partir de esta fecha, los productos no conformes no podrán venderse legalmente en la UE.

Productos con elementos digitales que se han comercializado legalmente en la UE antes del 11 de diciembre de 2027 Generalmente están exentos de los requisitos principales de la Ley de Marcas de la India (CRA). Esta exención solo aplica siempre que el producto no sufra una modificación sustancial después del 11 de diciembre de 2027. Si un producto se modifica sustancialmente después de esta fecha, debe cumplir con todos los requisitos de la CRA, y la entidad que realiza la modificación se convierte en el fabricante a efectos de la CRA.

Una excepción clave a la exención general es que las obligaciones relacionadas con la vulnerabilidad y los informes de incidentes (artículo 14) do Se aplicarán a todos los productos que entren en el ámbito de aplicación del Reglamento, incluidos aquellos comercializados antes del 11 de diciembre de 2027. Estas obligaciones de información serán obligatorias a partir del 11 de septiembre de 2026. 

Ahora, entendamos los requisitos de la CRA en detalle:

Explicación de los requisitos de la CRA

La CRA define expectativas de seguridad específicas para productos con elementos digitales. Estas se dividen en dos partes principales:

Parte I – Requisitos de ciberseguridad relativos a las propiedades de los productos con elementos digitales

Requisito	Requisito explicado	Cómo lograr el requisito
Parte I.1 – Seguridad por diseño	Los productos deben diseñarse y construirse con una seguridad adecuada a sus riesgos, desde el desarrollo inicial.	Realizar evaluaciones de riesgos, aplicar un ciclo de vida de desarrollo seguro (SDL), minimizar la superficie de ataque, utilizar prácticas de codificación segura e incluir controles de seguridad de hardware/software.
Parte I.2(a) – No se conocen vulnerabilidades explotables	No se deben lanzar productos con vulnerabilidades que ya sean conocidas públicamente o internamente.	Realizar escaneo de vulnerabilidades, pruebas de penetración, análisis de código estático/dinámico, revisión de SBOM y solución de problemas antes del lanzamiento.
Parte I.2(b) – Configuración predeterminada segura	Los productos deben enviarse con configuraciones de seguridad habilitadas de forma predeterminada y permitir el restablecimiento de fábrica.	Deshabilite los servicios innecesarios, aplique credenciales predeterminadas seguras o ninguna, utilice protocolos seguros, garantice la funcionalidad de restablecimiento a la configuración de fábrica y fortalezca las configuraciones del sistema.
Parte I.2(c) – Actualizaciones de seguridad oportunas	Los productos deben admitir actualizaciones de seguridad, idealmente automáticas, con opciones de exclusión voluntaria, notificaciones y aplazamiento.	Implementar mecanismos de actualización sólidos, entrega segura de actualizaciones, firma de actualizaciones, notificaciones a usuarios y monitoreo automatizado de vulnerabilidades.
Parte I.2(d) – Protección contra el acceso no autorizado	Los dispositivos deben evitar el acceso no autorizado y detectar/informar sobre los intentos.	Utilice autenticación sólida, gestión de identidad y acceso, control de acceso basado en roles, registro y almacenamiento seguro de credenciales.
Parte I.2(e) – Confidencialidad de los datos	Los dispositivos deben proteger los datos almacenados y transmitidos, a menudo mediante cifrado.	Implemente el cifrado para datos en tránsito y datos en reposo, asegure la gestión de claves y aplique estándares criptográficos modernos.
Parte I.2(f) – Integridad de los datos y los comandos	Los dispositivos deben proteger los datos, los comandos y la configuración contra cambios no autorizados y detectar la corrupción.	Usa firmas digitales, sumas de comprobación, actualizaciones firmadas, comunicación autenticada y supervisión de la integridad de los datos.
Parte I.2(g) – Minimización de datos	Los dispositivos sólo deben recopilar los datos mínimos necesarios para el propósito previsto.	Revisar los flujos de datos desde el punto de ingreso hasta el punto de salida, eliminar la redundancia y documentar las limitaciones de propósito.
Parte I.2(h) – Disponibilidad de funciones esenciales	Las características críticas deben seguir funcionando incluso después de un incidente, incluida la resiliencia contra la denegación de servicio.	Implementar redundancia, modos a prueba de fallas, limitación de velocidad, protección DoS y definir medidas de recuperación de incidentes.
Parte I.2(i) – Minimizar el impacto negativo en las redes	Los dispositivos no deben degradar ni dañar la disponibilidad de otros sistemas en red.	Implementar controles de ancho de banda, aislamiento de recursos, monitoreo de comportamiento y prácticas de comunicación seguras.
Parte I.2(j) – Reducción de la superficie de ataque	Los dispositivos deben minimizar las interfaces externas para reducir los posibles puntos de entrada de los atacantes.	Elimine los puertos y servicios no utilizados, utilice un diseño modular, restrinja las API y aplique valores predeterminados de configuración seguros.
Parte I.2(k) – Mitigación del impacto del incidente	Los dispositivos deben incluir medidas que limiten los daños causados ​​por incidentes de seguridad.	Realizar evaluaciones de impacto y mecanismos de respuesta inmediata a incidentes.
Parte I.2(l) – Monitoreo de eventos de seguridad	Los dispositivos deben registrar eventos de seguridad clave y permitir el monitoreo, con opciones de exclusión voluntaria para el usuario.	Implementar registro, registros de auditoría, informes de eventos, almacenamiento seguro de registros y monitoreo.
Parte I.2(m) – Eliminación y transferencia segura de datos	Los usuarios deben poder eliminar datos de forma segura y permanente, y cualquier transferencia de datos debe realizarse de forma segura.	Proporciona eliminación de almacenamiento cifrado, flujos de trabajo de exportación de datos protegidos y controles de usuario claros.

Parte II – Requisitos para el manejo de vulnerabilidades

Requisito	Requisito explicado	Cómo lograr el requisito
Parte II.1 – SBOM y seguimiento de componentes	Los fabricantes deben identificar y documentar todos los componentes de software y las vulnerabilidades de sus productos, incluida la generación de una lista de materiales de software (SBOM).	Realice descubrimientos criptográficos y mantenga un inventario detallado, realice análisis de vulnerabilidades, mantenga actualizados los inventarios de componentes y monitoree bibliotecas de terceros para detectar nuevos CVE.
Parte II.2 – Remediación rápida de vulnerabilidades	Los fabricantes deben corregir las vulnerabilidades rápidamente y proporcionar actualizaciones de seguridad oportunas. Las correcciones de seguridad deben estar separadas de las actualizaciones de funciones siempre que sea posible.	Establecer un programa de evaluación de vulnerabilidades, priorizar la remediación en función del riesgo, publicar parches de seguridad rápidos, utilizar CI / CD para una entrega rápida y actualizaciones de seguridad separadas de las actualizaciones de funciones.
Parte II.3 – Pruebas de seguridad periódicas	Los fabricantes deben realizar pruebas y revisiones de seguridad continuas durante todo el ciclo de vida del producto.	Realice pruebas de penetración periódicas, análisis estáticos/dinámicos, pruebas de fuzzing, revisiones de código y evaluaciones de seguridad continuas antes y después del lanzamiento del producto.
Parte II.4 – Divulgación pública de vulnerabilidades	Una vez que un parche está disponible, los fabricantes deben revelar públicamente información clara sobre las vulnerabilidades corregidas, a menos que exista una razón de seguridad justificada para retrasar la divulgación.	Para el fabricante: notificar a los usuarios sobre los parches, proporcionar clasificaciones de gravedad, describir los impactos y documentar los pasos de solución.
Parte II.5 – Política coordinada de divulgación de vulnerabilidades (CVD)	Los fabricantes deben establecer y aplicar una política formal que guíe cómo los investigadores externos pueden informar sobre vulnerabilidades.	Para fabricación: crear una política pública de ECV, definir procesos de admisión, establecer cronogramas para la clasificación, reconocer informes y coordinar la comunicación entre investigadores y equipos internos.
Parte II.6 – Compartir información sobre posibles vulnerabilidades	Los fabricantes deben facilitar la notificación de vulnerabilidades y compartir información sobre posibles debilidades tanto en su propio software como en componentes de terceros.	Fabricante principal: proporcione un contacto o correo electrónico de seguridad dedicado, utilice plataformas de admisión de vulnerabilidades, comparta avisos con socios, monitoree los canales de seguridad de terceros y fomente la divulgación responsable.
Parte II.7 – Distribución segura de actualizaciones	Los fabricantes deben distribuir actualizaciones de forma segura, garantizando que las vulnerabilidades puedan solucionarse de forma rápida y segura, incluido el soporte para actualizaciones automáticas cuando corresponda.	Para fabricantes: utilice actualizaciones firmadas, canales de entrega cifrados, mecanismos OTA (por aire) seguros, controles de integridad de actualizaciones y canales de implementación automatizados.
Parte II.8 – Actualizaciones de seguridad gratuitas y oportunas	Las actualizaciones de seguridad deben entregarse con prontitud y sin costo adicional (excepto en el caso de acuerdos comerciales personalizados). Las actualizaciones deben incluir avisos claros.	Publique actualizaciones rápidamente, notifique a los usuarios de inmediato, proporcione correcciones de seguridad gratuitas, incluya documentación que explique el impacto y las acciones recomendadas y garantice una instalación sencilla.

Estaca por incumplimiento

El incumplimiento de los requisitos de la CRA conlleva graves consecuencias para los fabricantes y cualquier persona que comercialice productos con elementos digitales en el mercado de la UE. Los productos que no cumplen las normas pueden ser retirados del mercado, las empresas podrían verse obligadas a rediseñar o reparar sus dispositivos, y el daño a la reputación puede ser grave. Dado que los incidentes de ciberseguridad pueden poner en peligro a personas, industrias e infraestructuras críticas, la CRA considera el cumplimiento una obligación prioritaria.

Además de perder el acceso al mercado, las empresas se enfrentan a importantes sanciones económicas. La CRA incluye un estricto sistema de cumplimiento diseñado para motivar a las organizaciones a priorizar la ciberseguridad, la seguridad de los productos y la gestión del ciclo de vida.

El artículo 64 de la Ley de Vigilancia del Mercado (CRA) otorga a las autoridades tanto multas administrativas como facultades de ejecución correctiva. Las autoridades de vigilancia del mercado no solo pueden imponer multas, sino también:

• ordenar que se retiren productos del mercado,
• restringir o prohibir futuras ventas, y
• exigir a los fabricantes que arreglen o rediseñen un producto antes de poder venderlo nuevamente.

Estos poderes se aplican cuando un producto presenta riesgos de seguridad o no cumple con los requisitos esenciales de la CRA.

Niveles máximos de multa

La CRA utiliza un sistema de sanciones escalonadas, donde las multas dependen de:

• quién cometió la infracción (fabricante, importador, distribuidor, etc.), y
• qué tan grave es la violación (relacionada con la seguridad o administrativa).

A continuación se presentan las tres categorías principales de multas.

Hasta 15 millones de euros o el 2.5% de la facturación global

Este es el nivel de sanción más alto y se aplica principalmente a los fabricantes, los responsables últimos de la seguridad del producto. Una empresa puede enfrentarse a esta multa si incumple alguna de las siguientes condiciones:

• Requisitos esenciales de ciberseguridad (requisitos del Anexo I)
• Obligaciones de notificación de incidentes
• Obligaciones de notificación de vulnerabilidades
• Otras responsabilidades básicas se definen en la CRA

Debido a que estas fallas impactan directamente en la seguridad del usuario y en el riesgo de ciberseguridad, conllevan las sanciones más severas.

Hasta 10 millones de euros o hasta el 2 % de la facturación anual mundial (lo que sea mayor) 

Esta categoría se aplica cuando las empresas incumplen sus obligaciones procesales o de cumplimiento, incluso si el producto en sí no presenta una inseguridad activa. Los incumplimientos más comunes que pueden dar lugar a esta sanción son: 

• Documentación técnica faltante o incompleta 

• No realizar o documentar evaluaciones de conformidad 

• Marcado CE incorrecto o faltante 

• No mantener la lista de materiales del software requerida (SBOM) 

• Procesos internos débiles para el monitoreo del cumplimiento 

La UE se basa en documentación y evidencia de conformidad Para implementar la ciberseguridad a gran escala. Si los auditores no pueden verificar el cumplimiento, la aplicación se vuelve imposible. 

Hasta 5 millones de euros o el 1 % de la facturación anual global (lo que sea mayor) 

Este es el nivel más bajo de sanciones y se aplica cuando una organización hace lo siguiente: 

• Proporciona información falsa, engañosa o incompleta 

• Oculta los datos solicitados a las autoridades de vigilancia del mercado 

• Tergiversa los controles de ciberseguridad o los resultados de las pruebas 

Esto incluye engaño intencional O inexactitudes negligentes. 

Lista de verificación de alto nivel para el cumplimiento de la CRA

CRA No solo busca que se realicen tareas de seguridad. Quiere pruebas de que la ciberseguridad es propiedad de la empresa, está gobernada y es detallada, no improvisada. Si nadie es claramente responsable, el fabricante no puede realizar una evaluación fiable a lo largo del ciclo de vida. A continuación, se proporciona una lista de verificación para garantizar una autoevaluación rápida y determinar la situación actual de su organización:

Evaluación de Riesgos

• Asegúrese de que se haya realizado una evaluación de riesgos de protección de datos, incluida la identificación, el análisis y la priorización de los riesgos.
• Asegúrese de que exista un proceso formal de gestión de riesgos para identificar, monitorear y gestionar los riesgos de seguridad.
• Asegúrese de que los riesgos se prioricen en función de la probabilidad y el impacto, con criterios de aceptación de riesgos documentados.
• Asegúrese de que se defina una matriz RACI para la propiedad del riesgo, la escalada y la toma de decisiones.
• Asegúrese de que las políticas y procedimientos de gestión de riesgos de seguridad estén documentados, actualizados y aprobados.
• Asegúrese de que las políticas criptográficas estén alineadas con los estándares regulatorios y los mejores estándares de la industria aplicables, como NIST, FIP, GDPR, etc.
• Asegúrese de que existan procesos de monitoreo continuo para los sistemas y servicios de TIC críticos.

Respuesta al incidente

• Asegúrese de que un plan de respuesta a incidentes y un plan de continuidad del negocio estén formalmente documentados y aprobados.
• Asegúrese de que existan procedimientos predefinidos para detectar, responder, contener y recuperarse de incidentes cibernéticos.
• Asegúrese de que los roles y responsabilidades para la respuesta a incidentes estén claramente definidos.
• Asegúrese de que el plan de respuesta a incidentes se pruebe periódicamente.
• Asegúrese de que las lecciones aprendidas de las pruebas de incidentes o incidentes reales se documenten y aborden.
• Asegúrese de que Listas de materiales de software (SBOM) Se recopilan y mantienen para respaldar la clasificación rápida de incidentes y el análisis de impacto.

Protección de Datos

• Asegúrese de que los datos personales y confidenciales, como PII, PHI y datos PCI, se clasifiquen de acuerdo con los requisitos reglamentarios y de confidencialidad.
• Asegúrese de que existan controles para proteger la confidencialidad, integridad y disponibilidad de los datos (CIA).
• Asegúrese de que se utilice cifrado para datos confidenciales en reposo y en tránsito.
• Asegúrese de que existan mecanismos para detectar, responder y contener las violaciones de datos.
• Asegúrese de que se implementen controles de integridad de datos y software (por ejemplo, sumas de comprobación, firma de código).
• Asegúrese de que se realicen auditorías y evaluaciones de seguridad periódicas para validar el cumplimiento de las políticas internas y los estándares de la industria.

Obligaciones de informes

• Asegúrese de que los controles de acceso apliquen los principios de acceso con privilegios mínimos mediante RBAC o IAM.
• Asegúrese de que todos los incidentes de software y ciberseguridad estén documentados de forma coherente.
• Asegúrese de que los incidentes se informen de acuerdo con los requisitos reglamentarios y legales.
• Asegúrese de que los plazos, los umbrales y las responsabilidades de los informes estén claramente definidos.
• Asegúrese de que se produzcan y mantengan los SBOM y otras evidencias de cumplimiento.
• Asegúrese de que los informes y la generación de evidencia estén automatizados siempre que sea posible para reducir el tiempo de respuesta y los errores.

Cómo puede ayudar la consultoría de cifrado

Consultoría de Cifrado ofrece servicios de asesoría a medida para ayudar a su empresa a cumplir con los requisitos específicos de la CRA de forma eficiente y segura. Mediante evaluaciones detalladas basadas en los requisitos y los artículos pertinentes de las normas de la CRA, identificamos debilidades como protocolos obsoletos, gestión de claves deficiente o configuraciones SSL/TLS incorrectas. Abordar estos problemas fortalece su arquitectura de cifrado y contribuye al cumplimiento continuo. 

Consultoría de cifrado ofrece CodeSign seguro, una solución integral de firma de código de nivel empresarial diseñada para ayudar a las organizaciones a cumplir con estrictos requisitos de ciberseguridad como los exigidos por la CRA de la UE. 

CodeSign Secure aborda los desafíos clave de cumplimiento de la CRA al proporcionar: 

• Protección de claves respaldada por HSMLas claves de firma privada permanecen almacenadas de forma segura dentro de HSM con certificación FIPS 140-2 Nivel 3, lo que garantiza cero riesgos de exposición o robo de claves y se alinea totalmente con los requisitos de la industria y las mejores prácticas esenciales para el cumplimiento de la CRA. 
• Integración de automatización y CI/CDLa solución se integra perfectamente con los pipelines DevOps más populares y los flujos de trabajo de compilación automatizados, lo que garantiza que la seguridad nunca impida la velocidad del desarrollo ni la innovación. 
• Aplicación de políticas y control de acceso granular:Las organizaciones pueden definir y aplicar políticas de seguridad detalladas, automatizar permisos de firma y controlar la gestión del ciclo de vida de la firma en todos los equipos, respaldando las demandas de auditoría y responsabilidad de la CRA. 
• Pistas de auditoría integralesEl registro detallado de eventos, las aprobaciones de múltiples niveles y los controles de quórum garantizan que cada acción de firma sea rastreada, validada y compatible, lo que simplifica las evaluaciones de conformidad de la CRA. 
• Modelos de implementación escalablesEncryption Consulting admite implementaciones en la nube, híbridas y locales, lo que permite a las organizaciones de todos los tamaños adoptar una firma de código sólida sin una sobrecarga excesiva de infraestructura. 
• Admite algoritmos de firma híbridos (tradicionales y PQC): Permitimos el uso de algoritmos criptográficos tradicionales como RSA y ECC (ECDSA) y criptografía poscuántica (PQC) algoritmos como ML-KEM, ML-DSA, LMSY más en flujos de trabajo de firma híbridos. Esto garantiza la resiliencia a largo plazo de las firmas digitales frente a las amenazas cuánticas emergentes. 

Una organización que fabrica dispositivos IoT se enfrentó a desafíos con el cumplimiento de la CRA, en particular en la gestión segura de las claves de firma de código y la demostración de la trazabilidad de cada lanzamiento. Abordamos estos problemas mediante la integración. HSM En su entorno se implementaron las claves para la protección, lo que permitió la autenticación multifactor para el acceso y la automatización de la firma de código en su canalización de CI/CD. También se habilitaron registros de auditoría a prueba de manipulaciones para cumplir con los estrictos requisitos de trazabilidad y documentación de la CRA. Al mismo tiempo, los sólidos procedimientos de revocación de claves garantizaron la rápida invalidación de cualquier clave comprometida, lo cual es fundamental para la gestión de vulnerabilidades y la respuesta a incidentes de la CRA. 

Conclusión

La CRA establece un nuevo estándar de seguridad, exigiendo a los fabricantes que consideren la ciberseguridad una responsabilidad continua durante todo el ciclo de vida del producto. Al adoptar un diseño seguro, una gestión proactiva de vulnerabilidades y la transparencia en la elaboración de informes, las organizaciones pueden proteger a los usuarios y, al mismo tiempo, mantener el acceso al mercado de la UE.

Referencia - http://cyberresilienceact.eu/the-cyber-resilience-act-annex-eu/