El Reglamento de Máquinas de la UE desde el 20 de enero de 2027: qué le exige al software de tus máquinas

El 20 de enero de 2027, la Directiva de Máquinas queda sustituida por el Reglamento (UE) 2023/1230, el Reglamento de Máquinas. La mayor parte le resultará familiar a cualquiera que construya máquinas con marcado CE. Una parte no. Por primera vez, la normativa de máquinas impone obligaciones directamente al software: la máquina tiene que indicar qué software necesita para funcionar con seguridad, detectar cuándo cambian ese software o su configuración, resistir la corrupción y conservar durante cinco años un rastro de las actualizaciones del software de seguridad.
Esto va dirigido a los directores de ingeniería y de automatización de los fabricantes de maquinaria. Si envías máquinas a la UE después de esa fecha, estos requisitos acaban en tus programas de PLC, en tu HMI, en tu acceso remoto y en el back end de tus actualizaciones.
Qué dice realmente la norma
La Comisión Europea afirma que el Reglamento «se aplica con carácter obligatorio a partir del 20 de enero de 2027» y que «incorpora disposiciones de ciberseguridad para los datos de software relevantes para la conformidad y los sistemas de mando de seguridad». El texto publicado en 2023 decía 14 de enero; una corrección de errores cambió la fecha.
Las obligaciones de software están en dos requisitos esenciales de salud y seguridad del anexo III del Reglamento.
Punto 1.1.9, protección contra la corrupción. En resumen:
- Conectar otro dispositivo a la máquina, directamente o a distancia, no debe provocar una situación peligrosa.
- El software y los datos que sean esenciales para cumplir los requisitos de seguridad «se indicarán como tales» y se protegerán contra la corrupción accidental o intencionada.
- El hardware que transmite señales o datos que dan acceso a ese software (piensa en un puerto de programación o en una interfaz de red hacia el controlador de seguridad) también tiene que protegerse, y la máquina tiene que recoger pruebas de cualquier intervención en él.
- La máquina «indicará el software que tenga instalado y que le resulte necesario para funcionar con seguridad, y deberá ser capaz de proporcionar esa información en todo momento de forma fácilmente accesible».
- La máquina «recogerá pruebas de toda intervención legítima o ilegítima en el software o de toda modificación del software que tenga instalado o de su configuración».
Punto 1.2.1, seguridad y fiabilidad de los sistemas de mando. Los sistemas de mando tienen que resistir los «intentos hostiles razonablemente previsibles de terceros de provocar una situación peligrosa». La letra f) añade la obligación de registro: el registro de seguimiento de los datos generados en relación con una intervención, y de las versiones del software de seguridad cargadas después de la introducción en el mercado de la máquina, tiene que estar «habilitado durante cinco años a partir de dicha carga». El registro existe para demostrar la conformidad cuando una autoridad nacional lo solicita de forma motivada, y para nada más.
También figura en la lista: la documentación técnica tiene que poder aportar «el código fuente o la lógica de programación del software relacionado con la seguridad» si una autoridad lo pide (anexo IV).
Qué máquinas están afectadas
Las normas se aplican a las máquinas introducidas en el mercado a partir del 20 de enero de 2027. Las máquinas introducidas en el mercado conforme a la antigua Directiva antes de esa fecha pueden seguir comercializándose (artículo 52), y las nuevas normas de software no alcanzan al parque ya instalado.
La trampa está en lo que significa «introducción en el mercado». La Guía azul de la Comisión dice que el concepto «se refiere a cada producto individual, no a un tipo de producto». Cada unidad que sale de tu fábrica hacia un cliente de la UE a partir del 20 de enero de 2027 tiene que cumplir los nuevos requisitos, software incluido. Una familia que se fabrica de forma continua necesita tener listo su software de control antes de la primera unidad de 2027, no en el próximo cambio de modelo.
Las actualizaciones posteriores también requieren reflexión. Un cambio hecho «por medios físicos o digitales» que el fabricante no previó, y que genera un nuevo peligro o aumenta un riesgo, puede ser una modificación sustancial. El considerando 32 dice que la evaluación de riesgos debe contemplar las actualizaciones de software previstas en el momento de la introducción en el mercado, así que describe ya ahí tu vía de actualización.
Qué significa en cada capa de la máquina
Controlador de seguridad y PLC
- Decide qué es relevante para la seguridad. Normalmente es el programa de seguridad, pero puede incluir código PLC estándar que alimenta una función de seguridad, parámetros de seguridad de los accionamientos y la configuración de los escáneres láser o de las cortinas fotoeléctricas. Déjalo por escrito para cada familia de máquinas; todo lo demás depende de ello.
- Referencia y comparación. Para cada configuración publicada, registra una suma de comprobación o una firma de cada elemento relevante para la seguridad. Al arrancar y a intervalos, la máquina compara lo que se está ejecutando con esa referencia y registra cualquier diferencia. Así se detecta la intervención que esquivó tu control de acceso, como un portátil conectado directamente al controlador.
- Cierra el acceso de ingeniería. Contraseñas en el programa de seguridad, puertos y servicios no utilizados desactivados, y acceso de ingeniería solo por una vía que autentique a la persona y registre lo que hizo.
HMI
- Una pantalla de identificación del software que enumere el software relevante para la seguridad con sus versiones y sumas de comprobación. Lee los valores en directo de los dispositivos. Una página redactada al publicar la versión se aleja de la realidad, y el requisito dice «en todo momento».
- Pantallas de parámetros. El punto 1.2.1, letra d), excluye las modificaciones de ajustes o reglas que puedan dar lugar a situaciones de peligro. Los parámetros relacionados con la seguridad van detrás de niveles de acceso, con límites impuestos en el controlador y no solo en la HMI, y cada cambio queda registrado con quién, cuándo, el valor anterior y el nuevo.
Acceso remoto
El punto 1.1.9 menciona expresamente los dispositivos remotos. En la práctica:
- Las funciones de seguridad siguen siendo locales. Una sesión remota puede leer, diagnosticar y preparar un cambio. No puede anular una parada, un resguardo ni un dispositivo de validación.
- Las sesiones se autentican por persona, no con una cuenta de servicio compartida, y el cliente puede ver cuándo hay una abierta.
- Cada inicio, fin y cambio de sesión va al mismo registro de pruebas que las intervenciones locales.
Back end y canal de actualizaciones
Si entregas actualizaciones después del envío, tu servidor de actualizaciones entra en el alcance del trabajo. Para cada número de serie tienes que saber qué versión del software de seguridad se cargó, cuándo y quién lo hizo. Firma las actualizaciones, y haz que la máquina compruebe la firma antes de instalar nada.
El propio registro de seguimiento
El Reglamento no dice dónde tiene que estar el registro. Nuestra opinión: la copia que cuenta está en la máquina, porque muchos clientes no permitirán una conexión permanente. Un espejo en la nube es útil, pero no puede ser la única copia.
El volumen es pequeño: intervenciones y cargas de software de seguridad, no datos de proceso. Cinco años caben en almacenamiento local si lo dimensionas a propósito. Protégelo contra el borrado y asegúrate de que sobrevive a un cambio de controlador. Si las entradas identifican a un técnico, son datos personales en las instalaciones del cliente: registra lo que exige el requisito y nada más.
Qué te da el fabricante de tu controlador y qué no
Tu plataforma de control te dará una parte de esto. Antes de construir nada, comprueba qué ofrece: una firma o una suma de comprobación sobre el programa de seguridad, protección por contraseña, gestión de usuarios, un registro de cambios, lectura de versiones. Usa lo que haya.
Son piezas de construcción. El fabricante no sabe cuáles de tus accionamientos y escáneres son relevantes para la seguridad, no ve tu pasarela remota ni tu servidor de actualizaciones, y no puede decidir cómo sobreviven las pruebas cinco años y un cambio de controlador. Configurar esas funciones, conectarlas en toda la máquina y documentar el resultado es trabajo del fabricante de la máquina, y es él quien firma la declaración UE de conformidad.
Cómo se relaciona con el Cyber Resilience Act
El Cyber Resilience Act va con su propio calendario. Sus obligaciones de notificación se aplican desde el 11 de septiembre de 2026, y sus requisitos completos se aplican a partir del 11 de diciembre de 2027. El Reglamento de Máquinas llega entre las dos fechas.
El CRA reconoce el solapamiento. El considerando 53 del Reglamento (UE) 2024/2847 dice que los fabricantes de máquinas que sean también productos con elementos digitales deben cumplir ambos, y que cumplir el CRA «podría facilitar» el cumplimiento de los puntos 1.1.9 y 1.2.1. Es el fabricante quien tiene que demostrar esa sinergia. El anexo I del CRA pide proteger la integridad de «los comandos, los programas y la configuración» e informar sobre los casos de corrupción, algo muy parecido a lo que pide el punto 1.1.9.
Hay una diferencia que importa para el diseño de tu registro. El requisito del CRA de registrar y vigilar la actividad interna viene «con un mecanismo de exclusión voluntaria para el usuario». El registro de seguimiento del Reglamento de Máquinas tiene que seguir habilitado durante cinco años. Construye un único mecanismo de registro si quieres, pero no dejes que la exclusión voluntaria del CRA desactive el registro de máquinas.
Construye ya para el Reglamento de Máquinas, porque llega antes, y diséñalo para que el mismo almacén de pruebas, la misma firma y los mismos registros de actualizaciones sirvan para el CRA en diciembre de 2027.
Las normas y el aplazamiento que no prosperó
No cuentes con que se cite una norma armonizada que cubra estos requisitos antes del 20 de enero de 2027. La página de normas armonizadas de la Comisión, actualizada en septiembre de 2026, dice que se está preparando la primera lista conforme al Reglamento de Máquinas. Recogerá la mayoría de las normas citadas conforme a la Directiva y las aclarará donde «todavía no abordan plenamente» los nuevos requisitos, y «cabe esperarla antes de que termine este año».
En enero de 2026, CEMA, CECE, CECIMO, EGMF y FEM pidieron en una posición conjunta del sector que los puntos 1.1.9 y 1.2.1, letra f), se aplazaran al 11 de diciembre de 2027, en línea con el CRA. Cifraron los costes de cumplimiento en «más de 1 millón de euros por arquitectura de plataforma» y dijeron que las normas previstas siguen siendo muy generales sobre el registro de datos del punto 1.2.1, letra f).
Esa petición no se aceptó. El Reglamento de Máquinas se modificó en julio de 2026 mediante el Reglamento (UE) 2026/1744, pero esa modificación trata de los sistemas de IA de alto riesgo en las máquinas y no toca la fecha de aplicación. Planifica con el 20 de enero de 2027.
Así que es posible que el primer día no tengas ninguna norma que dé presunción de conformidad para estos dos requisitos. En ese caso, tu expediente técnico tiene que describir la solución que aplicaste para cada uno (anexo IV). Escríbelo mientras construyes, no después. Para las máquinas que figuran en el anexo I, parte B, hay un paso más: la autoevaluación solo es posible si las normas armonizadas o las especificaciones comunes cubren todos los requisitos pertinentes; de lo contrario interviene un organismo notificado (artículo 25). Las máquinas que no figuran en el anexo I se autoevalúan en cualquier caso.
Un plan de 15 semanas
Del lunes 5 de octubre de 2026 a la fecha límite hay algo más de 15 semanas, con las fiestas en medio. Es justo pero viable si priorizas por fecha de envío: primero van las familias con unidades para la UE que salen en enero.
- Semanas 1 y 2 (del 5 al 16 de octubre): alcance. Haz una lista de todas las familias de máquinas que enviarán unidades a la UE después del 20 de enero de 2027. Para cada una, enumera el software y los datos relevantes para la seguridad: programa de seguridad, código estándar esencial para la conformidad, parámetros de seguridad de accionamientos y sensores, HMI, firmware y pasarela remota. Nombra un responsable por familia.
- Semanas 3 y 4 (del 19 al 30 de octubre): evaluación de riesgos y carencias. Actualiza la evaluación de riesgos para las conexiones, el acceso remoto, los intentos hostiles y la vía de actualización. Comprueba qué ofrece tu plataforma de control y qué está activado.
- Semanas 5 a 9 (del 2 de noviembre al 4 de diciembre): desarrollo. Pantalla de identificación del software, comparación con la referencia, control de acceso de ingeniería y remoto, el registro de seguimiento con capacidad para cinco años, actualizaciones firmadas y registros por número de serie en el back end.
- Semanas 10 y 11 (del 7 al 18 de diciembre): pruébalo como lo harían un técnico y un atacante. Cambia un parámetro de seguridad directamente con la herramienta del fabricante y confirma que la máquina lo registra. Cambia un controlador y comprueba que el registro sobrevive. Corta la corriente durante una actualización.
- Semanas 12 y 13 (del 21 de diciembre al 1 de enero): fiestas. No planifiques trabajo de ingeniería; deja una prueba de resistencia llenando el registro hacia su tamaño de cinco años.
- Semanas 14 y 15 (del 4 al 15 de enero): documentación y publicación. Las entradas del expediente técnico para los puntos 1.1.9 y 1.2.1, unas instrucciones de uso que expliquen cómo lee el cliente la identificación del software y qué puede y qué no puede hacer el acceso remoto, y un paso de producción que cargue la referencia publicada y la registre por número de serie.
Si hay más arquitecturas de plataforma que lo necesiten de las que caben en ese plazo, díselo ya a ventas: una unidad que no esté lista no puede introducirse legalmente en el mercado de la UE.
Para quién no es esto
Las máquinas introducidas en el mercado antes del 20 de enero de 2027 no se ven alcanzadas por estas normas de software, salvo que alguien las modifique después de forma sustancial. Si compras máquinas en lugar de fabricarlas, la obligación recae en tu proveedor; lo que te toca a ti es pedir en tus especificaciones la identificación del software y el acceso al registro.
Dónde conseguir ayuda
Somos una empresa de software, no un organismo notificado ni un bufete de abogados. Construimos y modificamos el software en el que acaban estos requisitos: aplicaciones de HMI y de back end, pasarelas de acceso remoto, canales de actualización y registro de pruebas, trabajando junto a los ingenieros de automatización responsables del programa de seguridad. Las plataformas antiguas con años de código acumulado son el caso más difícil, y ahí es donde suele empezar nuestro trabajo de mantenimiento de sistemas heredados; la parte del CRA la cubre nuestra guía del Cyber Resilience Act. Si tu equipo tiene el plan pero no las manos para terminarlo antes de enero, escribe a office@c9group.dev.