Digital Twin Security Guide: Data Flows, Access and Model Integrity

A digital twin pulls live data out of plants, buildings, vehicles and networks into one model, which makes it both a valuable target and a new path back into the physical systems it mirrors. Twins sit across OT, IT and cloud: sensors and controllers feed them, analytics and AI run on them, and some twins send set points or commands back. If the data is tampered with, operators and algorithms make decisions on a false picture; if the twin's identities are over-privileged, its cloud platform becomes a bridge into OT. This guide covers twin architectures, the OT to twin data path, access control and service identities, model and data integrity, cloud platform settings, and how NIST IR 8356 frames twin security. It is written for OT and cloud security engineers, architects building twins, and security leads who need to approve them.

Key takeaways

• Classify the twin by what it can do, not what it shows. A read-only monitoring twin, a simulation twin and a closed-loop twin that writes back to controllers need very different controls; write-back puts the twin inside the OT trust boundary.
• Keep OT data flows one way unless there is a proven need. Push data out from the OT side through a DMZ or unidirectional gateway, and never let the cloud initiate connections into control networks by default.
• The twin's service identities are its biggest privilege. Connector roles, managed identities and ingestion keys often hold broad read and write rights across storage and IoT services, so scope them per twin and per data source.
• Integrity is the primary security property. NIST IR 8356 warns that attackers could alter what operators see in the twin or hide changes, so protect data provenance, model versions and visualisation as carefully as the data itself.
• Centralisation concentrates risk. A twin pools measurements from many systems in one place, so one compromised tenant, account or API can expose a whole site's operating picture.

What a digital twin is, and why its security is different

NIST IR 8356, Security and Trust Considerations for Digital Twin Technology (final, February 2025), defines a digital twin as the virtual representation of a physical or perceived real-world entity, concept or notion. The Digital Twin Consortium describes it as an integrated, data-driven virtual representation of real-world entities and processes, synchronised at a specified frequency and fidelity. ISO 23247-1:2021 sets out a digital twin framework for manufacturing. The common thread is synchronisation: the twin is only useful while it reflects reality, and its security fails the moment it stops doing so without anyone noticing.

NIST IR 8356 lists five security challenges that are new with twins: massive instrumentation with inexpensive sensors that may be untrustworthy; centralisation of measurements, which creates one target; visualisation, where an attacker could alter what operators see in a VR or AR view or hide changes while controlling the twin; remote control, where a compromised instance could expose raw control signals behind a misleading high-level model; and the lack of standards for secure universal access to distributed models. The rest of this guide turns those into controls.

Securing the OT to twin data path

Most twin compromises that matter to operations will travel along the data path. Design it before choosing a platform.

• Collection at the edge: gateways read data from PLCs, historians and sensors, often over OPC UA (TCP 4840) or Modbus, and publish onwards. Use OPC UA with the SignAndEncrypt security mode and application certificates rather than the None mode, and keep gateways in an OT DMZ rather than on the control network. See the Edge Device Security Guide.
• Direction: the OT side should initiate outbound connections; the cloud should not open sessions inward. For high-consequence sites, a unidirectional gateway or data diode enforces this in hardware for monitoring twins.
• Transport: use TLS for every hop, for example MQTT over TLS on port 8883 or HTTPS to the cloud ingestion endpoint, with per-device certificates. See the Device and IoT Identity Guide.
• Data minimisation: send the tags the twin needs, at the rate it needs. Full historian replication to a cloud twin exposes far more process detail than most use cases require.
• Write-back: if the twin must send set points, route them through a separate, approved path that ends at an OT system which validates ranges and rates, logs every change and can be switched off locally. Safety functions must never depend on the twin.
• Zones and conduits: treat the twin connection as an IEC 62443 conduit between the OT zone and an external zone, with documented allowed flows. See the IEC 62443 Guide.

Access control and twin identities

A twin has two populations of identities: people (operators, engineers, data scientists, vendors) and services (ingestion functions, connectors, analytics jobs, AI agents). The second group is usually larger, less visible and more privileged.

• Data plane roles: Azure Digital Twins authorises requests with Microsoft Entra ID and Azure RBAC. It has two built-in data plane roles, Azure Digital Twins Data Owner (full access) and Azure Digital Twins Data Reader (read-only), and supports custom roles scoped to models, queries, twins, relationships and event routes. Microsoft recommends the narrowest possible scope. Most users need Reader; reserve Owner for the pipeline that maintains the graph.
• Managed identities over keys: Azure Digital Twins supports system-assigned and user-assigned managed identities for endpoints such as Event Hubs, Service Bus and Storage, so no keys or SAS tokens need storing. Event Grid endpoints do not support identity-based authentication, so plan compensating controls for them. See the Azure RBAC and Service Principals Guide.
• Setup versus runtime rights: the Azure Digital Twins data history feature needs broad roles during setup (Azure Event Hubs Data Owner, Contributor on the Azure Data Explorer cluster or database, Admin on the database) but only Azure Event Hubs Data Sender during normal operation. Remove the setup-only roles afterwards.
• Workspace roles in AWS: an AWS IoT TwinMaker workspace uses a service role trusted by iottwinmaker.amazonaws.com. AWS documentation shows an example S3 policy on arn:aws:s3:::* and a scoped version on the workspace bucket; use the scoped one. Connector permissions such as iotsitewise:BatchPutPropertyValues write data, so grant them only where the twin must write. Add aws:SourceAccount and aws:SourceArn conditions to the trust policy to prevent confused deputy use. See the AWS IAM Policies and Roles Guide.
• People: SSO with MFA for all human access, phishing-resistant MFA for administrators, and separate accounts for platform administration and twin use. NIST IR 8356 lists strong, multi-factor authentication among the traditional controls twins need.
• AI agents and analytics: agents that query or act on the twin should have their own identities, read-only by default, with write tools gated by approval.

See the Cloud Workload Identity Guide for scoping service identities across cloud platforms.

Model and data integrity

NIST IR 8356 defines trust in a twin as the probability that intended and actual behaviour match in a given context, environment and time, and lists 14 trust considerations, including temporal synchronisation, accuracy, error propagation and counterfeiting. In security terms, the questions are whether the data is genuine, whether the model is the approved version, and whether what people see matches the underlying state.

• Provenance: sign or authenticate data at the gateway, keep source timestamps alongside ingestion timestamps, and reject data from unknown devices. Azure Digital Twins data history, for example, records both TimeStamp and SourceTimeStamp in its property events table, which helps spot replay and delay.
• Plausibility checks: compare sensor values against physical limits, rates of change and correlated sensors. Inexpensive sensors and their gateways are the easiest place to inject false values.
• Model version control: keep twin models (for example DTDL models), simulation models and ML models in version control with reviewed changes, hashes and a record of which version is live.
• Visualisation integrity: operators should be able to check critical values against an independent source such as the local HMI. The ATT&CK for ICS technique Manipulation of View (T0832) describes exactly the outcome to avoid.
• History and audit: retain property, twin lifecycle and relationship lifecycle history so you can reconstruct what changed and when. Store it with access separate from the live twin.
• Backups: back up the twin graph, models and configuration so a corrupted twin can be rebuilt from a known good state.

Cloud platform hardening

See the Microsoft Azure Security Guide for tenant-wide controls.

Implementation approach

1. Define the twin's purpose and class: record whether it monitors, predicts, simulates or controls, which assets it covers and who uses it. Closed-loop twins need OT security and safety sign-off before design starts.
2. Map data flows: draw every flow from sensor to twin to consumer, with protocol, port, direction, identity and data classification. This becomes the conduit specification.
3. Build the path one way first: deploy collection through a DMZ or unidirectional gateway, prove the twin works read-only, and keep write-back for a later, separately approved phase.
4. Set identities and roles: create one service identity per connector or function, assign the narrowest built-in or custom roles, and remove setup-time privileges after deployment.
5. Harden the platform: enable private endpoints, restrict downstream stores, turn on diagnostic logging and alerting, then disable public access once private tooling is in place. Test in a non-production instance first and keep the previous network configuration documented so you can roll back.
6. Add integrity controls: plausibility rules, model version control, history retention and independent verification of critical values.
7. Pilot write-back, if needed: start with advisory set points that an operator confirms, enforce range and rate limits at the OT side, and keep a local switch to disconnect the twin.
8. Review quarterly: roles, data flows, new consumers (especially AI tools) and supplier access.

Small versus large organisations: a single building or plant twin can usually rely on a managed cloud service, private endpoints, managed identities and a DMZ broker. Large estates with many twins need a twin register, standard conduit patterns, a central PKI for gateways and a governance layer that approves new data sources and consumers.

Detection and measurement

• Identity events: new role assignments on the twin, keys or secrets created for connectors, and service identities used from unexpected locations.
• Data anomalies: values outside physical limits, gaps or bursts in telemetry, large differences between source and ingestion timestamps.
• Model changes: model uploads, deletions and relationship changes outside the release pipeline.
• Bulk access: large queries or exports from the twin or its analytics store.
• Write-back: every command or set point sent to OT, with who or what approved it.

Framework mapping

NIST IR 8356 points to the NIST Risk Management Framework, the Cybersecurity Framework, the Privacy Framework and SP 800-53 Rev. 5 for traditional controls, and recommends a zero trust approach. For the OT side, NIST SP 800-82 Rev. 3 is the main reference. In ISO/IEC 27001:2022 Annex A the closest controls are A.5.23 (cloud services), A.8.3 (information access restriction), A.8.16 (monitoring) and A.8.22 (segregation of networks).

Common failure patterns

• Wildcard connector roles. Teams copy example policies with access to every bucket or every asset, and the twin's role quietly becomes one of the most powerful identities in the account.
• Public access left on for convenience. Browser explorers, partner dashboards and proof-of-concept tools keep twin APIs and analytics clusters on the internet long after the pilot.
• Inbound connections into OT. A closed-loop pilot opens a path from cloud to controllers that is never removed, bypassing the DMZ.
• Trusting sensor data blindly. No plausibility checks, no source timestamps and no device authentication, so false values flow straight into decisions.
• Leaked platform credentials. Connected product and vehicle backends depend on cloud keys; the Toyota T-Connect key exposure left an access key on public GitHub for about five years, the kind of secret that also feeds fleet and vehicle twins.
• Simulation copies treated as harmless. Full process models, network maps and historian exports in a data science sandbox give an attacker a rehearsal environment.

Practitioner checklist

• Record each twin's class (monitoring, predictive, simulation, closed-loop), owner, assets and consumers.
• Map every data flow with direction, protocol, port, identity and classification, and approve it as a conduit.
• Push OT data outbound through a DMZ broker or unidirectional gateway; allow no cloud-initiated sessions into control networks without an exception.
• Use OPC UA SignAndEncrypt, TLS on every hop and per-device certificates for gateways.
• Give each connector its own service identity with roles scoped to named resources, and remove setup-only roles after deployment.
• Enable private endpoints, restrict downstream stores and turn off public access once private tooling works.
• Version-control twin, simulation and ML models, and add plausibility checks on critical tags.
• Route any write-back through OT-side validation with range and rate limits, logging and a local disconnect.
• Alert on role grants, model changes, bulk exports and telemetry anomalies.
• Review roles, flows and new consumers, including AI tools, every quarter.

Standards and references

• NIST: IR 8356 Security and Trust Considerations for Digital Twin Technology
• NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
• ISO: ISO 23247-1 Digital twin framework for manufacturing
• Digital Twin Consortium: Definition of a digital twin
• Microsoft Learn: Secure Azure Digital Twins
• Microsoft Learn: Azure Digital Twins data history
• AWS: IoT TwinMaker workspace service role
• MITRE ATT&CK: Manipulation of View

Related NHI Mgmt Group resources: OT Security Guide · IoT Security Guide · Edge Device Security Guide · Cloud Workload Identity Guide · IEC 62443 Guide