Una pantalla bloqueada puede parecer un problema informático.
Un motor que arranca cuando no debe, una alarma que deja de llegar al operador o un sistema de ventilación que pierde su control ya son otra cosa.
Entre ambos escenarios puede haber una conexión de red, una actualización de software, un acceso remoto o una alteración de un sistema de control.
La digitalización industrial ha conectado máquinas, sensores, PLC, sistemas SCADA, edificios e instalaciones que hace unos años funcionaban de forma mucho más aislada. Y esa conexión aporta enormes ventajas operativas, pero también obliga a revisar una frontera que muchas organizaciones todavía gestionan por separado:
¿qué ocurre cuando un incidente de ciberseguridad puede modificar físicamente las condiciones de trabajo?
En ese momento, la cuestión deja de pertenecer únicamente a IT. También afecta a producción, mantenimiento, emergencias y prevención de riesgos laborales.
IT y OT: parecidos por fuera, muy diferentes cuando algo falla
En términos sencillos, los sistemas IT —Information Technology— gestionan principalmente información y procesos digitales: correo electrónico, servidores, aplicaciones empresariales, bases de datos, ERP o puestos informáticos.
La OT —Operational Technology— controla o supervisa procesos físicos.
Dentro de este segundo grupo podemos encontrar PLC, SCADA, HMI, sensores, actuadores, robots, líneas automatizadas, sistemas de climatización industrial, instalaciones energéticas o determinadas funciones de edificios e infraestructuras.
La diferencia es fundamental desde el punto de vista preventivo.
Si falla un sistema IT, puede producirse pérdida de información, indisponibilidad de un servicio o interrupción de la actividad.
Cuando falla o se altera un sistema OT, además, puede cambiar lo que está ocurriendo físicamente en una instalación.
ENISA lleva años señalando el reto que supone la convergencia entre IT y OT. Y en su ejercicio Cyber Europe 2026 volvió a ponerlo sobre la mesa al simular ataques coordinados contra sistemas ferroviarios y marítimos que provocaban alteraciones operativas y situaciones de riesgo, incluidos incidentes de casi colisión en entornos portuarios.
Ese es precisamente el territorio en el que la ciberseguridad empieza a tener una lectura preventiva.
Cuándo un incidente digital puede convertirse en un riesgo físico
No cualquier ciberincidente tiene consecuencias para la seguridad laboral. La clave está en identificar qué sistemas digitales tienen capacidad para modificar una condición peligrosa.
Por ejemplo:
Movimientos inesperados
Una alteración del control de una línea, un robot, un transportador o un equipo automatizado puede modificar secuencias, velocidades o movimientos.
El riesgo ya no es la pérdida de datos: puede ser golpe, atrapamiento, aplastamiento o colisión.
Información incorrecta para el operador
Una interfaz HMI puede ser la referencia utilizada para comprobar temperaturas, presiones, niveles, estados de válvulas o condiciones del proceso.
Si esa información deja de estar disponible o no refleja correctamente la situación real, el operador puede tomar una decisión basándose en datos erróneos.
Pérdida de una alarma
Las alarmas son una de las capas que permiten detectar desviaciones antes de que se conviertan en una situación peligrosa.
Su indisponibilidad, retraso o alteración puede hacer que una anomalía física continúe sin que el personal reciba el aviso previsto.
Alteración de instalaciones auxiliares
Ventilación, extracción, climatización industrial, bombeo, suministro energético u otros sistemas auxiliares pueden depender total o parcialmente de controles digitales.
Una incidencia podría provocar desde una parada segura hasta, en determinados procesos, la aparición de exposiciones o condiciones peligrosas que deben haberse contemplado previamente.
Interferencias con accesos o respuesta ante emergencias
Cuando el control de accesos, las comunicaciones o determinados sistemas del edificio están interconectados, hay que garantizar que un fallo tecnológico no comprometa las funciones de seguridad y evacuación previstas.
La cuestión preventiva vuelve a ser la misma: ¿qué sucede si el sistema no está disponible cuando más se necesita?
La normativa de equipos de trabajo ya obliga a pensar en fallos y perturbaciones
No hace falta esperar a una regulación específicamente denominada «ciberseguridad y PRL» para plantear este problema.
El Real Decreto 1215/1997 establece que los sistemas de mando de los equipos de trabajo deben ser seguros, teniendo en cuenta posibles fallos y perturbaciones. También exige, entre otros aspectos, que la puesta en marcha no genere situaciones peligrosas, que la parada tenga prioridad sobre las órdenes de puesta en marcha y que los equipos dejen de utilizarse cuando una avería u otra circunstancia comprometa la seguridad de su funcionamiento.
La Guía Técnica del INSST sobre utilización de equipos de trabajo, disponible también en la base documental normativa de OTP, desarrolla estos criterios como parte de la evaluación y control de los riesgos derivados de los equipos.
Además, el Reglamento de los Servicios de Prevención exige volver a evaluar los puestos afectados por la introducción de nuevas tecnologías o por cambios en las condiciones de trabajo.
Una modificación de software o conectividad no tiene por qué desencadenar automáticamente una reevaluación completa. Pero si cambia el comportamiento, las protecciones, los modos de operación o las posibles consecuencias de fallo de un equipo o proceso, PRL debería estar dentro del análisis del cambio.
El nuevo Reglamento europeo de máquinas hace explícita la conexión
Esta relación será todavía más visible con el Reglamento (UE) 2023/1230 relativo a las máquinas, cuya aplicación general está prevista a partir del 20 de enero de 2027.
Entre sus requisitos esenciales de salud y seguridad aparece expresamente la protección frente a alteraciones accidentales o intencionadas de software y datos relevantes para la seguridad.
Además, los sistemas de mando deberán diseñarse para resistir, cuando corresponda según los riesgos, influencias externas e incluso intentos hostiles razonablemente previsibles de terceros que puedan conducir a una situación peligrosa.
El matiz es importante.
El Reglamento no convierte al departamento de PRL en responsable de ciberseguridad.
Lo que hace es reconocer algo que ya ocurre técnicamente: la seguridad funcional de una máquina puede depender también de la integridad de sus componentes digitales.
El Cyber Resilience Act añade otro indicador del cambio regulatorio
Desde el 11 de septiembre de 2026 se aplican las obligaciones de notificación previstas en el Cyber Resilience Act para fabricantes afectados por su ámbito de aplicación.
Estos fabricantes deben comunicar determinadas vulnerabilidades activamente explotadas e incidentes graves que afecten a la seguridad de productos con elementos digitales mediante la plataforma europea habilitada a tal efecto.
Conviene mantener aquí una distinción clara: el CRA no es una norma de prevención de riesgos laborales ni convierte a todas las empresas usuarias de maquinaria en sujetos obligados a esas notificaciones.
Su interés para PRL es otro.
Muestra cómo la regulación europea está incorporando progresivamente la seguridad del software y de los productos conectados dentro de la seguridad global del producto.
En industria, separar por completo «seguridad digital» y «seguridad física» cada vez tendrá menos sentido.
El punto crítico: máquinas antiguas conectadas a redes modernas
Una máquina puede haber sido diseñada para trabajar de forma aislada y años después terminar conectada a:
- una red Ethernet industrial;
- un sistema SCADA;
- una plataforma de monitorización;
- una pasarela IoT;
- un servicio del fabricante;
- o una conexión remota para mantenimiento.
El problema no es simplemente que sea antigua.
El verdadero cambio es que su entorno tecnológico ya no es aquel para el que fue concebida.
Los equipos legacy pueden tener limitaciones para admitir actualizaciones, segmentación, autenticación moderna o determinados mecanismos de protección. ENISA ha identificado precisamente la integración de sistemas OT heredados con tecnologías modernas como uno de los desafíos de sectores altamente digitalizados.
Desde PRL, la pregunta no debe ser cómo proteger técnicamente la red.
Debe ser:
si esta conexión falla, es manipulada o transmite una orden incorrecta, ¿qué consecuencia física puede producirse?
Ese cambio de pregunta marca la diferencia.
Actualizar software también puede modificar una condición de seguridad
No todos los problemas proceden de un ataque.
Una actualización defectuosa, una configuración incorrecta o un cambio legítimo realizado sin suficiente coordinación pueden producir efectos similares desde el punto de vista preventivo.
Especialmente cuando se interviene sobre:
- software asociado a funciones de seguridad;
- parámetros de proceso;
- PLC y sistemas de mando;
- interfaces operador-máquina;
- comunicaciones industriales;
- accesos remotos;
- sistemas auxiliares críticos.
Por eso debería existir un control del cambio que no valore exclusivamente si la actualización funciona técnicamente.
También debería comprobar si modifica alguna función relacionada con la seguridad y, cuando sea necesario, verificar el comportamiento del equipo antes de devolverlo a producción.
Mantenimiento remoto: cómodo, pero no invisible para PRL
Cada vez más fabricantes e integradores pueden acceder remotamente a máquinas e instalaciones para diagnosticar fallos, modificar parámetros o actualizar sistemas.
Operativamente es muy útil.
Preventivamente introduce una pregunta delicada:
¿puede una persona situada a cientos de kilómetros provocar un cambio en un equipo junto al que alguien está trabajando?
Si la respuesta es sí, la intervención remota debe coordinarse con la situación física del equipo.
Antes de permitir acciones que puedan alterar su funcionamiento deberían estar claras cuestiones como:
- quién autoriza la intervención;
- quién confirma localmente el estado del equipo;
- qué personas pueden estar expuestas;
- qué aislamiento o consignación es necesario;
- qué modificaciones se han realizado;
- y quién autoriza la posterior puesta en servicio.
Una sesión remota no debería saltarse las mismas precauciones que se exigirían a una intervención realizada junto a la máquina.
El momento más delicado puede llegar después del incidente
Cuando un sistema deja de funcionar, la prioridad tecnológica suele ser recuperarlo cuanto antes.
En un entorno industrial, recuperar servicio y recuperar seguridad no siempre son exactamente lo mismo.
Restaurar una copia, reiniciar un PLC, recuperar comunicaciones o volver a cargar una configuración puede devolver el sistema a funcionamiento. Pero antes de reactivar físicamente el proceso hay que saber:
¿En qué estado han quedado los equipos?
¿Se han conservado los parámetros correctos?
¿Hay personas trabajando en zonas peligrosas?
¿Se ha aislado alguna energía durante la incidencia?
¿Funcionan las alarmas y funciones de protección?
¿Es seguro volver a arrancar?
La recuperación debería incluir un criterio explícito de puesta en servicio segura, no únicamente una confirmación de que «el sistema vuelve a responder».
IT, OT, mantenimiento y PRL necesitan hablar el mismo idioma
Este tipo de riesgo suele caer entre departamentos porque cada equipo ve una parte diferente del problema.
IT y ciberseguridad conocen vulnerabilidades, accesos, comunicaciones e incidentes.
OT y automatización entienden PLC, redes industriales, lógicas y sistemas de control.
Producción conoce cómo se comporta realmente el proceso.
Mantenimiento sabe qué ocurre cuando se interviene físicamente sobre los equipos.
PRL debe analizar qué consecuencias pueden tener esas desviaciones para las personas y qué condiciones deben mantenerse para trabajar o reiniciar con seguridad.
Ninguno puede sustituir al resto.
El objetivo no es convertir a los técnicos de prevención en especialistas en hacking ni a los responsables IT en técnicos PRL.
Es garantizar que cuando una amenaza digital tenga una posible consecuencia física, exista un punto de encuentro entre ambos ámbitos.
Incluir escenarios ciberfísicos en simulacros sin «atacar» la planta
Probar la respuesta no significa lanzar ataques reales contra sistemas productivos.
Muchos escenarios pueden ensayarse mediante ejercicios de mesa o simulaciones controladas.
Por ejemplo:
- pérdida del HMI o del SCADA;
- datos del proceso cuya fiabilidad no puede garantizarse;
- indisponibilidad de una conexión con un sistema crítico;
- pérdida del acceso remoto del fabricante durante una avería;
- necesidad de detener el proceso por incertidumbre sobre el sistema de mando;
- recuperación de sistemas después de un incidente.
El ejercicio debería comprobar cuestiones preventivas:
¿Quién ordena la parada?
¿Cómo se lleva el proceso a un estado seguro?
¿Quién comunica la incidencia a producción?
¿Qué trabajos quedan prohibidos mientras exista incertidumbre?
¿Cómo se gestionan las energías peligrosas?
¿Quién verifica las funciones de seguridad antes del reinicio?
Un buen plan de continuidad no debería centrarse únicamente en cuánto tarda la empresa en volver a producir, sino también en cómo vuelve a producir sin introducir un riesgo nuevo.
Checklist: 8 preguntas para detectar un posible riesgo ciberfísico
1. ¿Qué sistemas digitales tienen capacidad para modificar una condición física?
Motores, robots, válvulas, presión, temperatura, ventilación, alarmas, accesos, elevación, transporte interno...
2. ¿Sabemos cuál debe ser el estado seguro si ese sistema falla o deja de ser fiable?
Una pérdida de comunicación debería tener una respuesta prevista, no improvisada.
3. ¿Existe alguna posibilidad de actuación remota sobre equipos con personas expuestas?
Si existe, deben coordinarse las autorizaciones tecnológicas y las condiciones físicas de seguridad.
4. ¿Las funciones de seguridad dependen de sistemas que pueden modificarse digitalmente?
Identificar esta dependencia permite establecer verificaciones y controles antes de intervenir.
5. ¿Se coordinan las actualizaciones y cambios de configuración con mantenimiento, producción y PRL cuando pueden afectar a la seguridad?
«Cambio informático» y «cambio de condición de trabajo» pueden coincidir.
6. ¿Tenemos maquinaria antigua ahora conectada a redes o servicios que no existían cuando fue diseñada?
La conectividad puede cambiar sustancialmente el escenario de fallo.
7. ¿Sabemos qué fabricantes, mantenedores e integradores pueden acceder remotamente y qué pueden modificar?
La cadena de proveedores también forma parte del control del cambio.
8. ¿Existe un criterio de puesta en servicio segura después de un incidente?
Antes del reinicio deben verificarse las condiciones físicas, los dispositivos de protección y las funciones críticas.
Ciberseguridad y PRL: dos riesgos distintos, una misma consecuencia
Un departamento de prevención no tiene que detectar ransomware.
Pero sí debe saber qué ocurre si un sistema digital del que depende una máquina, una alarma o una instalación deja de comportarse como estaba previsto.
Ese es el verdadero punto de conexión.
Desde OTP podemos ayudar a las organizaciones a analizar preventivamente los procesos y equipos, identificar las consecuencias físicas de posibles fallos, revisar procedimientos de emergencia y coordinar estos escenarios con los responsables tecnológicos, de mantenimiento y producción.
La ciberseguridad técnica debe seguir en manos de los especialistas correspondientes. La función preventiva es asegurarse de que, cuando un fallo digital pueda llegar hasta el mundo físico, las personas no sean la última barrera de seguridad.
La Salud es +
Impulsamos la prevención de riesgos laborales y ayudamos a fomentar el bienestar, la seguridad y salud de las personas en las organizaciones. #PRL #SST