Durante años, la criptografía ha permanecido en un segundo plano en la ingeniería de l software , un detalle que los equipos rara vez abordaban fuera de las revisiones de seguridad. La Ley de Ciberresiliencia de la UEla sitúa en el centro de la regulación de los productos. En virtud de dicha ley, las decisiones criptográficas que se tomen en tu software determinan ahora si este puede acceder legalmente al mercado europeo.
El mecanismo es el marcado CE. El mismo marcado que regula la seguridad física y eléctrica de los productos de la UE se extiende ahora a la ciberseguridad de cualquier producto que contenga un componente digital. Si no se cumplen los requisitos esenciales de la CRA, el producto no podrá llevar el marcado CE.
Sin el marcado CE, el producto no puede comercializarse. Esto se aplica a cualquier fabricante que comercialice un producto con elementos digitales en el mercado de la UE, independientemente de dónde tenga su sede la empresa.
Lo que exige realmente la Ley de Resiliencia Cibernética
La Ley de Resiliencia Cibernética, conocida oficialmente como Reglamento (UE) 2024/2847, es la primera normativa horizontal de la UE basada en el principio de «seguridad desde el diseño» para productos con elementos digitales. «Horizontal» significa que abarca todos los sectores, en lugar de centrarse en uno concreto. «Seguridad desde el diseño» significa que la seguridad debe integrarse en el producto desde el principio, y no añadirse posteriormente.
El reglamento divide las obligaciones en dos partes. El anexo I, parte I, se refiere al diseño de la seguridad del producto: las propiedades que debe tener un producto en el momento de su comercialización. El anexo I, parte II, se refiere a la gestión de las vulnerabilidades a lo largo del ciclo de vida: cómo detectar, corregir y comunicar las vulnerabilidades una vez que el producto está en el mercado. Cumplir con el CRA implica satisfacer ambos requisitos, no solo reforzar la versión inicial.
¿A quiénes afecta?
La CRA abarca una amplia gama de funciones a lo largo de toda la cadena de suministro de software :
- Software productores y editores, incluidos los independientes software y los integrados software.
- Soluciones de procesamiento remoto de datos que forman parte integrante de un producto, lo que significa que este no puede desempeñar su función sin ellas.
- Open-source administradores que distribuyen su « software » con fines comerciales.
- Los importadores y distribuidores, que deben comprobar que el fabricante de un producto ha cumplido con sus obligaciones.
Si desarrollas, empaquetas o revendes un « software » que llega a la UE, es casi seguro que tienes alguna responsabilidad en virtud de la CRA.
Categorías «Por defecto», «Importante» y «Crítica»
La CRA clasifica los productos según su nivel de riesgo. La mayoría de los productos se incluyen en la categoría «por defecto». Por encima de esta se encuentran las clases «importantes» (Clase I y Clase II) y la categoría «crítica», que conllevan obligaciones más estrictas en materia de evaluación de la conformidad. Varios ejemplos de productos «importantes» se enmarcan claramente en las tecnologías de la información y software, entre ellos los sistemas de gestión de identidades, las VPN software y los cortafuegos. Si tu producto desempeña una función de seguridad como estas, debes esperar un nivel de exigencia más alto en cuanto a las pruebas que debes aportar. En algunos casos, esto implica una revisión por parte de un organismo notificado, en lugar de una autodeclaración.
Por qué es importante: el marcado CE, los plazos y las sanciones
El argumento comercial es claro. Un producto « software » que no cumpla con la normativa pierde el marcado CE necesario para acceder al mercado de la UE. Por lo tanto, una deficiencia en el control de riesgos (CRA) supone un problema de ingresos y distribución, no solo de seguridad.
Las sanciones refuerzan este punto. Las multas pueden alcanzar los 15 millones de euros o el 2,5 % de la facturación anual total a nivel mundial, lo que sea mayor. Ese límite máximo se aplica a los incumplimientos de los requisitos esenciales del anexo I y de las obligaciones de los artículos 13 y 14, mientras que otras obligaciones tienen límites máximos más bajos.
Cómo se relaciona el CRA con la criptografía y la PKI
La CRA aborda la criptografía a través de varias áreas de control interrelacionadas del Anexo I. Cada una de ellas define una propiedad de seguridad y, detrás de la mayoría de ellas, se encuentra una infraestructura de clave pública (PKI) que permite aplicar dicha propiedad a gran escala. A continuación se explica cómo se relacionan entre sí estos elementos.
Confidencialidad de los datos almacenados y en tránsito
El anexo I, parte I, apartado 2, letra e), exige que los productos protejan la confidencialidad de los datos pertinentes mediante un cifrado de última generación, tanto en reposo como en tránsito. En la práctica, dicha protección depende de una infraestructura de clave pública (PKI) que emita los certificados de sesión y de servicio utilizados para establecer canales cifrados y proteger los datos almacenados.
Integridad de los datos, los comandos y la configuración
El anexo I, parte I, apartado 2, letra f), exige que se proteja la integridad de los datos, comandos, programas y configuraciones almacenados, transmitidos y procesados frente a cualquier manipulación no autorizada por el usuario, así como que se notifiquen los casos de corrupción. La configuración firmada y los canales autenticados y respaldados por certificados te permiten demostrar que un command o una configuración proceden de una fuente fiable y han llegado sin sufrir modificaciones.
Configuración e identidad seguras de forma predeterminada
El anexo I, parte I, apartados 2 b) y 2 d), exige que se establezcan configuraciones predeterminadas seguras y un control de acceso basado en la identidad. El punto 2, letras b) y d), exige además la posibilidad de restablecer el producto a su estado original, y el punto 2, letra d), exige la notificación de posibles accesos no autorizados. El objetivo práctico es disponer de una identidad única de servicio o instancia asignada en el momento de la implementación, en lugar de una credencial predeterminada compartida que se incluya con cada copia. Las identidades basadas en certificados permiten que cada carga de trabajo se autentique como tal.
Mecanismo de actualización seguro
El anexo I, parte I, apartado 2, letra c), junto con el anexo I, parte II, puntos 7 y 8, exige un mecanismo de actualización seguro. Las actualizaciones deben distribuirse sin demora y de forma gratuita durante todo el período de soporte obligatorio. Además, deben estar firmadas criptográficamente, de modo que los destinatarios puedan verificar su autenticidad antes de instalarlas. La firma de código es el control que permite verificar esto.
Visibilidad de los componentes criptográficos
El seguimiento de componentes cuenta con un mecanismo específico. El anexo I, parte II, punto (1), exige a los fabricantes que identifiquen y documenten las vulnerabilidades y los componentes, incluida una lista de materiales « software » en formato legible por máquina que abarque, como mínimo, las dependencias de nivel superior. Las expectativas específicas en materia de criptografía se están estableciendo a través del anexo K, un anexo transversal que se encuentra en fase de desarrollo en el marco de las normas ETSI CYBER-EUSR, exigidas por la solicitud de normalización M/606, y que se espera que defina una lista de mecanismos criptográficos permitidos basada en las directrices de la ENISA. Se espera que pueda identificar las bibliotecas y los algoritmos criptográficos integrados en su software y sus dependencias. Esto le permite evaluar la exposición y aplicar medidas correctivas rápidamente cuando se detecta que un componente es vulnerable.
Eliminación segura de datos
El anexo I, parte I, apartado 2, letra m), exige que se garantice la eliminación segura y definitiva de los datos y la configuración. En el caso de software , que gestiona entornos de clientes o de inquilinos, esto incluye la destrucción de las claves criptográficas durante el proceso de baja o desmantelamiento, de modo que los datos retirados no puedan recuperarse.
Prepararse para la auditoría: preguntas que plantearán los evaluadores
Las evaluaciones de conformidad con la CRA, ya sean autodeclaradas o revisadas por un organismo notificado, se centran en pruebas demostrables más que en declaraciones de intenciones. Una intención por escrito de cifrar los datos tiene poco valor sin pruebas de que el mecanismo exista y funcione. Utiliza los puntos de análisis que figuran a continuación como lista de comprobación para realizar una autoevaluación:
- Documentación sobre la evaluación de riesgos que justifique tus decisiones en materia de diseño criptográfico.
- Una identidad criptográfica única para cada servicio, instancia o cliente.
- Un canal de actualizaciones firmadas que verifica las firmas antes de la instalación, con las actualizaciones automáticas activadas por defecto.
- Un inventario de componentes criptográficos que incluye las dependencias heredadas de open-source .
- Procedimientos de borrado seguro y destrucción de claves para la baja o el desmantelamiento.
- Compromisos relativos al periodo de asistencia, documentados y comunicados. El plazo mínimo es de cinco años; será más largo cuando el producto se utilice durante más tiempo, y más corto únicamente cuando el uso previsto sea inferior a cinco años.
Por dónde empezar: un plan práctico de preparación
No es necesario que resuelvas todos los requisitos a la vez, pero el orden sí que importa. Un orden viable sería el siguiente:
- Confirma que tu proceso de notificación conforme al artículo 14 está operativo. Esto implica contar con un responsable designado, un canal de recepción de alertas sobre vulnerabilidades e incidentes, y la capacidad de presentar una alerta temprana de 24 horas, una notificación de 72 horas y un informe final a través de la plataforma única de notificación de la ENISA y de tu CSIRT coordinador.
- Consigue una visión clara de tus activos criptográficos, ya que no puedes proteger ni justificar lo que no ves.
- Asignar identidades únicas a los servicios y las instancias para sustituir los valores predeterminados compartidos.
- Poner en marcha un proceso de actualización firmado que incluya una verificación previa a la instalación.
- Elabora un inventario de componentes criptográficos que incluy open-source e las dependencias.
- Documenta las decisiones de diseño basadas en el riesgo que subyacen a cada elección.
Empieza con antelación. Los requisitos esenciales entrarán en vigor en diciembre de 2027, pero las obligaciones de notificación de vulnerabilidades se aplicarán a partir de septiembre de 2026. Los cambios de diseño mencionados anteriormente requieren tiempo para planificarlos, probarlos e implementarlos en un producto ya en el mercado.
Cómo Keyfactor ayudarte Keyfactor
Keyfactor ofrece a los editores de « software » una guía concreta desde los requisitos de la CRA hasta su implementación, relacionando cada área de control con una funcionalidad que se puede implementar.
Keyfactor AgileSec aborda la visibilidad de los componentes criptográficos. Detecta y cataloga las bibliotecas criptográficas, los algoritmos, las claves y los protocolos presentes en su código, terminales, cargas de trabajo en la nube y dependencias. A continuación, puntúa los riesgos, lo que le permite priorizar las medidas correctivas y demostrar su exposición ante un evaluador.
EJBCA Proporciona la base de la infraestructura de clave pública (PKI) para garantizar la confidencialidad, la integridad y una identidad segura por defecto. Emite los certificados que protegen los datos tanto en tránsito como en reposo. Asigna identidades únicas a los servicios y a las instancias, en lugar de credenciales compartidas, y permite la destrucción de claves criptográficas para garantizar una baja y un desmantelamiento completos.
Keyfactor SignServer, junto con Keyfactor Signum, proporciona el mecanismo de actualización segura. Ambos firman criptográficamente las actualizaciones de software y los artefactos de lanzamiento, con claves protegidas por hardware y registros de auditoría firmados, de modo que los destinatarios puedan verificar su autenticidad durante todo el periodo de soporte.
Keyfactor Command lo integra todo a nivel operativo. Automatiza el ciclo de vida de los certificados asociados a estas identidades y canales, lo que proporciona a los equipos de seguridad una visibilidad continua, la renovación automática y una gestión centralizada en todos los entornos.
Por separado, estos productos cumplen con los controles específicos de la CRA. En conjunto, forman el «Trust Control Plane» de Keyfactor. Se trata de un único sistema que permite supervisar su entorno criptográfico, analizar los riesgos, proporcionar identidades de confianza, coordinar acciones y gestionarlo todo de acuerdo con las políticas. Ese es precisamente el mismo ciclo continuo que la CRA le pide que demuestre, desde el diseño inicial hasta el final del periodo de soporte.
¿Estás listo para plasmar tus obligaciones en materia de CRA en un plan de preparación operativa? Solicitar una demo.
¿Tienes alguna duda sobre la Ley de Resiliencia Cibernética? Tenemos las respuestas.
¿Qué es la Ley de Ciberresiliencia de la UE?
La Ley de Ciberresiliencia (Reglamento (UE) 2024/2847) es la primera normativa horizontal de la UE que exige la ciberseguridad «segura desde el diseño» para los productos con elementos digitales, es decir, los productos software o hardware y sus soluciones de tratamiento de datos a distancia. Vincula el cumplimiento normativo directamente al marcado CE y divide las obligaciones en el diseño de la seguridad del producto y la gestión de las vulnerabilidades a lo largo de su ciclo de vida.
¿Se aplica el CRA a las empresas software fuera de la UE?
Sí. Se aplica a cualquier fabricante que comercialice en el mercado de la UE un producto con elementos digitales, independientemente de dónde tenga su sede la empresa. Software Los productores, open-source los gestores que se dedican a la distribución comercial, así como los importadores y distribuidores, tienen obligaciones.
¿Cuándo entran en vigor los requisitos del CRA?
Las obligaciones de notificación previstas en el artículo 14 se aplican desde el 11 de septiembre de 2026 y abarcan los productos que ya se encuentran en el mercado de la UE. Las disposiciones relativas a los organismos notificados se aplican desde el 11 de junio de 2026. Los requisitos esenciales, la evaluación de la conformidad y el marcado CE se aplican a partir del 11 de diciembre de 2027.
¿Cuáles son las sanciones por incumplimiento?
Las sanciones pueden alcanzar los 15 millones de euros o el 2,5 % de la facturación anual global total, el importe que sea mayor. Las empresas que incumplan la normativa software también pierden el marcado CE necesario para acceder al mercado de la UE, lo que convierte esta cuestión en un problema de acceso al mercado tanto como de seguridad.
¿Qué controles criptográficos exige la CRA?
La CRA aborda la criptografía a través de varias áreas de control del Anexo I. Estas abarcan la confidencialidad y la integridad de los datos, la configuración y la identidad seguras por defecto, las actualizaciones firmadas, la visibilidad de los componentes criptográficos y la eliminación segura de datos, incluida la destrucción de claves. Cada decisión debe justificarse mediante una evaluación de riesgos específica para cada producto.
¿Qué es un inventario de componentes criptográficos y por qué es importante?
Es un registro de todas las bibliotecas y algoritmos criptográficos integrados en tu software, incluidas las dependencias heredadas de open-source . Los evaluadores lo esperan y, sin él, no puedes determinar rápidamente qué queda expuesto cuando se da a conocer una vulnerabilidad en un componente.
¿Qué productos están sujetos a obligaciones más estrictas en materia de CRA?
Las categorías «Importantes» (Clase I y II) y «Críticas» conllevan obligaciones de evaluación de la conformidad más estrictas que la categoría por defecto. En el ámbito de las tecnologías de la información y software, esto incluye los sistemas de gestión de identidades y las VPN software.
¿Cómo contribuye la PKI al cumplimiento de los requisitos de la CRA?
La PKI sustenta los requisitos criptográficos fundamentales de la CRA. Los certificados cifran los datos tanto en tránsito como en reposo y proporcionan identidades únicas a los servicios y dispositivos. Además, firman las actualizaciones de software , de modo que los destinatarios puedan verificar su autenticidad durante todo el periodo de soporte.
