Ley Cibernética: Qué deben hacer ya los fabricantes

7 min. de lectura

El Cyber Resilience Act (CRA) de la UE entra en vigor a partir de diciembre de 2024 y afecta a cualquier fabricante que introduce productos con elementos digitales en el mercado europeo. A partir de septiembre de 2026, se implementan las primeras obligaciones de notificación, y a partir de diciembre de 2027, todos los productos deben cumplir con las nuevas exigencias de ciberseguridad. Para el sector manufacturero, esto significa que cualquier sensor conectado, cualquier control de máquina y cualquier componente de software están sujetos a la regulación. El tiempo para actuar es limitado.

Lo más importante en resumen

¿Qué regula el CRA y quién se ven afectados?

El Cyber Resilience Act es la primera regulación de la UE que introducir obligaciones de ciberseguridad vinculantes para todos los productos con elementos digitales. Su ámbito de aplicación está diseñado de manera consciente para ser amplio: Incluye dispositivos de hardware conectados como enrutadores, dispositivos de Smart Inicio y sensores industriales IoT, así como software puramente, incluyendo apps, sistemas operativos y firewalls.

Para el sector manufacturero, los implicaciones son amplias. Cualquier control de máquina con conexión a la red, cualquier sensor con función de actualización de firmware y cualquier sistema embebido en una planta de producción están sujetos a la regulación.

Especialmente relevante para el sector manufacturero: Incluso los importadores y distribuidores que introducen productos en la UE también tienen obligaciones propias. Quien importa un modulo IoT de origen chino y lo vende bajo su propio etiqueta se considera un fabricante y debe probar la conformidad completa al CRA. Esto afecta a muchos fabricantes de maquinaria y integradores de sistemas que incorporan componentes de terceros en sus soluciones.

Incluso aquellos que no fabrican estos productos, sino que los integran en sus propias soluciones, tienen obligaciones de conformidad como integradores.

Excluidos son algunas categorías: Productos médicos (ya regulados por el MDR), vehículos de motor (regulación UNECE), aeronáutica y ciertos productos de seguridad nacionales. El software de código abierto solo está afectado si se comercializa.

«El CRA asegura que los productos de hardware y software con menos vulnerabilidades lleguen al mercado y que los fabricantes tomen la seguridad del producto a lo largo de su ciclo de vida en serio.»
– Comisión Europea, comunicado de prensa sobre el CRA, septiembre de 2022

Las tres fechas: ¿Cuándo cuál se aplica

El CRA entró en vigor el 10 de diciembre de 2024 y se aplicará en tres etapas. La primera fecha llega más rápido de lo que muchos negocios esperan.

11 de junio de 2026: La notificación de las instituciones de evaluación de conformidad será efectiva. A partir de este día, las autoridades nacionales deben haber nombrado las instituciones que pueden evaluar productos de alto riesgo (categoría I y II).

11 de septiembre de 2026: Las obligaciones de notificación para fallos y incidentes de seguridad comienzan. Los fabricantes deben informar a ENISA sobre las vulnerabilidades activas dentro de las 24 horas. Para incidentes graves, la fecha límite es de 72 horas. Esta obligación comienza seis meses antes de la aplicación completa y es la primera fecha límite duro para muchos negocios.

11 de diciembre de 2027: Aplicación completa de todas las exigencias. A partir de este día, solo se pueden distribuir productos CRA conformes con la etiqueta CE en el mercado EU. Los productos que ya estaban en el mercado antes de este día y no se hayan modificado sustancialmente, se protegen.

Categorías de productos: Estándar, Importante, Crítica

El CRA clasifica los productos en tres categorías de riesgo que determinarán cómo debe llevarse a cabo la evaluación de conformidad. La clasificación tiene implicaciones directas para el esfuerzo y los costos.

Productos estándar (alrededor del 90% de todos los productos): Esto incluye sensores IoT simples, dispositivos Smart Inicio sin funciones de seguridad, software de consumo y equipos de oficina. Los fabricantes pueden demostrar la conformidad mediante una autoevaluación. No se requiere un evaluador externo.

Productos importantes (categoría I): Sistemas operativos, firewalls, enrutadores, software de VPN, sistemas de administración de redes. Aquí es necesario una evaluación según normas armonizadas o una evaluación por una tercera parte.

Productos críticos (categoría II): Módulos de seguridad de hardware, puertas de enlace de Smart Meters, sistemas de control industriales e infraestructuras de clave pública. Aquí se requiere una evaluación de conformidad por una entidad designada de una tercera parte.

Lo que los fabricantes deben implementar en la práctica

Las exigencias de la CRA se pueden dividir en tres áreas: desarrollo seguro, gestión de vulnerabilidades y documentación.

Seguridad desde la concepción: Los productos deben desarrollarse según el principio «Seguro por defecto» desde la fase de diseño. Esto significa: superficie de ataque mínima, comunicación cifrada, contraseñas no codificadas y mecanismos de actualización seguros. Los fabricantes deben demostrar que la seguridad no se ha añadido posteriormente, sino que se ha integrado desde el principio.

Gestión de vulnerabilidades: Los fabricantes deben proporcionar actualizaciones de seguridad a lo largo del ciclo de vida del producto, al menos durante cinco años después de su lanzamiento al mercado. Las vulnerabilidades activamente explotadas deben informarse a la ENISA en un plazo de 24 horas. Esto requiere un proceso PSIRT (Product Security Incident Response Team) operativo.

Documentación técnica: Para cada producto debe existir una documentación completa: análisis de riesgos, descripción de la arquitectura de seguridad, informes de pruebas, SBOM (Software Bill of Materials) y una declaración de conformidad con la UE.

Un aspecto que a menudo se subestima es la obligación de proporcionar actualizaciones de seguridad gratuitas durante al menos cinco años. Para los fabricantes de componentes industriales con ciclos de vida de diez a veinte años, esto representa una obligación a largo plazo sustancial. Quien hoy entrega un módulo de control conectado debe garantizar que estará seguro y actualizado hasta 2032. Esto requiere una arquitectura de software sostenible y una infraestructura de actualización operativa que se extienda más allá del ciclo de vida típico del producto.

En la práctica, también significa que los fabricantes deben reconsiderar sus relaciones con sus proveedores. Si una biblioteca de código abierto que se incluye en un producto deja de ser mantenida, el fabricante debe desarrollar los parches por sí mismo o reemplazar la componente. La SBOM se convierte en un sistema de alerta temprana: muestra las dependencias y dónde se encuentran los riesgos.

La SBOM es especialmente relevante, ya que debe enumerar todas las componentes de software, incluyendo las bibliotecas de código abierto.

SBOM: Por qué la lista de componentes de software será el cambio de juego

La Software Bill of Materials (SBOM) es uno de los nuevos instrumentos centrales de la CRA. En la práctica, es similar a una lista de ingredientes en una bebida: enumera cada componente de software que se incluye en un producto. Para muchos pequeños y medianos empresarios, esto representa un desafío, ya que las dependencias en las pilas de software modernas son complejas.

Un sistema embebido típico en una máquina de control contiene un sistema operativo en tiempo real, bibliotecas de comunicación, módulos de criptografía y decenas de otras componentes, que a menudo se integran como código abierto. Cada una de estas componentes puede contener vulnerabilidades que el fabricante debe conocer y controlar.

La buena noticia: existen estándares y herramientas estables. CycloneDX y SPDX son los formatos SBOM más utilizados. Las herramientas de compilación como Syft o Grype generan automáticamente SBOM a partir del repositorio de código. Para empresas que ya utilizan pipelines de CI/CD, la integración de la generación de SBOM en el proceso de compilación existente es posible sin perturbar el flujo de trabajo de desarrollo.

Para empresas que no desarrollan software propio y obtienen componentes de proveedores, se aplica: solicite a sus proveedores que proporcionen una SBOM. La CRA transfiere la responsabilidad a lo largo de la cadena de suministro. Quien integre componentes sin SBOM en sus productos es responsable de las vulnerabilidades desconocidas.

¿Cuánto costará el CRA para el sector mediano?

Los costos de cumplimiento dependen en gran medida de la categoría de producto y del nivel de madurez de los procesos de seguridad existentes. Para productos estándar con autovaloración, los expertos en la industria estiman costos únicos de 20.000 a 50.000 euros por línea de producto, principalmente para documentación, análisis de riesgos y creación de SBOM.

Para productos de categoría I y II que requieren una evaluación externa, los costos aumentan a 80.000 a 200.000 euros. Además, se deben considerar costos operativos para el manejo de vulnerabilidades: un proceso PSIRT dedicado con monitoreo, desarrollo de parches y notificaciones a ENISA requiere al menos una posición a tiempo parcial, aunque en la práctica a menudo más.

El balance: Los costos promedio de un incidente de ciberseguridad, según el BSI para el sector mediano, están en 500.000 euros. Un solo incidente grave superará los costos de cumplimiento durante varios años. Además, se obtiene un beneficio de acceso al mercado: quien cumple con el CRA puede comercializar sin restricciones en toda Europa, mientras que los competidores no conformes se ven excluidos del mercado.

CRA, NIS2 y AI Act: La tria reguladora

El CRA no existe aisladamente. Junto con NIS2 (seguridad de red e información) y el AI Act, forma una tria reguladora que afecta a las empresas europeas de manera simultánea. Para el sector mediano, esto significa: identificar superposiciones y aprovechar sinergias.

NIS2 obliga a los operadores de infraestructuras críticas y importantes a implementar un manejo de riesgos y notificar incidentes. El CRA obliga a los fabricantes de productos que estos operadores utilizan. Por ejemplo, si una empresa fabrica sensores IoT para proveedores de energía o software de control para plantas de agua, debe cumplir con el CRA para sus productos y con los requisitos de NIS2 para sus clientes.

La buena noticia: Muchos requisitos se superponen. Quien ya opera un sistema de gestión de seguridad de la información según ISO 27001 cubre en gran medida las necesidades organizativas. La requisición de SBOM del CRA se completa con las obligaciones de transparencia del AI Act para componentes de inteligencia artificial en productos.

Lista de control: Cinco pasos hacia el cumplimiento del CRA

El dezembre de 2027 puede parecer lejano, pero las obligaciones de notificación a partir de septiembre de 2026 están a seis meses de cumplirse. Una hoja de ruta pragmática.

1. Inventario de productos. ¿Qué productos con elementos digitales comercializa la empresa? ¿Cuáles de ellos tienen conexión a la red, firmware o componentes de software? La identificación de productos es la base para la clasificación de riesgos.

2. Clase de riesgo. Para cada producto, determinar: estándar, categoría I o categoría II. La clasificación determinará si una autovaloración es suficiente o se requiere un evaluador externo.

3. Proceso PSIRT. A partir de septiembre de 2026, las vulnerabilidades deben informarse en las 24 horas. Para ello, se necesita un proceso de respuesta a incidentes operativo con roles claros, datos de contacto para ENISA y un procedimiento de notificación documentado.

4. SBOM. Para cada producto, crear una declaración de materiales de software que enumere todos los componentes de software, incluyendo versiones y licencias. Herramientas como CycloneDX o SPDX automatizan este proceso.

5. Implementar ciclo de vida de desarrollo seguro. La seguridad desde la concepción debe integrarse en el proceso de desarrollo. Esto incluye modelado de amenazas, revisión de código, pruebas de penetración y mecanismos de actualización seguros.

Ejemplo práctico: Un pequeño empresario en camino a la CRA-Compliance

Un fabricante de sensores de temperatura y humedad con 80 empleados en Suiza produce sensores para la industria de alimentos. Los sensores tienen conexión WLAN, envían datos de medición a una plataforma en la nube y reciben actualizaciones de firmware sobre la marcha. Hasta ahora, no había un manejo estructurado de las vulnerabilidades y no había un inventario de componentes de software (SBOM).

Paso uno: Inventario de productos. La empresa identifica tres líneas de productos con elementos digitales, todas con riesgo estándar (autoevaluación posible). Paso dos: Creación de SBOM. Un proveedor externo analiza el código de firmware y crea una SBOM CycloneDX. Resultado: 47 componentes de software, de los cuales 12 son bibliotecas de código abierto, de las cuales tres no se mantienen desde hace más de un año. Estas tres deben reemplazarse o patcheadas por sí mismas.

Paso tres: Implementación de PSIRT. El líder de desarrollo de software assume el papel de responsable de seguridad. Se define un proceso simple: Monitoreo de vulnerabilidades a través de la National Vulnerability Database (NVD), evaluación en 48 horas, notificación a ENISA en 24 horas en caso de una explotación activa. Paso cuatro: Documentación. Se crean análisis de riesgos, arquitectura de seguridad y informes de pruebas. Gasto total: aproximadamente 35.000 euros y tres meses de duración del proyecto.

Resumen

El Cyber Resilience Act cambiará sustancialmente la forma en que se desarrollan productos en Europa. Para el pequeño empresario productivo, no es una recomendación opcional, sino una condición obligatoria para el acceso al mercado. Cualquier empresa que venda productos conectados en la UE debe ser conforme con la CRA a partir de diciembre de 2027.

La primera fecha límite no es el diciembre de 2027, sino septiembre de 2026: a partir de entonces, se deben notificar las vulnerabilidades. Seis meses no son mucho tiempo para implementar un proceso PSIRT si aún no existe. Quien comienza ahora, tendrá éxito. Quien espera, tendrá que trabajar bajo presión de tiempo. La inversión en CRA-Compliance no es solo un costo, sino una inversión en la calidad del producto, la seguridad del cliente y el acceso al mercado a largo plazo en un Europa donde la ciberseguridad se convierte en una necesidad básica.

Preguntas frecuentes

Lectura complementaria

Ley AI a partir de agosto de 2026: KI de alto riesgo en la pequeña y mediana empresa

Ataque de cadena de suministro GlassWorm: 400+ herramientas comprometidas – SecurityToday

Seguridad de la cadena de suministro de contenedores: Docker y SBOM – cloudmagazin

Fuente de la imagen de portada: Anete Lusina / Pexels