Securing the Digital Twin: An Implementation Guide for Manufacturing and Industrial Simulation Environments

A digital twin introduces risk in three places that a traditional OT security program is not built to cover, and all three sit on top of, not instead of, the existing plant-floor attack surface.

• Ingestion pipeline integrity. Every twin is only as trustworthy as the telemetry it ingests. An attacker who can inject, replay, or subtly alter sensor readings between the observable manufacturing element and the digital twin domain does not need to touch a single PLC to make the twin misrepresent the state of the physical system.
• Model integrity. The twin's model, whether a physics-based simulation, a statistical fusion of sensor streams, or a trained machine learning component, can drift from reality through unmanaged retraining, or be deliberately poisoned if the training pipeline and the update mechanism are not access-controlled and version-tracked like any other production code path.
• Twin-to-physical command injection. Where a twin is permitted to push a parameter, a setpoint, or a maintenance action back to real equipment, whether through a closed automated loop or a human approving a twin-generated recommendation, that pathway is a new command channel into the physical process, and it needs the same scrutiny as any other write path into a control system, not the implicit trust an IT-side integration usually gets.

These three surfaces are distinct from the industrial protocol and network-level risks covered in our general OT/ICS platform coverage; a Dragos or Claroty sensor watching Modbus traffic on the plant floor will not tell you whether the model consuming that traffic has been poisoned or whether the twin's write-back API has an authorization gap.

• OT network segmentation already in place. The observable manufacturing element and device communication entity domains need to sit in a segmented OT zone, separate from the digital twin domain's IT or cloud infrastructure, before you start layering twin-specific controls on top.
• An inventory of every data source feeding the twin. List each PLC, historian, SCADA gateway, and IoT sensor that supplies telemetry, along with the protocol and authentication method each one uses. You cannot secure an ingestion pipeline you have not fully mapped.
• A defined trust boundary for the model. Decide, before implementation, whether the twin is read-only (monitoring and simulation only), advisory (a human reviews and approves any twin-derived action before it reaches physical equipment), or closed-loop (the twin can act on the physical system with no human in the path). This decision drives nearly every control in the sections below.
• Version control and change management for the model itself. The model, its training data, and its configuration need to be treated as a production artifact with its own change log, not an analytics notebook that gets silently updated.
• Executive and OT engineering sign-off on the command path, if one exists. A twin that can write back to physical equipment is a new control system integration point, and it needs the same engineering and safety review any other new command path into the plant would get.

1. Authenticate and sign telemetry at the source. Every device communication entity feeding the digital twin domain should authenticate with a unique credential or certificate rather than a shared gateway account, and where the underlying protocol supports it, telemetry should be integrity-protected (signed or sent over an authenticated, encrypted channel) so the digital twin domain can detect tampering or replay in transit, not just at rest.

2. Deploy the device communication entity as a mediating layer, not a pass-through. ISO 23247 places a device communication entity domain between the observable manufacturing element and the digital twin domain specifically so that raw field-level access is never granted directly to twin-side infrastructure. Configure this layer to normalize, timestamp, and validate incoming data against expected ranges before forwarding it, rejecting or flagging readings that fall outside physically plausible bounds.

3. Version and hash every model artifact. Store the model definition, its parameters or trained weights, and its training or calibration dataset under version control, and record a cryptographic hash of the deployed model artifact at release time. Any discrepancy between the hash of the running model and the hash of the last approved release is a signal to investigate before trusting that model's output.

4. Gate model retraining and updates behind a change-controlled pipeline. Treat a model update the same way you would treat a firmware update to a PLC: require review and approval before a retrained or reconfigured model replaces the one currently in production, and retain the ability to roll back to the last known-good model artifact.

5. Continuously validate the twin against ground truth. Run an independent comparison between the twin's model output and a small set of directly instrumented physical measurements on a recurring schedule. A twin that has drifted from the physical asset it represents, whether from stale calibration or a poisoned model, will diverge from ground truth before it produces an obviously wrong result.

6. Classify the command path and apply matching controls. If the twin is read-only or advisory, ensure there is no technical write path from the digital twin domain back to the observable manufacturing element domain at all, only through the device communication entity to a human-reviewed action queue. If the twin is closed-loop, apply the same authentication, rate limiting, bounds checking, and logging to twin-originated commands that you would require of any other automated write path into a control system, and make sure a physical or engineering-level override can halt or reject a twin-originated command regardless of what the twin's software layer decides.

7. Restrict the user domain to the least access each role needs. An operator viewing a dashboard, an engineer adjusting simulation parameters, and an administrator managing model deployments are three different privilege levels; ISO 23247's user domain should not be treated as a single flat access tier, and no user domain account should have a path to the observable manufacturing element domain that bypasses the digital twin and device communication domains.

8. Log every cross-domain interaction. Every transaction between the observable manufacturing element, device communication entity, digital twin, and user domains should be logged with enough detail to reconstruct, after the fact, exactly what data entered the twin, what the model produced, and what, if anything, was sent back to physical equipment.

Replay a known-good telemetry capture with a single sensor value altered outside its physically plausible range and confirm the device communication entity layer flags or rejects it rather than passing it through to the model unmodified. Deploy a deliberately altered model artifact (a changed parameter, not a retrained model) to a staging environment and confirm the hash-verification step in your deployment pipeline blocks it from reaching production. Run the twin's model against a physical measurement you know to be correct and confirm your ground-truth validation step actually flags the resulting discrepancy, rather than silently absorbing it into the next scheduled recalibration. If a command path exists, submit a synthetic twin-originated command that falls outside a configured safe operating bound and confirm it is rejected at the device communication entity or the physical control system's own limits, not solely by logic inside the twin's own software. Attempt to log in to the digital twin domain with a user-domain account that should not have write access to the command path, and confirm the attempt is denied and logged, not merely hidden from the interface.

Silent model drift mistaken for a stable twin. The most common real-world failure is not a dramatic breach but a twin that has quietly drifted from the physical system it represents, because no one built a recurring ground-truth validation step into the deployment. The twin keeps producing plausible-looking output, and the people relying on it have no reason to doubt it until a decision made on the twin's recommendation turns out to be wrong.

A shared or over-privileged device communication entity credential. Treating the device communication entity layer as a single trusted gateway with one shared credential, rather than authenticating each observable manufacturing element source individually, means a single compromised credential grants an attacker the ability to inject fabricated telemetry from any connected device, not just one.

An advisory twin that quietly became closed-loop. A twin deployed as advisory, with a human expected to review recommendations before acting on them, can drift into de facto closed-loop operation once operators start automatically accepting every recommendation without review. At that point the safety and access controls appropriate to a closed-loop system are needed, but were never implemented, because the deployment was never formally reclassified.

Compromise of an upstream manufacturing system feeding the twin's training data. A digital twin's model is only as trustworthy as the data used to train or calibrate it, and that data often comes from the same product lifecycle and manufacturing execution systems targeted by ransomware operators; our coverage of the Clop campaign against Windchill and FlexPLM is a concrete example of the kind of upstream manufacturing software compromise that can quietly poison a twin's training data long before the twin itself is directly attacked.

Model update pipeline treated as a data science workflow instead of a production deployment. Where a model is retrained or recalibrated through an ad hoc notebook process outside the organization's normal change-management and code review discipline, there is no reliable way to detect an unauthorized or accidental change to production model behavior until its output starts diverging from expectations.

Authenticating and validating telemetry at the device communication entity layer adds latency and engineering overhead to a pipeline that plant teams often expect to be near real time. Bounds checking and integrity verification will occasionally reject legitimate but unusual readings, and the operational cost of tuning those thresholds correctly is ongoing, not a one-time setup task.

Hash-verifying and version-controlling every model artifact assumes the organization has the model management maturity of a software engineering team, not a data science or simulation team, and standing that discipline up is a real organizational cost that is easy to underestimate at the start of a twin project.

Ground-truth validation catches drift and poisoning that has already produced a measurable divergence from reality; it does not catch a model that has been subtly manipulated in a way that stays within the tolerance of your validation checks. A validation process is only as good as the physical measurements and thresholds it is built around, and a sufficiently patient or well-informed adversary can in principle stay under that threshold.

Restricting or eliminating the command path back to physical equipment is the single most effective control available, and it is also the one most likely to be quietly weakened over time by legitimate operational pressure to automate more of the loop. Any decision to move a twin from read-only or advisory toward closed-loop operation should be treated as a new control system deployment requiring its own engineering, safety, and security review, not an incremental software update to an existing dashboard.