OPC UA rara vez falla debido a su criptografía. Falla porque alguien dejó una lista de confianza abierta, mantuvo habilitado un inicio de sesión anónimo "solo para la puesta en marcha" o implementó un servidor basado en una biblioteca que nadie parchó. Si busca las mejores prácticas de seguridad de OPC UA que se sostengan en una planta real, comience por ahí: el protocolo es sólido, las implementaciones son el punto débil. 

Esa no es solo nuestra opinión. La BSI de Alemania revisó la especificación en 2016 y nuevamente en 2022 (la actualización cubrió la versión 1.04 y la implementación open62541) y no encontró fallas sistemáticas de diseño. Sin embargo, el equipo TRACE de Bitsight contabilizó 14,220 servidores OPC UA expuestos a Internet durante los doce meses previos a junio de 2025, y el 51.74% de ellos aceptaba conexiones anónimas. De los dispositivos que informaron sus modos de seguridad, aproximadamente el 80% aún ofrecía el modo sin cifrar None. El mismo protocolo, resultados muy diferentes. 

Este blog está escrito para CISOs, líderes de seguridad de OT y arquitectos de planta que ya saben qué es OPC UA. Cubre cómo funcionan realmente los certificados y las listas de confianza en campo, qué políticas de seguridad habilitar y cuáles retirar, las configuraciones incorrectas que vemos con mayor frecuencia y los avisos publicados en 2026 que cambian lo que debe revisar este trimestre. 

Puntos clave 

• Trate la autenticación de aplicaciones (certificados y listas de confianza) como el control más importante. Los usuarios anónimos son tolerables detrás de ella y peligrosos sin ella. 

• Deshabilite la política None y las políticas obsoletas Basic128Rsa15 y Basic256, a menos que un dispositivo heredado documentado le obligue a mantenerlas. 

• Utilice SignAndEncrypt en cada endpoint y asegúrese de que los tokens de nombre de usuario también estén cifrados con una política moderna. 

• Haga un inventario de las bibliotecas OPC UA dentro de sus productos. El aviso de Eclipse Milo de octubre es un recordatorio de que la versión de la pila importa tanto como la configuración del servidor. 

• Nunca exponga un endpoint OPC UA directamente a Internet y audite aquellos que puedan comunicarse entre sí dentro de la planta. 

Seguridad de OPC UA en 2026: qué cambió y por qué es importante 

Los avisos de seguridad de OPC UA se han acumulado desde el verano y apuntan en una sola dirección: los puntos débiles están en las pilas, las anclas de confianza y la criptografía heredada, más que en el protocolo en sí. Aquí está el cronograma, del más reciente al más antiguo. Ninguno de los elementos a continuación es un incidente confirmado; los avisos describen lo que es posible y los fabricantes no reportan explotación conocida para la mayoría de ellos. 

Tres patrones que merecen su atención 

1. La lógica de autorización falla incluso cuando la configuración es correcta. Varias de las fallas de Milo residen en el control de acceso más que en la criptografía. Un CVE se refiere a una copia de configuración del servidor que descarta de forma silenciosa el mapeador de roles configurado, lo que puede dejar métodos y nodos protegidos por roles expuestos, particularmente donde el servidor también permite sesiones anónimas. Otro permite que una llamada a un método protegido se introduzca dentro de un lote con uno permitido. Un tercero hace que los nodos de diagnóstico sean legibles sin autorización, lo que revela detalles de seguridad de la sesión, incluidas las políticas en uso y los certificados de cliente públicos. Puede configurar todo correctamente y aun así quedar vulnerable, razón por la cual el inventario de bibliotecas pertenece a su programa de OPC UA. 

2. La criptografía heredada sigue conllevando un riesgo real. El problema más grave de Milo, CVE-2026-60007 (CVSS v4.0 9.1), es un padding oracle en el manejo de tokens de nombre de usuario. Un atacante en la ruta (on-path) que capture un token de nombre de usuario cifrado con Basic128Rsa15 puede enviar solicitudes ActivateSession no autenticadas repetidas y recuperar la contraseña. Las sesiones que evitan esa política no están expuestas a esta técnica específica, por lo que retirar las políticas obsoletas es una mitigación concreta, no una simple tarea de mantenimiento. Tenga en cuenta que las puntuaciones difieren según la fuente: el aviso en sí enumera CVSS v3 8.2 en general, mientras que los CVE individuales utilizan vectores v4.0. 

3. Las anclas de confianza y los clientes son la superficie de ataque silenciosa. El aviso de Prosys y el error del cliente open62541 provienen de direcciones opuestas pero comparten una lección: en qué confía su cliente o conexión de broker OPC UA importa tanto como lo que acepta su servidor. Prosys informa que sus conexiones de cliente y servidor OPC UA no se vieron afectadas, porque utilizan el almacén de certificados de la aplicación en lugar de la lista de CA de Java. Ese es el propio modelo PKI de OPC UA haciendo su trabajo; la exposición se encontraba en las conexiones MQTT, HTTPS y LDAP circundantes. 

Actualizaciones de especificaciones y pilas 

En el frente de los estándares, la versión 1.05.07 de la especificación OPC UA trajo cambios significativos en las políticas de seguridad ECC. La versión de mantenimiento open62541 1.5.5 los implementó, incluida la autenticación de sesión basada en ECC, y su servidor ahora se niega a usar políticas ECC para la autenticación a través de un canal no seguro (None). Una solicitud de la OPC Foundation dirigida a 1.05.07 también traslada la política ECC nistP256 de AES-128-CBC a AES-128-GCM. A continuación explicamos lo que esto significa para sus opciones de política. 

Cómo se estructura la seguridad de OPC UA en capas (y dónde falla) 

La seguridad de OPC UA consta de tres controles independientes que comúnmente se tratan como uno solo. La propia guía de la OPC Foundation los describe como seguridad de usuario, de aplicación y de transporte, y cada uno puede configurarse, o configurarse mal, de manera independiente. 

La consecuencia práctica es que un servidor puede anunciar "seguridad basada en certificados" y seguir estando abierto. La autenticación de la aplicación es la capa que los atacantes sondean primero, porque cuando no se aplica, un cliente no autorizado puede abrir un canal seguro, solicitar la lista de endpoints y elegir la opción más débil que ofrezca el servidor. Un cliente elige el endpoint; el servidor decide si lo permite. Si su configuración deja un endpoint None junto a uno seguro, un atacante simplemente elige None. 

Un límite que debe tenerse en cuenta: la OPC Foundation es explícita en que OPC UA no reemplaza un sistema de gestión de seguridad de la información como ISO 27001. Le brinda mecanismos. La política, la capacitación, la seguridad física y el diseño de la red siguen siendo su responsabilidad. 

Certificados de OPC UA: listas de confianza, GDS y gestión del ciclo de vida 

El manejo de certificados es donde la mayoría de los programas de seguridad de OPC UA se estancan silenciosamente. La criptografía funciona; la carga operativa de distribuir, aprobar y renovar certificados en cientos de dispositivos es lo que hace que los equipos desactiven las verificaciones. 

Cómo funciona realmente la confianza 

Cada aplicación OPC UA posee un certificado de instancia. Los servidores y los clientes mantienen cada uno una lista de confianza que contiene los certificados (autofirmados o emitidos por CA) con los que están dispuestos a comunicarse. Cualquier cosa que no esté en la lista debería terminar en un almacén de rechazados hasta que un administrador lo transfiera. Ese paso manual es el control. También es la razón por la que se evade. 

Al resumir la investigación académica sobre 48 productos industriales que afirman admitir OPC UA, se agruparon los problemas de certificados en tres categorías: sin soporte alguno para listas de confianza (11 productos, o 22.9%), listas de confianza deshabilitadas de forma predeterminada y configuración insegura de la lista de confianza. En su análisis, el 14.6% de los productos anunciaban un diseño seguro pero no verificaban adecuadamente la confianza del certificado. Las funciones existen; los valores predeterminados y la documentación con demasiada frecuencia orientan a las personas a evitarlas. 

Tres preguntas expondrán la mayor parte del riesgo en su propia infraestructura: 

1. ¿Cada servidor rechaza los certificados de cliente desconocidos de forma predeterminada o los acepta automáticamente? 

2. ¿Quién está autorizado para mover un certificado al almacén de confianza y se registra esa acción? 

3. Cuando un certificado caduca o se retira un dispositivo, ¿qué lo elimina de cada lista de confianza que lo referencia? 

Use un GDS o una autoridad certificadora de OT a escala 

La confianza dispositivo por dispositivo funciona para diez servidores. No funciona para mil. El modelo Global Discovery Server (GDS) de OPC UA permite que un administrador central de certificados firme certificados de aplicaciones y envíe (push) listas de confianza a los servidores, de modo que cada servidor solo tenga que confiar en el GDS en lugar de en cada par. Cuando se agrega un nuevo certificado de CA al GDS, la actualización se propaga a cada servidor administrado. 

Algunos puntos operativos de la documentación del fabricante y la práctica de campo: 

• El servidor debe confiar primero en el agente de GDS. El error habitual al aplicar la configuración (push) es que aún no se confía en el GDS, y la solución es el aprovisionamiento específico del fabricante o mover el certificado del GDS al almacén de confianza. 

• La cuenta utilizada para la distribución remota necesita derechos de administración de certificados en el servidor (por ejemplo, pertenecer a un rol SecurityAdmin). Trate esa cuenta como un administrador de dominio. 

• Algunos servidores se reinician después de recibir un nuevo certificado. Programe las rotaciones en una ventana de mantenimiento y verifique que los clientes se reconecten. 

• Mantenga esta CA privada. El aviso de Prosys mencionado anteriormente muestra lo que sucede cuando un cliente TLS hereda silenciosamente la confianza de un almacén raíz público. Una CA propiedad de OT, o una CA subordinada estrictamente delimitada, restringe quién puede dar fe de la identidad de una aplicación. 

Lista de verificación de higiene de certificados 

Un riesgo de implementación adicional merece mención. Team82 de Claroty descubrió que algunos servidores, que implementaban las comprobaciones de cadenas de certificados por sí mismos, no prevenían que una cadena creara un bucle sobre sí misma (el certificado A firmado por B, B firmado por A), permitiendo la denegación de servicio. Si construye o integra sus propios componentes de OPC UA, pruebe la validación de la cadena con el mismo rigor con el que prueba el cifrado. 

Políticas y modos de seguridad de OPC UA: qué habilitar y qué retirar 

Una política de seguridad es un conjunto definido de algoritmos (firma, cifrado asimétrico, cifrado simétrico, derivación de claves) establecido en la Parte 7 del estándar. El modo (None, Sign o SignAndEncrypt) decide si esos algoritmos se aplican o no. Necesita que ambos sean correctos. Una política robusta en un endpoint None no protege nada. 

Una nota sobre ECC. Las políticas de curvas elípticas ofrecen una seguridad equivalente o mayor con claves más cortas, lo que se adapta a dispositivos con recursos limitados, y open62541 ya admite seis curvas. Pero la familia todavía se está estabilizando. La revisión 1.05.07 modificó cómo funcionan los canales seguros ECC y la autenticación de sesiones, una modificación traslada nistP256 de AES-CBC a AES-GCM, y al menos un SDK de .NET importante ahora marca sus URI de política originales Curve25519 y Curve448 como obsoletos en favor de variantes ChaCha20-Poly1305. Cada curva ECC también necesita su propio certificado y par de claves, aunque las políticas RSA y ECC pueden coexistir en un mismo servidor. Nuestro consejo: implemente pilotos de ECC donde controle ambos extremos y aún no lo convierta en un requisito estricto en una planta con múltiples proveedores. 

Modos y tokens de usuario 

• Utilice SignAndEncrypt como estándar predeterminado. La guía de la OPC Foundation permite Sign donde la sobrecarga de cifrado sea genuinamente un problema, pero para el tráfico de control y cualquier transmisión que transporte credenciales, hay pocas razones para no cifrar. 

• Busque una configuración de política de seguridad mínima. Algunos productos le permiten establecer un límite inferior para que el servidor rechace categóricamente las políticas más débiles. FactoryTalk Optix de Rockwell es un ejemplo. Si sus productos tienen este ajuste, utilícelo, porque convierte una recomendación en una regla de cumplimiento obligatorio. 

• Proteja el token de usuario por separado. El nombre de usuario y la contraseña viajan dentro de la activación de la sesión, cifrados de acuerdo con la política del token de usuario. Si esa política es Basic128Rsa15 o débil de algún modo, una política de canal robusta no lo protegerá. Prefiera tokens de usuario X.509 para sesiones máquina a máquina (M2M) y conserve las contraseñas para los humanos, con MFA en la capa de acceso. 

• No olvide PubSub. OPC UA PubSub sobre MQTT o UDP utiliza sus propias políticas de seguridad de mensajes (basadas en AES-CTR) y, para MQTT, TLS hacia el broker. Aplique la misma disciplina de CA privada allí. 

Diez configuraciones incorrectas comunes de OPC UA y cómo corregirlas 

La mayoría de los hallazgos de OPC UA se reducen a una lista corta de infracciones recurrentes. Utilice esta tabla como lista de verificación para auditorías. Los primeros cuatro concentran la mayor parte de la exposición en el mundo real. 

Una revisión de quince minutos que puede ejecutar esta semana 

Apunte un cliente OPC UA gratuito como UaExpert hacia un servidor por sitio y lea su lista de endpoints. Cada línea debe mostrar SignAndEncrypt con Basic256Sha256 o superior. Luego intente conectarse con un certificado recién generado que no esté en la lista de confianza. El servidor debería rechazarlo. Si alguna de las pruebas falla, habrá encontrado los puntos 1 al 4 en su propia red antes de que lo haga un atacante. 

El patrón aquí coincide con lo que Trout Software señaló en sus publicaciones sobre el tema: la mayoría de las vulnerabilidades en campo son errores de configuración más que fallas de protocolo. Esa es una buena noticia, porque la configuración se puede solucionar sin esperar el parche de nadie. 

Riesgos en la cadena de suministro y del lado del cliente en OPC UA 

Su exposición en OPC UA está determinada en parte por código que usted no escribió y no puede ver. El Team82 de Claroty reportó aproximadamente 50 vulnerabilidades en cerca de 15 pilas de protocolo OPC UA, lo que afectó a cientos de productos, y concluyó que las pilas son el eslabón más débil en la cadena de suministro porque muchos proveedores las reutilizan con pocas modificaciones. Una falla en una biblioteca puede manifestarse en un PLC, un gateway y un historiador al mismo tiempo. 

Dos hábitos hacen que esto sea manejable. 

Conozca lo que hay dentro. El análisis de Viakoo sobre el aviso de Milo resalta un punto que vale la pena reiterar: Milo puede estar integrado en servidores y otros productos, por lo que la versión de la biblioteca por sí sola no le dice si un sistema en particular está expuesto. Solicite a los proveedores la pila de OPC UA y la versión utilizada en cada producto, y regístrela junto al activo. Cuando surja un aviso, querrá responder "¿nos afecta?" en una tarde, no en un mes. 

Trate a los servidores como no confiables desde la perspectiva del cliente. Las discusiones sobre seguridad de OPC UA se centran en proteger los servidores, pero los clientes también son atacados. Team82 encadenó vulnerabilidades en dos clientes populares, Inductive Automation Ignition y Softing edgeAggregator, alimentándolos con contenido malicioso desde un servidor OPC UA, y logró la ejecución remota de código. El error de cliente open62541 de 2026 sigue la misma lógica: un servidor hostil suministra definiciones de tipos de datos y el cliente las procesa indebidamente. Un atacante que pueda montar un servidor no autorizado y convencer a un cliente de conectarse tiene una vía de acceso a su red. 

Controles prácticos: 

• Proporcione a los clientes una lista explícita de servidores permitidos a los que pueden conectarse, utilizando listas de confianza en lugar de la aceptación automática. 

• Segmente concentradores, gateways y servidores de integración. Actúan como puentes entre sistemas, lo que los convierte en excelentes puntos de pivote. 

• Trate cualquier texto, nombre de nodo o estructura entregada por un servidor como entrada no confiable en sus propias aplicaciones y tableros. 

• Incluya estas cinco preguntas en los cuestionarios de seguridad para proveedores: 

1. ¿Qué pila y versión de OPC UA utiliza este producto? 

2. ¿Publica un SBOM y con qué rapidez entrega correcciones para CVE en la pila? 

3. ¿El servidor rechaza certificados de clientes desconocidos de forma predeterminada? 

4. ¿Podemos establecer una política de seguridad mínima y deshabilitar None? 

5. ¿Qué controles de acceso basados en roles aplica el servidor OPC UA y cómo se prueban? 

Lista de verificación para el endurecimiento (hardening) de OPC UA en redes industriales 

Los certificados y las políticas son necesarios pero no suficientes. Estos son los controles complementarios que esperaríamos ver en cualquier implementación madura de OPC UA. 

Red y arquitectura 

• Segmente los servidores OPC UA en zonas definidas e implemente conductos entre ellas, en línea con el enfoque de IEC 62443. El tráfico de OPC UA entre zonas debe pasar por un punto controlado, no por una ruta plana. 

• Permita explícitamente las direcciones de clientes en el firewall. El puerto predeterminado, 4840, es ampliamente conocido (el 96.81% de los servidores expuestos hallados por Bitsight lo usaban), así que no confíe en la seguridad por oscuridad. 

• Donde los productos admitan conexión inversa (reverse connect), permita que el servidor establezca la conexión hacia el cliente para evitar abrir puertos entrantes hacia la zona de control. 

• Enrute el acceso remoto a través de una VPN o una ruta de acceso intermediada con MFA. Nunca publique un endpoint OPC UA en Internet. 

Identidad y acceso 

• Asigne a cada persona y a cada servicio su propia cuenta. Los inicios de sesión compartidos invalidan las auditorías. 

• Utilice tokens de usuario X.509 para sesiones máquina a máquina y reserve las contraseñas para las personas. 

• Otorgue acceso de lectura de manera amplia y acceso de escritura o llamada a métodos de forma restringida; luego, vuelva a probar la aplicación de roles después de cada actualización o copia de configuración. El error del mapeador de roles de Milo es exactamente el tipo de regresión silenciosa que detecta una prueba posterior a un cambio. 

Monitoreo y detección 

• Active la auditoría del servidor y reenvíe los eventos a su sistema de monitoreo de OT o SIEM. 

• Genere alertas ante sesiones abiertas sobre None, nuevos certificados de cliente que aparezcan en almacenes rechazados o confiables, ráfagas de llamadas fallidas a ActivateSession (la firma de un ataque de tipo oráculo) y servicios de escritura (Write) o llamada (Call) desde hosts que nunca antes los habían utilizado. 

• Supervise las solicitudes de descubrimiento de endpoints procedentes de fuentes inesperadas. Las labores de reconocimiento suelen comenzar ahí. 

Gestión de parches y resiliencia 

• Mantenga actualizado el inventario de componentes OPC UA y aplique parches a través de canales admitidos por el fabricante. No reemplace una biblioteca dentro de un dispositivo de fabricante por su cuenta. 

• Mientras espera una corrección, restrinja las rutas de OPC UA a los clientes necesarios utilizando firewalls existentes y acceso remoto aprobado, que es el paso provisional recomendado en la cobertura del aviso de Milo. 

• Establezca límites de conexión, sesión y tamaño de mensaje donde el producto lo permita. Varias fallas publicadas de OPC UA, incluido el problema de B&R PPT30, son problemas de agotamiento de recursos que un par no autenticado puede desencadenar. 

• Pruebe los servidores críticos en un laboratorio con un fuzzer de protocolos antes de la puesta en marcha, y nuevamente después de actualizaciones importantes. 

Un plan de seguridad de OPC UA de 90 días para CISOs 

Si usted es responsable del riesgo pero no de la planta operativa, esta secuencia le permite pasar de "creemos que estamos bien" a contar con evidencia en un trimestre. 

Dos consejos prácticos. Primero, contemple la existencia de dispositivos heredados que no podrán cumplir con la línea base. Documente cada excepción con un responsable, un control compensatorio (aislamiento, listas de permitidos, monitoreo) y una fecha de revisión. Segundo, informe al equipo de ingeniería de planta antes de cambiar cualquier cosa. Endurecer una lista de confianza en una línea de producción activa sin previo aviso es la forma más rápida en que los programas de seguridad pierden el respaldo del equipo. 

Cómo ayuda Shieldworkz a proteger OPC UA en infraestructuras críticas 

Shieldworkz es una empresa de ciberseguridad industrial y de OT integral. Protegemos entornos SCADA, OT e IoT en infraestructuras críticas, integrando productos, servicios y soluciones en una única solución unificada, de modo que los hallazgos de una revisión se conviertan en soluciones sin traspasos fragmentados entre proveedores. 

Para OPC UA en específico, esto habitualmente comprende: 

• Visibilidad: descubrimiento de servidores, clientes y gateways OPC UA en todas las plantas, mapeando qué sistemas pueden alcanzarlos. 

• Evaluación: revisión de endpoints, políticas, certificados, tokens de usuario y comportamiento de listas de confianza respecto a la línea base de este artículo, clasificando qué corregir primero. 

• Soporte para remediación: asistencia en el diseño de procesos para certificados y GDS, segmentación de red y controles compensatorios para dispositivos heredados que no pueden cumplir la línea base. 

• Gestión de parches y vulnerabilidades: seguimiento de avisos como los de Eclipse Milo y open62541 en relación con su inventario de activos real, programando actualizaciones que respeten las ventanas de mantenimiento de OT. 

Si desea una segunda opinión experta sobre su infraestructura de OPC UA, póngase en contacto con el equipo de Shieldworkz para realizar una evaluación de seguridad de OPC UA. 

Seguridad de OPC UA: preguntas frecuentes 

¿Cuáles son las mejores prácticas de seguridad más importantes de OPC UA? 

Haga cumplir las listas de confianza de certificados, use SignAndEncrypt con Basic256Sha256 o superior, deshabilite None y las políticas obsoletas, desactive el acceso anónimo, mantenga los servidores fuera de Internet, habilite la auditoría y aplique parches a la pila de OPC UA dentro de cada producto. 

¿Es OPC UA seguro de forma predeterminada? 

La especificación lo es, de acuerdo con las revisiones de la BSI. Los productos individuales a menudo no lo son, porque las listas de confianza, el acceso anónimo y las políticas heredadas son configurables y algunos se entregan con opciones permisivas activas. Verifique cada producto en lugar de darlo por hecho. 

¿Qué política de seguridad de OPC UA debo utilizar? 

Aes256_Sha256_RsaPss o Aes128_Sha256_RsaOaep donde todos los componentes las admitan, y Basic256Sha256 como nivel mínimo de partida. Retire Basic128Rsa15 y Basic256. Pruebe políticas ECC en entornos controlados mientras los cambios de la versión 1.05.07 son asimilados por los proveedores. 

¿Es aceptable el acceso anónimo en algún caso? 

Solo donde la autenticación de la aplicación se aplique mediante confianza basada en certificados, el acceso se restrinja a datos no sensibles de solo lectura y la auditoría esté activa. El acceso anónimo en un servidor expuesto sin aplicación de confianza en certificados es una puerta abierta. 

¿Necesito un Global Discovery Server? 

Si administra más de un puñado de aplicaciones OPC UA, sí, o un proceso de gestión de certificados equivalente. Permite que cada servidor confíe en un administrador de certificados central en lugar de en cada par, y hace que la rotación sea un proceso repetible. 

¿Deberían las vulnerabilidades de octubre de 2026 de Eclipse Milo hacerme abandonar OPC UA? 

No. Identifique cuáles de sus productos integran Milo, solicite a los fabricantes actualizaciones compatibles, restrinja el acceso a la red mientras tanto y retire Basic128Rsa15 para eliminar el vector de ataque más grave. 

¿Se pueden exponer los servidores OPC UA a Internet de forma segura? 

La exposición directa no es recomendada por los principales fabricantes de OT. Si se requiere acceso remoto, utilice una VPN o un servicio de acceso remoto intermediado con MFA, y mantenga el endpoint dentro de una zona protegida.