The Attack Starts in IT. The Consequence Lands in OT.

The boundary exists on the drawing. The business runs across it.

The Purdue model is still the clearest way to describe an industrial estate: enterprise systems at the top, operations and supervisory layers beneath them, control and the physical process at the bottom, with a boundary between the business levels and the operational ones. It is a good model and it describes an architecture, not a traffic pattern.

What crosses that boundary in a working plant is a list of integrations that each made sense on its own. A historian replicates process data upward so that somebody can report on yield. Remote access exists because the vendor who supports a line is four time zones away and the alternative is a flight. Directory services were unified because running two sets of accounts produced more risk than it removed. Engineering laptops dock on both sides because that is what an engineer's job requires.

None of this is negligence and almost none of it is reversible. The convergence that security literature discusses as a trend arrived years ago as a series of individually sensible decisions, and the security model on either side of the line has not caught up with the sum of them.

The path, hop by permitted hop

The route from an enterprise compromise to an industrial consequence rarely involves an exploit against an industrial device. It involves a sequence of hops along paths that were built deliberately, using credentials that are entitled to use them.

It starts where every other intrusion starts, with an account on the business side. From there the directory answers the questions that matter: who supports which site, which groups exist, what the naming conventions reveal about the estate. That reconnaissance is performed by reading things any employee can read.

The hop that matters is the one into a remote access gateway or a jump host, and then onto an engineering workstation. That workstation is the prize, and not because it is poorly defended. It is the prize because of what it legitimately holds: the project files, the vendor software, and an established, expected pattern of speaking to controllers. MITRE ATT&CK for ICS names the shape plainly. Valid Accounts, T0859. Remote Services, T0886. Neither is an exploit. Both are the system working.

The middle is where the incident disappears

Run that path past two separate monitoring operations and something specific happens. The enterprise operation sees the first half: a compromised account, a directory read, a session to a gateway. It has no way to judge whether that matters, because the thing on the other end of the session is out of its scope and frequently out of its tooling.

The industrial monitoring sees the second half: an engineering workstation performing reads against controllers. It has no way to judge whether that matters either, because an engineering workstation performing reads against controllers is what an engineering workstation does, and nothing in its view explains who is driving it.

The crossing hop is the only part both can see, and it is the part that looks most ordinary from either direction. The incident is not invisible. It is split in two, and neither half raises an eyebrow on its own.

Why merging the two teams is the wrong fix

The obvious response is organisational: put the plant under the security operations centre and be done with it. It is attempted often and it goes badly often, for reasons that are not about culture.

The two functions optimise for different things, and both are correct to. An enterprise security team is trained to act decisively because the cost of being wrong is an inconvenienced user. An operations team is trained to be conservative because the cost of being wrong is physical, and it works under management of change for the same reason. Those are not attitudes to be reconciled. They are the right postures for two different risk profiles.

What has to be joined is not the reporting line. It is the evidence. Two teams can keep separate authority, separate change control and separate out-of-hours rotas and still be looking at one timeline, and it is the absence of that timeline, rather than the presence of two org charts, that lets the middle of an incident vanish.

• Different objectives: integrity and confidentiality first on one side, safety and availability first on the other.
• Different authority: one side may contain within policy, the other requires an engineering judgement.
• Different clocks: an enterprise change ships this afternoon, a plant change waits for a window.
• Same adversary, same account, same session, and currently two unrelated tickets.

One timeline across two estates

The practical requirement is narrower than a platform strategy. It is that an investigation of the compromised account can follow that account across the boundary and keep going, and that an observation on an industrial asset can be asked where it came from and receive an answer.

That means identity and endpoint evidence on the business side correlated with protocol-level observation on the operational side, joined by asset and by account rather than presented side by side in two panes. A shared dashboard is not this. Two tools rendering into one screen still produce two investigations, and the analyst performing the join in their head is the bottleneck the whole exercise was meant to remove.

It also has to run fast enough to matter. The reconnaissance phase in industrial intrusions is long, which is the defender's advantage, but the enterprise half moves at the usual speed: average breakout time for a criminal intrusion is 29 minutes. An investigation that spans both estates and takes an afternoon has already conceded the half that was quick.

Same timeline, different response rules

Joining the evidence does not mean joining the response, and this is where a converged approach either earns trust on the plant floor or loses it permanently.

On the enterprise side of the boundary, containment can be autonomous within a policy: revoke the sessions, disable the account, isolate the host. On the operational side it is graded and authorised, because the actions have physical consequences and because an industrial estate runs under change control. One platform, two policies, and the second policy written by the people who own the process.

Practically this means Spharaka Sphere handling detection, investigation and response across the enterprise estate, Spharaka Signal observing the industrial one passively and producing findings with asset and control loop context, and a single investigation that reads across both. The evidence is shared. The authority is not, and it should not be.

• Autonomous containment on the business side, within a policy the security team owns.
• Graded, authorised containment on the plant side, with the rung chosen by people who know the process.
• One investigation producing the evidence both decisions are made from.
• One record afterwards, because the post-incident review will cover both halves.

The boundary controls that actually earn their place

Most of what gets deployed at the IT and OT boundary is a firewall with a rule set nobody has reviewed since commissioning. The controls that change outcomes are less glamorous and more specific.

The first is an honest inventory of what crosses, maintained as a list of conduits with written definitions rather than as a diagram. The second is brokered remote access: no direct path from the business network to an engineering workstation, sessions established through a broker, recorded, and tied to a named person rather than to a shared vendor account. The third is separate credentials on each side, which is unpopular and is the single control that most reliably stops the hop described above.

The fourth is treating engineering workstations as the crown jewels they are, with the monitoring and the access restrictions that implies. They are the hinge the whole path turns on, and they are frequently the least governed machine in either estate.

• A conduit inventory with written definitions, reviewed on a schedule.
• Brokered, recorded remote access tied to named individuals, not shared vendor accounts.
• Separate credentials either side of the boundary, with no reuse and no shared directory group.
• Engineering workstations monitored and restricted as the high-value assets they are.
• Historian replication one way, out of the plant rather than into it.

Questions worth asking at the next joint review

The fastest way to find out whether an organisation has this problem is not an assessment. It is five questions asked with both teams in the room, because the useful information is usually in how long the answers take.

The industrial threat review published in February 2026 reported ransomware attacks on industrial organisations rising 49 percent in 2025, affecting around 3,300 organisations, with 119 groups tracked that have demonstrated capability to affect operational environments. Most of those incidents did not begin with an industrial exploit. They began on the business side and crossed, which makes these questions less theoretical than they sound.

• If an enterprise account were compromised today, who would notice that it had reached a jump host, and how?
• Which specific paths exist between the business network and the engineering workstations, and who maintains that list?
• When industrial monitoring raises a finding, can anybody say which account and which session caused it?
• Who authorises cutting a vendor's remote access at three in the morning, and who covers them?
• After an incident, would there be one timeline or two, and who would reconcile them?

The honest version

The convergence argument is often made as though the problem were that the two estates are connected. The connections are not the problem and will not be removed, because the business that pays for both is run across them.

The problem is that the connections are operated by one group, defended by another, and observed by two systems that cannot hold a single thought between them. An adversary crossing that line is not evading a control. They are walking through the seam between two correct worldviews, and the seam is wide because nobody owns it.

Closing it does not require merging the teams, rewriting the architecture or unplugging the historian. It requires that the account, the session and the asset appear in one investigation, fast enough to matter, with the response rules on each side left exactly as strict and as different as they already are.