SCADA no ha muerto. Se ha integrado. Los sistemas de supervisión y adquisición de datos que durante tres décadas hicieron funcionar fábricas, utilities y oleoductos siguen ahí, siguen leyendo tags de los PLC, siguen disparando alarmas en los HMI. Lo que ha cambiado es todo lo que los rodea. En 2026, un despliegue SCADA creíble raramente es un producto autónomo: es una carga de trabajo más encima de una plataforma IoT industrial que también gestiona provisión de dispositivos, analítica, ciberseguridad y despliegue multicliente. Elegir la plataforma SCADA IoT correcta se ha convertido en la decisión con más apalancamiento que un integrador o un fabricante de dispositivos toma este año.

Ese cambio no es cosmético. Según Fortune Business Insights, el mercado de cloud industrial alcanzó 114,45 mil millones de dólares en 2026 y proyecta llegar a 449,82 mil millones en 2034, con un CAGR del 18,66%. SCADA representa aproximadamente el 22% de ese mercado. Al mismo tiempo, solo entre el 25 y el 30% de los grandes fabricantes han escalado IIoT más allá del piloto, lo que significa que el dinero de verdad sigue encima de la mesa y es para quien sea capaz de hacer correr ambos mundos sobre un mismo stack.

Esta guía es para quien tenga que tomar esa decisión. Si eres un System Integrator evaluando plataformas para tus clientes, un Device Manufacturer decidiendo si white-label el stack de otro, o el responsable técnico de un operador intentando modernizar sin arrancar la base instalada, las próximas 3.000 palabras son para ti.

Ilustración de portada para la evaluación de una plataforma SCADA IoT en 2026

El Mercado de la Plataforma SCADA IoT en 2026 de un Vistazo

La conversación sobre la plataforma SCADA IoT en 2026 no se parece en nada a la de 2020. La han reescrito tres fuerzas.

La base instalada envejece y cuesta dinero. Una buena parte de los despliegues SCADA en industrias de proceso sigue corriendo sobre servidores Windows, bases de datos de tags propietarias y licencias HMI por puesto. Las ventanas de mantenimiento son frágiles. Añadir un sitio nuevo significa replicar todo el stack.

La nube y el edge importan los dos. SCADA puramente en cloud fracasó: la latencia y los requisitos de aislamiento de red lo mataron. SCADA puramente on-premise no escala a 50 sitios de forma económica. La arquitectura de 2026 es híbrida: las pasarelas edge gestionan el control determinista y el preprocesado, y la nube se encarga de la agregación multisitio, la analítica y el acceso remoto. IoT Analytics cataloga el edge computing como componente arquitectónico estándar -- ya no experimental -- para los despliegues industriales de este año.

El comprador ha cambiado. Hace cinco años, la decisión SCADA recaía en un ingeniero de planta. Hoy la decisión de plataforma SCADA IoT es conjunta entre OT, IT, ciberseguridad y finanzas. Ese comité quiere menos proveedores, integración más estrecha con su ERP y su analítica en cloud, y una respuesta clara a la pregunta NIS2. Un producto diseñado para un ingeniero de planta solitario no sobrevive a ese comité.

Diagrama de arquitectura de convergencia OT/IT para una plataforma SCADA IoT moderna

En Cloud Studio IoT llevamos más de 25 años viendo esto desde dentro. Los partners con los que trabajamos -- integradores que envían IoT bajo su propia marca y fabricantes que añaden una capa de software a su hardware -- ya no preguntan "¿necesito SCADA o IIoT?". Preguntan "¿qué plataforma SCADA IoT me permite lanzar más rápido y pasar el filtro del comité?".

Por Qué el SCADA Heredado Está Crujiendo y una Plataforma SCADA IoT Gana

Antes de decidir qué comprar, conviene ser preciso sobre lo que se rompe en el SCADA heredado y dónde una plataforma SCADA IoT moderna cierra el hueco.

Datos OT en silos que IT no puede usar. El SCADA heredado almacena tags en historizadores propietarios. Sacar esos datos a un data warehouse moderno para analítica entre plantas implica escribir conectores a medida y mantenerlos para siempre. Cualquier intento de añadir mantenimiento predictivo o benchmarking energético se estrella contra ese muro.

Integración a golpe de martillo. Cada nueva familia de dispositivos requiere un driver nuevo. Cada protocolo -- Modbus, DNP3, IEC 61850, serie propietario -- es un proyecto aparte. Añadir 1.000 sensores LoRaWAN a una planta que corre sobre DNP3 es un trabajo de seis meses, no una tarde.

Postura de seguridad de otra época. Muchos HMI siguen corriendo sobre máquinas Windows 7 o 10 fuera de soporte, hablan por canales sin cifrar y usan cuentas de operador compartidas. Cuando los auditores llegan tras NIS2, eso es lo primero que encuentran.

Precio por sitio que se rompe con la escala. Las licencias SCADA se diseñaron para despliegues de un solo sitio. Correr el mismo sistema en 30 sitios significa 30 stacks de licencias, 30 trabajos de backup, 30 elementos que parchear. La multitenencia nunca estuvo en la especificación original.

Plantilla que envejece, conocimiento que envejece. Los ingenieros que configuraron las pantallas SCADA originales se jubilan. Los nuevos perfiles han crecido con dashboards web y APIs REST. Nadie quiere aprender un lenguaje de scripting propietario de 2005.

Ninguno de estos problemas obliga a tirar SCADA por la ventana. Obligan a poner SCADA encima de una plataforma que hable el idioma del resto del stack. Eso es exactamente lo que la categoría plataforma SCADA IoT existe para resolver.

La Convergencia OT/IT que Está Reescribiendo la Plataforma SCADA IoT

La convergencia OT/IT lleva siendo palabra de moda desde 2015. Lo que realmente importa para una plataforma SCADA IoT en 2026 es la fontanería concreta, porque dos protocolos han hecho el trabajo pesado.

MQTT con la especificación Sparkplug B. Sparkplug es una especificación abierta de la Eclipse Foundation que añade a MQTT un namespace de topics estandarizado, un formato de payload definido y estado de sesión. Para SCADA es un cambio de juego: da desacoplamiento publicación/suscripción entre dispositivos y aplicaciones, conciencia de si un dispositivo está online, y un payload que cualquier plataforma de datos moderna puede consumir sin parsers a medida. Añadir un dispositivo nuevo no requiere tocar los suscriptores existentes.

OPC-UA sobre TCP y OPC-UA sobre MQTT. OPC-UA se convirtió en el estándar de facto para la comunicación entre PLC y plataforma. El binding más reciente OPC-UA-sobre-MQTT combina la semántica industrial de OPC-UA con la escalabilidad de la mensajería pub/sub, haciéndolo viable para despliegues grandes o multisitio.

El patrón de unified namespace (UNS). En lugar de integraciones punto a punto, las arquitecturas modernas ponen todos los datos operativos sobre un único bus de mensajes jerárquico. SCADA lee y escribe de ese bus. También lo hacen el MES, el historizador, los modelos ML y la analítica en cloud. Cualquier sistema puede entrar o salir sin romper los demás. El UNS es lo que permite a un partner white-label añadir un cliente nuevo sin un proyecto de integración de tres meses.

Para que una plataforma SCADA IoT sea creíble en 2026, el soporte nativo de MQTT, Sparkplug B y OPC-UA no es opcional. Tampoco lo es un modelo de datos unificado que trate igual a un sensor de humedad LoRaWAN y a una bomba Modbus una vez que los datos llegan a la plataforma. Si hay que elegir una capacidad innegociable, elige amplitud de protocolo. Todo lo demás viene detrás.

Arquitecturas SCADA Cloud-Native y Edge-Híbridas

La arquitectura de referencia en 2026 para una plataforma SCADA IoT tiene tres capas horizontales y una preocupación vertical.

Capa 1 - Edge. Los sitios corren pasarelas edge que gestionan el lazo determinista: leer PLCs, ejecutar lógica local, manejar HMIs locales y hacer buffering de datos cuando el enlace sube se cae. El edge es donde vive el control sub-100ms. Nuestra guía de edge computing para IoT entra en detalle, pero el principio clave es que el control queda local y disponible aunque la nube no lo esté.

Capa 2 - Plataforma. Una plataforma multitenant agrega los datos de todos los sitios, ejecuta la lógica supervisora que no necesita latencia de milisegundos, expone dashboards, dispara alertas y alimenta la analítica. Aquí vive el branding white-label, aquí se aplica el control de acceso por rol, y aquí corren los scripts específicos por cliente.

Capa 3 - Integraciones. APIs REST, webhooks, exports a data warehouse, conectores de BI e integraciones con MES. Todo sistema fuera de la plataforma tira o empuja a través de esa capa en lugar de hablar directamente con los dispositivos.

Preocupación vertical - Seguridad. Identidad, certificados, logs de auditoría, segmentación de red y gestión de vulnerabilidades atraviesan las tres capas. Más sobre esto a continuación.

La diferencia entre una plataforma SCADA IoT moderna y un SCADA heredado con un plugin cloud recalentado se nota en cómo se diseñaron esas capas. ¿La multitenencia estaba en la arquitectura original, o es un añadido a posteriori? ¿La pasarela edge asume que la nube siempre está disponible, o tolera días de desconexión con gracia? ¿La plataforma corre on-premise para un cliente que no puede enviar datos a ninguna nube, con las mismas prestaciones que el despliegue cloud?

CS Gear, nuestra plataforma, se construyó sobre la hipótesis híbrida desde el día uno. El edge hace lo que el edge tiene que hacer: control local determinista, preprocesado, HMI local. La plataforma hace lo que la plataforma tiene que hacer: dashboards multitenant, alertas, scripting SCADA, analítica, apps móviles. Los partners eligen AWS, su propia nube privada u on-premise puro para clientes concretos, y el conjunto de prestaciones es idéntico en las tres.

Cuadro de evaluación de plataforma SCADA IoT con siete criterios

Ciberseguridad en la Era Post-NIS2 / CISA-ICS

La ciberseguridad es donde la mayoría de los proyectos de modernización de la plataforma SCADA IoT encuentran su presupuesto -- o lo pierden.

La Directiva NIS2 de la UE ya es exigible a entidades esenciales e importantes, lo que en la práctica incluye a la mayoría de fabricantes, utilities y operadores de infraestructura crítica. Los avisos ICS de CISA en Estados Unidos han subido el listón en paralelo. Ambos regímenes exigen, como mínimo: inventario documentado de activos, redes segmentadas, autenticación multifactor para accesos privilegiados, acciones administrativas logueadas y monitorizadas, y planes de respuesta a incidentes con recuperación probada.

Traducido a la evaluación de una plataforma SCADA IoT, eso se convierte en una lista corta.

Identidad y acceso. Integración SSO (SAML, OIDC), control de acceso por rol a nivel de proyecto y dispositivo, soporte MFA y logs de auditoría que sobrevivan a un requerimiento legal.
Datos en tránsito. TLS para cada conexión externa. Autenticación de dispositivos basada en certificados, no en claves estáticas.
Segmentación de red. Capacidad de desplegar pasarelas edge en una red OT segmentada que solo hable con la plataforma a través de una salida definida. Sin conexiones entrantes desde internet a la red OT.
Gestión de parches y vulnerabilidades. Una ruta documentada para que el proveedor parchee la plataforma, y fronteras claras sobre qué parchea el partner y qué el proveedor.
Soberanía de datos. Elección clara de dónde se almacenan los datos -- UE, Estados Unidos, LATAM u on-premise -- sin perder prestaciones.

Profundizamos en estos puntos en nuestra guía de ciberseguridad IoT, pero el atajo de evaluación es este: pídele al proveedor su white paper de seguridad y el resumen de su último pentest. Si no tiene ambos listos para enviarlos bajo NDA, el comité se lo va a comer en la revisión.

Qué Evaluar al Elegir una Plataforma SCADA IoT en 2026

Esta es la parte que la mayoría de los artículos de la competencia se saltan. Describen las tendencias y te dejan averiguar la evaluación. Este es el marco que usamos con nuestros partners cuando nos preguntan qué mirar, acaben en nuestra plataforma o en otra.

1. Amplitud y Soporte Nativo de Protocolos

Una plataforma SCADA IoT debe hablar los protocolos que tus dispositivos actuales y futuros usan, de forma nativa, no a través de una pasarela que tengas que atornillar.

MQTT (3.1.1 y 5.0) con soporte Sparkplug B
OPC-UA (TCP y sobre MQTT)
Modbus TCP y RTU, DNP3, IEC 61850 cuando aplique
LoRaWAN con Network Server incorporado (no un LNS externo que debas integrar)
NB-IoT, LTE-M y BLE para la cola larga

Pide una lista de protocolos soportados con números de versión. "Soportamos MQTT" sin versión es una bandera roja.

2. White-Label y Multitenencia por Diseño

Si eres System Integrator o Device Manufacturer, tus clientes nunca deberían ver la marca del proveedor. Eso significa dominio propio, colores propios, logo propio, notificaciones por email y push móvil propias, e idealmente apps iOS y Android con tu marca. Multitenencia significa poder gestionar cientos de clientes finales desde una única instancia de plataforma, con aislamiento estricto de datos y personalización por cliente.

La mayoría de los productos SCADA heredados nunca se diseñaron para esto. La mayoría de las plataformas IoT cloud (AWS IoT Core, Azure IoT Hub) hacen el white-label real prácticamente imposible. Las plataformas diseñadas desde el principio para el modelo B2B2B -- las páginas de solución de Cloud Studio IoT describen la nuestra, y hay algunas más -- resuelven esto de forma nativa.

3. Capacidades SCADA Dentro de la Plataforma

No deberías tener que atornillar SCADA encima de una plataforma IoT. Busca:

Interfaces SCADA web con gráficos vectoriales y enlace de datos en vivo
Una capa de scripting para lógica personalizada, alarmas y automatizaciones (idealmente JavaScript o Python, no un lenguaje propietario)
Almacenamiento de datos histórico con consultas time-series rápidas e informes exportables
Gestión de alarmas con reconocimiento, escalado y entrega multicanal (email, SMS, push, webhook)
Dashboards por rol para que los operadores vean lo que los operadores necesitan y nada más

Este es el conjunto de capacidades específicas de SCADA que decide si tus integradores pueden reemplazar un HMI heredado o solo complementarlo.

4. Flexibilidad de Despliegue

Solo cloud es un descarte automático para una fracción importante de clientes industriales: industrias reguladas, infraestructura crítica, clientes con preocupaciones de soberanía de datos. Asegúrate de que la plataforma corre en:

La nube gestionada del proveedor (AWS, GCP, Azure)
Tu propia cuenta cloud
Servidores on-premise con Docker o Kubernetes
Entornos air-gapped con sincronización periódica

Y que el conjunto de prestaciones no se degrada en las huellas más pequeñas.

5. Coste Total, No Precio de Licencia

El precio por mensaje (te estoy mirando, AWS IoT Core) es predecible a escala piloto y letal en producción. Un sitio que envía 10 mensajes por segundo por dispositivo sobre 1.000 dispositivos genera 860 millones de mensajes al mes. Haz el cálculo con tu número real de dispositivos y tu frecuencia real de mensajes antes de firmar nada. El precio plano por dispositivo o por tenant gana casi siempre a escala. Nuestra página de prestaciones de plataforma incluye el tipo de modelado de costes que deberías esperar de cualquier proveedor serio.

6. Soporte a la Migración

Si vienes de Google IoT Core (cerrado en 2023), de un proveedor SCADA heredado que está descatalogando un producto, o de una plataforma a medida que ha superado a quien la mantiene, el plan de migración importa tanto como la plataforma destino. Pide playbooks de migración documentados, herramientas para mapear tags y dispositivos existentes, y un punto de contacto nombrado para el corte. Habla con el equipo -- con cualquier equipo -- antes de comprar si tienes una migración compleja por delante.

7. Responsabilidad del Proveedor

A los doce meses de un despliegue, lo que salva el proyecto es la disposición del proveedor a coger el teléfono un viernes por la noche. Evalúa:

SLA para respuesta a incidentes (nosotros nos comprometemos a menos de 60 minutos en el plan premium)
Canales de soporte (email, WhatsApp, teléfono, Slack dedicado)
Rutas de escalado y contactos técnicos nombrados
Años del proveedor en IoT (los proveedores de trayectoria corta desaparecen más rápido que sus plataformas)

Una plataforma de un proveedor con más de 25 años en IoT no es automáticamente mejor que la de un proveedor más nuevo, pero el modo de fallo es distinto -- y normalmente recuperable.

De Proyecto SCADA a Práctica SCADA: Qué Pasa en 2027

Tres tendencias visibles a principios de 2026 van a definir la categoría en 2027.

IA en la plataforma, no atornillada. La detección de anomalías, el mantenimiento predictivo y las consultas en lenguaje natural pasarán de ser proyectos ML separados a ser prestaciones integradas en la plataforma, operadas por expertos de dominio, no por data scientists. Las plataformas que construyeron bien su modelo de datos llevarán una ventaja sustancial aquí.

Sparkplug B por defecto. El patrón UNS con Sparkplug B todavía es nicho hoy. En 2027 será la asunción por defecto en los RFPs. Las plataformas que lo tratan como un añadido perderán concursos frente a las que se construyeron para él.

Consolidación de proveedores. Espera que la cola larga de pequeños proveedores SCADA o bien sean adquiridos por mayoristas de automatización industrial, o pivoten a servicios de integración encima del puñado de plataformas que ganaron la guerra de protocolos y ecosistema. Es una buena noticia para los integradores que eligieron la plataforma correcta, y mala para los que apostaron por un producto especialista.

Conclusiones Clave y Siguientes Pasos

En 2026, la pregunta SCADA ya no es "¿SCADA o IIoT?". Es "¿qué plataforma SCADA IoT me permite servir a mis clientes ahora, escalar a 50 sitios en 2028 y pasar una auditoría NIS2 por el camino?". Los equipos que están ganando esa apuesta son los que eligieron una plataforma con amplitud de protocolo nativa, white-label y multitenencia genuinos, despliegue híbrido cloud-y-edge, y capacidades SCADA integradas en lugar de atornilladas.

Tres acciones para este trimestre:

Audita tu huella SCADA actual. Anota cada sitio, cada protocolo, cada licencia y cada hueco de ciberseguridad. No se puede modernizar lo que no se ha inventariado.
Ejecuta una evaluación con los siete criterios anteriores. Haz una lista corta de tres plataformas. Puntúalas. Descarta las que fallen los primeros cuatro criterios sobre el papel antes de perder tiempo en demos.
Pilota en un sitio real, no en un sandbox. Las plataformas quedan bien en las demos. Las plataformas muestran quiénes son en una planta viva con dispositivos que se portan mal y un enlace poco fiable.

Si estás en medio de esa evaluación y quieres poner a prueba tu shortlist, reserva una demo: te mostramos cómo la plataforma SCADA IoT de Cloud Studio IoT afronta cada uno de los criterios anteriores, y en qué casos recomendaríamos honestamente a otro proveedor según tus restricciones. SCADA en 2026 es demasiado importante como para equivocarse.

Plataforma SCADA IoT en 2026: Evaluación para Compradores