AVEVA System Platform and InTouch Security Guide

AVEVA System Platform runs supervisory control for plants, utilities and pipelines, and almost every serious weakness reported in it comes back to one thing: how accounts, credentials and trust between nodes are managed. A Galaxy is a distributed Windows application in which a shared network account, SQL Server logins, operator roles, a System Management Server and remote HMI gateways all hold access to the process. This guide explains how identity and access work across Application Server, InTouch HMI, Historian and InTouch Access Anywhere, which accounts carry the most risk, what to log, and how to harden a Galaxy without breaking it. It is for OT engineers, integrators and security teams running AVEVA (formerly Wonderware) estates. Check the documentation for your exact release before changing a production node.

Key takeaways

The ArchestrA Network Account is the Galaxy's master key. It authenticates inter-node communication, must be the same on every node, and has been the target of credential exposure flaws (CVE-2019-6525, CVE-2022-0835), so treat it as a privileged non-human identity.
Use OS group based security backed by Active Directory. Operators, engineers and administrators should map to domain groups through Galaxy roles, so joiners and leavers are handled in one place rather than in each application.
The System Management Server is a trust anchor. It issues the certificates for TLS between nodes and single sign-on; protect it like a certificate authority and keep only one per topology.
Remote HMI gateways are the internet-facing risk. InTouch Access Anywhere has had unauthenticated, remotely exploitable flaws with public exploits (ICSA-22-342-02); it belongs behind a DMZ and current versions only.
Most fixes are configuration, not code. Disabling AutoBuild on runtime nodes, removing Guest and Anonymous accounts, changing SQL login passwords and protecting memory dumps closed several published vulnerabilities without patching.

How identity and access work in AVEVA System Platform

System Platform bundles Application Server (the Galaxy Repository, the IDE and runtime AppEngines), InTouch HMI (WindowMaker for design, WindowViewer and the Industrial Graphic Server for runtime), Historian, communication drivers and a set of common platform services. Identity runs at four layers, and each one needs its own owner.

Layer	What authenticates	Identity used	Main risk
Windows operating system	Logon to engineering, runtime and server nodes	Domain or local Windows accounts; the aaAdministrators group and related aa groups	Local admin sprawl, Guest and Anonymous accounts left enabled
Inter-node communication	Platform and engine traffic between Galaxy nodes	ArchestrA Network Account (called "ArchestrA User" in older releases)	One shared credential on every node; credential exposure in memory
Galaxy security	Who can design, deploy, operate and acknowledge in the Galaxy	Galaxy roles mapped to users or OS groups, with permissions and InTouch access levels	Roles left at defaults or mapped to broad groups such as Domain Users
Database and web services	Galaxy Repository and Historian databases; Industrial Graphic Server, REST and web clients	SQL Server logins, Windows authentication, AVEVA Identity Manager single sign-on	Well-known SQL login passwords, HTTP endpoints without TLS

Galaxy authentication modes

Galaxy security is configured in the IDE under Galaxy, Configure, Security. The Galaxy can run with no security, with Galaxy-managed user names and passwords, or with operating system authentication either per user or per group. In OS group based mode, administrators create Security Roles on the Roles tab, map each role to one or more domain groups entered as domain\group, assign an access level for InTouch and tick the permissions the role holds. InTouch applications then inherit this model when WindowMaker's security type is set to ArchestrA (Special, Security, Select Security Type). A technical note from an AVEVA distributor describes OS security as the most secure option for InTouch runtimes because logins stay in Active Directory.

Choose OS group based: for any site with a domain. Access changes become group membership changes that IAM processes and reviews already cover.
Avoid InTouch-managed passwords: AVEVA bulletin LFSEC00000080 reported weak password storage in the InTouch security type, and noted that Windows Integrated security was not affected.
Use a domain, not a workgroup: the installation guide recommends domain networking, warns against installing the Galaxy Repository on a domain controller, and says workgroup set-ups that rely on the "Let everyone permissions apply to anonymous users" policy weaken access control.

For the wider OT identity model, see the Identity for OT Environments Guide.

Admin roles and privileged access

Privilege in a Galaxy is split between Windows groups, Galaxy roles and SQL Server rights. The installation guide adds a pre-existing Network Account to aaAdministrators together with the SQL Server privileges Application Server needs, and notes that membership of aaAdministrators does not by itself give Windows system administrator rights. Membership of Administrators or aaAdministrators is needed to configure the System Management Server, and further groups can be allowed by adding them to the AllowGroups array in the Management Server's appsettings.json (keep aaAdministrators in the list).

Privileged function	Who should hold it	Control
Galaxy security configuration and role design	Two or three named platform administrators	Dedicated admin accounts, separate from daily logins; changes approved through management of change
Object deploy and undeploy to runtime	Control engineers on shift or in a change window	Galaxy role permission scoped to the areas they own; deployment logged and reviewed
System Management Server configuration and certificates	Platform administrators	Members of aaAdministrators only; AllowGroups not widened to general engineering groups
Historian remote management through SMC	Historian administrators	Remote SMC access is disabled by default; when enabled it is limited to aaAdministrators, aaPowerUsers and aaUsers, so keep those groups small
SQL Server sysadmin on Galaxy Repository and Historian	Database administrators	Separate DBA accounts; no operator or engineer accounts with sysadmin
Local Administrator on HMI and engine nodes	Break-glass only	Unique local admin passwords per node (for example Windows LAPS), recorded and rotated after use

Where an integrator holds Galaxy design rights, give each engineer a named account in a time-boxed group rather than a shared "integrator" login; see the OT Third-Party and Integrator Access Guide. For tiering of admin accounts in the supporting domain, see the Active Directory and Entra ID Hardening Guide.

Integrations, API tokens and service accounts

A Galaxy is full of non-human identities. Each one should be in an inventory with an owner, a purpose, where it is used and how it is rotated. See the Service Account Inventory Template.

The ArchestrA Network Account

AVEVA describes the Network Account as "a user name and password combination that enables inter-node communication between all System Platform computers". It must be identical on every node that communicates, and by default operating system user rights block it from logging on locally or through Remote Desktop Services. If you specify a pre-existing account, its password must be set to never expire and not be changeable by the user. That combination makes it a long-lived shared secret by design, which is why its exposure has been the subject of advisories:

CVE-2019-6525 (ICSA-19-029-03): in Wonderware System Platform 2017 Update 2 and earlier, a low-privileged user could call an API to retrieve the Network Account credentials (CWE-522, CVSS 8.8). Fixed in 2017 Update 3 (bulletin LFSEC00000135).
CVE-2022-0835 (ICSA-22-067-02): in System Platform 2020 to 2020 R2 P01, credentials for the network account and logged-in users were held in cleartext in memory and could leak through diagnostic memory dumps saved to unprotected locations (CWE-316, CVSS 8.1). Fixed in 2020 R2 SP1 and 2020 P01 (bulletin AVEVA-2021-007).
CVE-2021-32942 (ICSA-21-159-03): the same class of issue in InTouch WindowViewer for 2020 R2 and earlier (CVSS 6.6), fixed by patch or security update.

Controls that follow: keep the account dedicated (never a human's account, never Domain Admin), keep it out of interactive logon rights, monitor any interactive or network logon by it from an unexpected host, restrict who can create process dumps on Galaxy nodes, and plan a coordinated password change across all nodes during a maintenance window after any suspected exposure. The Service Account Security Guide covers the general pattern.

SQL Server logins and Historian accounts

AVEVA's documentation advises changing passwords or deleting unused SQL logins, and specifically warns against keeping Historian accounts such as aaUser and aaAdminUser with well-known or publicly documented passwords. Treat these as default credentials: change them at commissioning, store them in a vault, and prefer Windows authentication where the component supports it.

Web, REST and driver identities

Industrial Graphic Server: supports Windows Authentication (the default) or User Authentication, which provides single sign-on through AVEVA Identity Manager running on the System Management Server. External access is through a Secure Gateway URL and a reverse proxy in the DMZ.
Common platform services: run on HTTP 80 and HTTPS 443 by default. A port change needs a netsh http add urlacl reservation for the NT SERVICE\GDIWebServer service identity and a restart of the AVEVA Communication Backend Service, which shows these services run under virtual service accounts.
AutoBuild: the AutoBuild service is intended only for the Galaxy Repository node during configuration. ICSA-21-180-05 described five chained flaws (including CVE-2021-33008, missing authentication, CVSS 8.8) that could give code execution with system privileges; AVEVA's mitigation is to disable AutoBuild on runtime nodes and on the GR node where it is not used.

Certificates, TLS and remote HMI access

The System Management Server stores shared security certificates and provides TLS 1.2 between nodes, single sign-on and certificate management. AVEVA states there should be only one System Management Server in a topology, and that nodes on System Platform 2017 Update 3 or later communicate securely only when configured to connect to it. Certificates can be "Automatically Generated" (the default) or "Provided by IT"; imported certificates use the .PFX format with a password. When a remote node first connects, the trust prompt warns that "By establishing trust between machines, communications can pass freely", so verify the security code before accepting. For environments where TLS 1.0 and 1.1 are disabled, the installation guide sets SystemDefaultTlsVersions and SchUseStrongCrypto to 1 under the .NET Framework v4.0.30319 registry keys.

Remote access path	Published issue	Defensive position
InTouch Access Anywhere and Secure Gateway	ICSA-22-342-02: path traversal readable without authentication (CVE-2022-23854), outdated OpenSSL (CVE-2021-3711, CVSS 9.8) and jQuery XSS (CVE-2020-11022); public exploits available	Run 2023b or later only (no hotfixes for older versions), Secure Gateway alone on a DMZ node (AVEVA advises against sharing it with other components), MFA in front
Streamed HMI sessions	AVEVA-2022-001: the Windows Language Bar let an authenticated user escape the streamed application to a command prompt (CVSS 7.4)	Disable the Language Bar on the host, dedicated low-privilege remote accounts, Group Policy restrictions and WDAC block rules
Industrial Graphic Server web clients	None specific; HTTPS is used when a System Management Server is configured	Reverse proxy in the DMZ, User Authentication with SSO, no direct inbound rule to the control network
Vendor and integrator remote desktop	CISA advisories consistently advise VPNs kept up to date, noting a VPN is only as secure as the connected devices	Brokered, recorded, time-limited access through a jump host; see the OT Remote Access Guide

Logging and detection

AVEVA components log through the System Management Console logger and to Windows and SQL Server logs. Bring the security-relevant sources into the OT monitoring stack rather than leaving them on each node; see the OT Security Operations Centre Guide.

Signal	Source	Why it matters
Logons by the Network Account outside Galaxy nodes, or interactive logons by it	Windows Security log 4624 and 4625 (logon type), domain controller logs	Indicates the shared credential has been harvested and reused (ATT&CK for ICS T0859 Valid Accounts)
Changes to aaAdministrators, aaPowerUsers, aaUsers and the AD groups mapped to Galaxy roles	Windows 4732 and 4728 group membership events	Role mapping means group changes grant process control
Galaxy security configuration changes, object deploys and undeploys	Galaxy change history and SMC logger	Unauthorised deploys can change control logic or alarms (T0836 Modify Parameter)
Operator writes and alarm acknowledgements by user	Historian events and alarm database	Attributes process changes to a person; supports investigation of T0831 Manipulation of Control
Process dump creation for aaEngine, WindowViewer and related processes	EDR or Sysmon process access events	Memory dumps exposed credentials in CVE-2022-0835 and CVE-2021-32942
Inbound connections to Secure Gateway and web services	Reverse proxy and firewall logs	Detects exploitation attempts against internet-facing HMI (T0883 Internet Accessible Device, T0866 Exploitation of Remote Services)

Metrics that show it is working:

Percentage of Galaxy roles mapped to named AD groups with an owner and quarterly review (target 100%).
Number of nodes with AutoBuild, Guest or Anonymous accounts enabled (target zero).
Days since the Network Account and Historian SQL logins were last rotated, against your agreed interval.
Publicly reachable AVEVA services found by external scanning (target zero).
Time from AVEVA bulletin publication to triage decision for your installed versions.

Hardening baseline

Apply this in order, starting on a test Galaxy or a restored backup, then a pilot node, then production in a change window. Take a Galaxy backup and node images before each step so you can roll back. Generic Windows hardening for HMI and server nodes is covered in the HMI and SCADA Server Hardening Guide; this list is AVEVA-specific.

Inventory versions: record the System Platform, InTouch, Historian, Access Anywhere and Communication Drivers versions on every node, and compare them with AVEVA's security bulletin list.
Remove exposure: confirm no Galaxy, Historian or Access Anywhere service is reachable from the internet, in line with CISA's first OT primary mitigation, and that IT-to-OT traffic passes through a DMZ.
Join the domain and switch to OS group based security: design roles first (viewer, operator, supervisor, engineer, administrator), map them to new AD groups, test in WindowViewer, then retire Galaxy or InTouch-managed passwords.
Lock down the Network Account: dedicated account, no interactive or RDP logon, not in Domain Admins or local Administrators, password in a vault, rotation procedure written and rehearsed.
Disable what runtime nodes do not need: AutoBuild on runtime nodes, Guest and Anonymous local accounts (AVEVA's mitigation for ICSA-23-318-01), unused drivers and web components.
Configure the System Management Server: one server, certificates from IT where you have a PKI, TLS 1.2 enforced, and AllowGroups limited.
Change database defaults: rotate or delete aaUser, aaAdminUser and other unused SQL logins; prefer Windows authentication.
Protect memory and diagnostics: restrict debug privileges, store any diagnostic dumps on protected shares and delete them after support cases.
Rebuild remote access: Access Anywhere 2023b or later, Secure Gateway alone in the DMZ, MFA, Language Bar disabled, dedicated remote accounts.
Patch on a cycle: triage each bulletin against your versions; see the ICS Advisory Triage and OT Vulnerability Management Guide.

Choosing between options

Small sites with one or two nodes: a workgroup may be all that exists. Prioritise unique local accounts, no anonymous permissions and no remote access over joining a domain you cannot run securely. An OT-only domain is better than joining the corporate domain directly.
Large multi-site estates: use an OT domain or forest separate from corporate AD, central role definitions, and PKI-issued certificates for the System Management Server.
Remote viewing: where read-only views meet the need, publish Historian or web dashboards through the DMZ instead of streaming full HMI sessions with control rights.

Common misconfigurations

Network Account in Domain Admins: done to "make it work" during commissioning, it turns any credential leak into domain compromise. The account needs aaAdministrators and SQL rights, not domain administration.
Galaxy security left at none: anyone with IDE access can change and deploy objects.
Roles mapped to broad groups: mapping an operator role to Domain Users gives every corporate account control rights on the HMI.
Old Access Anywhere on the internet: versions before 2023b have no hotfixes, and the flaws in ICSA-22-342-02 need no authentication. Exposed remote access was also the entry point in the Colonial Pipeline ransomware attack, where an unused VPN account without MFA was enough.
AutoBuild running everywhere: left enabled on runtime nodes after commissioning, exposing the flaws in ICSA-21-180-05.
Default Historian SQL passwords: aaUser and aaAdminUser with documented passwords, reachable from engineering laptops.

Framework mapping

Control area in this guide	NIST SP 800-53 Rev. 5	NIST CSF 2.0	ATT&CK for ICS technique addressed
OS group based roles, role reviews	AC-2, AC-6	PR.AA-05	T0859 Valid Accounts
Network Account and SQL login management	IA-5, AC-2	PR.AA-01	T0859 Valid Accounts
Remote access and Secure Gateway placement	SC-7, IA-2	PR.AA-05	T0822 External Remote Services, T0883 Internet Accessible Device
Disabling AutoBuild, Guest and unused services	CM-7	PR.PS-02	T0866 Exploitation of Remote Services
Bulletin triage and patching	SI-2	PR.PS-02	T0866 Exploitation of Remote Services
Logging of deploys, logons and operator actions	AU-2, AU-6	DE.CM-01	T0836 Modify Parameter, T0831 Manipulation of Control

For zone and conduit design around the Galaxy, see the IEC 62443 Guide and the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.

Practitioner checklist

Record versions of every AVEVA component on every node and check them against AVEVA's security bulletin list.
Switch the Galaxy to OS group based security with roles mapped to named AD groups that have owners.
Make the ArchestrA Network Account dedicated, non-interactive, outside Domain Admins and vaulted, with a rehearsed rotation procedure.
Disable AutoBuild on runtime nodes and Guest and Anonymous accounts on all nodes.
Run a single System Management Server with IT-issued certificates where possible and limit its AllowGroups.
Change or remove aaUser, aaAdminUser and any unused SQL logins.
Restrict process dump creation and protect diagnostic dump locations.
Upgrade InTouch Access Anywhere to 2023b or later, isolate the Secure Gateway in the DMZ and require MFA.
Forward logon, group change, deploy and gateway logs to OT monitoring and review them.

AVEVA System Platform and InTouch HMI Security Guide: Securing Galaxy identities, roles and remote access