Reglamento de Máquinas 2027 · Reglamento (UE) 2023/1230
¿Qué exige el Reglamento de Máquinas en ciberseguridad?
El Reglamento (UE) 2023/1230 introduce un requisito esencial que no existía en la Directiva 2006/42/CE: el punto 1.1.9 del Anexo III, «Protección contra la corrupción». Obliga a proteger el software y los datos relevantes para la seguridad, a declarar qué software lleva instalado la máquina y a recoger pruebas de toda intervención, legítima o ilegítima. El Anexo I de la Directiva termina en el punto 1.1.8 y no contiene la palabra «corrupción» ni una sola vez.
¿Dónde habla el Reglamento de Máquinas de ciberseguridad?
En dos requisitos esenciales del Anexo III que no tienen equivalente en la Directiva: el punto 1.1.9, titulado «Protección contra la corrupción», y el punto 1.2.1, sobre seguridad y fiabilidad de los sistemas de mando. La palabra «ciberseguridad» no aparece en ninguno de los dos: el Reglamento la trata como un requisito de seguridad de la máquina, no como una disciplina aparte.
El considerando 25 explica el encuadre y marca el límite:
«Otros riesgos relacionados con las nuevas tecnologías digitales son los provocados por terceros malintencionados que afectan a la seguridad de los productos incluidos en el ámbito de aplicación del presente Reglamento. En este sentido, debe obligarse a los fabricantes a adoptar medidas proporcionadas que se limiten a proteger la seguridad de los productos incluidos en el ámbito de aplicación del presente Reglamento.»
considerando 25Esa frase acota el alcance y conviene leerla despacio. El Reglamento de Máquinas no pide proteger la confidencialidad de los datos de producción ni la disponibilidad de la línea: pide impedir que un tercero provoque una situación peligrosa. La continuidad de negocio y la protección del dato quedan fuera y las cubren otros actos de la Unión, que el mismo considerando declara aplicables en paralelo.
Qué exige exactamente el punto 1.1.9
El requisito tiene cinco párrafos y cada uno impone una obligación distinta. Es habitual leer solo el primero, que es el más citado y el menos exigente en la práctica documental.
| Obligación | Qué dice el Reglamento |
|---|---|
| Conexión sin peligro | La máquina se diseña y fabrica de manera que la conexión con otro dispositivo, «a través de cualquier característica del propio dispositivo conectado o a través de un dispositivo remoto que se comunique con la máquina», no provoque situaciones peligrosas. |
| Hardware protegido | El componente de hardware transmisor de señales o datos que sea pertinente para la conexión o el acceso al software esencial para la conformidad «se diseñará de manera que esté protegido adecuadamente contra la corrupción accidental o intencionada». |
| Pruebas de intervención en el hardware | La máquina o el producto relacionado «recogerán pruebas de toda intervención legítima o ilegítima» en ese componente de hardware, cuando sea pertinente. |
| Software y datos identificados y protegidos | El software y los datos esenciales para cumplir los requisitos esenciales «se indicarán como tales y se protegerán adecuadamente contra la corrupción accidental o intencionada». |
| Inventario de software accesible | La máquina o el producto relacionado «indicarán el software que tengan instalado y que les resulte necesario para funcionar con seguridad», y deberán poder «proporcionar esa información en todo momento de forma fácilmente accesible». |
| Pruebas de intervención en el software | La máquina o el producto relacionado recogerán pruebas «de toda intervención legítima o ilegítima en el software o de toda modificación del software que tengan instalado o de su configuración». |
Anexo III, 1.1.9
Los dos últimos son los que cambian el producto, no el papel. Una máquina que no sepa enumerar su propio software instalado, o que no registre un cambio de configuración, no cumple, por muy bien redactado que esté el expediente. Y la palabra «legítima» no está de adorno: el registro no es un detector de intrusiones, es una traza de todo cambio, incluido el que hace el propio servicio técnico en una puesta a punto.
Los sistemas de mando y los ataques previsibles
El punto 1.2.1 aborda el mismo problema desde el sistema de mando, y lo hace con una fórmula que traslada al fabricante una obligación de anticipación. Los sistemas de mando se diseñan y fabrican de manera:
«a) que resistan, cuando proceda según las circunstancias y los riesgos, los esfuerzos previstos de funcionamiento y las influencias externas previstas o no, incluidos los intentos hostiles razonablemente previsibles de terceros de provocar una situación peligrosa;»
Anexo III, 1.2.1, letra a)La fórmula «razonablemente previsibles» es el mismo criterio que el Reglamento y la Directiva usan para el mal uso, y arrastra la misma consecuencia: si el intento hostil era previsible y la evaluación de riesgos no lo recoge, la evaluación está incompleta. Esto convierte la amenaza deliberada en una entrada más del análisis de riesgos, junto al aplastamiento y al atrapamiento, y no en un anexo de informática que se adjunta al final.
¿Cuánto tiempo hay que conservar los registros de software de seguridad?
Depende del registro, y son dos plazos distintos en dos párrafos contiguos del mismo punto 1.2.1. El registro de las intervenciones y de las versiones de software de seguridad cargadas se mantiene cinco años desde cada carga. Los datos del proceso de toma de decisiones en materia de seguridad de los sistemas basados en software se conservan un año desde su grabación.
| Qué se registra | Cuánto | Dónde |
|---|---|---|
| Datos generados en relación con una intervención y versiones del software de seguridad cargadas después de la introducción en el mercado o la puesta en servicio | 5 años desde cada carga | Anexo III, 1.2.1, letra f) |
| Datos sobre el proceso de toma de decisiones en materia de seguridad de los sistemas de seguridad basados en software que garantizan la función de seguridad, incluidos los componentes de seguridad | 1 año desde su grabación | Anexo III, 1.2.1, párrafo sobre sistemas de mando con niveles de autonomía, letra b) |
Los dos comparten la misma finalidad tasada: se conservan «exclusivamente para demostrar la conformidad» si llega «una solicitud motivada de una autoridad nacional competente». Esa palabra, «exclusivamente», tiene efecto práctico en el diseño: el registro no se puede reutilizar para productividad, control del operario ni mantenimiento predictivo sin resolver aparte la base jurídica de ese otro tratamiento.
El segundo plazo solo alcanza a las máquinas cuyo comportamiento o cuya lógica sean «total o parcialmente autoevolutivos», diseñadas para operar con distintos niveles de autonomía. El primero alcanza a cualquiera que reciba software de seguridad después de salir de fábrica, que hoy es casi cualquier máquina con mantenimiento remoto.
¿Un certificado de ciberseguridad sirve para cumplir el Reglamento de Máquinas?
Sirve en parte y con condiciones. El artículo 20.9 concede presunción de conformidad con los puntos 1.1.9 y 1.2.1 del Anexo III a las máquinas certificadas con arreglo a un sistema de ciberseguridad adoptado según el Reglamento (UE) 2019/881, siempre que las referencias de ese sistema se hayan publicado en el Diario Oficial y solo en la medida en que esos requisitos sean objeto del certificado.
«Las máquinas y los productos relacionados que hayan sido certificados o respecto de los cuales se haya emitido una declaración de conformidad con arreglo a un sistema de ciberseguridad adoptado de conformidad con el Reglamento (UE) 2019/881 y cuyas referencias se hayan publicado en el Diario Oficial de la Unión Europea se presumirán conformes con los requisitos esenciales de salud y seguridad que figuran en el anexo III, puntos 1.1.9 y 1.2.1, en lo que respecta a la protección contra la corrupción y la seguridad y fiabilidad de los sistemas de mando en la medida en que dichos requisitos sean objeto del certificado de ciberseguridad o de la declaración de conformidad o partes de estos.»
art. 20.9Hay tres condiciones encadenadas y las tres tienen que cumplirse a la vez: que el sistema de certificación se haya adoptado conforme al Reglamento sobre la Ciberseguridad, que sus referencias estén publicadas en el Diario Oficial, y que el requisito concreto esté efectivamente cubierto por ese certificado. La última es la que suele fallar: la presunción se extiende a lo que el certificado cubra «o partes de estos», no al punto 1.1.9 entero por el hecho de tener un certificado colgado en la pared.
El considerando 51 confirma que el legislador la diseñó así, como una pasarela parcial y no como una vía alternativa de cumplimiento.
El software de seguridad también está en el Anexo I
La ciberseguridad no solo cambia los requisitos del producto: puede cambiar quién firma la conformidad. El Anexo I lista las categorías que reciben un tratamiento reforzado, y cuatro entradas son de software:
- Parte A, 5. «Componentes de seguridad con un comportamiento total o parcialmente autoevolutivo que utilicen enfoques de aprendizaje automático que garanticen funciones de seguridad.»
- Parte A, 6. Máquinas que incorporen sistemas con ese mismo comportamiento autoevolutivo, cuando no se hayan introducido de forma independiente en el mercado y únicamente respecto de dichos sistemas.
- Parte B, 18. «Software que garantiza las funciones de seguridad.»
- Parte B, 19. Componentes de seguridad autoevolutivos con aprendizaje automático que garanticen funciones de seguridad.
Las dos de la parte A llevan siempre organismo notificado. Las de la parte B lo evitan solo si existe una norma armonizada que cubra todos los requisitos esenciales aplicables. La diferencia entre una y otra parte, y lo que implica cada procedimiento, está desarrollada en qué categorías del Anexo I exigen organismo notificado.
Dónde estaba esto en la Directiva
En ningún sitio. Es la respuesta corta y es literal: el Anexo I de la Directiva 2006/42/CE termina en el punto 1.1.8, «Asientos», y en todo su texto consolidado no aparece ni una vez la palabra «corrupción» ni la palabra «ciberseguridad». El requisito 1.1.9 no sustituye a nada anterior: se añade.
Esto tiene una consecuencia incómoda para quien planifique la transición como una renumeración. Los otros cambios se pueden abordar revisando el expediente: cambian las referencias, cambia la estructura de la declaración, se reordenan los anexos. El punto 1.1.9 no se resuelve escribiendo, porque exige capacidades del producto que la máquina tiene o no tiene: enumerar su software, registrar intervenciones, proteger lo que es esencial para la seguridad. Si el diseño no las trae, el plazo real no termina el 20 de enero de 2027 en el departamento de documentación, sino antes, en el de ingeniería.
Lo que esto significa en la práctica
Cuatro puntos que separan al que llega a 2027 con esto resuelto del que llega con un informe:
- El inventario de software es una función de la máquina, no una hoja del expediente. El requisito dice «en todo momento» y «de forma fácilmente accesible». Un listado en un PDF del manual no lo cumple.
- El registro cubre la intervención legítima. Quien diseñe el registro pensando solo en el ataque se deja fuera la mitad del requisito, que es la actualización rutinaria del propio fabricante.
- Los dos plazos, cinco años y uno, no coinciden, y viven en párrafos contiguos del mismo punto. Cualquier política de retención que aplique un plazo único a los dos registros incumple uno de los dos.
- El intento hostil previsible entra en la evaluación de riesgos. No es un anexo de informática: es una entrada del mismo análisis que trata el aplastamiento, y se documenta igual.
Los seis requisitos de software y ciberseguridad, con el artículo de cada uno, están recogidos en el mapa de brechas junto a las correspondencias del Anexo XII.
Documento divulgativo de cambios normativos, actualizado el 18 de septiembre de 2026 sobre el texto consolidado 02023R1230-20260727. No es una evaluación de conformidad ni asesoramiento jurídico sobre un producto concreto. Las citas entrecomilladas son literales.