Sistemas legacy en plantas industriales: el desafío de proteger protocolos que nunca se diseñaron para ser seguros

Una planta industrial no se parece a un centro de datos. Mientras un servidor de oficina se sustituye cada tres o cuatro años, un PLC, un variador de frecuencia o una estación remota puede llevar quince, veinte o incluso treinta años controlando el mismo proceso. Esa longevidad es, en gran parte, la razón por la que las plantas funcionan: los activos industriales se diseñaron para durar, no para actualizarse. Pero es también el origen de uno de los problemas más persistentes de la ciberseguridad OT actual: cómo proteger equipos y protocolos que se concibieron en una época en la que nadie contemplaba que estuvieran conectados a una red, y mucho menos a internet.

Este artículo repasa por qué los sistemas legacy siguen siendo el punto más débil de la ciberseguridad industrial, por qué la respuesta clásica de “instalar un agente” no funciona en la mayoría de estos entornos, y qué enfoques arquitectónicos permiten reducir el riesgo sin tocar el activo que hay que proteger.

Qué entendemos por “sistema legacy” en un entorno industrial

En el contexto OT, “legacy” no significa simplemente “antiguo”. Se refiere a un conjunto de características que, combinadas, generan un perfil de riesgo muy distinto al de un sistema IT convencional:

• Hardware con recursos limitados, diseñado para ejecutar el proceso de control en tiempo real y nada más.
• Sistemas operativos discontinuados o versiones de firmware que el fabricante dejó de mantener hace años.
• Protocolos de comunicación —Modbus, Profinet, S7, DNP3, IEC 104, BACnet— diseñados en las décadas de 1970 a 1990 para redes cerradas y físicamente aisladas.
• Certificaciones de seguridad funcional (safety) que impiden modificar el software o el hardware sin repetir procesos de homologación largos y costosos.
• Ciclos de reemplazo medidos en décadas, condicionados por la vida útil de la maquinaria física a la que están asociados.

El resultado es un parque de activos que sigue operando —a menudo de forma perfectamente fiable desde el punto de vista funcional— pero que fue diseñado en un momento en el que la ciberseguridad, simplemente, no formaba parte de los requisitos.

El problema de fondo: protocolos sin autenticación ni cifrado

La raíz técnica del problema está en los propios protocolos industriales. Modbus, uno de los más extendidos en fabricación, energía y agua, se diseñó para entornos completamente controlados y no incorpora ningún mecanismo de autenticación: basta con conocer una dirección IP y un código de función para establecer una sesión y leer o escribir registros. Protocolos como Profinet o S7 comparten limitaciones similares en sus versiones clásicas: fueron pensados para un mundo de “confianza implícita” en el que cualquier dispositivo que hablara el protocolo se consideraba legítimo por definición.

Esa confianza implícita era razonable cuando las redes industriales estaban físicamente aisladas de todo lo demás. El problema apareció con la convergencia IT/OT: la digitalización, el mantenimiento remoto y la integración con sistemas de gestión empresarial conectaron esas mismas redes —y esos mismos protocolos sin autenticación— a entornos mucho más expuestos. Existen ya evoluciones más seguras, como Modbus/TCP seguro, pero su adopción es lenta precisamente porque requiere actualizar equipos que, en muchos casos, no se pueden actualizar.

Por qué instalar un agente no es una opción

Frente a un riesgo como este, el reflejo de un equipo de seguridad IT es instalar un agente, un EDR, un cliente de acceso remoto, una sonda de monitorización. En el mundo OT, esa respuesta choca con varias barreras que no son opcionales:

Recursos insuficientes. Muchos controladores y RTU no tienen CPU, memoria ni almacenamiento de sobra para ejecutar un proceso adicional sin comprometer el control del proceso físico que gestionan.

Sistemas operativos en tiempo real cerrados. Un porcentaje relevante de los activos legacy corre sobre firmware propietario o RTOS que no admite la instalación de software de terceros, y menos aún de un agente que requiera privilegios elevados.

Certificaciones de seguridad funcional (safety). En procesos que afectan a la seguridad física de personas o instalaciones, cualquier modificación del software instalado puede invalidar la certificación del sistema y obligar a repetir procesos de homologación que llevan meses.

Fin de soporte del fabricante. Cuando un proveedor de ICS deja de dar soporte a una versión de plataforma, el sistema sigue en producción —a veces durante años— pero sin que exista ya un canal legítimo para desplegar agentes ni parches.

Riesgo operativo de la propia intervención. Un escaneo activo de vulnerabilidades pensado para IT puede, por sí mismo, bloquear o degradar un equipo OT sensible; el coste de una parada de producción para “asegurar” el sistema puede superar al del riesgo que se pretendía mitigar.

La consecuencia práctica es que buena parte del parque industrial instalado a nivel mundial es, y seguirá siendo durante años, incompatible con agentes de IA. Cualquier estrategia de ciberseguridad que dependa de desplegar software en el propio activo deja fuera, por diseño, a una parte sustancial de la superficie que hay que proteger.

El coste de dejarlo sin resolver

Este no es un problema teórico. La manufactura lleva cinco años consecutivos siendo el sector más atacado a nivel global según el índice IBM X-Force, y en 2025 concentró el 27,7 % de todos los ciberataques registrados. Dragos, en su informe anual de ciberseguridad OT, documentó 3.300 organizaciones industriales afectadas por ransomware en 2025 —frente a 1.693 en 2024— y 119 grupos de ransomware activos contra el sector industrial, un 49 % más que el año anterior. En España, el sector de manufactura e industria concentró más del 34 % de los incidentes de ransomware en 2025, según ESED, impulsado precisamente por la baja tolerancia de estos entornos a cualquier parada.

Un dato de Dragos resulta especialmente relevante para el problema que nos ocupa: la causa más común de compromiso de red en los incidentes industriales analizados no fue una vulnerabilidad exótica ni un exploit de día cero, sino el acceso a través de portales de acceso remoto y servicios de virtualización (VPN, interfaces de firewall, túneles de proveedor). Dicho de otro modo: el punto de entrada más habitual no es el PLC legacy en sí, sino la puerta que alguien dejó abierta para poder llegar hasta él sin desplazarse físicamente a la planta.

Esto conecta dos problemas que a menudo se tratan por separado: la imposibilidad de instalar agentes en los activos legacy, y la necesidad (cada vez mayor) de que técnicos internos y proveedores externos accedan a esos mismos activos de forma remota para mantenimiento, soporte o supervisión. Cuantas más manos remotas tocan un sistema que no puede defenderse a sí mismo, mayor es la superficie de exposición.

El marco de referencia: qué dicen los estándares

No es necesario partir de cero. Existen marcos consolidados que abordan específicamente este problema, aunque su aplicación práctica en plantas con parque legacy siga siendo compleja:

IEC 62443 es el estándar internacional de referencia para la ciberseguridad de sistemas de automatización y control industrial. Introduce el concepto de zonas y conductos: una zona agrupa activos con requisitos de seguridad comunes, y un conducto es el canal de comunicación entre zonas, que debe protegerse al nivel de la zona más exigente que conecta. También define niveles de seguridad (SL-1 a SL-4) según la capacidad y motivación del atacante frente al que hay que protegerse.

El modelo de Purdue (o Purdue Enterprise Reference Architecture), desarrollado en los años 90 y adoptado como base conceptual por la propia IEC 62443, organiza la red industrial en niveles jerárquicos —desde el campo (sensores y actuadores) hasta la red corporativa—, con una zona desmilitarizada (DMZ) entre los niveles OT e IT. CISA y NIST SP 800-82 lo siguen recomendando como referencia para establecer límites de confianza claros, aunque reconocen sus limitaciones frente a arquitecturas más dinámicas basadas en IIoT o nube.

A nivel regulatorio, la Directiva NIS2 (UE 2022/2555), en vigor desde octubre de 2024, amplía de forma notable las obligaciones de gestión de riesgo y notificación de incidentes para operadores de servicios esenciales, incluyendo buena parte del sector industrial. En España, el Esquema Nacional de Seguridad (ENS) y las guías CCN-STIC del Centro Criptológico Nacional aterrizan estos principios —segmentación, control de acceso, trazabilidad— para las administraciones públicas y las infraestructuras que dependen de ellas.

Ninguno de estos marcos exige, ni podría exigir de forma realista, que se instale un agente en cada PLC de 1998. Lo que exigen es control de las comunicaciones, segmentación efectiva y trazabilidad de quién accede a qué. La seguridad se construye en la red y en el acceso, no en el propio dispositivo legacy.

Estrategias de mitigación que no requieren tocar el activo

A partir de ese marco, las organizaciones industriales disponen de varias palancas que no dependen de modificar el sistema legacy:

• Segmentación de red por zonas y conductos. Separar físicamente o lógicamente la red de planta de la red corporativa, con firewalls o listas de control de acceso entre cada nivel del modelo de Purdue, limita el movimiento lateral en caso de compromiso.
• Monitorización pasiva del tráfico. Herramientas de descubrimiento de activos y análisis de tráfico que no envían tramas activas a los dispositivos permiten obtener visibilidad —inventario, versiones de firmware, comunicaciones inesperadas— sin el riesgo de interrogar directamente a un equipo frágil.
• Cortafuegos conscientes de protocolo industrial. Dispositivos capaces de inspeccionar Modbus, S7 o Profinet a nivel de función permiten bloquear comandos de escritura no autorizados aunque el protocolo en sí carezca de autenticación.
• DMZ entre IT y OT. Cualquier flujo de datos que necesite salir de la red de planta hacia sistemas corporativos debe pasar por una zona intermedia, idealmente con flujo unidireccional (diodo de datos) o mediante un proxy de protocolo controlado.
• Gateways de protocolo y virtualización del acceso. Cuando un equipo legacy debe exponer su interfaz a un técnico —local o remoto— sin instalar nada en el propio equipo, el control se traslada a la capa de acceso: quién se conecta, desde dónde, durante cuánto tiempo y con qué nivel de privilegio.

Este último punto es, en la práctica, donde se juega buena parte de la partida. Si el acceso remoto es el vector de entrada más habitual según los propios datos de incidentes, la forma en que se gestiona ese acceso —y no solo la protección del endpoint del técnico— se convierte en el control más determinante.

La pregunta que queda abierta

Segmentar, monitorizar de forma pasiva y filtrar por protocolo reduce el riesgo de forma sustancial, pero deja una pregunta sin resolver del todo. ¿Cómo se garantiza que el acceso remoto a un activo legacy —imprescindible para el mantenimiento diario— no se convierta él mismo en la puerta de entrada? Una VPN cifra el canal, pero si el equipo del técnico está comprometido, ese compromiso puede propagarse hasta el activo, porque el endpoint sigue teniendo acceso directo a él a través del túnel.

Es en este punto donde entra en juego un enfoque distinto al del acceso remoto tradicional.

Endurance: aislar el activo, no solo cifrar el canal

Cosmikal, fabricante de tecnología española, desarrolla Endurance, una plataforma de Remote Shielded Workspace (RSW) que integra funcionalidades PAM, VDI, IAM y DLP. Frente al modelo de VPN, en el que un endpoint comprometido puede terminar afectando al activo porque mantiene acceso directo a él a través del canal, Endurance aísla el activo tanto del endpoint como de la red. además de cifrar la conexión, introduce un salto de aire (air gap) entre el dispositivo desde el que se conecta el técnico y el sistema industrial al que accede. El activo nunca queda expuesto directamente a un endpoint que la organización no controla del todo.

Esta arquitectura resulta especialmente relevante para el problema descrito en este artículo: como el control se aplica en la capa de acceso y no en el propio dispositivo, Endurance permite proteger sistemas legacy que no admiten agentes de IA, sin necesidad de instalar nada en el PLC, el HMI o la estación de ingeniería que hay que mantener. Esto convierte a Endurance en una vía práctica para llevar los principios de segmentación y control de acceso de IEC 62443 hasta el último eslabón de la cadena —el activo legacy inagentable— sin comprometer su certificación de seguridad funcional ni su disponibilidad operativa.

Endurance forma parte del catálogo CPSTIC gracias a sus certificaciones —entre ellas, LINCE en su taxonomía PAM—, lo que respalda su idoneidad para su uso en infraestructuras críticas y administraciones públicas españolas. En un panorama de amenazas donde el acceso remoto se ha convertido en el vector de compromiso más habitual contra el sector industrial, garantizar que ese acceso nunca toca directamente el activo deja de ser una opción y pasa a ser una ventaja competitiva.

Fuentes

• Dragos, OT Cybersecurity Year in Review 2026 — resumido en Infosecurity Magazine, “Significant Rise in Ransomware Attacks Targeting Industrial Operations”
• IBM Security, X-Force Threat Intelligence Index 2026 — citado en SentinelOne, “¿Qué es el Modelo Purdue?”
• Check Point Software Technologies, Manufacturing Threat Landscape 2025 — citado en CyberSecurity News, “El sector manufacturero es el mayor objetivo del ransomware”
• ESED, Resumen: sectores más ciberatacados por ransomware en 2025
• INCIBE-CERT, Evolucionando a Modbus seguro
• INCIBE-CERT, Configuraciones seguras en dispositivos industriales
• ISA Sección Española, Diseño de zonas, conductos y canales según la normativa IEC 62443 (ISA99) en una Industria 4.0
• InprOTech, InprOTech Guardian y el Modelo Purdue: segmentación OT en la práctica
• WeLiveSecurity, Proteger sistemas industriales heredados frente a las ciberamenazas modernas
• SecurityToday, ¿Qué es la ciberseguridad OT? Protección de plantas industriales
• Bluemation, Ciberseguridad en sistemas industriales OT/IT: IEC 62443 y NIS2
• Directiva (UE) 2022/2555 (NIS2)