Emerson DeltaV DCS: Authentication Gaps, CISA Advisories, and Zero Trust Remediation

Emerson’s DeltaV Distributed Control System is the process control backbone at thousands of facilities worldwide — oil refineries, pharmaceutical manufacturing plants, chemical processing sites, and power generation facilities. Its installed base is large enough that DeltaV’s security posture is effectively an OT sector-wide concern, and the historical record of CISA advisories against the platform makes clear that the security baseline has required sustained attention from operators.

This article covers the documented vulnerability landscape, the authentication gaps in legacy DeltaV communication protocols, CISA advisory history, and the hardening path — including what Emerson’s DeltaV v16.LTS release in 2026 changes.

Protocol Authentication Gaps

The most consequential security characteristic of legacy DeltaV deployments is that several of the platform’s internal communication protocols were designed without authentication. A 2022 CISA advisory (ICSA-22-181-03) documented specific protocol categories within DeltaV that lack authentication controls:

Firmware upgrade protocol: DeltaV’s internal firmware update mechanism operates without authentication, meaning an attacker with network access to the DeltaV network could potentially push firmware updates to controllers without credentials.
Plug-and-Play service: The PnP discovery and configuration service does not authenticate connecting nodes, creating a path for an unauthorised device to integrate into the DeltaV network.
HAWK service: The HAWK monitoring and alerting service is unauthenticated, allowing any reachable host to query process values and alarm states.
Management protocol: Internal management communications between DeltaV components are unauthenticated on affected versions.
SIS communications: Safety Instrumented System communications in legacy configurations do not include authentication.
Multicast communications: Process variable broadcasts use unauthenticated multicast, allowing any listening host to receive process data.

The practical implication: an attacker who achieves network access to the DeltaV process control network — through a compromised workstation, a vulnerable remote access path, or physical access to a network switch — can interact with DeltaV controllers and components without supplying credentials. Depending on the specific capability, this includes reading process values, writing to certain memory areas, and interfering with monitoring services.

This is not a software bug that can be patched in isolation. It is a protocol design characteristic of a generation of industrial automation systems built before OT cybersecurity was an active design consideration. Remediation requires a combination of network controls, updated software versions, and architectural hardening.

Workstation Vulnerabilities

Beyond protocol-level issues, CISA advisories have documented multiple vulnerability classes at the DeltaV workstation layer — the Windows-based engineering workstations and operator stations that are the human interface to the control system:

Uncontrolled Search Path Element (CWE-427): DeltaV workstations have been affected by DLL search order vulnerabilities that allow a malicious DLL placed in a searched directory to be loaded by DeltaV processes, enabling code execution in the context of the DeltaV service.

Relative Path Traversal (CWE-23): Path traversal vulnerabilities in workstation components allowed reading files outside intended directories, creating information disclosure risks.

Improper Privilege Management (CWE-269): Certain DeltaV workstation services ran with excessive privileges, meaning a compromised service could be leveraged to escalate to higher-privilege access.

Stack-Based Buffer Overflow (CWE-121): Multiple workstation components have been affected by stack buffer overflows in the parsing of network messages or file formats, enabling potential remote code execution.

The 2018 CISA advisory (ICSA-18-228-01) documented vulnerabilities specifically in DeltaV DCS workstations. CISA’s 2021 advisory (ICSA-21-355-04) covered additional DeltaV components. The 2022 advisory (ICSA-22-181-03) addressed the protocol authentication issues documented above.

Emerson has released patches addressing these workstation vulnerabilities in successive DeltaV versions. The challenge in OT environments is that patching workstations and controllers in production requires planned outages, extensive testing, and coordination with operational teams — creating a lag between patch availability and patch deployment that can stretch to years.

DeltaV v16.LTS: The 2026 Security Baseline

Emerson released DeltaV Version 16.LTS at the start of 2026, described as a “fundamental pivot toward Software-Defined Automation.” From a cybersecurity perspective, v16.LTS introduces several relevant improvements:

Hardware-based security enhancements: The S-series controller hardware introduced with v16.LTS includes hardware-based encryption and secure boot capabilities that were absent from the M-series hardware deployed in older installations. This is a hardware-layer change — existing M-series hardware cannot be upgraded to gain these capabilities without hardware replacement.

Zero Trust alignment: Emerson published a Zero Trust Maturity Model white paper (May 2025) specifically for DeltaV environments, outlining a phased approach to implementing Zero Trust principles within the DeltaV architecture. This reflects the shift in OT security guidance from CISA and IEC 62443 toward zone-and-conduit network segmentation enforced by authentication at the conduit level.

Armexa collaboration: Emerson partnered with Armexa (an OT cybersecurity services firm) to provide cybersecurity assessment and monitoring services for DeltaV customers, extending security capabilities beyond what the platform software alone provides.

v16.LTS represents the security baseline that Emerson is actively maintaining. Facilities still running legacy M-series hardware with older DeltaV versions are running software that has known vulnerabilities and limited security enhancement potential.

Hardening Recommendations for OT Operators

Network segmentation is the highest-priority control. The protocol authentication gaps cannot be patched away in legacy installations; they can only be contained by ensuring that unauthenticated protocols are unreachable from anything other than authorised DeltaV components. IEC 62443 zone-and-conduit architecture, implemented via industrial firewalls at the conduit boundaries, is the correct architectural approach.

Specifically for DeltaV:

The DeltaV network (Level 1/2 in the Purdue model) should be isolated from the DMZ and corporate network by an industrial demilitarised zone (IDMZ) with explicit allow-listing of permitted traffic types and source/destination pairs
Remote access for engineering or support should terminate in the IDMZ and require authentication to an intermediary jump host before accessing the DeltaV network — never direct connectivity from the internet or corporate network to the process control network
Historian replication from DeltaV to business systems should use one-way data diodes or firewall rules permitting only outbound historian queries on the specific ports required

Application whitelisting on DeltaV workstations prevents DLL hijacking attacks and execution of unauthorised tools. DeltaV workstations run a defined set of applications and should not be executing anything outside that set. Emerson provides guidance on configuring application whitelisting for DeltaV environments.

Patch to the latest supported DeltaV version. The workstation vulnerabilities documented in CISA advisories have patches available. Prioritise workstations with direct connectivity to other network zones for patching first, as they represent the highest-risk exposure points.

Implement DeltaV change auditing. DeltaV includes audit logging for configuration changes to controllers and modules. These logs should be exported to a security information system and monitored for unexpected changes — particularly changes to output values, module parameters, or alarm setpoints, which can indicate either an attack or an operational error with safety implications.

Monitor for anomalous DeltaV protocol traffic. Passive OT monitoring tools (Dragos Platform, Claroty Continuous Threat Detection, Nozomi Networks Guardian) include DeltaV protocol decoders that can identify anomalous read/write operations, unexpected devices communicating on the DeltaV network, and protocol patterns inconsistent with normal operations.

Sector Exposure

DeltaV’s installed base is concentrated in sectors where process safety is critical:

Oil and gas: Refinery control, pipeline management, LNG terminals
Pharmaceutical: Drug manufacturing batch processes (GMP-regulated environments)
Chemical: Continuous process control for commodity and specialty chemicals
Power generation: Combined cycle plant control, substation automation

A successful attack on a DeltaV system in any of these environments carries the potential for process disruption, safety system interference, or environmental release. The TRITON/TRISIS malware (2017-2019) — which targeted Schneider Electric Safety Instrumented Systems — demonstrated that nation-state adversaries are capable of and willing to target safety-critical OT systems. DeltaV’s SIS communications gap in legacy versions is directly relevant to that threat model.