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

Publicado: enero de 2026. Actualizado: agosto de 2026. Revisado por el equipo de Asesoría en Cumplimiento Normativo de Encryption Consulting.

¿Qué exige la Ley de Resiliencia Cibernética?

La Ley de Resiliencia Cibernética (CRA, por sus siglas en inglés), formalmente el Reglamento (UE) 2024/2847, es la primera ley horizontal de la Unión Europea que establece requisitos obligatorios de ciberseguridad para productos con elementos digitales, ya sean de hardware o software, comercializados en cualquier lugar del mercado de la UE. El cumplimiento gradual de la Ley de Resiliencia Cibernética (CRA, por sus siglas en inglés) se basa en un principio rector recogido en el artículo 6 : solo los productos que sean seguros desde su diseño y que cuenten con soporte durante todo su ciclo de vida pueden comercializarse en el mercado de la UE.

Ese principio se divide en dos pilares.

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

Un producto cumple con la normativa únicamente si satisface los requisitos esenciales de ciberseguridad del Anexo I, Parte I , y si el usuario u operador lo instala, mantiene y actualiza correctamente. En la práctica, esto significa que el producto debe enviarse de forma segura y mantener su seguridad durante toda su vida útil, no solo superar una verificación inicial.

La CRA clasifica los productos en cuatro categorías de riesgo, y la categoría a la que pertenece un producto determina cómo se evalúa su conformidad:

• Categoría predeterminada: Aproximadamente el 90 por ciento de los productos con elementos digitales, incluidos los aparatos electrónicos de consumo de uso general como altavoces inteligentes, discos duros y software de edición de fotos, incorporan tecnología digital.
• Productos importantes de Clase I: Productos con funciones relevantes para la ciberseguridad, como sistemas de gestión de identidades, navegadores web, gestores de contraseñas, software VPN y dispositivos de seguridad para el hogar inteligente.
• Productos importantes de Clase II: Productos de mayor riesgo, como cortafuegos, sistemas industriales de detección y prevención de intrusiones, hipervisores y microprocesadores resistentes a manipulaciones.
• Productos críticos: El nivel de mayor riesgo, donde entidades esenciales dependen del producto, como los elementos de seguridad en tarjetas inteligentes y pasarelas de contadores inteligentes.

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

El cumplimiento no se limita al dispositivo enviado. Según el Anexo I, Parte II , los fabricantes deben implementar un proceso de gestión de vulnerabilidades, seguir prácticas de desarrollo seguro durante todo el ciclo de vida del producto y proporcionar actualizaciones de seguridad mientras el producto tenga soporte. El cumplimiento de la CRA es un programa operativo permanente, no una certificación única.

¿Quiénes deben cumplir con la Agencia Tributaria Canadiense (CRA)?

Cualquier fabricante, ya sea de la UE o de fuera de la UE, que venda productos con elementos digitales en Europa, está incluido en el ámbito de aplicación, que se desglosa de la siguiente manera:

• Fabricantes de la UE Empresas con sede en la UE que fabrican productos con software o firmware y los venden en la UE.
• Fabricantes no pertenecientes a la UE Con sede fuera de la UE, por ejemplo en EE. UU. o China, que venden directamente en el mercado de la UE o a través de distribuidores e importadores de la UE.

Si el producto se comercializa en el mercado de la UE, la normativa CRA se aplica independientemente de la ubicación de la empresa. Vender a través de una plataforma de comercio electrónico no exime de esta obligación; si los clientes de la UE pueden adquirirlo, el fabricante está sujeto a la normativa.

La CRA abarca el software y el firmware que se ejecuta en dispositivos conectados o que se distribuye con ellos: sistemas operativos de dispositivos, firmware integrado, aplicaciones móviles que controlan productos de IoT, herramientas de administración de escritorio e interfaces en la nube que interactúan con dichos dispositivos. Las categorías típicas incluyen dispositivos IoT y dispositivos integrados utilizados en hogares, centros de salud y entornos industriales; equipos de control y automatización industrial; y electrónica de consumo como dispositivos portátiles, electrodomésticos inteligentes y productos de seguridad conectados.

¿Cuál es el cronograma de cumplimiento de la CRA?

La CRA se implementará gradualmente según un calendario fijo confirmado por la UE. No existe ningún período de gracia posterior a estas fechas.

1. El 10 de diciembre de 2024, la CRA entra en vigor. La normativa entró en vigor en esta fecha. No exige su cumplimiento inmediato, pero marca el inicio de la cuenta atrás; los fabricantes, importadores y distribuidores deben empezar a desarrollar los procesos, la documentación y los controles técnicos que exigen los plazos posteriores.
2. A partir del 11 de junio de 2026, se aplicarán las disposiciones relativas al organismo notificado y a la vigilancia del mercado. Las disposiciones del Capítulo IV que rigen los organismos de evaluación de la conformidad y las autoridades de vigilancia del mercado entran en vigor, lo que da tiempo a que se ponga en marcha la infraestructura de aplicación de la ley antes de que comiencen las obligaciones de presentación de informes.
3. El 11 de septiembre de 2026 comenzará la notificación de vulnerabilidades e incidentes. Según el artículo 14, los fabricantes deben notificar las vulnerabilidades explotadas activamente y los incidentes graves a ENISA y a los CSIRT nacionales dentro de los plazos establecidos, y deben contar con un proceso básico de gestión y divulgación de vulnerabilidades en funcionamiento. Este es el inicio gradual de la CRA: transparencia y alerta temprana, antes del cumplimiento total del producto.
4. 11 de diciembre de 2027, cumplimiento total obligatorio. Todo producto con elementos digitales comercializado en la UE debe cumplir íntegramente con los requisitos de la CRA: desarrollo seguro desde el diseño y por defecto, creación y mantenimiento de la lista de materiales de base (SBOM), gestión documentada de vulnerabilidades, mecanismos de actualización de seguridad operativos y marcado CE vinculado a la conformidad con la ciberseguridad. Los productos que no cumplan con estos requisitos no podrán venderse legalmente en la UE después de esta fecha.

Los productos comercializados legalmente en la UE antes del 11 de diciembre de 2027 generalmente están exentos de los requisitos principales, siempre que no sufran una modificación sustancial después de esa fecha; una modificación sustancial convierte a la entidad que la realiza en el fabricante a efectos de la notificación de incidentes y, por lo tanto, el producto queda sujeto a la normativa. El único requisito que afecta a los productos que ya están en el mercado, independientemente de dicha exención, es el artículo 14 sobre notificación de vulnerabilidades e incidentes, que se aplica a partir del 11 de septiembre de 2026 a todos los productos incluidos en su ámbito de aplicación.

¿Qué orientación ofrece la CRA sobre la selección de algoritmos y sistemas criptográficos?

La CRA es deliberadamente neutral en cuanto a la tecnología. El Anexo I, Parte I, exige a los fabricantes que protejan la confidencialidad de los datos «encriptando los datos pertinentes, tanto en reposo como en tránsito, mediante mecanismos de última generación» (Artículo 2(e)) y que protejan la integridad de los datos, comandos y configuraciones almacenados y transmitidos contra modificaciones no autorizadas (Artículo 2(f)), pero no especifica algoritmos concretos. Esta decisión, así como el registro de auditoría correspondiente, queda a criterio del fabricante, y es precisamente ahí donde la mayoría de las evaluaciones de conformidad detectan deficiencias.

Una base de referencia defendible para los productos sujetos al alcance de la CRA se vería así:

• Datos en reposo y en tránsito: AES-256 para el cifrado simétrico, TLS 1.3 para los canales de red y una razón documentada cuando todavía se utilice un conjunto de cifrado más débil para la interoperabilidad con sistemas heredados.
• Firmas digitales para la integridad del firmware y las actualizaciones: RSA-2048 o ECDSA P-256 como mínimo clásico, avanzando hacia la firma híbrida que combina un algoritmo clásico con un esquema post-cuántico del NIST como ML-DSA (FIPS 204) para la firma de propósito general.
• Firmware restringido y de larga duración: La norma NIST SP 800-208 designa los esquemas basados ​​en hash con estado LMS y XMSS para la firma de firmware y software, donde el tamaño de la firma y la huella del código importan más que el rendimiento bruto, razón por la cual la CNSA 2.0 de la NSA los nombra actualmente como la opción a corto plazo específicamente para el firmware.
• Encapsulación de claves para garantizar la confidencialidad: ML-KEM (FIPS 203) donde la vida útil de soporte prevista de un producto se extiende hasta la década de 2030 y una ventana de exposición de recolección ahora y descifrado después es realista.

La selección de un algoritmo no es una decisión que se tome una sola vez. Debe documentarse como parte del expediente técnico que un organismo notificado o una autoridad de vigilancia del mercado solicitará, y debe existir un procedimiento definido para reemplazar un algoritmo sin rediseñar la arquitectura del producto, tema que se aborda en las dos secciones siguientes.

¿Qué modelo de amenazas asume la CRA?

Los requisitos esenciales de la CRA se corresponden con un conjunto específico de capacidades de los atacantes contra las que la regulación espera que los fabricantes se defiendan, y no con un mandato genérico de "mantenerse seguro":

• Cadena de suministro e inyección de actualizaciones. Un atacante que compromete una canalización de compilación, una clave de firma o un canal de distribución intenta instalar firmware o software no autorizado en dispositivos que ya están en funcionamiento. El Anexo I, Parte I, apartados 2(c) y 2(f), abordan este problema directamente al exigir actualizaciones firmadas y verificables, así como la detección de manipulaciones para el código y la configuración.
• Explotación de vulnerabilidades conocidas. El Anexo I, Parte I 2(a) supone que los productos se distribuirán con vulnerabilidades descubiertas después de su lanzamiento y requiere un proceso de divulgación y parcheo que funcione, no solo un escaneo limpio en el lanzamiento.
• Acceso no autorizado y ataques de credenciales. Las credenciales predeterminadas o codificadas, las interfaces de administración expuestas y la autenticación débil se tratan como un fallo de diseño según 2(b) y 2(d), no como un error de configuración que el cliente debería haber detectado.
• Cosecha ahora, descifra después. La CRA no menciona la computación cuántica como una amenaza, pero la obligación de soporte de más de cinco años en virtud del Artículo 13 significa que los datos o firmas protegidos hoy solo por algoritmos clásicos pueden necesitar permanecer confidenciales o verificables mucho después del punto en que una computadora cuántica criptográficamente relevante se convierta en un riesgo creíble, razón por la cual la agilidad algorítmica pertenece al modelo de amenazas, aunque la regulación en sí sea neutral en cuanto a algoritmos.
• Compromiso en la etapa física y de fabricación. En el caso de los dispositivos IoT e integrados, un atacante con acceso físico al dispositivo o con presencia en el proceso de fabricación por contrato es un actor realista, por lo que el arranque seguro basado en hardware y el aprovisionamiento por dispositivo son tan importantes como los controles de software que los complementan.

¿Cuáles son las ventajas y desventajas en cuanto a rendimiento e interoperabilidad?

Cumplir con los requisitos criptográficos de la CRA no es gratuito, y las ventajas y desventajas varían según la clase de producto.

• Tamaño de la firma en dispositivos con limitaciones. Las firmas ML-DSA y SLH-DSA son aproximadamente de 2 a 8 veces más grandes que una firma ECDSA P-256, lo cual afecta directamente el tiempo de arranque y el presupuesto de memoria flash en dispositivos IoT con microcontroladores. Esta es la razón práctica por la que LMS y XMSS de NIST SP 800-208, con sus firmas más pequeñas, siguen siendo la opción a corto plazo para el firmware, a pesar de que requieren una gestión de claves con estado y consistente ante fallos dentro de un HSM validado.
• Gastos generales de firma híbrida. Firmar con un algoritmo clásico y otro post-cuántico durante el período de transición prácticamente duplica el tiempo de generación y verificación de la firma. Para los sistemas de firma CI/CD de alto volumen, esto suele ser aceptable; sin embargo, para un dispositivo que verifica una firma durante una secuencia de arranque con limitaciones de energía, no lo es.
• La armonización de las normas aún está en proceso. La Comisión Europea ha encargado a CEN y CENELEC la elaboración de normas armonizadas que, una vez publicadas, otorgarán a los fabricantes una presunción de conformidad. Hasta que dichas normas estén finalizadas, los fabricantes evalúan la conformidad directamente con el texto del Anexo I, lo que significa que dos auditores pueden llegar a conclusiones diferentes sobre el mismo control hasta que las normas armonizadas se actualicen.
• Distribución de actualizaciones transfronterizas. Un único mecanismo de actualización debe funcionar en todas las condiciones de red de los Estados miembros de la UE y, para los productos que también se venden fuera de la UE, debe coexistir con los requisitos reglamentarios de fuera de la UE sin necesidad de mantener un sistema de firmas independiente para cada región.

¿De qué sistema de gestión de claves depende la firma segura de actualizaciones?

El requisito de actualización segura del Artículo 13 es tan sólido como la gestión de claves que lo respalda. Una actualización firmada basada en una clave mal gestionada no difiere significativamente de una no firmada una vez que dicha clave se filtra. Una arquitectura defendible separa al menos tres roles:

• Clave raíz sin conexión. Se utiliza con poca frecuencia, normalmente solo para emitir o renovar el certificado de la clave de firma en línea, que se genera y se guarda dentro de un HSM que permanece desconectado de cualquier red y se conecta a internet únicamente para las ceremonias de clave programadas y presenciadas.
• Clave de firma en línea. Lo que realmente llama el proceso de compilación en cada lanzamiento, respaldado por HSM y accesible a través de una API autenticada para que la firma se pueda automatizar, pero nunca la misma clave que la raíz sin conexión, por lo que rotarla nunca toca el ancla de confianza ya integrada en los dispositivos implementados.
• Identidad de fabricación por dispositivo. Un par de claves único, configurado en el momento de la fabricación según el estándar IEEE 802.1AR, que permite que un dispositivo se autentique ante un servidor de actualizaciones como un dispositivo genuino y no clonado antes incluso de recibir una imagen firmada.

Además de esta separación, un programa funcional requiere hardware validado según FIPS 140-3 que proteja cada clave de firma, un requisito de aprobación M-of-N para evitar que una sola persona firme y distribuya unilateralmente, protección contra reversión que impida la reinstalación de una versión de firmware anterior firmada pero vulnerable, y una clave sucesora preconfigurada para que una clave comprometida pueda reemplazarse sin necesidad de una retirada del sistema. Las organizaciones que necesiten conocer los detalles técnicos deben consultar los documentos " Establecimiento de un marco de firma de firmware para el cumplimiento de la CRA" y "Arquitectura de cumplimiento de la CRA para la firma segura de código" , que describen en detalle la jerarquía completa de claves y el flujo de trabajo de revocación.

¿Cómo son en la práctica las implementaciones que cumplen con la normativa CRA?

Los mismos requisitos esenciales se aplican de manera diferente según la categoría del producto.

Fabricante de dispositivos IoT (categoría predeterminada). Un proveedor de sensores para hogares inteligentes se enfrentó al patrón de fallo común: una única clave de firma compartida utilizada en todas las líneas de productos, generada en un servidor de compilación en lugar de en el hardware. La solución trasladó la generación de claves a un HSM, dividió la firma en claves por producto para que una vulneración en una línea de productos no exponga a las demás, añadió autenticación multifactor para el acceso de firma y automatizó la firma dentro del pipeline de CI/CD con registro de auditoría a prueba de manipulaciones, satisfaciendo así tanto el requisito de integridad como la trazabilidad que exige una evaluación de conformidad.

Fabricante de controladores industriales (Clase II importante). Un proveedor de controladores lógicos programables para la automatización de fábricas necesitaba un arranque seguro basado en una raíz de hardware inmutable, dado que estos dispositivos funcionan en campo durante una década o más con acceso físico poco frecuente para mantenimiento. El diseño separó la cadena de verificación de arranque, vinculada a la raíz sin conexión que se rota con poca frecuencia, de la cadena de verificación de actualización, vinculada a la clave de firma en línea que se rota con mayor frecuencia, de modo que una clave en línea comprometida o obsoleta nunca requiere volver a flashear la ROM de arranque inmutable.

Fabricante de dispositivos médicos (Clase I importante o Crítica, según su función). Un fabricante de dispositivos de diagnóstico conectado necesitaba conciliar las obligaciones de la SBOM y de notificación de vulnerabilidades de la CRA con los requisitos reglamentarios vigentes para dispositivos médicos. El enfoque de trabajo consideró la SBOM de la CRA como el inventario maestro que alimentaba tanto el flujo de trabajo de notificación del Artículo 14 de la CRA como el proceso de farmacovigilancia de dispositivos médicos existente, en lugar de mantener dos inventarios de componentes separados que podrían desvincularse.

Resumen de los requisitos de la CRA: Requisitos, controles y cómo la CE puede ayudar

La tabla que aparece a continuación relaciona los requisitos esenciales de ciberseguridad que un fabricante debe cumplir con el control técnico que los satisface y el servicio o producto de consultoría de cifrado diseñado para dicho control.

Requisito de la CRA (Anexo I)	Control Técnico	Servicio de consultoría en cifrado
Diseño seguro (Parte I.1)	Evaluación de riesgos, ciclo de vida de desarrollo seguro, minimización de la superficie de ataque.	Asesoramiento de cumplimiento
No se conocen vulnerabilidades explotables (2(a))	Análisis de vulnerabilidades, revisión de SBOM, corrección previa al lanzamiento.	Aviso de cumplimiento, CBOM Secure
Configuración predeterminada segura (2(b))	Configuración predeterminada reforzada, compatibilidad con restablecimiento de fábrica, servicios no utilizados deshabilitados.	Asesoramiento de cumplimiento
Actualizaciones de seguridad oportunas y verificables (2(c))	Paquetes de actualización firmados, claves de firma respaldadas por HSM, protección contra reversión.	CodeSign seguro
Confidencialidad de los datos almacenados y transmitidos (2(e))	Cifrado de última generación en reposo y en tránsito, ciclo de vida de claves gestionado.	PKI como servicio, HSM como servicio
Integridad de los datos, comandos y configuración (2(f))	Firmas digitales, sumas de verificación, canales de comunicación autenticados	CodeSign Secure, PKI como servicio
Monitoreo y registro de eventos de seguridad (2(l))	Registros de auditoría inmutables vinculados a cada evento de firma y acceso.	CodeSign Secure, CBOM Secure
Lista de materiales y seguimiento de componentes (Parte II.1)	Descubrimiento criptográfico, inventario de dependencias, monitoreo de CVE	CBOM seguro
Divulgación e informe de vulnerabilidades (Parte II.4, Artículo 14)	Política de divulgación coordinada, flujo de trabajo de informes ENISA, cronogramas documentados.	Asesoramiento de cumplimiento

¿Cuáles son las sanciones por incumplimiento?

El artículo 64 otorga a las autoridades de vigilancia del mercado facultades tanto para imponer multas como para aplicar medidas correctivas: ordenar la retirada de productos del mercado, restringir o prohibir su venta y exigir un rediseño antes de que un producto pueda volver a comercializarse. Las multas se clasifican según la gravedad de la infracción.

Violación	Multa máxima	Límite de rotación (el que sea mayor)
Incumplimiento de los requisitos esenciales de ciberseguridad (Anexo I), obligaciones del artículo 13 o 14	15 millones de euros	2.5% de la facturación anual global
Otras obligaciones: documentación técnica incompleta, falta de evaluación de conformidad, marcado CE incorrecto, falta de SBOM	10 millones de euros	2% de la facturación anual global
Información falsa, engañosa o incompleta a las autoridades	5 millones de euros	1% de la facturación anual global

Lista de verificación de cumplimiento de la CRA

La CRA exige pruebas de que la ciberseguridad está controlada, gestionada y documentada, y no implementada de forma improvisada. Utilice esta lista de verificación para evaluar la situación actual de la organización.

Evaluación de Riesgos

• Un proceso formal de gestión de riesgos identifica, supervisa y gestiona los riesgos de seguridad con criterios documentados de aceptación de riesgos.
• Una matriz RACI define la responsabilidad del riesgo, la escalada y la toma de decisiones.
• Las políticas criptográficas se ajustan a estándares reconocidos como NIST y FIP.

Respuesta al incidente

• Un plan documentado de respuesta ante incidentes define los procedimientos de detección, contención y recuperación, y se somete a pruebas periódicas.
• Listas de materiales de software (SBOM) Se mantienen para facilitar la clasificación rápida de incidentes y el análisis de su impacto.

Protección de Datos

• El cifrado protege los datos confidenciales tanto en reposo como en tránsito, mediante algoritmos documentados conforme a un estándar vigente.
• Controles de integridad de software y datos, incluidos firma de código, se implementan y se auditan de forma independiente.

Obligaciones de informes

• Los plazos, los umbrales y las responsabilidades para las notificaciones del artículo 14 a ENISA están claramente definidos y se han ensayado.
• Los SBOM y demás pruebas de cumplimiento se automatizan siempre que sea posible para reducir el tiempo de respuesta y los errores.

Limitaciones

Esta guía es un punto de partida, no un sustituto de una evaluación formal de la conformidad ni de una revisión legal. Es importante aclarar algunos límites. Las normas armonizadas que CEN y CENELEC están elaborando otorgarán a los fabricantes una presunción de conformidad para controles técnicos específicos; hasta su publicación, la evaluación directa según el texto del Anexo I deja margen para diferentes interpretaciones entre fabricantes y organismos notificados. Los ejemplos de categorías de productos en esta guía son ilustrativos y no sustituyen el proceso de clasificación formal, que determina la ruta de evaluación de la conformidad que debe seguir un producto específico. Cuando un producto también se rige por NIS2, DORA o un régimen sectorial específico, como la regulación de dispositivos médicos, la CRA no reemplaza dichas obligaciones, sino que las complementa, y la superposición debe resolverse caso por caso. Finalmente, las referencias a algoritmos y normas en esta guía reflejan el panorama actual de NIST y CA/Browser Forum a agosto de 2026; las normas PQC y las votaciones de CA/B Forum siguen evolucionando, por lo que un programa de cumplimiento requiere un proceso para el seguimiento de las actualizaciones, no una lectura única de este artículo.

¿Qué recomendaría Encryption Consulting?

Antes de adquirir cualquier herramienta, comience con una evaluación de brechas. El servicio de Asesoramiento en Cumplimiento de Encryption Consulting realiza una evaluación detallada en función de los artículos específicos de la CRA y los requisitos del Anexo I que se aplican a la categoría del producto, e identifica brechas concretas como protocolos obsoletos, una gestión de claves deficiente o configuraciones TLS incorrectas, en lugar de una puntuación de madurez genérica.

En lo que respecta específicamente a la actualización segura y el requisito de firma de firmware, CodeSign Secure está diseñado precisamente para este control: las claves de firma privadas permanecen dentro de los HSM con certificación FIPS 140-2 Nivel 3, la aprobación M-of-N evita la firma unilateral, cada evento de firma produce un registro de auditoría inmutable y la firma híbrida admite tanto algoritmos clásicos como esquemas post-cuánticos como ML-DSA y LMS desde la misma infraestructura de firma, por lo que un fabricante no tiene que reconstruir el proceso cuando se implementan los estándares armonizados.

Para cumplir con los requisitos de confidencialidad e integridad relacionados con los datos en reposo y en tránsito, PKI-as-a-Service proporciona la infraestructura de certificados y claves gestionada que respalda los canales cifrados y la identidad del dispositivo sin necesidad de desarrollar una CA interna, lo cual es fundamental para los fabricantes que necesitan que esto funcione mucho antes de la fecha límite de presentación de informes de septiembre de 2026, no después.

Una organización fabricante de dispositivos IoT se enfrentaba precisamente a esta combinación de deficiencias: una clave de firma compartida, falta de trazabilidad entre certificados y versiones, y ausencia de un manual de revocación. La integración de la protección de claves mediante HSM, la autenticación multifactor para el acceso a la firma y la firma automatizada de CI/CD subsanaron las deficiencias de integridad y control de acceso, mientras que el registro de auditoría a prueba de manipulaciones y los procedimientos definidos de revocación de claves satisficieron simultáneamente los requisitos de trazabilidad y gestión de vulnerabilidades de la CRA.

Conclusión

La CRA establece un nuevo punto de partida: la ciberseguridad como una responsabilidad continua y demostrable a lo largo del ciclo de vida de un producto, en lugar de una mera casilla de verificación el día del lanzamiento. La fecha límite del 11 de septiembre de 2026 llega primero y pone a prueba si un proceso de divulgación de vulnerabilidades funciona realmente bajo presión; la fecha límite del 11 de diciembre de 2027 pone a prueba todo lo demás, desde la ingeniería segura desde el diseño hasta la precisión de la lista de materiales de base (SBOM) y las actualizaciones firmadas y auditables. Los fabricantes que consideren la selección de algoritmos, la gestión de claves y la firma de actualizaciones como infraestructura que deben construir ahora, en lugar de papeleo que deben recopilarse después, serán los que cumplirán con ambas fechas sin contratiempos.

Preguntas frecuentes

¿Cuándo entra en vigor realmente la Ley de Resiliencia Cibernética?

La Ley de Reclamaciones por Agravios (CRA) entró en vigor el 10 de diciembre de 2024. Las obligaciones de notificación de vulnerabilidades e incidentes, conforme al artículo 14, se aplican a partir del 11 de septiembre de 2026. El cumplimiento total, incluido el marcado CE, es obligatorio antes del 11 de diciembre de 2027. No existe ningún período de gracia adicional después de estas fechas.

¿La Agencia Tributaria canadiense (CRA) exige un algoritmo de cifrado específico?

No. El Anexo I, Parte I, exige un cifrado de última generación para la protección de la confidencialidad e integridad de los datos, comandos y configuración, pero no especifica algoritmos concretos. Los fabricantes eligen y documentan algoritmos como AES-256, TLS 1.3 y esquemas de firma adecuados a las limitaciones y la vida útil prevista del producto, y dicha elección pasa a formar parte de la documentación técnica que revisa la evaluación de conformidad.

¿Existe algún producto exento de la Ley de Reinversión Comunitaria (CRA)?

Los productos que ya se comercializaban legalmente en el mercado de la UE antes del 11 de diciembre de 2027 generalmente están exentos de los requisitos principales, a menos que sufran una modificación sustancial después de esa fecha. Ciertas categorías, como los productos ya cubiertos por reglamentos sectoriales de la UE para dispositivos médicos, aviación o vehículos, se rigen por excepciones específicas definidas en el reglamento. El artículo 14 sobre notificación de vulnerabilidades e incidentes sigue aplicándose a los productos incluidos en el ámbito de aplicación, independientemente de esta exención, a partir del 11 de septiembre de 2026.

¿Qué relación existe entre la CRA, NIS2 y DORA?

NIS2 y DORA rigen la postura de ciberseguridad y la resiliencia operativa de las organizaciones que gestionan infraestructuras críticas y entidades financieras. La CRA regula los productos que estas y otras organizaciones compran y utilizan. Un banco sujeto a DORA, por ejemplo, debe confirmar que los dispositivos conectados y el software que adquiere cumplen con los requisitos de la CRA; ambas regulaciones son complementarias, no se superponen ni se sustituyen.

¿Cuál es el mayor error relacionado con la criptografía que cometen los fabricantes al prepararse para la CRA?

Utilizar una única clave de firma compartida para todas las líneas de productos es la vía más rápida para lograr el cumplimiento, pero también la peor opción según el Artículo 14: una sola vulneración de la clave obliga a notificar un incidente que afecta a toda la cartera de productos a la vez, en lugar de limitarse a una sola línea de productos. El aislamiento de claves por producto, generado dentro de un HSM, es la solución que la mayoría de las evaluaciones de conformidad acaban exigiendo.

Referencias

• Reglamento (UE) 2024/2847 del Parlamento Europeo y del Consejo, Ley de Ciberresiliencia, EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
• Comisión Europea, Ley de Ciberresiliencia, Dando forma al futuro digital de Europa: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
• Anexos I a VIII de la CRA, Requisitos esenciales y listas de productos: https://www.cyberresilienceact.eu/the-cyber-resilience-act-annex-eu/
• Ley de Resiliencia Cibernética, Artículo 71, entrada en vigor y aplicación: https://www.european-cyber-resilience-act.com/Cyber_Resilience_Act_Article_71.html
• NIST SP 800-208, Recomendación para esquemas de firma basados ​​en hash con estado: https://csrc.nist.gov/pubs/sp/800/208/final
• NIST FIPS 204 (ML-DSA) y FIPS 205 (SLH-DSA), finalizadas en agosto de 2024: https://csrc.nist.gov/pubs/fips/204/final