IT Network Segmentation Is Not OT Security

“The plant network is segmented from IT, so OT security is handled.”

Right.

Let us take that apart before somebody puts it in a risk register and calls the project complete.

IT segmentation is not OT security.

A separate VLAN isn’t OT security.

A firewall between IT and OT isn’t OT security.

A route table with no path from the internet to a PLC is not OT security.

They are network reachability controls.

Useful ones.

Necessary ones.

In a plant, foundational.

But they answer a narrower question.

Which network paths are permitted?

They don’t answer whether a fieldbus protocol authenticates its commands.

They don’t tell an engineering workstation when it may alter a controller.

They don’t preserve the independence of a Safety Instrumented System.

They don’t make a patch safe to install during production.

They don’t decide what the physical process does after a control fails.

Those aren’t small omissions.

They are most of the problem.

People who would never say “we have a firewall, so controller configuration needs no authorization” somehow draw a box labelled OT VLAN and decide the plant now has a security programme.

Apparently the switch learned process safety overnight.

It didn’t.

1. “But the Purdue Zones Are Documented.”

Good.

Documentation beats a whiteboard diagram photographed after the meeting.

The Purdue Enterprise Reference Architecture gives your plant a useful hierarchy.

Level 0 is the physical process.

Sensors, actuators, valves, motors.

Level 1 is basic control.

PLCs, RTUs, DCS controllers executing real-time logic against that process.

Level 2 is supervisory control.

HMIs and SCADA software watching and adjusting Level 1.

Level 3 is manufacturing operations.

MES, batch management, historians.

Operating across shifts, hours and minutes rather than the milliseconds of Level 1.

Level 4 is business logistics, including ERP and scheduling. Level 5 is enterprise IT, email and internet access.

That is a map of industrial functions.

It is not a security standard, a protocol-security design, or an operational procedure.

The familiar Level 3.5 Industrial DMZ is worth getting right too.

It is not part of the original Purdue numbering.

It is a now-standard practice added between Levels 3 and 4.

Its point is termination and initiation.

An IT-side session ends in the IDMZ, then a separate session begins from the IDMZ toward OT.

No packet goes directly from corporate IT to a plant controller.

Stronger than an undifferentiated “IT can talk to OT through this firewall” rule.

But a correctly labelled 3.5 does not decide which controller may be programmed, which protocol is acceptable, or whether a safety function can tolerate the operational change.

Purdue tells everybody where the floors are.

It does not issue your keys.

2. “But the PLCs Have No Internet Route.”

Excellent.

Keep them that way.

But lack of an internet route is a statement about one path.

It is not a statement that the controller is unreachable.

Or correctly configured.

Or authenticated.

Or safe to maintain.

Or safe to change.

The documented 2017 TRITON incident is the unpleasantly specific example.

Attackers reached the plant’s IT network through conventional means, then moved toward OT using RDP jump boxes, poorly configured OT firewalls and stolen valid credentials.

The interesting boundary was not “internet versus PLC.”

It was the IT-to-OT boundary that was supposed to prevent compromised IT reaching a safety engineering workstation.

The target was a Schneider Electric Triconex Tricon Safety Instrumented System, engineered through a Windows workstation running TriStation.

The controller’s physical keyswitch had PROGRAM and RUN positions.

PROGRAM permits memory writes.

RUN is intended to prevent them during normal operation.

The workstation was reachable from compromised IT.

And the keyswitch had been left in PROGRAM.

There is your layered control failure.

Segmentation failed to contain the path.

An operational control left the controller writable.

The absence of a public route contributed precisely nothing to either fact.

No internet route is a reachability property. Controller configuration authority is a different control problem.

3. “But Patches Risk Production Downtime.”

They can.

This is the first objection that is actually an OT objection, rather than an IT one wearing a hard hat.

IEC 62443 has a part on patch management in an industrial automation and control environment.

It has others on security risk assessment for system design, on system security requirements and Security Levels, and on secure product development lifecycle and component requirements.

Patch management belongs in OT security.

It does not follow that you should install a change merely because the vulnerability scanner produced an alarming colour.

IEC 61511 governs Safety Instrumented Systems in your process industries.

Its governing principle is independence.

The SIS performs its safety function regardless of the state of the Basic Process Control System it protects.

A Safety Instrumented Function receives a SIL through structured hazard analysis against a tolerable-risk target.

Its hardware, testing and change management follow a separate safety lifecycle.

So a firmware update or monitoring agent that looks ordinary under IEC 62443 patch guidance can be an unauthorized change to a certified safety function under IEC 61511.

The same change can be defensible in one rulebook and unacceptable in the other, until it has been assessed and tested appropriately.

That does not mean never patch.

It means test the patch against process and safety requirements before treating its network-security benefit as the only consequence.

Availability in OT is not merely whether the server answers a health check.

It can be whether a process remains stable, and whether the safety function remains valid.

4. “But the Engineering Workstation Is Only Used During Maintenance.”

Which is why it is high risk.

A workstation that can change controller or safety logic is not made low consequence by being used infrequently.

It is a privileged maintenance path to systems that act on a physical process.

“Only during maintenance” is the moment a change is supposed to be possible.

It is not a control proving the change is authorized, or safe.

TRITON makes the distinction concrete.

Its safety-system target used the proprietary TriStation engineering protocol, and the documented controller used UDP port 1502 for it.

That is not evidence that every plant has the same protocol, controller or port.

It is evidence that industrial control paths are product-specific and operationally consequential.

A generic IT rule saying “allow this workstation to that VLAN” is not an asset-aware authorization model.

The practical design needs a defined conduit for the engineering path.

A managed jump host.

Time-bounded access.

An authorization record tied to the maintenance task.

It also needs your asset inventory to say which workstation reaches which controller, through which protocol, for which process function, with which safety dependency, under which change procedure.

An IP address and an owner field are not an OT inventory.

That is a phone book for equipment that can move valves.

5. “But a Firewall Blocks Unauthorized Traffic.”

It blocks traffic its rules do not permit.

Not the same thing as knowing what “authorized” means to a plant.

NIST SP 800-41 Rev.

1 states the baseline correctly.

Inbound and outbound traffic not expressly permitted by policy should be blocked.

Default-deny reduces attack risk, because the allowlist describes necessary traffic rather than trying to predict every future bad actor.

On sequentially evaluated firewalls, rules most likely to match belong at the top.

That ordering can decide which rule a packet actually meets.

All good network-security mechanics.

Use them.

But a firewall can faithfully permit an unsafe rule.

“Engineering subnet to controller VLAN” may be a wide, permanent path with no distinction among controller function, maintenance state, protocol or safety dependency.

Allowed.

And still an indefensible OT conduit.

IEC 62443 supplies the vocabulary IT segmentation usually lacks.

A zone groups assets sharing a common security requirement.

A conduit is the defined, controlled path between zones, with requirements of its own.

A Level 1 control zone, an IDMZ zone and an enterprise zone do not merely receive different address ranges.

They receive distinct requirements.

IEC 62443 assigns target Security Levels from SL 0, where no protection is required, through SL 4.

Protection against a sophisticated attacker with extended resources and IACS-specific skills.

SL 1 and SL 2 cover unintentional and simple-intentional violations.

The asset owner, product supplier, system integrator and service provider share responsibility.

None can make an SL target true alone.

So write the segmentation matrix.

Industry shorthand rather than NIST or PCI vocabulary, and useful: source zone, destination zone, allowed or denied path.

Then make each allowed path explain its purpose, direction, protocol, owner, maintenance conditions and safety impact.

A firewall cannot infer any of that from an IP header.

It barely gets enough fields to be offended by.

6. “But Safety Systems Will Stop Anything Dangerous.”

No. Safety systems perform defined safety functions.

They are not a universal malware amnesty programme.

IEC 61511 assigns a Safety Instrumented Function a Safety Integrity Level from SIL 1 to SIL 4.

For low-demand operation, each SIL step is an order of magnitude.

SIL 1 gives a 10-to-100-times risk reduction; SIL 4 gives 10,000 to 100,000.

Those figures measure failure when the defined safety function is demanded.

They are not a declaration that every cyber event is neutralized.

Or that every production interruption is harmless.

Or that every safety-system change is acceptable.

In TRITON, a defect in the malware caused a Tricon controller to enter its failed-safe state.

The plant shut down as designed, when the controller could not verify a safe condition.

Operations paused for more than a week, and an additional unexplained shutdown preceded the eventual discovery of malware on the safety system.

The safety system did what it was designed to do.

The plant still lost availability.

Which is the point people miss when they use “fails safe” as a synonym for “the security incident is no longer consequential.”

A safety trip can protect people and equipment while producing a major operational event.

Your security response has to preserve the former without casually causing the latter.

7. No, This Does Not Mean Segmentation Is Optional.

It isn’t.

Segmentation is foundational in OT.

The IT-to-OT boundary, the Level 3.5 IDMZ, zones, conduits, default-deny paths and a reviewed ruleset are not decorative controls.

In TRITON, the ability to reach the safety engineering workstation from compromised IT was a segmentation failure.

That fact alone should end any argument that segmentation is compliance scenery.

The correction is narrower and more useful.

Segmentation is one control layer.

It reduces reachability and constrains lateral movement.

It does not authenticate an unauthenticated industrial protocol.

It does not secure a permissive physical keyswitch.

It does not tell a controller whether a command belongs to an approved maintenance task.

It does not assess whether a security change invalidates a safety basis.

NIST also expects firewall changes to pass through formal change management, with policy documented in your system security plan and updated frequently.

In OT, that process needs your process and safety owners in the room.

A network-only review can tell everybody whether the new conduit is routable.

It cannot say whether the plant should use it.

Do not remove the fence because it is not also a safety instrument.

Install the fence.

Then stop calling it the whole factory.

8. What You Should Actually Do

Start with an inventory that is useful during a change and during an incident. For each PLC, RTU, DCS controller, HMI, SCADA service, historian, engineering workstation and safety component, record its Purdue level, IEC 62443 zone, process function, protocol and conduit, owner, permitted communications, maintenance path and safety dependency.

Record the controller’s physical operating mode where it controls writes.

An asset total will not help anybody decide whether an engineering path can change a SIL-rated function.

Build a zone-and-conduit model, not a flat OT subnet with special feelings.

Use an IDMZ between Level 3 and Level 4, with termination and initiation.

Set default-deny for traffic from IT, vendor access and inter-zone paths.

A permitted rule needs an explicit source, destination, direction, protocol, purpose, owner and review path.

Treat the segmentation matrix as a living change-control artifact, not a spreadsheet that survives by becoming impossible to read.

Control maintenance deliberately. Managed jump hosts.

Time-bounded access.

A task-specific authorization record for engineering workstations and vendor connections.

Keep safety-controller keys in RUN when a controller is not actively being reprogrammed, and secure the physical key elsewhere.

That is a specific lesson from the Tricon case, not a claim that every controller has the same switch.

Monitor with OT-safe telemetry, and make the control path visible. A stateful IT firewall tracks connections through a state table keyed on source and destination address, source and destination port, and connection state.

An application-proxy gateway creates two separate connections and can inspect a protected flow between them.

Useful capabilities.

Deploy and test them against the assets and functions they will observe.

Monitoring that disrupts a safety function has not improved the plant.

Test patches, configuration changes, response procedures and recovery steps against process behaviour and safety requirements before production use. IEC 62443’s security-management work and IEC 61511’s safety lifecycle have to meet at the change record.

The paperwork is not your control.

The tested consequence is.

9. The Actual Model Is Not Complicated.

Network security answers: which paths and flows may communicate?

OT security asks that too, then adds: which asset is this, what physical function does it serve, which protocol and maintenance path can alter it, what safety function depends on it, and what happens after your control changes?

Purdue names the levels.

IEC 62443 defines the zone and conduit security structure.

IEC 61511 governs safety functions and their independent lifecycle.

Default-deny constrains traffic.

A managed engineering path constrains change.

Safety-informed testing constrains the consequences of a well-intended security action.

Use all of them.

The durable point is simple.

Reducing reachability does not authenticate an unauthenticated industrial protocol, or model the physical consequences of using it.

A separate VLAN can be a good beginning.

It is not the ending.