The immediate operational consequence is straightforward: installing an updated Enterprise SCADA server while leaving binary serialization enabled does not complete the remediation. AVEVA says every compatible server and client node must first be upgraded, then server settings must change from Binary Formatter to JSON, acceptance of binary-formatted data must be disabled, the XOS Event Handlers assembly must be re-cached, connected clients must use JSON, and Enterprise SCADA HMI displays must be migrated.
This is an industrial-control security fix with a Windows administration problem at its center: estates frequently have mixed server, HMI, historian, simulator, and engineering-client versions, and AVEVA’s own instructions make that heterogeneity a remediation blocker rather than an inconvenience.
The vulnerable condition is an unsafe deserialization path
AVEVA identifies the weakness as CWE-502, Deserialization of Untrusted Data. The affected software can process serialized objects in a way that lets an authorized operator manipulate the input before it is reconstructed. If an attacker can build a suitable payload, the result may be code execution under the account context represented by Enterprise SCADA’s “DNA Apps” security group.
The vendor’s CVSS 4.0 vector produces a 6.1 Medium rating. It requires network access, low privileges, and high attack complexity; it does not require user interaction. AVEVA’s scoring also records high impacts to integrity and availability, which is the important part for a SCADA deployment: successful exploitation may permit more than reading data or changing a display. It could alter the behavior of the process running the deserialization operation.
“Authenticated” should not be read as “safe from insider or endpoint compromise.” Microsoft has spent years warning .NET developers that BinaryFormatter deserialization should never process data treated as untrusted, and that a compromised desktop client can become a route into a backend service even when the application was designed for an internal network. The pattern described by AVEVA maps directly to that risk: the vulnerable party is already permitted to participate in the Enterprise SCADA environment, then turns a trusted application data exchange into code execution.
AVEVA does not describe the permissions held by “DNA Apps,” nor does it publish proof-of-concept code, indicators of compromise, affected network ports, or evidence of active exploitation. Those omissions mean defenders should avoid inventing an internet-facing threat scenario. But they also mean the safe planning assumption is narrower and more actionable: an operator workstation, test client, or credential set with the specified authority is part of the threat boundary.
The update alone is explicitly insufficient
AVEVA lists fixed server releases beginning with Enterprise SCADA 2025 P1, 2024 SP1 P2, 2023 SP1 P1, 2022 SP2 P3, and 2021 SP2 P6. The same server-side fixes are available for AVEVA Pipeline Operations for Gas/Liquids at the corresponding release levels. Any Enterprise SCADA server on 2025 before P1, 2024 through 2024 SP1 P1, 2023 through 2023 SP1, 2022 through 2022 SP2 P2, or 2021 SP2 P5 and earlier falls within AVEVA’s affected ranges.
The client side has separate baselines. AVEVA specifies Enterprise SCADA HMI 2024 R2 HF7 or later, HMI 2024 P1, or HMI 2023 P2 HF1. It also names Pipeline Integrity Monitor and Pipeline Training Simulator 2025 SP1 P2 or later, Measurement Advisor 2025 P1 or later, and Measurement Advisor 2021 SP1 HF16.
The significant caveat is in AVEVA’s sequencing: secure serialization settings are to be applied after all server and client nodes are upgraded to compatible versions that support the fix. That wording makes sense technically. Turning off acceptance of Binary Formatter payloads on one server before all connected components have moved to JSON could interrupt clients, interfaces, displays, or tools that still send the older data format.
For change managers, this turns a security bulletin into a dependency inventory exercise. Teams should identify every node that sends data to, receives data from, or otherwise interfaces with the Enterprise SCADA deployment—not only the primary server and HMI consoles. A neglected simulator, integrity-monitoring component, Measurement Advisor installation, or third-party integration can become the reason an otherwise patched site keeps accepting unsafe serialized input.
JSON is the security control, not a cosmetic preference
The remediation requires three server actions:
- Change the
BinarySerializermode fromBinary FormattertoJson. - Change
AcceptBinaryFormattedDatafromtruetofalse. - Re-cache the XOS Event Handlers assembly after the configuration change.
Connected components must be configured to use JSON serialization, while HMI displays must be migrated. AVEVA points customers to KB117814, “AVEVA Midstream Product Bulletin – Removal of Binary Formatter,” for the compatible-version matrix and the display-migration procedure.
That display step deserves special attention. A client migration that only updates installed binaries but leaves legacy display definitions or integration settings dependent on binary data can fail at cutover. AVEVA’s inclusion of “Migrate HMI displays” is a practical signal that compatibility is not solely a package-version question. Administrators should schedule functional testing of alarms, control workflows, event handling, historic data views, custom scripts, and any display elements that exchange serialized objects.
Microsoft’s .NET guidance also explains why AVEVA is removing the older format rather than attempting to harden it with a limited setting change. BinaryFormatter permits object data to influence the types and object graph created during deserialization; Microsoft states it is insecure and cannot be made secure. JSON is not automatically safe in every application, but moving to a serializer designed around explicit data contracts removes the dangerous general-purpose object reconstruction behavior at the heart of this advisory.
“DNA Authority – Operator” needs a fresh access review
AVEVA’s compensating guidance is not limited to patching. The company tells customers to audit assigned permissions and ensure only trusted users receive “DNA Authority – Operator” rights, to review device inventories, network topology, and perimeter protections against its Enterprise SCADA reference architecture, and to disallow BLT Test clients in production.
The permission review is especially important because the vulnerability begins with an authenticated user. Security teams should pull a current entitlement list, identify named accounts, shared accounts, service identities, contractor access, and accounts that retain operator authority after a role change. Any account that does not require the privilege for routine duties should lose it before the maintenance window, rather than waiting for the broader upgrade project.
Operational technology teams should also separate the question of who can operate the process from which endpoint can submit serialized data. A trusted employee using a compromised HMI workstation still presents a different risk than a malicious employee, and AVEVA’s bulletin does not claim that perimeter defenses substitute for eliminating Binary Formatter. Network segmentation, allow-listed management paths, endpoint monitoring, and least privilege reduce opportunities to reach the vulnerable path; the JSON migration removes the particular unsafe mechanism.
BLT Test clients merit a specific check because AVEVA explicitly calls for their exclusion from production. Test and engineering utilities are often retained for troubleshooting long after a commissioning window closes. Their presence can add an unmanaged client type to a server-client compatibility plan and can complicate the verification that every participating component has moved to JSON.
Build the outage plan around compatibility verification
The cleanest remediation sequence is to inventory first, acquire the AVEVA update through the vendor’s support channel, upgrade all servers and clients to their supported fixed versions, validate operational compatibility, then switch serialization settings and migrate displays in a controlled window. Configuration backups and a documented rollback path should be prepared before changing serializer behavior, but rollback must not become a reason to re-enable acceptance of binary-formatted data indefinitely.
After cutover, teams should verify the configured values on each applicable server, confirm connected products are emitting JSON, confirm HMI displays function correctly, and review application and event-handler logs for rejected legacy payloads or failed client connections. AVEVA’s instruction to re-cache XOS Event Handlers should be treated as a validation point, not a checkbox: the intended code and configuration must be active across redundant and standby systems as well as the primary node.
CISA’s advisory and AVEVA’s bulletin provide the underlying vulnerability record; AVEVA’s remediation language provides the more consequential finding for operators. There is no “patch now, migrate later” safe state described here. A deployment remains short of the vendor’s full mitigation until it no longer accepts Binary Formatter data and all relevant Enterprise SCADA clients, interfaces, and HMI displays have completed the JSON transition.