Ley de resiliencia cibernética para las tecnologías de la información y Software
Criptografía e infraestructura de clave pública (PKI) para los productos de « Software » con elementos digitales
| Región | A nivel mundial (se aplica a cualquier producto comercializado en la UE, independientemente de la ubicación del fabricante o del editor) |
| Ámbito de aplicación | Software Productores y editores: productos independientes software, componentes SaaS con un elemento digital y productos integrados software comercializados en la UE Open-Source Responsables: organizaciones que distribuyen comercialmente open-source software con elementos digitales, en las condiciones definidas en el reglamento Importadores y distribuidores: deben verificar el cumplimiento de los requisitos por parte de los productores antes de poner software a disposición en el mercado de la UE |
| Apartados pertinentes | Anexo I, Parte I: Requisitos esenciales de ciberseguridad (diseño y configuración por defecto) Anexo I, Parte II: Requisitos relativos a la gestión de vulnerabilidades durante todo el período de soporte Anexos III y IV: Categorías de productos importantes y críticas sujetas a una evaluación de conformidad más estricta |
Visión general
La Ley de Resiliencia Cibernética (CRA), Reglamento (UE) 2024/2847, es la primera normativa horizontal de la UE que exige la ciberseguridad «segura desde el diseño» para los productos que sean o contengan un elemento digital, estén conectados hardware, software o impliquen el tratamiento remoto de datos, y que se comercialicen en el mercado de la UE, vinculando su cumplimiento directamente al marcado CE. Divide las obligaciones en requisitos de diseño de seguridad del producto (anexo I, parte I) y requisitos de gestión de vulnerabilidades a lo largo del ciclo de vida (anexo I, parte II).
En el caso concreto de la norma « software », los fabricantes deben suministrar productos con protección criptográfica para la confidencialidad e integridad de los datos activada de forma predeterminada, actualizaciones verificadas criptográficamente software y un mecanismo seguro de identidad y autenticación, todo ello justificado mediante una evaluación de riesgos de ciberseguridad específica para cada producto, en lugar de una lista de verificación fija. Entre las categorías importantes (Clase I y II) se incluyen los sistemas de gestión de identidades y las VPN software, ambos claramente incluidos en el sector de las tecnologías de la información y software .
Por qué es importante
La CRA se aplica, en esencia, a cualquier producto « software » conectado que se comercialice en la UE, y las categorías de productos «importantes» y «críticos», los sistemas de gestión de identidades, las VPN software y otros productos similares relacionados con la seguridad software están sujetos a obligaciones de evaluación de la conformidad más estrictas que las de la categoría por defecto.
Los requisitos esenciales deberán aplicarse íntegramente a más tardar el 11 de diciembre de 2027, mientras que las obligaciones de notificación de vulnerabilidades y de explotación activa entrarán en vigor en un plazo más breve, a partir de septiembre de 2026. Las sanciones pueden alcanzar los 15 millones de euros o el 2,5 % de los ingresos totales a nivel mundial, lo que sea mayor, y los « software » que incumplan la normativa perderán la marca CE necesaria para acceder al mercado de la UE, lo que convierte esta cuestión en un problema de acceso al mercado tanto como de seguridad.
Cómo se aplica esto a la criptografía
La Ley de Ciberresiliencia de la UE aborda la criptografía a través de varias áreas de control interrelacionadas. Las áreas clave con implicaciones criptográficas directas son:
| Sección | Función | Lo que dice | Asistencia para los productos « Keyfactor » |
| Anexo I, Parte I, apartado 2, letra e) | Confidencialidad de los datos en reposo y en tránsito | Cifra los datos relevantes, tanto en reposo como en tránsito, mediante mecanismos de última generación, respaldados por la PKI que emite certificados de sesión y de servicio. | Command / EJBCA |
| Anexo I, Parte I, apartado 2, letra f) | Integridad de los datos, los comandos y la configuración | Proteger los comandos, la configuración y el estado de las aplicaciones frente a manipulaciones no autorizadas, normalmente mediante una configuración firmada y canales autenticados. | EJBCA |
| Anexo I, Parte I, apartados 2 b) y 2 d) | Configuración e identidad «seguras por defecto» | Se entrega con una configuración predeterminada segura y un control de acceso basado en identidades, lo que significa que, en el momento de la implementación, se asigna una identidad única al servicio o a la instancia, en lugar de una credencial predeterminada compartida. | Keyfactor Command |
| Anexo I, Parte I, apartado 2, letra c); Anexo I, Parte II, apartado 7 | Mecanismo de actualización segura | Firmar criptográficamente las actualizaciones de software y difundirlas sin demora y de forma gratuita durante todo el periodo de soporte obligatorio. | SignServer / Signum |
| Se da por supuesto en la evaluación de riesgos exigida; se prevé en la futura lista de productos autorizados del anexo K | Visibilidad de los componentes criptográficos | Identificar y realizar un seguimiento de las bibliotecas y algoritmos criptográficos integrados en el « software » y sus dependencias para evaluar el riesgo y facilitar la corrección. | Command / AgileSec |
| Anexo I, Parte I, apartado 2, letra m) | Eliminación segura de datos | Permitir el borrado seguro y definitivo de datos y configuraciones, incluida la destrucción de claves criptográficas, en caso de baja de un cliente o de desmantelamiento del servicio. | EJBCA |
Preparación para la auditoría
Las evaluaciones y los exámenes, ya sean realizados por la propia organización, llevados a cabo por un organismo regulador o revisados por un evaluador independiente, se centran en las pruebas demostradas y no únicamente en las declaraciones de política. Áreas clave que suelen analizar los examinadores y evaluadores:
- Documentación sobre la evaluación de riesgos: ¿Ha llevado a cabo y documentado la organización una evaluación de riesgos de ciberseguridad específica para el producto que justifique sus decisiones en materia de diseño criptográfico?
- Aprovisionamiento de identidades para servicios e instancias: ¿Se asigna una identidad criptográfica única a cada servicio, instancia o inquilino, en lugar de recurrir a credenciales compartidas o predeterminadas?
- Proceso de actualización firmado: ¿Puede la organización demostrar que las actualizaciones de « software » están firmadas criptográficamente y se verifican antes de su instalación, con las actualizaciones automáticas activadas de forma predeterminada?
- Inventario de componentes criptográficos: ¿Mantiene la organización un inventario de todas las bibliotecas y algoritmos criptográficos integrados en el software, incluidas las dependencias heredadas de open-source ?
- Borrado seguro y destrucción de claves: ¿Permite el producto el borrado seguro de datos, incluida la destrucción de claves criptográficas, en caso de baja de un usuario o de retirada del servicio?
- Compromisos relativos al periodo de soporte: ¿Se ha documentado y comunicado a los usuarios el periodo obligatorio de soporte para las actualizaciones de seguridad, que es de un mínimo de cinco años o, si es inferior, la vida útil prevista del producto?
LLEVA ESTO A LA DIRECCIÓN
La CRA convierte la ciberseguridad en un requisito de acceso al mercado para software , al igual que lo hace para hardware: sin el marcado CE, no hay acceso al mercado de la UE, además de multas de hasta 15 millones de euros o el 2,5 % de nuestra facturación global total. Cada producto conectado software que comercializamos debe contar con una identidad de servicio válida, actualizaciones firmadas y cifrado activado por defecto, respaldado por documentación que demuestre que hemos evaluado el riesgo y lo hemos diseñado en consecuencia.
Tenemos hasta diciembre de 2027 para cumplir plenamente con la normativa, pero el plazo para notificar vulnerabilidades comienza en septiembre de 2026, con un margen mucho más reducido, y ese tiempo se agota rápidamente si se tiene en cuenta la adaptación de productos que nunca se diseñaron con un proceso de firma ni con una identidad por inquilino. Si no podemos elaborar un inventario criptográfico de un producto, incluidas sus dependencias open-source , no podremos decirle a un organismo regulador —ni a nosotros mismos— qué es lo que realmente queda expuesto cuando surja la próxima vulnerabilidad.
Cumplimientos normativos relacionados
Preparación para la era poscuántica en el ámbito de las tecnologías de la información y Software
Ley de resiliencia cibernética para el sector manufacturero
