By Yogesh Deshpande, Technical Director, Paladin Security
Operational Technology Security · ICS Attack Paths · Segmentation Validation

The first compromised machine is an ordinary office workstation. It cannot communicate with a PLC, it has no engineering software installed and the user knows little about the plant.

On the network diagram, this is an IT incident.

The attacker sees something different. The workstation provides a domain identity, access to internal documentation and a place from which to discover how people administer the environment. A maintenance procedure names the OT jump host. A support ticket identifies the remote-access group used by a vendor. A file share contains an old network diagram. None of those items controls the process, but together they describe the route towards systems that do.

The path into operational technology rarely begins with an exotic PLC exploit. It is more often assembled from ordinary weaknesses: reusable credentials, excessive administration rights, broad firewall rules, unmanaged remote access and a jump host that connects security zones without enforcing a meaningful change in trust.

The boundary exists in more than the firewall

An organisation may have separate IT and OT VLANs, an industrial firewall and a jump host between them. That is useful architecture, but it does not prove separation.

The effective boundary also includes identity, endpoint administration, name resolution, patching, backups, monitoring, file transfer and vendor support. If the same privileged account can administer systems on both sides, compromise of that account crosses the boundary without defeating the firewall. If an IT management platform can deploy software to an OT server, that management path is also an IT-to-OT connection. If the jump host accepts a broad corporate group and permits unrestricted onward access, the boundary is little more than an extra login screen.

This is why an OT assessment must compare the documented architecture with effective access. Packets, credentials and administrative tools reveal connections that diagrams often omit.

A plausible route from IT to operations

The details vary by site, but a common chain is:

Office workstation → enterprise identity → OT access path → jump host → engineering workstation → control network

The chain does not imply that every compromised office PC can reach a PLC. Each arrow represents a control that must fail, be misconfigured or grant more trust than intended. The purpose of testing is to determine whether those breaks exist before an attacker does.

The office foothold provides identity and context

Initial access may come from phishing, an exposed remote service, stolen credentials or exploitation of an internet-facing system. From an internal workstation, familiar Windows weaknesses can assist credential access and lateral movement: excessive local administrator rights, reusable service-account passwords, weak SMB signing coverage, or name-resolution behaviours such as LLMNR and NetBIOS Name Service where they remain enabled.

These conditions do not create OT impact on their own. Their significance depends on whether the resulting identity or host can reach a system that is trusted by OT.

An attacker will look for that trust in group memberships, remote desktop access, password vault entries, support documentation, scripts, scheduled tasks and management platforms. The fastest route is often the one engineers and vendors already use.

Shared administration collapses the intended separation

Using Active Directory in an OT environment is not inherently insecure. The risk depends on its design and dependencies. A dedicated OT forest with constrained trust and separate administration presents a different exposure from OT systems joined directly to the corporate domain and administered by the same accounts used in IT.

Credential reuse is especially dangerous. A domain administrator signing into a lower-trust workstation can leave credentials or reusable authentication material within reach of an attacker. A local administrator password shared across engineering workstations can turn compromise of one machine into compromise of several. A service account used in both environments can provide a quiet bridge even when interactive logon is restricted.

The boundary must therefore prevent privilege from flowing in either direction. Separate administrative identities, controlled privilege tiers, unique local credentials and restrictions on where privileged accounts may log on are as important as the rules on the industrial firewall.

The jump host should terminate trust

A well-designed jump host is a controlled checkpoint. Access is strongly authenticated, individually attributable, approved where appropriate, recorded and restricted to defined destinations and protocols. File transfer follows a controlled process. Internet access, email, general browsing, clipboard redirection and drive mapping are absent unless a documented operational need justifies them.

The weak version is simply a Windows server with two useful routes. It is administered like an ordinary IT asset, accepts a large access group and holds saved credentials, vendor tools, VPN clients, scripts and network documentation. Once compromised, it gives the attacker the same reach intended for operators and maintainers.

A jump host must reduce trust, not relay it. Connections should terminate there, with separate credentials used for the next zone. Otherwise, compromise on the IT side can carry an authenticated session straight through the control intended to stop it.

The engineering workstation changes the risk

The engineering workstation is often the point at which an attacker gains both reach and process context. It may contain vendor programming software, controller project files, device configurations, logic backups and the communications needed to manage controllers.

Compromise of this machine is serious, but it should not be described as automatic control of the plant. The outcome depends on controller mode, protocol and product security features, network access, safety interlocks, change procedures and the attacker’s understanding of the process. Incorrect changes may simply fail, trigger alarms or stop equipment. Deliberate manipulation without understanding can be dangerous to the attacker as well as the operator.

Even so, an engineering workstation can enable theft or corruption of project files, unauthorised configuration changes, loss of a trusted recovery source and use of legitimate vendor functions against field devices. It should be managed as a high-consequence asset, not as a general-purpose desktop.

Legacy does not have to mean exposed

Many industrial assets remain in service for decades. Some protocols and devices provide limited authentication, encryption, integrity protection or user-level accountability. Older Windows systems, web interfaces, VNC, FTP, Telnet and community-string-based SNMP may also exist because replacing or modifying them carries operational risk.

The defensible response is not to pretend every asset can be patched or replaced immediately. It is to constrain who can communicate with it, from where, using which protocol, and to monitor that communication.

An unauthenticated industrial protocol inside a tightly controlled cell is one risk. The same protocol reachable from a broadly accessible jump host is another. Where native security functions exist, they should be evaluated and enabled without compromising safety or availability. Where they do not, zoning, allow-listed communications, hardened intermediaries and passive monitoring become critical compensating controls.

An intruder may learn before acting

Immediate disruption is not the only credible outcome. An attacker who reaches OT support systems may spend time examining historian trends, alarm configurations, maintenance records, controller projects and recovery procedures. This can reveal which assets are operationally important, how the plant responds to abnormal conditions and which systems would delay recovery if encrypted or corrupted.

That knowledge can support extortion or ransomware even if the attacker never modifies PLC logic. Loss of operator visibility, engineering workstations, historians or supporting identity services may be enough to cause a precautionary shutdown. The operational consequence depends on the process and the organisation’s ability to operate and recover safely and not solely on direct controller access.

How the path accumulates

Most plants did not acquire this exposure through one reckless design decision. Connectivity accumulated around operational needs.

A vendor required remote support. A historian needed data in the corporate network. An engineering workstation was domain-joined to simplify administration. A temporary firewall rule remained after commissioning. A shared account made recovery faster during an outage. Each decision solved an immediate problem; together they formed a durable route across trust zones.

That route is why point-in-time vulnerability scanning is insufficient. Scanning may identify an old service on an OT server, but it will not necessarily show that an IT helpdesk account can administer the jump host, that the jump host can reach every engineering station, or that the same password is used on both sides of the boundary.

Test whether the chain breaks

A useful OT security assessment asks practical questions under agreed safety constraints:

– Can a compromised IT identity authenticate to any OT-facing system?
– Which services and management platforms cross the IT/OT boundary?
– Does the jump host restrict destinations, protocols, file transfer and credential flow?
– Are IT and OT administrative identities separated in practice?
– Can vendor access occur without approval, strong authentication or useful session records?
– Which hosts can reach engineering workstations and controller networks?
– Are controller and engineering changes attributable and recoverable?
– Can defenders see representative reconnaissance and lateral movement at the boundary?
– Can essential OT functions continue or recover if corporate identity and management services are unavailable?

Testing in OT must be proportionate to operational risk. Active techniques that are routine in an office network may be unsafe against fragile devices or live processes. Architecture review, configuration evidence, passive traffic analysis and controlled validation on agreed systems may provide better assurance than aggressive scanning. Any test that could affect availability or process safety requires explicit planning, ownership and stop conditions.

Break the route before it reaches the process

The strongest controls are those that interrupt several attack paths at once: a properly governed IT/OT boundary; separate privileged identities; hardened and monitored jump infrastructure; tightly controlled vendor access; allow-listed communications between zones; protected engineering workstations; and tested recovery from known-good controller projects and configurations.

Segmentation should be demonstrated, not assumed. For each permitted connection, the organisation should know the business owner, source, destination, protocol, direction and monitoring expectation. Rules and remote-access accounts should be reviewed against current operational need rather than retained because removing them feels risky.

The path from an office PC to a PLC is rarely a single leap. It is a sequence of trusted actions that were never meant to be available to the same compromised identity.

OT security succeeds when that sequence is broken early, observed clearly and recoverable safely before an ordinary IT incident becomes an operational event.