Digital twins — software representations of physical assets, processes, or systems that are continuously synchronised with their real-world counterparts — have moved from industrial concept to mainstream deployment across energy, manufacturing, water, and transport sectors. Siemens, AVEVA, GE Vernova, and Rockwell Automation all offer digital twin platforms integrated with their OT product lines. The business case is compelling: predictive maintenance, operator training without production risk, process optimisation, and remote monitoring all become substantially more capable with a live digital replica.
The security implication is less prominently discussed: digital twins require continuous data flows between physical assets and software environments, often introducing cloud connectivity or IT network access into OT zones that were previously isolated. Every bidirectional data channel into an OT environment is a potential attack path. The attack surface digital twins create is real and in many current deployments, inadequately analysed.
What Digital Twins Connect
Understanding the security risk requires understanding what a digital twin actually connects in practice.
At the asset level, sensors and controllers stream operational data — temperatures, pressures, flow rates, vibration signatures, energy consumption — to the twin platform. This requires communication paths from OT assets that may sit in SCADA/DCS networks (Purdue Model Level 2-3) to data aggregation systems that feed the twin.
The twin platform itself is typically hosted in an IT environment, a vendor-managed cloud, or increasingly in hyperscaler cloud infrastructure (Azure IoT Hub, AWS IoT Greengrass, GE’s Predix). The twin ingests operational data, runs simulations, generates maintenance predictions, and may feed recommendations back to operators — or in automated configurations, directly to control systems.
For operator training applications, the twin needs to respond to simulated operator inputs and mimic control system behaviour. This means the twin has a model of the control logic running in the production system, which itself represents a valuable intelligence asset for an adversary mapping OT vulnerabilities.
For process optimisation applications, the data flows may be bidirectional — the twin generates setpoint recommendations that are applied to production systems, either manually by operators or through automated feedback loops.
Attack Path 1: The Twin as an OT Pivot
The most direct risk: an attacker who compromises the digital twin platform has a foothold adjacent to OT systems. If the data flows between the twin and OT assets are bidirectional and not strictly filtered, the compromised twin environment becomes a pivot point toward control system networks.
This is not theoretical. The pattern of adversaries using IT-side infrastructure as a staging point for OT lateral movement is well-documented (Volt Typhoon’s pre-positioning in IT networks adjacent to US critical infrastructure utilities, the Ukraine power grid attacks that used IT compromise as the entry point for SCADA access). A digital twin platform that has network adjacency to Level 2-3 OT systems, and that was introduced without re-evaluating network segmentation architecture, extends the IT-OT adjacency that attackers seek.
Assessment questions for your environment:
- Does the digital twin platform have direct network access to OT assets, or does data flow through a DMZ or data diode?
- Are the data collection agents running on OT assets (PLCs, historians, SCADA servers) accessed from the twin environment? If so, what is the authentication and network path?
- Are there bidirectional data flows — not just OT-to-twin, but also twin-to-OT? What is the mechanism, and is it strictly authenticated?
Attack Path 2: The Twin as an Intelligence Target
Even without direct pivot capability, the digital twin represents a high-value intelligence target for adversaries planning OT attacks. A well-implemented digital twin contains:
- A real-time operational model of the physical process, including current operating states, setpoints, and historical patterns
- Control logic models derived from actual PLC/DCS configurations
- Predictive maintenance data that reveals asset condition and degradation patterns
- Operator behaviour patterns and decision logic
- Vendor and equipment configuration details
An adversary who exfiltrates digital twin data gains detailed knowledge of industrial processes, control system architecture, and operational patterns that would otherwise require physical access or extensive reconnaissance inside the OT environment to obtain. For infrastructure attack planning — the kind of pre-positioning documented in Volt Typhoon and Sandworm operations — this represents significant intelligence value.
Vendor-hosted twin platforms introduce third-party risk. If your twin data is hosted in a vendor cloud and the vendor’s infrastructure is compromised, that data is potentially accessible to the adversary regardless of your own security posture.
Attack Path 3: The Supply Chain Through Vendor Tools
Digital twin platforms typically include vendor-managed connectivity components: agents running on OT assets, configuration management tools, and remote access capability for vendor support. These components represent supply chain risk.
The Siemens SIMATIC environment, AVEVA System Platform, and GE Vernova’s SCADA platforms all have vendor support mechanisms that create remote access paths into OT environments. If a vendor’s update infrastructure or support access mechanism is compromised, those access paths become adversary entry points into customer OT environments.
The Hitachi Energy supply chain advisory published earlier this year (ICSA-26-188-02) covering the ProMod V platform illustrates the pattern: third-party software components in OT vendor products create supply chain exposure that customers must track and remediate, often with significant operational complexity in environments where software updates cannot be applied without extended maintenance windows.
Segmentation Requirements for Digital Twin Deployments
The fundamental control for digital twin security is maintaining meaningful segmentation between the twin platform and the OT environment it models, even when operational data flows require connectivity.
Data diodes for telemetry collection provide hardware-enforced unidirectional data flow — data can move from OT assets to the twin, but no network path exists in the reverse direction. This eliminates the pivot risk at the cost of preventing bidirectional twin-to-OT optimisation flows. For critical infrastructure environments, this trade-off is appropriate.
Historian-mediated data collection maintains the Purdue Model boundary by having OT historians (already in the OT/IT DMZ) serve as the data collection point. The twin reads from the historian rather than directly from PLCs or DCS assets. This limits the twin’s direct network exposure to OT Level 2-3 systems.
Strict network access controls for twin-to-OT data paths: if bidirectional flows are operationally required, they should traverse a clearly defined, monitored path with protocol validation (not generic TCP/IP), source/destination restrictions, and inspection that understands the industrial protocols in use (OPC UA, Modbus, DNP3). Generic firewall rules that permit “OT segment to cloud” traffic without protocol-level validation are insufficient.
Separate authentication domains for twin access and OT access. Credentials that authenticate to the digital twin platform should not also grant access to OT control systems. The twin platform should be treated as an IT system with its own identity management, regardless of what it connects to.
Sector-Specific Considerations
Energy: Grid digital twins connected to EMS/SCADA create particular risk given the regulatory significance of grid operations and the documented nation-state interest in pre-positioning in energy infrastructure. NERC CIP requirements apply to bulk electric system assets and do not directly mandate twin security standards — but the principle of electronic security perimeters that CIP defines should be applied to the network boundaries around twin connectivity.
Manufacturing: Digital twins in smart manufacturing environments often have the closest integration with production control systems, including real-time feedback loops. This operational value is also the greatest security risk. Manufacturing OT is increasingly a ransomware target; twins provide a logical lateral movement path from corporate IT networks where initial access typically occurs.
Transport: Rail and aviation digital twins for asset management, predictive maintenance of rolling stock, and infrastructure monitoring are expanding rapidly post-infrastructure investment cycles. NIS2 obligations apply to essential transport operators and require risk management measures appropriate to the services being provided — digital twin connectivity is an emerging area where NIS2 compliance programmes should extend.
Operational Guidance
Before deploying a digital twin or before expanding an existing twin’s connectivity:
Conduct a security architecture review that specifically addresses the new network paths the twin requires. Map every data flow — source, destination, protocol, authentication mechanism, directionality — and assess each against the segmentation principles that protect your OT environment.
Engage your OT security team (or OT security service provider) alongside the operational technology and IT teams driving the twin deployment. Vendor-driven rollouts that prioritise operational capability over security architecture have repeatedly created the twin connectivity risks described above.
Establish monitoring for data flows between the twin platform and OT assets. Anomalous volumes, unexpected source addresses, or protocol deviations from the expected telemetry pattern may indicate the connectivity is being used for purposes beyond operational data collection.