Why Micro-segmentation Alone Isn’t Enough
For years we’ve treated Zero Trust in operational technology (OT) as mostly a network segmentation problem. Build the zones, restrict the communications, limit lateral movement, push least privilege down to the network layer. That work matters, and I’m not here to argue against it.
But if you look at the industrial incidents that actually did damage over the last decade, the network architecture usually wasn’t the deciding factor. The identity that walked through it was.
The Colonial Pipeline attack came down to a remote access path and a credential, not clever lateral movement. The Oldsmar water treatment attack in Florida told the same story from a different angle: the question was never what the compromised system could talk to once inside, it was how someone got in and what they could do once connected. That’s a North-South problem, not an East-West one — and it’s the half of Zero Trust most OT programs are still skipping.
Plenty of organizations have put real effort into segmentation while leaving remote access more or less untouched. Flat VPNs, shared vendor accounts, persistent tunnels, third-party connections nobody’s watching, admin privileges handed out years ago and never revisited. The result is a hardened interior with the front door propped open.
You need both halves: East-West segmentation to contain movement once someone’s inside, and North-South identity-aware access to control who gets in and what they can reach. One without the other leaves a gap big enough to matter.
Where Segmentation by Itself Falls Short
Don’t read this as a knock on segmentation. Done well, it shrinks the attack surface, slows ransomware, isolates critical assets, and keeps a compromise in one zone from becoming a compromise everywhere. It’s worth doing.
The catch is that segmentation assumes the attacker is already inside. It answers a good question – what can this system talk to – but not the one that comes first: who should have access at all?
That gap is widest in oil and gas, where third-party and remote access aren’t edge cases, they’re how the business runs. Refineries, pipelines, terminals, and upstream sites all lean on vendor maintenance, integrator troubleshooting, contractor engineering work, remote operators, and third-party monitoring. Most of those paths grew up around getting work done, not around security, and the exceptions pile up over time: always-on tunnels, shared accounts, flat remote access, jump hosts nobody manages, sessions nobody can see, authentication that wouldn’t survive a second look. You can build a beautiful segmentation architecture and still lose if the identities crossing into it are overprivileged and ungoverned.
Zero Trust in OT Is a Two-Axis Problem
A more honest model treats OT Zero Trust as two problems, not one.
East-West is the segmentation half. It allows systems to talk to each other once access exists. Restrict the unnecessary paths, enforce least-privilege flows, keep trust zones from collapsing into one another, and hold down the blast radius when something does go wrong.
One piece of hard-won advice here: start with discovery and traffic analysis, not enforcement. OT environments rarely match their own diagrams, so policy built on assumptions is how you cause an outage. Baseline what’s actually talking before you try to control it.
North-South is the access half. It’s how people and external systems get in. Instead of dropping a vendor onto the network through a VPN and hoping for the best, identity-aware access pins everything to a person and a session. It should include:
- Per-user authentication
- MFA
- Role-based authorization
- Per-session scope
- Browser-isolated or application-specific access
- Full session logging
- Just-in-time connectivity that goes away when the work is done
The difference is easy to miss, but it’s the whole point. Traditional remote access mechanisms, like VPNs extend your network outward to the user. Identity-aware access brokers the user inward — one person, one session, one authorized destination at a time. Less exposure and far better accountability for the same piece of work.
Replacing the Legacy Remote Access Grab Bag
Pulling out legacy remote access is one of the bigger shifts in this whole effort, and one of the more contentious. The VPN gets most of the attention, and it earns it. Most VPNs were built to extend trust, not to limit it, so once you connect you typically see a lot more of the network than your job requires.
But the VPN is rarely the only door, and often not the worst one.
Walk into a brownfield OT environment and you’ll usually find a layer of remote access tools that nobody put on a diagram: TeamViewer, AnyDesk, and others, that a vendor installed during a commissioning call and never removed. And what do you find? RDP exposed straight to the internet or sitting one hop inside a flat network, dial-up or cellular modems on a few stubborn assets, and integrator-specific clients with their own baked-in accounts.
Oldsmar was a shared remote-desktop tool, not a VPN. Colonial Pipeline was a compromised VPN account, and the Unitronics attacks were internet-exposed devices with default credentials. The pattern across all of them is the same: an access path that authenticates weakly or not at all, attributes nothing to a specific person, and hands over far more reach than the task needed.
Identity-bound remote access flips all of that — and it doesn’t much care which tool it’s replacing. Users authenticate to specific applications or assets rather than to a network. Access is granted by identity and policy, sessions are temporary and auditable, connectivity can be held to a single protocol or workflow, and a vendor gets exactly the slice they need without a window into the rest of your OT estate. Just as important, it collapses that scattered grab-bag – the VPN, the ad-hoc TeamViewer install, the exposed RDP, the integrator’s pet client – into one brokered path you can actually see, manage, and govern.
You can’t secure access paths you don’t know exist, and the consolidation is what finally makes the unknown ones go away. That matters most in refining and pipeline operations, where downtime is measured in dollars per minute and remote support often can’t wait on a manual provisioning ticket. Whatever you put in place has to lower risk without becoming the thing that slows operations down. If it does, it won’t survive contact with the plant.
The Operational Reality
The architecture is the easy part. The operational reality is where these programs live or die.
Engineering teams are right to be cautious about enforcing segmentation in a live environment. An IT outage is an inconvenience; an OT outage can carry a dollar figure and a safety review. That’s why phasing matters. The programs that work tend to move in the same order — passive discovery, traffic baselining, policy simulation, gradual enforcement at the trust boundaries, then expansion inward, with remote access modernization running alongside the whole time. Each step earns the confidence to take the next one.
Remote access follows the same rule. Trying to rip out VPNs overnight gets you resistance from operations and vendors in equal measure. The mature move is to run the new secure access platform in parallel during the transition and retire the legacy paths gradually, as people get comfortable.
Where Integration Actually Gets Difficult
Here’s a part that doesn’t get talked about enough: the seam between the segmentation platform and the remote access platform.
On paper it’s clean. Identity authenticates the user, the access broker hands off the connection, the segmentation layer enforces the network policy. In practice, that hand-off is where things get messy. How does identity context actually shape segmentation policy? Who handles temporary exceptions, and how? How does a vendor session map to asset-level enforcement? How fast do policy changes propagate, and what happens when there’s an emergency and someone needs in right now?
The organizations that get this right treat it as a workflow problem, not two separate technology purchases. The architecture matters. The coordination between the two matters more.
Session Recording Isn’t Only a Security Feature
One underrated payoff of identity-aware access is centralized session visibility — and not only for the security team. Security wants it for investigations and forensics. But operations usually finds its own reasons to like it: what changed, who made the change, what commands ran, what sequence of events led up to a problem, whether a deviation was someone troubleshooting or something worse. That shared value is often what gets operations to actually adopt the thing, which is half the battle.
East-West and North-South Network Zones: Both Halves or Neither
The industry tends to frame Zero Trust in OT as a segmentation project because segmentation is visible, architectural, and easy to measure. But segmentation without identity governance leaves the entry wide open, and identity-aware access without segmentation still lets an attacker move once they’re in. The two aren’t competing approaches — they cover each other’s blind spots. Segmentation limits movement. Identity-aware access limits entry. Run both and you end up with something far more resilient than either one alone.
Zero Trust in OT was never going to be a single product or a one-time project. It’s visibility, segmentation, identity, and access control working together in a way that fits how plants actually run, not how the diagram on the wall says they do.
How Forescout Can Help
Our latest offer, Forescout Secure Remote Access, is a flexible, secure remote access approach designed to support different users, needs, and operational scenarios. Forescout SRA replaces broad remote connectivity with a controlled access layer that governs how users connect to critical systems, what they can reach, and what can happen during the session.
You cannot control remote access that you do not know exists. Forescout SRA helps uncover hidden and unmanaged connections, so shadow access no longer sits outside governance.
Remote access is not just a connection. Forescout SRA brings request, approval, duration, and audit into one governed workflow, so teams can enforce policy and support compliance end-to-end. Authentication is only the starting point. Forescout SRA combines identity-based access with controlled, isolated sessions to protect critical assets after access begins — and supports on-prem, cloud, and hybrid deployments with options for appliances, virtual machines, and containers on existing hardware.