Editores de software y CRA: la seguridad del producto se vuelve obligatoria

¿De qué trata la CRA?

El CRA se aplica a los «productos con elementos digitales»: software y hardware conectados directa o indirectamente a una red. Define requisitos esenciales de ciberseguridad y obligaciones de gestión de vulnerabilidades, con categorías «importantes» y «críticas» sujetas a evaluaciones más estrictas.

Existen regímenes específicos, en particular para el software libre no comercial y los productos ya cubiertos por una normativa sectorial equivalente.

¿El sector «Editores de software» está afectado?

Todo editor que comercialice un software en el mercado europeo es, en principio, fabricante de un producto con elementos digitales. El nivel de exigencia depende de la criticidad del producto: la mayoría del software se encuadra en el régimen básico, y algunos (herramientas de seguridad, componentes sensibles) en las categorías reforzadas.

Se aplica un régimen simplificado al open source no comercial; no obstante, un componente open source integrado en un producto comercial sigue siendo responsabilidad del editor que lo comercializa.

Obligaciones detalladas

Sanciones y riesgos

Los incumplimientos de los requisitos esenciales de ciberseguridad pueden sancionarse con hasta 15 M€ o el 2,5 % del volumen de negocio mundial; otros incumplimientos corresponden a umbrales inferiores. La no conformidad también puede conllevar la retirada o la recuperación del producto del mercado.

Para un editor, el desafío es doble: la sanción y el acceso al mercado, ya que el marcado CE de ciberseguridad se convierte en una condición de comercialización.

Calendario de aplicación

• 1Entrada en vigor. Finales de 2024.
• 2Obligaciones de notificación. Aplicables aproximadamente 21 meses después de la entrada en vigor (a lo largo de 2026).
• 3Requisitos completos. Aplicables aproximadamente 36 meses después de la entrada en vigor (horizonte 2027).

Errores frecuentes en el sector

• 1« CRA = hardware únicamente ». Creer que el CRA solo afecta al hardware, cuando un software es un producto con elementos digitales.
• 2Sin SBOM. Ignorar la nomenclatura de componentes, lo que hace imposible la gestión de vulnerabilidades.
• 3Ausencia de política de parches. No garantizar actualizaciones durante el período de soporte.
• 4Vulnerabilidades no notificadas. Omitir la notificación de vulnerabilidades activamente explotadas.

Caso práctico

Un editor de software ampliamente desplegado descubre que una dependencia open source integrada presenta una vulnerabilidad activamente explotada. Gracias a su SBOM, identifica en horas las versiones afectadas, publica un parche en el marco de su política de soporte y notifica a la ENISA — cadena de reacción exigida por el CRA e imposible sin nomenclatura ni PSIRT establecidos.

Hoja de ruta de cumplimiento

1. 1

   Establecer un SBOM. Cartografiar todos los componentes de software y sus dependencias.

2. 2

   Implantar un PSIRT. Estructurar la gestión y la divulgación coordinada de vulnerabilidades.

3. 3

   Definir el período de soporte. Fijar y comunicar el plazo de suministro de los parches.

4. 4

   Preparar el cumplimiento. Constituir la documentación técnica y la evaluación de conformidad con vistas al marcado CE.

5. 5

   Instrumentar la notificación. Establecer el proceso de notificación de vulnerabilidades explotadas a la ENISA.

Preguntas frecuentes