Before the SOC acts: attack-path modelling and digital twins across IT and OT

The security team wants to close the supplier's remote-access connection. The production team needs it for scheduled maintenance. Both have a good reason.

A new threat intelligence report describes attackers using the same technology to reach engineering systems. Before anyone changes a rule, we need to establish whether that route exists here and what closing it would interrupt.

This is the sort of decision attack-path modelling and digital twin simulation should help us make. We need a current picture of the service, a way to compare interventions and evidence that the chosen action will work. The recovery arrangements belong in that picture too.

The NCSC's guidance on creating and maintaining a definitive view of OT architecture provides a useful foundation. It covers maintaining the record, identifying assets, documenting connectivity and understanding third-party risks. The proposal here builds on that systems understanding to ask what a change would do across IT, OT and the organisation's recovery arrangements. NCSC OT architecture guidance.

What are we actually modelling?

An attack path describes a sequence of conditions and actions through which an adversary could reach an objective. Across IT and OT, that might involve an enterprise identity, a remote-access service, a jump host, an engineering workstation and an operational system.

A network connection alone doesn't establish that path. The attacker may also need a particular privilege, a vulnerable configuration or a session that is currently available. Each step has prerequisites. If the model ignores them, it can produce plausible-looking routes that don't work, or miss routes that do.

For this article, a cybersecurity digital twin means a maintained model of the parts of an environment relevant to a security decision, with a defined relationship to evidence from that environment. It may represent configurations, identities, connectivity and dependencies. More detailed implementations may also simulate software execution or physical processes.

Before relying on a twin, ask what it represents, how it is updated and which questions it has been validated to answer.

Following the dependencies across IT and OT

Claroty and Frenos announced a partnership in July 2026 that connects asset intelligence with environment-specific digital twins, attack simulation and remediation prioritisation. The announcement also describes validating segmentation and firewall policies. These are the vendors' stated capabilities; I haven't independently tested them. Claroty and Frenos announcement.

An OT asset may depend on enterprise authentication, supplier access or a system run by another team. Our model needs to follow those relationships across departmental boundaries.

Operational requirements also shape which interventions are acceptable. NIST's Guide to OT Security addresses security alongside the distinctive performance, reliability and safety requirements of these environments. Those requirements help determine what we need to simulate. NIST SP 800-82 Rev. 3.

Build a knowledge graph of the service

For our production line, start with the equipment, applications, access arrangements and people needed to keep it available.

A knowledge graph makes those objects and their relationships explicit. A workstation runs software, an identity administers it, a process depends on it, and a recovery procedure requires access to a backup and an authorised operator. We can follow an attack path through that model, then examine the dependencies needed for recovery.

Include data, software components, business processes, suppliers and response tools. We want to see what an attacker could reach and what we'd lose by removing access.

Discovery records need to be reconciled so that each object retains a stable identity, an owner and a lifecycle state. An address change shouldn't create a second workstation, and an asset that stops reporting shouldn't simply vanish from the dependency map.

Use discovery methods appropriate to the environment. In OT, that can mean combining passive observations, configuration records and operator knowledge, with active methods validated for the equipment involved. Continuous understanding does not require indiscriminate continuous scanning.

Keep three views distinct: what telemetry shows happening, what configuration permits and what owners have approved as legitimate. Repeated activity isn't necessarily authorised, and a connection missing from recent traffic may still be possible.

Each object and relationship should carry its evidence source, verification time and any uncertainty. Distinguish an observed session from an inferred dependency. If sources disagree or become stale, the assessment should reflect that rather than silently treating the last known state as current.

Software bills of materials (SBOMs) can connect component-level threat information to products, but must be tied to the deployed release and configuration. A listed component alone doesn't establish exploitability. Similarly, data-access modelling needs effective permissions and relevant sessions, including service identities, rather than just a directory of users and groups.

Existing authoritative systems can supply this connected view. Preserve object identity, state and relationship meaning as they change. Rules and validated simulation capabilities are still needed to predict an intervention's effects.

What changed: the environment or our understanding?

Return to the remote-access report. Does the affected configuration exist here? Can it be reached under the reported conditions, and what privileges would compromise provide? The report gives us a reason to check; it hasn't changed the environment itself.

If those conditions are supported, the report may justify adding a newly understood transition to the attack model or changing the priority of an existing path. It doesn't prove that an attacker has used it. Evidence of an active session or suspicious behaviour is a separate input.

The model should therefore respond to more than threat feeds. A new identity permission, a temporary firewall exception or a change in a maintenance arrangement can alter a path without any new vulnerability being disclosed. Missing telemetry can reduce our confidence without changing the underlying path at all.

Show the change behind the assessment. Knowing that a supplier identity can now reach another workstation is more useful than seeing a higher score.

Reachability isn't probability. Rank paths using explicit criteria, but don't present a score as the numerical chance of compromise without a defensible probability model and supporting evidence.

A worked example: which access should we remove?

Let's make the supplier example more concrete. This remains a hypothetical design exercise, not a tested production case.

A supplier engineer authenticates through an enterprise identity service. A remote-access gateway permits a session to a jump host, which can reach an engineering workstation. That workstation has an authorised route to a controller used by the production line.

New threat intelligence prompts a review of the gateway. During the review, the team finds an unexpected active supplier session. Whether that session is malicious still needs investigation. The model helps the team examine its possible reach and prepare response options.

These are options to assess, not an action sequence. Terminating a session might be enough, or leave the attacker with another way in.

Run the legitimate maintenance task through the proposed change as well. Check that the engineer can still do the required work, that unintended restrictions can be recovered from and that alternative attacker routes have been considered.

Patching an entry point also doesn't establish that an existing compromise has been removed. The response must consider where the attacker may already have reached.

Containment has recovery consequences

Closing access may be quick. Getting the service back into approved operation can take longer. Business continuity and disaster recovery (BCDR) requirements need to be part of the containment decision.

Two familiar objectives help frame that discussion. The recovery time objective (RTO) sets the required restoration timeframe for the defined service or capability. The recovery point objective (RPO) identifies the point in time to which data must be recovered, commonly expressed as a tolerable period of data loss. NIST RTO definition; NIST RPO definition.

These are objectives, not proof that recovery can be achieved. In the supplier scenario, an isolated workstation might be quick to reconnect but take much longer to validate and return to approved operational use. An access restriction might also stop replication or make backups, keys or restore tooling inaccessible. The age and integrity of the last usable recovery point matter more than the scheduled backup frequency.

For each candidate intervention, assess the expected service interruption, restore sequence, available recovery data and the people and systems required. Compare those findings with agreed objectives and wider tolerances, including any safe degraded mode. Keep uncertain estimates visible and use tested recovery evidence where available.

Meeting RTO or RPO is not a safety approval. Nor should a threatened breach of an objective automatically prevent urgent containment when continued compromise could cause greater harm. The decision needs an accountable owner weighing both consequences. In OT, restoration also needs to account for physical process state and safe restart conditions; restoring digital records doesn't reverse a physical event.

How much can a twin prove?

Here are the distinctions I'd use when reviewing a solution. They describe the scope of the evidence, not a formal maturity standard.

Removing a line from a graph is a prediction about the model. Demonstrating that the corresponding action works against a representative configuration provides stronger evidence for that specific behaviour. Neither should be described as blanket proof that deployment is safe.

Give the operational owner the tested dependencies and the remaining unknowns alongside the recommendation.

A network model may help compare restrictions on the supplier connection. To assess the effect of workstation isolation on production, we also need evidence about its operational role. More elaborate simulation only helps if it captures that behaviour.

What does the AI agent do?

An agent could help interpret a threat report, identify potentially affected assets, gather missing context and propose scenarios to test. It could also compare simulation outputs and explain why a candidate action leaves a residual path.

If the agent says a firewall blocks traffic, I want to see the checked configuration or test result. Its account of an identity's permissions should trace back to the relevant policy and state.

Graph queries, policy evaluation and simulation engines should do the work they are designed for. An LLM's fluency doesn't substitute for those checks. Where the agent proposes an unverified relationship, it should remain a hypothesis until evidence supports it.

Threat reports and retrieved documents are also untrusted inputs. They should supply information for assessment, not instructions that expand the agent's permissions. Access to inspect the model and run an isolated scenario can be separated from authority to change a production system.

Check what actually happened

Before deployment, retain the model version, relevant source timestamps, assumptions, proposed change, expected outcome and operational approval. If an important dependency changes between simulation and deployment, the result may need to be reassessed.

After deployment, verify the actual state. Did the intended policy take effect? Did the session end? Does the legitimate service still work? Feed those observations back into the model and investigate differences between prediction and reality.

For urgent incidents, a full simulation may be too slow. Previously evaluated actions can be authorised within specific conditions, with a defined response when those conditions aren't met. Planned remediation allows more time for deeper testing. The workflow should support both without treating yesterday's assessment as permanently valid.

Judge the model by the decisions it improves: an overlooked route found, an ineffective intervention rejected or a disruption anticipated. The number of simulated paths alone won't tell us that.

The incident plan is behind the failed login

Now suppose the identity service becomes unavailable. The team tries to open its contact directory, incident plan and approval workflow. All three require the login that has just failed.

Those are dependencies in the response itself. They belong in the model too.

A tabletop exercise can test how people handle that situation. Ask the team to work through who authorises the intervention, how they contact that person and where they obtain the recovery instructions. Then check the proposed fallback through an appropriate practical exercise. Saying an offline copy exists is different from demonstrating that it is current, accessible and usable.

These exercises can involve technical responders, operational staff and executives. They complement technical simulation: the model informs the scenario, while the exercise reveals dependencies and assumptions to feed back into the model. NIST's exercise guidance addresses preparing personnel, exercising plans and testing systems as related activities. NIST exercise guidance.

If the team can't coordinate recovery, blocking the attack path hasn't answered the whole question.

Begin with a decision you can validate

A sensible first implementation could cover one service, its remote-access route and a small set of proposed interventions. Establish the relationships with the service owner, reproduce the relevant conditions in an isolated environment and compare the model's predictions with what actually happens.

Test missing and stale information deliberately. A useful system should show when it lacks the evidence to answer. Then test how it responds to a new permission or threat report, and whether it explains the resulting change in its assessment.

That gives security and operations a common basis for comparing changes: the exposure they address, their consequences and the work required. It also gives investment decisions something firmer to rest on.

In our supplier scenario, success is a justified decision about access, with the effects checked and a workable route to recovery. That's what I'd want the model to help deliver.

I've been exploring related investigation and response decisions through a simulated IT/OT scenario in my Playground. Explore the AI SOC demonstration and consider what additional evidence you would need before approving its response. The demonstration is an illustration of those decisions; it isn't validation of the digital twin approach described here. I'd welcome your feedback.

Explore the interactive attack-path simulation to compare hypothetical responses and their business consequences in a synthetic chemical factory. Its authored outcomes illustrate the decision; they do not establish production effectiveness or physical safety.