AVEVA System Platform SCADA Security: Attack Surface, Vulnerabilities, and Hardening Guide

AVEVA System Platform — known for most of its history as Wonderware System Platform before AVEVA’s acquisition — is deployed in thousands of industrial facilities globally across manufacturing, energy, water, oil and gas, chemical, and pharmaceutical sectors. Its core components: InTouch HMI for operator displays, the ArchestrA runtime for distributed object management, and the Galaxy Repository as the central configuration database, form a deeply interconnected platform that, when secured correctly, provides a mature and auditable SCADA environment. When secured incorrectly, those interconnections are attack paths.

Most industrial facilities running AVEVA System Platform inherited it through years of industrial project deployments. Security review of the platform configuration is often deferred because it is perceived as operational risk — and operators are not wrong that misconfigured changes to a running SCADA platform can cause operational disruptions. But deferred security review means the platform’s default and legacy configurations persist in production.

Component Overview and Attack Surface

Understanding the attack surface requires understanding how the components connect.

Galaxy Repository is the central SQL Server-hosted database that stores all ArchestrA object templates, instances, and configurations. Everything in the platform derives from Galaxy — it is the single authoritative source of truth for the automation architecture. Compromise of the Galaxy SQL Server is effectively compromise of the entire SCADA platform.

ArchestrA Integration Development Environment (IDE) is the engineering workstation tool used to develop and deploy platform objects. The IDE connects to the Galaxy Repository over the network. In many deployments, the IDE is installed on general-purpose Windows engineering workstations that also have internet access and standard corporate software.

InTouch HMI is the operator display layer. InTouch clients connect to the platform through ArchestrA runtime services. In legacy configurations, multiple InTouch nodes may connect to Galaxy directly. The InTouch tag database (tagname dictionary) is stored locally on each HMI node.

AVEVA Historian (formerly Wonderware Historian) is the process data historian, storing time-series data from the plant floor. Historian is often network-exposed to corporate networks to support business intelligence queries and is a common pivot point from IT to OT networks.

Communications: DCOM — ArchestrA uses Microsoft’s Distributed COM (DCOM) for inter-component communications. DCOM authentication and encryption are configurable but often left at defaults, which include NTLM authentication that is vulnerable to relay attacks.

Known Vulnerability Classes

SQL Server attack surface (Galaxy Repository) — Wonderware and AVEVA platforms have historically been shipped and installed with SQL Server Express configurations using default SA credentials, SQL Server authentication enabled, and the SQL Server Browser service exposed. Environments installed before the vendor hardened its default installation guides may still have these configurations in place. Attackers with network access to the Galaxy SQL Server — reachable from any Windows machine on the OT network — can authenticate and read or modify the platform configuration directly.

DCOM authentication weaknesses — ArchestrA’s DCOM communications can be configured to require authentication at various levels (None, Connect, Call, Packet, Packet Integrity, Packet Privacy). Default configurations in older deployments use lower authentication levels that permit unauthenticated DCOM calls from the same network segment. Combined with NTLM relay vulnerabilities, this creates a lateral movement path between OT workstations.

Legacy Windows OS — InTouch HMI nodes and engineering workstations running older AVEVA/Wonderware versions are often constrained to Windows 7, Server 2008, or earlier Windows versions that are end-of-life and no longer receive security patches. These systems are not easily upgraded without re-testing the SCADA application against the new OS.

Unencrypted tag communications — InTouch to DAS (Direct Access Server) and SuiteLink protocol communications transmit process values in plaintext by default. An attacker with packet capture capability on the OT network can read live process data and, in some configurations, inject tag value changes.

Historian network exposure — Historian instances are frequently connected to both OT and IT networks to support cross-network data queries. An Historian accessible from the corporate network provides an attacker who has breached IT with a direct connection into the OT network segment, and a pivot point with established OT protocol knowledge (process tag names, equipment naming conventions, process values that indicate plant state).

AVEVA CVE History — CISA has issued multiple ICS advisories for AVEVA System Platform and related products covering SQL injection in web components, directory traversal in the Historian web API, and authentication bypass in tag serving components. ICSA-22-263-02 (Wonderware Historian 2020 and earlier), ICSA-23-164-01 (AVEVA System Platform), and related advisories should be reviewed against deployed versions.

Hardening Priorities

Galaxy Repository SQL Server

Confirm SQL Server is running a supported version with current patches applied. SQL Server Express versions bundled with older platform releases are frequently years behind.
Disable SQL Server Browser service if not required for the platform topology.
Disable SQL Server authentication; use Windows authentication only. Remove or disable the SA account.
Restrict SQL Server network access to the IP addresses of authorised IDE workstations and platform servers. Apply Windows Firewall rules at the SQL Server host level, not only at the network perimeter.
Audit Galaxy SQL Server accounts regularly. Remove accounts created for temporary access (contractors, project deployments) that were never cleaned up.

DCOM Hardening

Set DCOM authentication level to “Packet Privacy” (level 6) for all ArchestrA communications where platform versions support it.
Disable anonymous DCOM access: in Component Services, set the Default Authentication Level and Default Impersonation Level appropriately.
Apply Windows security patches for DCOM vulnerabilities (CVE-2021-26414 and related DCOM hardening patches have changed default DCOM authentication behaviour — verify platform compatibility before applying).

Network Segmentation

The Historian should not be dual-homed between OT and IT networks. Use a unidirectional data diode or a dedicated historian replication server in a DMZ to forward read-only process data to IT without creating a bidirectional path.
IDE workstations (engineering computers running the ArchestrA IDE) should be on a dedicated engineering network segment, not the general corporate network. IDE machines are high-value targets because they have authenticated access to the Galaxy Repository.
Apply allowlisting at the OT network firewall: ArchestrA communications should flow only between known platform components on documented ports, not from arbitrary network sources.

Role-Based Security

AVEVA System Platform includes a built-in role-based security layer. Enable and configure it:

Define roles that match operational requirements: operators should not have the ability to modify Galaxy templates or deploy platform objects.
Enforce authentication for all IDE connections — do not allow anonymous Galaxy access even within the OT network.
Audit platform security logs: ArchestrA maintains logs of Galaxy access and object modifications. Review these for unusual modification activity, especially outside maintenance windows.

InTouch HMI Nodes

Enable InTouch security: require operator login with individual accounts rather than shared credentials. Shared “operator” accounts make audit logs useless.
Apply application allowlisting (Microsoft AppLocker or equivalent) to InTouch nodes. Operator workstations should not execute arbitrary processes.
Disable USB storage on InTouch HMI nodes if not required for operations. Removable media is a common initial access vector for air-gapped or near-air-gapped OT environments.
Update InTouch to supported versions that receive security patches. If legacy OS constraints prevent upgrade, evaluate compensating controls (host-based IDS, network monitoring).

Patch Management

AVEVA releases security patches and updates on a schedule aligned with CISA ICS advisories. Subscribe to CISA ICS-CERT advisories for AVEVA products and maintain a version inventory that allows you to assess patch applicability. Patch testing in a staging environment before production deployment is necessary given the operational sensitivity, but untested patches that are months or years delayed represent significant unmitigated risk.

Monitoring and Detection

Galaxy modification monitoring — changes to Galaxy object templates, deployments to runtime nodes outside scheduled maintenance windows, and new account creation in platform security are all high-signal events. Instrument these through platform logs or through SQL Server audit logging on the Galaxy database.

SuiteLink and DCOM traffic analysis — passive network monitoring tools that understand industrial protocols (Claroty, Dragos, Nozomi) can baseline normal ArchestrA communication patterns and alert on anomalous connections, unexpected sources accessing Galaxy, or unusual tag write volumes.

Historian access patterns — query logs on the Historian database can reveal reconnaissance behaviour: queries for unusual tag name patterns, exports of large datasets outside business hours, or connections from hosts not previously seen.

Incident Response Considerations

An AVEVA platform incident requires coordination between security and operations. Isolating a compromised Galaxy Repository from the network severs all runtime communication — ArchestrA objects cannot check back to Galaxy for configuration and may enter fault states. Understand the operational impact of network isolation before executing it, and have a plan for maintaining operator visibility (local InTouch mode, paper-based procedures, DCS fallback) during platform recovery.

Recovery from a Galaxy Repository compromise requires restoring from a known-good backup and replaying any legitimate configuration changes made since that backup. Maintain Galaxy backups at a frequency appropriate to your rate of platform change, and test restoration procedures. A Galaxy backup that has never been tested for restoration may not restore cleanly.