CRA para fabricantes de maquinaria tras las directrices de la Comisión de 27 de julio de 2026. ¿Qué hay que implantar realmente?

Durante años, la ciberseguridad de una máquina podía resumirse en tres pasos: un controlador de marca, una VPN «porque así se hace» y el clásico «el cliente ya protegerá la red». Y si además alguien añadía un firewall en el armario, el asunto solía darse por cerrado, al menos hasta que alguien intentaba comprobar qué ocurría ante un ataque real y no en una presentación.

El problema es que la ciberseguridad no circula por PROFINET. Los componentes pueden tener certificados, declaraciones y un «secure by design» en el folleto comercial, pero la máquina en su conjunto puede seguir siendo predecible de una forma que no tiene nada que ver con la seguridad. Igual que un relé de seguridad no convierte un sistema en seguro si la lógica de control permite eludirlo, un HMI «seguro» no resuelve por sí solo los problemas de arquitectura, integración, permisos, actualizaciones y de lo que ocurre cuando alguien deja de pedir permiso.

El CRA (Cyber Resilience Act, Reglamento del Parlamento Europeo y del Consejo (UE) 2024/2847) no es un añadido para IT. Es una normativa de producto que entra de lleno en el ciclo de vida de la máquina sin pedir permiso al departamento de automatización. Abarca el diseño del control, el análisis de riesgos, la cadena de suministro, la configuración, las actualizaciones, así como el mantenimiento del producto mucho después de que se haya firmado el FAT y la máquina haya salido de la nave. Y no, el argumento «no la conectamos a internet» no cierra el tema. En la práctica, basta un portátil de servicio, una memoria USB, un diagnóstico remoto «solo un momento» o la integración con un sistema de planta para que la frontera entre aislamiento y exposición deje de existir.

Las directrices de la Comisión de 27 de julio de 2026 no modificaron el propio reglamento, pero sí redujeron de forma efectiva el margen de interpretación que antes permitía tratar la ciberseguridad como una capa opcional. Se precisó, entre otras cosas, el límite del producto, el papel del tratamiento remoto, la responsabilidad por los cambios posteriores a la entrega y el hecho de que «después del FAT ya no es nuestro problema» ha dejado de ser una suposición segura.

Sin embargo, el cambio más importante es más de fondo: un ciberataque deja de ser exclusivamente un incidente de IT y pasa a convertirse en un escenario que afecta a la seguridad funcional de la máquina. Si una modificación no autorizada del programa puede provocar el movimiento de un eje, la anulación de un enclavamiento, el cambio de parámetros del proceso o la pérdida de funciones de seguridad, ya no estamos hablando de un «incidente de red». Estamos hablando de un comportamiento potencialmente no controlado de la máquina, con independencia de que el origen haya sido un error de configuración, una vulnerabilidad del software o una intervención deliberada.

En este contexto, un pentest puntual antes del FAT deja de ser una prueba de conformidad y pasa a ser solo una instantánea del estado del sistema en un momento concreto. El CRA exige un enfoque continuo: desde el diseño, pasando por la producción y la puesta en marcha, hasta las actualizaciones, la gestión de vulnerabilidades, la respuesta ante incidentes y el mantenimiento durante el periodo de soporte declarado.

En la práctica, esto significa abandonar la idea de «hecho = seguro» y sustituirla por «mantenido = controlado». Sin la ilusión de que un firewall en el armario, una VPN y el certificado de un componente cierran el asunto. Y sin asumir que la ciberseguridad termina en el momento de firmar el acta de recepción.

En este artículo desgranamos qué cambian realmente las directrices del CRA para fabricantes, integradores y modernizadores de máquinas, sin reducir todo el tema al lema de «cambiemos la contraseña y añadamos una casilla de cybersecurity».

1. Para que una máquina quedara fuera del CRA, tendría que ser casi solo de contactores

En muchos proyectos, el alcance del CRA se comprueba con una sola pregunta:

¿La máquina va a estar conectada a internet?

No.

Entonces, asunto cerrado.

En el esquema hay un PLC, un HMI, varios accionamientos, entradas y salidas distribuidas, una isla de válvulas, un escáner de seguridad y un puerto para cargar el programa. El controlador se comunica con el panel por PROFINET, intercambia palabras de control y de estado con los accionamientos, y los sensores transmiten datos por IO-Link.

Pero no hay ningún router con tarjeta SIM.

Como todo el mundo sabe, los datos solo son datos cuando salen de la nave de producción.

Solo que el CRA no pregunta si la máquina tiene acceso a internet.

Pregunta si su finalidad prevista o su uso razonablemente previsible incluye una conexión de datos directa o indirecta, lógica o física, con un dispositivo o una red. No tiene por qué ser una conexión con la nube, con el servidor del fabricante ni con internet público. Puede realizarse por cable, por ondas de radio, mediante una interfaz de software o como parte de un sistema mayor.

Y aquí viene la pregunta clave: ¿qué transmite realmente datos en una máquina típica?

¿El HMI lee estados del PLC y escribe consignas?

¿El PLC envía al accionamiento una palabra de control y recibe a cambio velocidad, estado y código de error?

¿La isla de entradas y salidas transmite la imagen del proceso?

¿El sensor IO-Link envía el valor de medición, el identificador del dispositivo y datos de diagnóstico?

¿El safety PLC se comunica con los módulos a través de PROFIsafe?

¿El programa, la configuración de hardware o el firmware se cargan desde un portátil de servicio?

¿Las recetas, los informes o las actualizaciones pueden transferirse por USB?

Si la respuesta хотя бы una vez es «sí», lo más probable es que estemos ante una conexión de datos.

Y eso no cambia por el hecho de que:

• la máquina funciona en una red local,
• no tiene dirección IP pública,
• el puerto Ethernet se utiliza solo durante la puesta en marcha,
• el portátil lo conecta exclusivamente el servicio técnico,
• la comunicación se realiza únicamente dentro del sistema de control,
• el cliente prometió que nunca conectará la máquina a internet.

El CRA no solo abarca el uso descrito en el manual como uso previsto, sino también el uso razonablemente previsible. Por tanto, un puerto de servicio no deja de transmitir datos solo porque en el esquema figure la anotación «SERVICE ONLY».

Sin embargo, las directrices de la Comisión de 27 de julio de 2026 introducen una distinción importante.

No todo cable ni toda señal eléctrica constituye una conexión de datos.

Si la señal sirve exclusivamente para activar, desactivar o alimentar una función determinada y no transmite información codificada digitalmente, la mera existencia de dos estados eléctricos no basta para considerarla una conexión de datos.

Un pulsador que aplica tensión a la bobina de un contactor no se convierte en una interfaz digital solo porque su estado pueda describirse como cero o uno.

Del mismo modo, un final de carrera clásico integrado en un circuito de relés y contactores puede limitarse a abrir o cerrar el circuito. No transmite el número del dispositivo, un valor de proceso, un código de diagnóstico, la versión del firmware ni un telegrama que contenga varias informaciones.

Pero cuando ese mismo estado llega a un dispositivo inteligente, se codifica, se transmite por el bus, se vincula al diagnóstico y el receptor lo interpreta como información, la situación ya es distinta.

Por tanto, la frontera no está entre una máquina «online» y otra «offline».

Está entre una señal de control simple y el intercambio de información codificada digitalmente.

Por eso, en la práctica, una máquina que pretendiera quedar fuera del CRA únicamente por no tener conexión de datos tendría que parecerse más a un sistema clásico con pulsadores, finales de carrera, relés y contactores que a un proyecto actual abierto en TIA Portal.

Por supuesto, esto no supone una exclusión legal para los contactores.

Se puede construir una máquina sencilla con PLC que, tras un análisis detallado, no cumpla el criterio de alcance. Y también se puede añadir a un sistema de contactores un regulador digital, una interfaz de servicio o un módulo de comunicación y quedar exactamente al otro lado de la frontera.

El nombre del componente no decide la cuestión.

Lo que decide es lo que el producto hace realmente y con qué intercambia datos.

Por eso, antes de responder a la pregunta de si una máquina concreta está sujeta al CRA, hay que determinar:

• dónde se sitúa el límite del producto evaluado,
• qué dispositivos y elementos de software lo componen,
• qué interfaces físicas y lógicas tiene,
• qué información se transmite a través de ellas,
• qué conexiones son directas y cuáles se realizan a través de un sistema mayor,
• cuáles de ellas se producen durante el funcionamiento normal, la puesta en marcha, el diagnóstico, la actualización o el servicio,
• qué formas de uso son razonablemente previsibles, aunque el fabricante preferiría no preverlas.

Mientras no respondamos a estas preguntas, no sabremos si la máquina queda fuera del ámbito del CRA.

Como mucho, tendremos una frase cómoda:

«La máquina no está conectada a internet».

Solo que esa es la respuesta a una pregunta que el CRA no formula.

PROFINET no es internet. Y para el CRA ni siquiera tiene por qué serlo.

2. La ciberseguridad no se propaga por PROFINET

En muchos proyectos, el tema de la conformidad de la máquina empieza ya en la fase de compras.

PLC de un fabricante reconocido.
HMI con firmware actualizado.
Switch gestionable.
Router industrial con VPN.
Accionamientos con funciones de seguridad.
Safety PLC con el certificado correspondiente.

Para cada equipo, una declaración de conformidad, un manual y varios documentos con palabras como «secure», «encrypted» y «defence in depth».

Sobre el esquema, todo parece profesional.

Pero sigue sin saberse si la máquina completa es cibersegura.

Porque la ciberseguridad no «se transmite» por PROFINET.

Es un poco como una cerradura en una puerta:
puedes tener una cerradura muy buena en cada habitación, certificada, ensayada, con una documentación impecable y un holograma de «secure», pero eso sigue sin garantizar la seguridad si alguien dejó la puerta de entrada completamente abierta «porque así era más rápido durante la puesta en marcha».

Y aquí ocurre exactamente lo mismo: los componentes pueden ser ejemplares y, aun así, el sistema puede quedar… creativamente abierto.

El PLC no «transfiere» seguridad al HMI.
El firewall no «corrige» la lógica de la aplicación.
El switch no «ordena» los accesos de los usuarios.
Y el hecho de que cada elemento tenga certificado no significa todavía que toda la máquina no sea una enorme vulnerabilidad, amablemente documentada.

PROFINET transmite datos.

No transmite responsabilidad.
Y, por desgracia, tampoco transmite sentido común.

El CRA abarca tanto los productos completos como los componentes comercializados por separado. Esto significa que el controlador, el panel de operador o el módulo de comunicación pueden evaluarse por separado. Pero el fabricante de la máquina sigue teniendo que demostrar que el conjunto funciona de forma segura en la configuración real del cliente, es decir, en esa versión en la que alguien «seguro que ya no cambió nada más… ¿verdad?».

Y aquí aparece el error más frecuente.

Es exactamente el mismo mecanismo que conocemos desde hace años en la seguridad de máquinas.

La cortina tiene PL e.
El Safety PLC tiene SIL 3.
El accionamiento dispone de STO.

¿Significa eso que toda la máquina queda automáticamente en ese mismo nivel?

Es como cuando cada componente de un andamio cumple las normas de seguridad: eso, por sí solo, no garantiza que toda la estructura sea estable.

No.

Porque todavía hay que comprobar cómo funciona todo en conjunto; es decir, esa fase poco popular de «pensar en el sistema» que, por desgracia, no tiene botón de «auto-certify».

En ciberseguridad ocurre exactamente lo mismo.

Puedes tener componentes «seguros», pero en la práctica:

• el operador ve y puede modificar más datos de los que realmente necesita, porque «así era más cómodo»,
• una única contraseña de servicio funciona en todas las máquinas, porque «el servicio técnico ya sabe lo que hace»,
• el puerto de servicio está accesible «por si acaso», es decir, para cualquier caso,
• el acceso remoto abarca toda la red, porque alguien dijo una vez «si solo es para diagnóstico»,
• las actualizaciones pueden cargarse sin control, porque «nunca ha pasado nada»,
• los dispositivos «confían entre sí» sin limitaciones, porque la confianza sale más barata que la segmentación,
• y la integración da por hecho que nadie cometerá nunca un error, lo cual es —como demuestra la historia— la hipótesis más optimista de la ingeniería.

Cada elemento, por separado, puede ser correcto.

Pero el sistema en su conjunto puede construir, a partir de esos elementos correctos, algo que funciona… aunque no necesariamente como se había previsto.

Y esto es lo importante: el riesgo no está en los dispositivos, sino en su interconexión, en la configuración y en ese acceso «dejado temporalmente» que todos conocen.

El CRA exige al fabricante de la máquina algo más que coleccionar declaraciones como si fueran trofeos. Exige comprobar si lo que se ha ensamblado a partir de componentes sigue siendo seguro como conjunto, y no solo que «quede bien en la tabla de conformidad».

En la práctica, esto se traduce en preguntas sencillas de negocio:

• si cada usuario tiene únicamente el acceso que realmente necesita, y no «por si algún día hace falta»,
• si el acceso remoto está limitado al mínimo o, más bien, al máximo de comodidad,
• si el servicio técnico no tiene «plenos permisos en todas partes» porque alguien decidió que así se agiliza todo,
• si la red no es una única superficie común porque la segmentación «complica el proyecto»,
• si las actualizaciones están controladas o más bien se «suben y rezamos»,
• si es posible identificar rápidamente qué máquinas están expuestas o si más bien «ya lo comprobaremos después del incidente»,
• si el fallo de un solo elemento no deja abierto todo el sistema porque «así salió en la integración».

No son preguntas técnicas «para los ingenieros de las cosas difíciles».

Son preguntas sobre riesgo de negocio: paradas, costes, responsabilidad y ese pequeño detalle de que la producción, al fin y al cabo, tiene que funcionar.

Por eso no basta con decir:

«todos los componentes son conformes»

Porque eso sigue sin responder a la pregunta:

¿toda la máquina es segura en el uso real, o solo en el PowerPoint de la revisión del proyecto?

La declaración del proveedor es importante.

Pero se refiere solo a un elemento: precisamente al que se ensayó en condiciones de laboratorio, no en un entorno de «algún punto de la planta, con VPN, USB y presión de tiempo».

No cubre cómo se ha utilizado.
No cubre la configuración.
No cubre la integración.
No cubre las decisiones tomadas «rápidamente durante la puesta en marcha, porque el cliente estaba esperando».
No cubre lo que ocurre tras años de explotación, cuando ya nadie recuerda por qué algo se dejó «abierto temporalmente».

Por eso la evaluación no puede terminar en una lista de dispositivos.

Hay que mirar el sistema como un todo:

• quién tiene acceso y por qué (y no «porque siempre lo ha tenido»),
• qué es realmente necesario y qué simplemente «se dejó porque no molestaba»,
• dónde pueden salir los datos fuera de control porque alguien consideró que «solo es diagnóstico»,
• qué ocurrirá si alguien utiliza un acceso legítimo de forma ilegítima (es decir, exactamente como actúan los ataques),
• con qué rapidez se puede reaccionar cuando aparezca un problema, y no «después de la revisión trimestral».

Mientras no haya respuesta a estas preguntas, solo tenemos un conjunto de componentes muy correctos.

Todavía no tenemos una máquina segura.

La conformidad de los componentes no crea automáticamente la conformidad del sistema. La conformidad de la máquina hay que diseñarla, verificarla y —lo más difícil— mantenerla a pesar de la tentación de «no tocar nada más, porque funciona».

3. No añadas el ciberataque a la lista de peligros. Une los dos análisis en el lugar correcto

En el mercado de la maquinaria, un análisis formal del riesgo de ciberseguridad sigue siendo más bien una excepción que un elemento estándar del proyecto.

Lo más habitual es que haya un router industrial.

Hay VPN.

Hay una contraseña para el PLC.

A veces hay un switch gestionable que luego nadie gestiona.

En la versión más ambiciosa, el fabricante recibe del proveedor una presentación sobre «defence in depth» y considera que con eso acaba de completar el análisis de riesgos de ciberseguridad de toda la máquina.

No lo ha completado.

Ha comprado unas cuantas medidas técnicas.

Eso todavía no es un análisis.

Por tanto, no tiene sentido describir el problema como si en cada proyecto se elaboraran dos evaluaciones profesionales —una según ISO 12100, otra sobre ciberseguridad— que simplemente, por casualidad, no se hubieran conectado entre sí.

Lo más habitual es que se elabore una sola.

Evaluación de riesgos de la máquina.

Y el análisis de ciberseguridad del producto ni siquiera llega a elaborarse.

La evaluación de riesgos de la máquina según ISO 12100 no consiste en anotar en una tabla:

fallo del sensor → movimiento inesperado → aplastamiento.

Eso puede ser un fragmento de un escenario concreto, pero no el punto de partida.

Primero hay que definir los límites de la máquina.

¿Cuál es su uso previsto?

¿Cuáles son las fases de su ciclo de vida?

¿Quién va a utilizarla?

¿Qué tareas se realizarán durante el transporte, el montaje, la puesta en marcha, la producción, el ajuste, la limpieza, la eliminación de atascos, el mantenimiento, el diagnóstico y el desmontaje?

¿En qué modos puede funcionar la máquina?

¿Dónde se encuentra la persona durante cada una de estas operaciones?

¿Qué partes de la máquina permanecen entonces bajo tensión, presión, carga o en movimiento?

¿Qué uso no se ajusta a las instrucciones, pero sigue siendo razonablemente previsible?

Solo después, para una tarea u operación concreta, se identifican, entre otros, los siguientes elementos:

• la fuente de peligro,
• el tipo de peligro,
• la zona de peligro,
• la persona expuesta,
• la situación peligrosa,
• el suceso peligroso, si aparece en ese escenario,
• las posibles consecuencias y el tipo de daño.

Así es como se realiza el análisis de riesgos de una máquina.

No se empieza por el componente.

Se empieza por la persona que realiza una tarea concreta en una máquina que se encuentra en un estado determinado. ISO 12100 establece precisamente esta metodología para identificar peligros, así como para estimar y evaluar el riesgo durante las fases pertinentes del ciclo de vida de la máquina.

Veamos un ejemplo sencillo.

El operario retira una pieza atascada del interior de una célula de paletizado.

Tenemos, por tanto:

Tarea: eliminación del atasco.

Fase de uso: explotación, intervención tras la parada del proceso.

Modo de funcionamiento: manual o de servicio.

Persona expuesta: operario o personal de mantenimiento.

Zona de peligro: interior de la célula, en particular el espacio entre la pinza, la pieza y la estructura de la máquina.

Fuente de peligro: energía mecánica del robot, del eje lineal o de la pinza neumática.

Situación peligrosa: la persona se encuentra en la zona mientras sigue siendo posible ejecutar un movimiento.

Suceso peligroso: movimiento inesperado del eje, cierre de la pinza o liberación de energía acumulada.

Posible consecuencia: golpe, aplastamiento, fractura o amputación.

Solo en este momento puede evaluarse el riesgo y definirse las medidas para reducirlo.

Puede ser necesario un enclavamiento del resguardo.

Puede ser necesaria una parada segura.

Puede ser necesario evitar una puesta en marcha inesperada.

Puede que haya que descargar la energía neumática.

Puede que el movimiento en modo manual solo pueda realizarse mediante un dispositivo de validación y a velocidad limitada de forma segura.

Esto sigue siendo una evaluación de riesgos clásica de la máquina.

¿Dónde entra la ciberseguridad?

No como una nueva categoría junto al peligro mecánico, eléctrico o térmico.

«Hacker» no es una fuente de peligro mecánico

Añadir a la tabla de ISO 12100 la entrada:

Peligro: ciberataque

aporta muy poco.

Un ciberataque no es un eje giratorio, un borde cortante, una temperatura elevada ni energía neumática.

Tampoco es una zona de peligro independiente.

El operario no sufre un aplastamiento por una vulnerabilidad CVE.

Lo sufre por un elemento de la máquina que ha ejecutado un movimiento cuando la persona se encontraba en un lugar inadecuado.

En cambio, un ciberataque puede alterar el estado del sistema de control, los datos, el programa, la configuración o la forma de actuar de una medida de protección.

Por tanto, puede convertirse en:

• la causa de un suceso peligroso,
• una vía adicional que conduce a una situación peligrosa,
• la causa de la pérdida de eficacia de una medida de reducción del riesgo,
• o una forma de eludir las hipótesis adoptadas durante el diseño de las funciones de seguridad.

Y ese es el verdadero punto de contacto.

No la lista de peligros.

El comportamiento de la máquina.

El análisis de ciberseguridad debe elaborarse por separado

En una máquina o un sistema de automatización, el análisis de ciberseguridad tendrá una estructura distinta de la evaluación de riesgos según ISO 12100.

La estructura más natural para un sistema de automatización industrial la proporciona IEC 62443-3-2.

La norma exige, entre otras cosas:

• definir el sistema objeto del análisis, es decir, el SUC,
• dividir el sistema en zonas y conductos de comunicación,
• evaluar el riesgo para cada zona y conducto,
• determinar los niveles de seguridad objetivo SL-T,
• documentar los requisitos de seguridad.

Es un punto de partida completamente distinto al de ISO 12100.

En IEC 62443 nos preguntamos, entre otras cosas:

¿Qué pertenece exactamente al sistema analizado?

¿Qué activos hay que proteger?

¿Qué dispositivos, aplicaciones e interfaces forman parte del sistema?

¿Qué elementos deberían pertenecer a la misma zona?

¿Cómo se desarrolla la comunicación entre zonas?

¿Quién puede obtener acceso?

¿Desde qué lugar?

¿Mediante qué interfaz?

¿Qué vulnerabilidades pueden explotarse?

¿Qué datos, funciones o componentes pueden modificarse?

¿Qué recorrido puede seguir un atacante desde el router de servicio hasta el PLC, el HMI, el accionamiento o la estación de ingeniería?

¿Qué consecuencias tendría la pérdida de confidencialidad, integridad o disponibilidad?

¿Qué medidas de protección son necesarias?

Para el proceso de desarrollo seguro del producto y para los requisitos aplicables a los propios componentes, también serán relevantes otras partes de la serie, en particular IEC 62443-4-1 e IEC 62443-4-2. Por su parte, IEC 62443-3-3 estructura los requisitos técnicos de seguridad a nivel de sistema.

Hoy por hoy, el CRA no obliga al fabricante a indicar en la portada del análisis «realizado conforme a IEC 62443».

IEC 62443 tampoco sustituye la demostración de conformidad con los requisitos del CRA.

Sin embargo, para un sistema de automatización industrial, constituye un punto de referencia mucho más lógico que intentar añadir unos cuantos escenarios de hacking a una tabla de ISO 12100.

Porque ambas metodologías responden a preguntas distintas.

ISO 12100:

¿Durante qué tarea, en qué lugar, a partir de qué fuente y como consecuencia de qué suceso puede una persona sufrir daños?

IEC 62443:

¿Quién, por qué vía y aprovechando qué vulnerabilidad puede influir en el sistema, en sus datos o en sus funciones?

Solo después hay que comprobar si la respuesta de ese segundo análisis modifica el escenario del primero.

Un mismo escenario, dos análisis diferentes

Volvamos al operario que retira una pieza atascada.

El análisis ISO 12100 mostró que la persona entra en una zona en la que puede ser aplastada por el movimiento del robot o de la pinza.

La medida de reducción del riesgo es un resguardo con enclavamiento, una función de parada segura y un rearme local situado fuera de la zona de peligro.

Ahora realizamos el análisis de ciberseguridad del sistema.

Identificamos:

• el router utilizado para el servicio remoto,
• la cuenta de servicio,
• el portátil de ingeniería,
• el HMI,
• el PLC estándar,
• el safety PLC,
• los accionamientos,
• la interfaz de programación,
• la red PROFINET y la comunicación PROFIsafe,
• los mecanismos de carga del programa y de configuración.

Consideramos el siguiente escenario:

La toma de control de la cuenta de servicio permite acceder de forma remota al PLC estándar y enviar una orden de movimiento mientras hay una persona dentro de la célula.

¿Este escenario conduce a un suceso peligroso?

No puede responderse basándose únicamente en el hecho de que se haya comprometido el PLC.

Hay que verificar la arquitectura de las funciones de seguridad.

Si la apertura del resguardo está supervisada por el safety PLC, la función desconecta de forma segura el par de los accionamientos, el rearme es exclusivamente local y el PLC estándar no puede restablecer el movimiento con independencia del estado de la función de seguridad, la toma de control del controlador estándar puede detener la producción o dañar el proceso.

Pero no debería provocar movimiento con el resguardo abierto.

En ese caso, el análisis de ciberseguridad evidencia un ataque.

La evaluación de riesgos de la máquina evidencia un peligro mecánico.

Sin embargo, una función de seguridad correctamente diseñada corta la vía entre ambos.

Y ahora, una segunda variante.

El modo de servicio se selecciona desde un HMI convencional.

El valor de velocidad limitada procede del PLC estándar.

El técnico remoto puede ejecutar el rearme.

La misma cuenta de ingeniería permite modificar el programa estándar y la configuración de safety.

La copia del programa de safety no está vinculada a una versión concreta de la máquina.

Nadie verifica la suma de comprobación después de la intervención.

Los parámetros del accionamiento pueden modificarse a distancia.

En esta arquitectura, la toma de control de la cuenta ya no implica únicamente una pérdida de confidencialidad o una breve parada.

Puede alterar las condiciones en las que se basaba la reducción del riesgo.

Puede dar lugar a:

• la selección de un modo incorrecto,
• la modificación de un parámetro de movimiento seguro,
• un rearme no autorizado,
• la carga de una configuración no aprobada,
• o el debilitamiento de la función que debía evitar una puesta en marcha inesperada.

Y entonces el escenario de ciberseguridad debe vincularse con un escenario concreto de seguridad de la máquina:

tarea de desatasco → persona en la zona de peligro → modificación no autorizada del sistema de control o de la función de protección → movimiento inesperado → aplastamiento.

La fuente del peligro no ha cambiado.

Sigue siendo la energía mecánica de la máquina.

La zona de peligro no ha cambiado.

Sigue estando dentro de la célula.

La posible consecuencia no ha cambiado.

Sigue siendo la lesión del operario.

Lo que ha cambiado es la vía que conduce al suceso peligroso.

No toda vulnerabilidad debe incluirse en ISO 12100

Esta distinción es igual de importante.

Supongamos que una vulnerabilidad en el HMI permite leer datos históricos de producción.

Eso puede ser un problema relevante desde el punto de vista del CRA.

Puede vulnerar la confidencialidad de los datos.

Puede requerir una actualización, una evaluación del impacto, actuaciones dirigidas a los usuarios y, en determinadas circunstancias, también notificación.

Pero si no influye en el comportamiento de la máquina, no modifica una medida de protección y no puede dar lugar a una situación peligrosa, no tiene sentido forzar su inclusión en la evaluación de riesgos según ISO 12100.

Del mismo modo, un ataque que provoque únicamente la indisponibilidad de los informes de producción puede suponer un problema de negocio y también un problema de conformidad con el CRA.

Sin embargo, no tiene por qué generar un riesgo para el operador.

Por otro lado, una posibilidad aparentemente inocua de modificar un único valor de consigna puede tener poca relevancia para la confidencialidad de los datos, pero una importancia enorme para la seguridad física.

Por ejemplo, cuando ese valor determina:

• la velocidad máxima de un eje,
• la fuerza de apriete,
• la temperatura del proceso,
• la presión,
• la posición de parada,
• el tiempo de apertura de una válvula,
• o el límite permitido durante el funcionamiento con el resguardo abierto.

Por tanto, no clasificamos una ciberamenaza por lo técnico que suene.

Analizamos qué puede hacer realmente a la máquina.

El Reglamento de Máquinas obliga a tender ese puente

Esta conexión no es solo una buena práctica de ingeniería.

El punto 1.2.1 del anexo III del Reglamento de Máquinas exige que los sistemas de mando se diseñen y fabriquen de manera que se eviten situaciones peligrosas, también como consecuencia de intentos maliciosos de terceros razonablemente previsibles.

Por su parte, el CRA indica que sus requisitos esenciales de ciberseguridad pueden contribuir a demostrar la conformidad, entre otros, con los requisitos 1.1.9 y 1.2.1 del Reglamento de Máquinas.

Pero esto no ocurre de forma automática.

El fabricante debe demostrar esa relación sobre la base de la evaluación de riesgos. La evaluación de la conformidad según el CRA y la evaluación de la conformidad según el Reglamento de Máquinas siguen siendo procesos separados.

Es decir, no basta con preparar:

• una evaluación de riesgos ISO 12100,
• un análisis IEC 62443,
• dos informes independientes,
• y confiar en que la similitud de los números de las normas cree entre ellos una trazabilidad de auditoría.

Hace falta una vinculación.

Para cada escenario cibernético relevante, hay que determinar:

1. qué elemento o función puede ser tomado o modificado,
2. qué comportamiento de la máquina puede provocar,
3. si ese comportamiento conduce a una situación peligrosa o a un suceso peligroso,
4. a qué tarea y a qué zona de peligro afecta,
5. qué posible consecuencia se ha identificado en la evaluación ISO 12100,
6. qué medida de reducción del riesgo debe interrumpir el desarrollo del escenario,
7. si esa medida sigue siendo eficaz después de que el elemento atacado haya sido comprometido.

Este último punto es el más importante.

Porque si el ataque y la protección dependen de:

• el mismo controlador,
• la misma cuenta,
• la misma red,
• la misma estación de ingeniería,
• o el mismo programa,

entonces es posible que no tengamos dos capas de protección independientes.

Tengamos una sola capa descrita en dos documentos.

Por tanto, no necesitamos una única tabla enorme con el nombre de:

«evaluación de riesgos safety & cybersecurity».

Necesitamos dos análisis correctos, realizados con las metodologías adecuadas, y un punto de contacto controlado entre ambos.

ISO 12100 debe describir a la persona, la tarea, la fuente de peligro, la zona, la situación peligrosa, el suceso peligroso y el posible daño.

IEC 62443 debe ayudar a describir el sistema, sus zonas, los canales de comunicación, los activos, las amenazas, las vulnerabilidades, las rutas de ataque y las protecciones necesarias.

Y el fabricante debe demostrar si el escenario de la segunda evaluación puede activar el escenario de la primera o anular la eficacia de la medida que debía detenerlo.

Un ciberataque no tiene por qué crear un peligro nuevo. Basta con que abra una nueva vía hacia un accidente ya conocido.

4. Un pentest antes del FAT es una foto. El CRA exige una película

En muchos proyectos, la ciberseguridad aparece dos semanas antes del FAT.

Se encarga un pentest.

Se genera un informe.

Se corrigen las vulnerabilidades críticas, se aceptan las medias y el documento acaba en la carpeta del proyecto.

La máquina es cibersegura.

Hasta el martes siguiente.

Un pentest puede ser un elemento de verificación muy valioso. Sin embargo, muestra el estado de una versión concreta del producto, en una configuración concreta y utilizando escenarios de prueba determinados.

No responde a la pregunta de qué hará el fabricante después.

Y el CRA se aplica a todo el ciclo de vida del producto. La evaluación del riesgo de ciberseguridad debe influir en la planificación, el diseño, el desarrollo, la producción, la entrega y el mantenimiento del producto. Una vez comercializado, el fabricante debe gestionar las vulnerabilidades durante el periodo de soporte declarado.

Volvamos a la máquina de envasado de verduras.

La máquina superó el FAT.

El pentest no detectó vulnerabilidades críticas.

Ocho meses después, el fabricante del router de servicio publica información sobre una vulnerabilidad que permite tomar el control del equipo.

Y ahí es donde empieza el trabajo de verdad.

¿Qué máquinas suministradas tienen ese modelo de router?

¿Qué versión de firmware se instaló en cada unidad?

¿Está activo el acceso remoto?

¿Puede explotarse la vulnerabilidad en la configuración real?

¿La toma de control del router da acceso únicamente al diagnóstico, o también al HMI, PLC, accionamientos y safety PLC?

¿Solo es posible leer datos, o también modificar el programa o los parámetros?

¿Puede el ataque afectar a una función de seguridad?

¿Ha publicado el proveedor una corrección?

¿La actualización del router cambiará los certificados, las reglas de comunicación o la forma de establecer el túnel?

¿Después de una actualización hay que volver a comprobar el servicio remoto, la comunicación y parte de las funciones de seguridad?

¿A qué clientes hay que notificarlo?

¿Y la situación cumple los criterios para comunicar una vulnerabilidad explotada activamente o un incidente grave?

El informe de un pentest realizado antes del FAT no responderá a ninguna de estas preguntas.

Describe una máquina que ya no existe.

Porque desde que se realizó el ensayo han cambiado las versiones del software, las configuraciones, el entorno del usuario y el conocimiento disponible sobre las vulnerabilidades.

Por eso, el fabricante no necesita solo una prueba, sino un proceso:

• identificar las versiones de hardware, firmware y software de cada unidad suministrada,
• supervisar la información sobre vulnerabilidades,
• evaluar su posible explotación en la arquitectura real,
• comprobar las posibles consecuencias para el proceso y la seguridad de la máquina,
• preparar y probar las actualizaciones,
• informar a los usuarios,
• documentar las decisiones adoptadas,
• gestionar las notificaciones exigidas.

A partir del 11 de septiembre de 2026, los fabricantes estarán obligados a notificar las vulnerabilidades explotadas activamente y los incidentes graves que afecten a la seguridad de los productos con elementos digitales. La alerta inicial deberá enviarse en un plazo de 24 horas, y la notificación completa en un plazo de 72 horas.

Eso significa que, una vez detectado el problema, no habrá tiempo para empezar a buscar:

«¿Quién fabricó realmente este router y dónde tenemos la lista de las máquinas en las que lo instalamos?»

CRA e IEC 62443-4-1 muestran bien la diferencia entre proteger un producto de forma puntual y mantener un ciclo de desarrollo seguro. No abarcan solo el diseño y la verificación, sino también la gestión de defectos, correcciones y el fin de vida del producto.

Por tanto, el FAT puede cerrar una fase del proyecto.

No cierra el ciclo de vida del producto.

No cierra el periodo de soporte.

No pone fin a la supervisión de vulnerabilidades.

Y no significa que la configuración del día de la recepción quede congelada durante los quince años siguientes.

La máquina puede pasarse mucho tiempo envasando verduras para supermercados.

Pero el fabricante no puede empaquetar su ciberseguridad junto con el manual, sellarla con film y dar por hecho que queda entregada de una vez para siempre.

Un pentest puede cerrar un punto de la lista del FAT. CRA abre un proceso que dura hasta el final del periodo de soporte del producto.