Ciberseguridad para fabricantes de maquinaria

A partir de 2027, una máquina con un controlador, una pantalla de operador o una conexión de datos responde ante dos reglamentos de la UE. Ambos parten de la misma pregunta: qué software hay en esta máquina, versión a versión, y qué contiene.

1. 11 de septiembre de 2026Se aplica la notificación de vulnerabilidades activamente explotadas e incidentes graves del Cyber Resilience Act.
2. 20 de enero de 2027Se aplica el Reglamento relativo a las máquinas, (UE) 2023/1230, que sustituye a la Directiva de máquinas.
3. 11 de diciembre de 2027El Cyber Resilience Act, (UE) 2024/2847, se aplica en su totalidad.

Reglamento relativo a las máquinas

Dos requisitos esenciales de salud y seguridad del anexo III tratan la ciberseguridad:

• 1.1.9, protección contra la corrupción. La conexión de otro dispositivo a la máquina, directa o a distancia, no debe dar lugar a una situación peligrosa. El software y los datos que son críticos para la conformidad de la máquina con los requisitos esenciales de salud y seguridad deben identificarse y protegerse contra la corrupción accidental o intencionada. La máquina debe identificar el software instalado en ella que necesita para funcionar de forma segura y facilitar esa información en todo momento. También debe recopilar pruebas de las intervenciones legítimas o ilegítimas en ese software o en su configuración.
• 1.2.1, seguridad y fiabilidad de los sistemas de mando. Los sistemas de mando deben resistir los intentos malintencionados razonablemente previsibles de terceros que den lugar a una situación peligrosa. Conforme a 1.2.1(f), deben llevar un registro de seguimiento de las intervenciones y de las versiones del software de seguridad cargadas después de la introducción de la máquina en el mercado, durante cinco años desde la carga.

Cyber Resilience Act

Una máquina con conexión de datos, o una parte de ella vendida por separado, es un producto con elementos digitales. El fabricante debe actuar con la diligencia debida respecto a los componentes de terceros que integra, elaborar una SBOM que cubra al menos las dependencias de nivel superior, gestionar las vulnerabilidades durante el período de soporte, que es de al menos cinco años salvo que se prevea que el producto se use durante menos tiempo, y conservar la documentación técnica durante al menos diez años o durante el período de soporte, si este es más largo.

No automáticamente. El Cyber Resilience Act no otorga presunción de conformidad con el Reglamento relativo a las máquinas. Su considerando 53 dice que cumplir los requisitos esenciales del CRA podría facilitar el cumplimiento de los requisitos del Reglamento relativo a las máquinas sobre protección contra la corrupción y sobre seguridad y fiabilidad de los sistemas de mando. También dice que el fabricante tiene que demostrarlo, por ejemplo aplicando normas armonizadas tras una evaluación de riesgos, y que los procedimientos de evaluación de la conformidad de ambos reglamentos siguen aplicándose.

La norma armonizada que se está elaborando para el punto 1.1.9 es la EN 50742, Safety of machinery – Protection against corruption. En noviembre de 2026 era un proyecto final, FprEN 50742, que cubre el punto 1.1.9 y los puntos relacionados del 1.2.1, y mientras la referencia de una versión definitiva no se publique en el Diario Oficial de la UE no otorga presunción de conformidad. Combina la evaluación del riesgo de la EN ISO 12100 con conceptos de seguridad de la IEC 62443, y acepta la aplicación coherente de la IEC 62443-4-1, la IEC 62443-3-3 y la IEC 62443-4-2 como una vía equivalente para cumplir sus objetivos de protección. La IEC 62443-4-2 establece los requisitos técnicos de seguridad de los componentes de sistemas de control, graduados por nivel de capacidad de seguridad. En Alemania, los principios de ensayo GS-IFA-M25, de julio de 2026, convierten la protección contra la corrupción en 66 criterios de ensayo, con la terminología del prEN 50742. Uno de ellos, el T46, pide que el producto pueda facilitar a petición la versión y la configuración del software instalado. Para responder a ello en cada configuración hace falta un registro de lo que contiene cada versión del software.

El Reglamento relativo a las máquinas tiene una presunción propia, y llega por otra vía: los esquemas europeos de certificación de la ciberseguridad adoptados en virtud del Reglamento sobre la Ciberseguridad, Reglamento (UE) 2019/881. Un certificado o una declaración de conformidad en el marco de uno de esos esquemas presume la conformidad con 1.1.9 y 1.2.1 en la medida en que cubra esos requisitos.

Así, una evaluación de riesgos y un conjunto de evidencias pueden servir para ambos reglamentos, pero la conformidad se demuestra con cada uno. Si su máquina tiene conexión de datos, planifique para ambos. Las evidencias del software, es decir, las SBOM, los registros de vulnerabilidades y el historial de actualizaciones, son la parte que comparten.

En enero de 2026, las asociaciones del sector de la maquinaria pidieron aplazar 1.1.9 y 1.2.1(f), y en marzo de 2026, que se aplicaran a partir de la fecha del CRA, el 11 de diciembre de 2027. Es una petición, no una ley: a noviembre de 2026 no se había adoptado ningún aplazamiento. Las fechas de esta página son las fechas de los reglamentos.

• Las máquinas de construcción, de manutención, de minería e industriales están sujetas al Reglamento relativo a las máquinas, y también al CRA cuando la máquina o sus partes tienen una conexión de datos.
• Los tractores agrícolas y forestales regulados por el Reglamento (UE) n.º 167/2013 están excluidos del Reglamento relativo a las máquinas, salvo las máquinas montadas en ellos. La lista de exclusiones del CRA no menciona ese reglamento, por lo que un tractor conectado puede entrar en el ámbito del CRA.
• Los vehículos de carretera homologados con arreglo al Reglamento (UE) 2019/2144 están excluidos del CRA.
• Componentes vendidos por separado. El CRA también se aplica a los componentes de software y hardware introducidos en el mercado por separado. Un proveedor que vende por separado una ECU o una unidad telemática es, por derecho propio, fabricante conforme al CRA. Cuando la unidad solo se integra en la máquina, el fabricante de la máquina asume la obligación para toda la máquina y debe actuar con la diligencia debida respecto al componente del proveedor.

Esto es información general, no asesoramiento jurídico. Compruebe la clasificación de su propio producto.

Dentro de una misma máquina, el software procede de distintos lugares, y solo el equipo que construye una pieza de software puede decir de forma fiable qué contiene. Según nos cuentan los fabricantes de maquinaria, las ECU bare-metal contienen poco código abierto, mientras que el software sobre Linux, Android y Windows contiene mucho.

Poco volumen, mucha variedad. Un fabricante de maquinaria puede tener cientos de plataformas en el mercado, vender un puñado de unidades de cada una al año y configurar muchas máquinas bajo pedido. Cada configuración es un conjunto de software distinto, por lo que una SBOM por cada build importa más que una SBOM por cada línea de producto.

Vidas útiles largas. Las máquinas siguen en servicio durante una década o más, mientras los proveedores cambian o desaparecen. El registro de lo que entró en una versión de software tiene que hacerse cuando se construye, porque no se puede reconstruir años después.

Predomina el software de proveedores, y sus SBOM suelen ser deficientes. Nos llegan SBOM de proveedores con componentes que faltan, sin URL de paquete ni CPE, sin licencias y sin hashes, algunas escritas a mano y que no superan la validación del esquema. El análisis binario de una ECU ya programada es un parche provisional: adivina el contenido en lugar de registrarlo.

El riesgo está en las capas conectadas. Gran parte de la lógica de las ECU se genera a partir de modelos y contiene poco código abierto. El código abierto, y la exposición a la red, se concentran en las capas de Linux, conectividad y aplicaciones, así que dedique allí su esfuerzo primero.

Un ejemplo ilustrativo: la pila de software de una plataforma ficticia de cargadora de ruedas, desde la nube hasta las ECU.

1. Back end en la nube y aplicación complementariaPropios. Mayoritariamente de código abierto y expuestos a la red. Cyber Resilience Act.
2. Pasarela telemáticaLinux embebido, mayoritariamente de código abierto, conectada a la red móvil. Cyber Resilience Act, y 1.1.9 por la conexión remota.
3. Pantalla del operadorImagen de Linux embebido con un framework de interfaz, mayoritariamente de código abierto, conectada al bus de la máquina y a las herramientas de servicio. Cyber Resilience Act y 1.1.9.
4. Controlador de la máquinaAplicación propia sobre una plataforma de un proveedor, relevante para la seguridad. 1.1.9 y 1.2.1, y el Cyber Resilience Act cuando se puede acceder a ella a través de una conexión.
5. ECU hidráulica, de dirección y de motorFirmware de proveedores, propietario y generado a partir de modelos, con poco código abierto, relevante para la seguridad. 1.1.9 y 1.2.1; el Cyber Resilience Act a través de la máquina.

El código abierto y la exposición a la red están en las tres capas superiores, que es también donde suelen estar sus propios pipelines de build. Empiece por ahí.

Los fabricantes de maquinaria fijan ahora requisitos de SBOM para el software que compran, como URL de paquete o CPE, licencias, hashes y un formato que supere la validación, y devuelven los archivos que no los cumplen. Si construye en GitHub Actions, CRACI produce la SBOM a partir del propio build, de modo que enumera lo que realmente entró en la versión, incluidos los componentes que ningún lockfile menciona, con una URL de paquete y la licencia declarada de cada componente. Compruebe la exportación con la lista completa de campos que pide su cliente. Más información sobre cómo responder a las solicitudes de SBOM de los clientes.