Beckhoff TwinCAT and EtherCAT Security: Attack Surface Analysis and Hardening Guide

Beckhoff Automation’s TwinCAT platform is a PC-based control system that runs on standard x86 hardware alongside Windows, making it one of the most prevalent control platforms in European manufacturing, automotive, logistics, and building automation. Its prevalence combined with its Windows-native architecture creates a security attack surface that differs meaningfully from traditional PLC environments — and that OT security teams frequently underestimate.

The TwinCAT Architecture Security Implications

TwinCAT runs as a Windows driver (TwinCAT/BSD on newer Beckhoff IPCs), co-existing with a standard Windows installation. The control runtime shares hardware with a general-purpose OS. This architecture provides operational flexibility — Windows applications can communicate directly with the control runtime, and standard IT tools can manage the underlying OS — at the cost of a larger attack surface than a dedicated embedded controller.

The security consequences:

Windows attack surface applies. A TwinCAT IPC running Windows is subject to the same vulnerability classes as any Windows system: unpatched OS CVEs, remote desktop vulnerabilities, SMB exploitation, and weak credential attacks. Unlike a dedicated PLC, a compromised TwinCAT IPC gives an attacker both control-system access and a functional Windows environment from which to conduct further lateral movement.

ADS (Automation Device Specification) is unauthenticated by default. ADS is the native Beckhoff communication protocol used between TwinCAT components, engineering workstations (TwinCAT XAE), and SCADA systems. It uses AMS (AMS Net IDs — six-octet addresses) for routing, but there is no built-in authentication in the base protocol. Any device with network access and knowledge of a target’s AMS Net ID can send ADS commands, including reading and writing to PLC variables, starting and stopping the control runtime, and modifying task scheduling.

EtherCAT is not inherently secure. EtherCAT is a deterministic real-time fieldbus protocol operating at Layer 2. It is not designed with security in mind — there is no authentication, no encryption, and no mechanism to prevent a device on the EtherCAT segment from injecting malicious frames or spoofing an I/O module.

Known Vulnerability Classes

ADS Remote Code Execution

Beckhoff has disclosed and patched multiple vulnerabilities in the ADS protocol stack over the past several years. Critical concerns include:

CVE-2023-51178 through CVE-2023-51184: A set of memory corruption vulnerabilities in the Beckhoff ADS server component disclosed by CISA in early 2024. These allow unauthenticated remote code execution on systems with ADS exposed to the network. CVSS scores ranged from 7.5 to 9.8.
TwinCAT 3 prior to 3.1.4026.0: Earlier versions of TwinCAT 3 had ADS server components with insufficient input validation on message parsing, creating buffer overflow conditions exploitable over the network.

Patch status: the patches are available, but TwinCAT update deployment in production environments is operationally challenging. Many facilities defer TwinCAT updates during production runs, leaving patching cycles measured in months rather than weeks.

EtherCAT Segment Attacks

An attacker with physical or logical access to the EtherCAT segment — either through a compromised device on the bus or through an IT/OT boundary that allows Layer 2 traffic to reach the fieldbus — can:

Inject malicious EtherCAT frames targeting specific process data object (PDO) mappings, modifying I/O values being read by the controller
Replay captured process data, causing the controller to act on stale or fabricated sensor readings
Enumerate connected slaves and their process image layouts, enabling targeted manipulation of specific I/O modules

The EtherCAT specification does not define security extensions; safety-critical applications relying on EtherCAT for communication between the controller and safety I/O modules should implement additional application-layer integrity checks.

TwinCAT Engineering Port (TCP 48898)

TwinCAT’s ADS-over-TCP service listens on TCP 48898 by default. This port provides direct access to the ADS router, which can route commands to any reachable TwinCAT system. If this port is accessible from an IT network or the internet, it presents a significant attack surface. Confirmed exploitation of internet-exposed TwinCAT ADS ports has been documented in multiple incident response engagements.

Hardening Steps

1. Isolate the ADS Network

ADS traffic should not traverse the IT/OT boundary. Place TwinCAT IPCs and engineering workstations on a dedicated OT network segment with firewall rules that block TCP 48898 and UDP 48898 from IT networks and external interfaces.

If ADS connectivity from an engineering workstation to the OT network is required, route it through a jump server or privileged access workstation (PAW) with session logging enabled — not an open firewall rule from the IT network to the OT segment.

Firewall rule template (iptables/nftables on OT DMZ firewall):

# Block ADS protocol from IT network to OT network
iptables -I FORWARD -s <IT_NETWORK_CIDR> -d <OT_NETWORK_CIDR> -p tcp --dport 48898 -j DROP
iptables -I FORWARD -s <IT_NETWORK_CIDR> -d <OT_NETWORK_CIDR> -p udp --dport 48898 -j DROP

2. Use ADS Firewall Feature

TwinCAT 3 includes an ADS firewall (configured in TcAdsFirewall.xml) that allows administrators to restrict which AMS Net IDs can communicate with the local ADS router and what operations they can perform. This is underused in most deployments.

Configure the ADS firewall to:

Whitelist only the AMS Net IDs of legitimate clients (SCADA systems, authorised engineering workstations)
Restrict SCADA/HMI systems to read-only variable access where possible
Deny all ADS traffic from AMS Net IDs not explicitly listed

Beckhoff documentation for ADS firewall configuration is available in the TwinCAT 3 Information System under “ADS Communication Security.”

3. Harden the Windows Host

TwinCAT IPCs run Windows; apply standard Windows hardening:

Disable RDP unless actively needed; if needed, restrict source IPs and use NLA
Disable SMBv1 (Set-SmbServerConfiguration -EnableSMB1Protocol $false)
Remove unnecessary Windows services and features
Apply OS patches on a scheduled maintenance cycle — coordinate with control engineers but do not indefinitely defer patches
Enable Windows Defender Application Control (WDAC) to restrict which executables can run on the IPC

4. EtherCAT Segment Physical Security

EtherCAT segments are Ethernet at Layer 2. Physical security of the EtherCAT cabling and terminal blocks matters: an unoccupied EtherCAT port on a terminal block or I/O module can be used to inject traffic onto the segment. Audit physical access controls for EtherCAT infrastructure, particularly in facilities where third-party maintenance engineers have regular access.

For new deployments, consider placing safety-critical EtherCAT I/O on dedicated EtherCAT segments separated from general-purpose I/O.

5. Monitor ADS Traffic

Deploy passive monitoring (using industrial network sensors such as Claroty, Dragos, or Nozomi) on the OT network to baseline ADS traffic patterns and alert on:

ADS connections from unexpected source AMS Net IDs
ADS write commands to PLC variables during non-maintenance windows
ADS runtime start/stop commands
Connections to TCP 48898 from sources outside the authorised whitelist

OT network monitoring is increasingly standard practice, but the ADS-specific detection logic is less commonly configured. Work with your network monitoring vendor to confirm that Beckhoff ADS parsing is enabled and that write-command detection is active.

Patch Management for TwinCAT

TwinCAT patch management is operationally constrained: updating the TwinCAT runtime typically requires a maintenance window since it interrupts the control runtime. This creates pressure to defer patches. Recommended practice:

Maintain a test TwinCAT IPC (identical software configuration to production) on which patches can be validated before deploying to production
Schedule TwinCAT OS and runtime patches quarterly at minimum, aligned with planned shutdown windows
Track CISA ICS Advisories for Beckhoff-specific CVEs; the cadence is typically several advisories per year

Current advisory tracking: as of August 2026, the most recently active Beckhoff advisory relates to TwinCAT OPC-UA server components. Monitor the CISA ICS Advisory page filtered for Beckhoff.