Secure Remote Access for OT: From Guidance to Architecture

The Door Nobody Designed

Three patterns account for most of the remote access in OT environments today. None of them comes from negligence. Each is what happens when an operational need shows up before a governed way to meet it does.

The first, and most common, is a VPN per vendor. On paper it looks tidy: every vendor gets its own tunnel, its own credentials, and its own documented arrangement. The trouble is at the far end of the tunnel. A VPN usually drops the connecting device onto a network segment which often means the vendor’s laptop. Here’s a machine the operator doesn’t manage, patch, or monitor sitting next to everything else on that segment. The access was scoped to a vendor. The reachability was scoped to a network. The joint principles call this out directly when they ask operators to prevent lateral movement from vendor access.

The second is the jump host that grew up. A workstation set aside for one commissioning project picks up more tools, more accounts, and more jobs until it has effectively become the front door to a zone. It rarely gets patched because patching interrupts whoever happens to be using it — and it’s often running an operating system that fell out of support years ago. The guidance is pointed here: obsolete products should be treated as untrusted and never relied on as security controls. A jump host in that condition is the control and the weakest asset behind it simultaneously.

The third is the one CISA documented in the water sector, and it’s the starkest. A programmable logic controller (PLC) gets wired directly to a cellular modem, so that a utility with no permanent on-site staff can check on it. No broker, no intermediary, no segment. The controller is simply on the internet. In cases described by CISA, threat actors changed controller passwords to lock operators out and changed IP addresses to disconnect equipment.

Underneath all three is an inventory problem. You can’t govern what you’ve never counted, and remote access is unusually hard to count because so much of it never shows up in a system of record. Dormant tunnels. Vendor-supplied gateways. Remote desktop tools installed for a project that was never uninstalled. Wireless and cellular links that bypass the wired diagram entirely … All of it is real, and you won’t find any of it by reading documentation.

The most important thing about these patterns is why they stick around. When there’s no governed path, people build ungoverned ones because the turbine still needs servicing and the integrator still has a contract to deliver on. Any program that starts by ripping out access without first offering something better will get worked around, and the operator will end up with less visibility than before.

Exposure Is the New Perimeter

CISA’s Internet Exposure Reduction Guidance is clear about the order of operations. Find every internet-reachable asset. Remove the access you don’t need. Route what’s left through a gateway or centrally managed solution, not directly to a PLC, HMI, or RTU. It’s just as careful to say that reducing exposure doesn’t mean shutting off remote access that operations depend on. Removing the access you don’t need is what makes the guidance usable. It’s the difference between advice an operations team will adopt and advice it will fight.

What this really asks for is a shift from ‘Does a weakness exist?’ to ‘Can anyone reach it?’. A vulnerable controller deep inside a well-segmented plant is a maintenance ticket. The same controller with a public IP address is an incident waiting for somebody to run a search. Reachability, not severity, should set the urgency. A remediation queue sorted by exposure looks very different from one sorted by severity score.

And the scale of the reachability problem isn’t guesswork.

Forescout’s Vedere Labs found nearly 60,000 internet-exposed VNC servers with authentication disabled. More than 670 of which were connected to OT and ICS control panels. These exposures do not require a zero-day exploit. They are access paths left open after serving a legitimate operational need.

Exposure also isn’t limited to the connections an operator expects. Wireless links, cellular backhaul, vendor-supplied gateways, contractor equipment, and entire environments inherited through acquisitions all create edges no diagram records. That’s why discovery has to be empirical rather than documentary. What matters isn’t what the architecture says is connected. It’s about the complete context: what is actually talking to what system on the other end over which protocol.

The practical response has three parts, and the guidance spells out all of them: know what’s reachable, remove what isn’t needed, and broker what remains. The first is a visibility problem, the second is a decision problem, the third is an architecture problem. Most operators can work all three in parallel. And, the first one produces the evidence that justifies the other two.

What Good Looks Like

The Secure Connectivity Principles for Operational Technology were published by the UK’s National Cyber Security Centre along with CISA, the FBI and five other national agencies. The eight principles cover the whole life of a connection: deciding whether it should exist at all, limiting what it exposes, standardizing how it is built, securing the protocols it carries, hardening the boundary it crosses, containing what it can reach, monitoring what it does, and being able to sever it on demand.

What separates them from a control catalog is that they’re framed as desirable end states rather than minimum requirements. That’s easy to skim past, and it changes the evaluation completely.

The question isn’t whether a product checks a box. It’s whether it moves the architecture toward the end state and makes it easier to stay there.

This matters because compliance decays. A product can meet a requirement on assessment day and drift away from it over the next two years as exceptions accumulate, integrations change, and the person who configured it changes jobs. End-state thinking asks the harder question: does the design make the right behavior the default or does it need constant discipline to stay right? An architecture where unscoped, open-ended access is hard to create is worth more than one where it is merely against policy.

The table below summarizes what each principle asks for in practice. The next two sections map thirty-eight items identified in this paper across those principles to specific capabilities. Coverage is rated direct where the capability meets the requirement, rated supporting where it supplies the evidence, visibility or enforcement behind it. And, rated partner where another control or process is needed — and Forescout integrates with or informs it.

Table 1  ·  The Eight Principles at a Glance

One Path In

Principles 1 through 4 focus on whether a connection should exist, how much it exposes, how it’s built, and what it carries. Put together, they describe consolidation: swapping a pile of bespoke arrangements for one hardened path that everybody uses.

The case for consolidation isn’t mainly about cost. It’s about how many places there are to make a mistake. Twelve vendor VPNs means 12configurations to harden, 12 sets of credentials to rotate, 12 renewal cycles to track, and 12 chances for a temporary exception to become permanent. One brokered path means one configuration, one place to instrument, and one thing to change when the threat picture shifts. Principle 3 asks specifically for exactly that unification with a caveat that connections should be categorized by type, so human-to-machine and machine-to-machine flows are governed on purpose instead of lumped together.

Brokering flips the problem around. Instead of stretching the operator’s network out to reach the vendor, you bring the vendor in to an intermediary that sits in a security-controlled segment between enterprise IT and OT. The external session ends there. Nothing on the OT side is exposed to the outside, no inbound port into OT is needed, and the user’s own device never touches the asset. It’s also how a modern, maintained boundary component replaces that aging jump host from earlier compressesing two requirements into one.

Time is the second control eliminating the single biggest category of standing exposure. Access granted for an approved window that expires on its own behaves very differently from access granted indefinitely and reviewed once a year (if you’re lucky). Most of the credentials and tunnels attackers find useful stay valid long after the work they were created for is done. Just-in-time access makes that condition impossible.

Scope is the third. A session opened to a named asset over a named protocol is a fundamentally different risk from a session dropped onto a network segment. That’s the flat-VPN problem the guidance describes, and it’s why lateral movement from vendor access gets its own requirement instead of a footnote under authentication.

Principle 4 covers protocols.  This is where candor is in order. Migrating from DNP3 to DNP3-SAv5, or from OPC DA to OPC UA, is an engineering program you run with your automation vendors over a period of years. That migration depends on equipment lifecycles and vendor support. No access platform can complete it on its own. What software can do is provide the inventory that program depends on: which assets speak which protocols today, where insecure traffic crosses a trust boundary, and whether industrial protocols are staying inside the OT segments where they belong. Schema-based validation at those boundaries is enforcement work for protocol gateways and application-layer firewalls, so the mapping below records it as a partner control rather than claiming it.

Table 2  ·  Principles 1 to 4

Hardening the Boundary

Principles 5 through 8 move from designing the path to governing what happens to it. They cover identity and least privilege at the boundary, containing what a session can reach, monitoring built around how attackers actually behave, and the ability to isolate quickly and deliberately.

Identity comes first, and the guidance names phishing-resistant multi-factor authentication explicitly. The practical benefit of enforcing it at a broker rather than at each endpoint is consistency. Every vendor authenticates the same way no matter what their own organization does internally, and the operator no longer depends on a third party’s security posture to protect its own boundary. Principle 5 makes the same point from the contract side when it asks operators to enforce security requirements on third parties. A single governed path enforces them by design instead of by clause.

Attribution follows from identity. The guidance asks for a user-attributable audit trail, which sounds like a logging requirement, but it is really an architectural one. Shared vendor accounts, still common in OT, make attribution impossible no matter how much you log. Credential vaulting fixes this: the person authenticating is named, and the credential used on the asset is never known to them. It also takes care of the joiners, movers, and leavers problem, because a departing contractor can’t walk out with a password they never had.

Containment is the theme of Principle 6. Browse-down administration, separation of duties, and micro-segmentation all come back to one idea: compromising one thing shouldn’t mean compromising everything. Browser-based, zero-footprint sessions keep the vendor’s laptop off the OT network entirely. It is better to remove a whole class of contamination risk instead of just mitigating it. Segmentation designed from observed communication rather than an idealized diagram is what keeps the remaining blast radius small.

Principle 7 asks that monitoring be designed around attacker behavior rather than compliance reporting. This distinction has teeth. The most valuable capability isn’t log volume. It’s correlation: tying every session to an approved request, so the SOC is checking activity against a stated expectation instead of judging it in a vacuum. A vendor connecting at an odd hour is ambiguous. A vendor connecting at an odd hour with no approved request behind it is not. So, when break-glass access needs to be used, it should set off the loudest alarm in your organization.

Principle 8 asks for tested isolation plans at three scopes: a single third party, a service, and a full site. It’s the principle everyone nods at and almost nobody exercises. Being able to revoke one vendor’s access while everything else keeps running is a capability. An isolation plan that’s never been rehearsed is a document. You only find out which one you have on the day it matters.

Table 3  ·  Principles 5 to 8

Across the 38 requirements in both tables, Forescout directly addresses 21, supports 13, and informs four that belong to partner controls or to process.

The four gaps are intentional, and naming them is part of the point. Hardware-enforced, unidirectional flows are, well, hardware. Schema-based validation at trust boundaries belongs to protocol gateways and application-layer firewalls. External attack surface management of public IP space is a different discipline with different tools. And tested isolation plans tied to business continuity and supplier contracts are governance work that no platform can do on an operator’s behalf. Any vendor claiming all 38 is describing a product that doesn’t exist.

Limiting the Blast Radius

Brokering the way in solves the entry problem. By itself, it doesn’t solve the reach problem. An attacker who gets hold of a legitimate session or who enters through a path nobody brokered still benefits from every flat adjacency inside the environment. That’s why the guidance treats segmentation and isolation as peers of access control, not afterthoughts.

Most OT environments are flatter than their owners think. Zones were drawn during design and then worn down by a decade of practical exceptions: a historian that needed to reach two more subnets, a vendor appliance that only worked with broad permissions, or a temporary rule from a commissioning project that outlived the project. The architecture on the wall and the traffic on the wire drifted apart slowly enough that nobody noticed.

The fix is to design from observed behavior, not intent. A communication matrix built from passive monitoring shows what actually talks to what, which is a more honest starting point and a much easier one to defend in a change review. Testing the resulting policy in monitor mode before enforcing it is what makes segmentation achievable in places where a bad rule has physical consequences.

Continuous flow monitoring keeps it right afterward. Segmentation isn’t a project with an end date. It’s a posture, and postures drift. New assets appear, firewall rules get added under pressure, and a zone that was clean in March is porous by September. Monitoring the flows between segments turns that drift into an alert instead of something you discover in the middle of an incident.

Isolation is the sharp end of the same capability. The guidance asks operators to be able to cut off a single third party, a service, or an entire site, and to have tested each one. This is where a brokered architecture pays off: the first of those becomes a policy action instead of an engineering exercise. One vendor’s access is revoked and every other session carries on undisturbed. The second and third depend on containment orchestrated across existing enforcement points, and on the operator having decided ahead of time who’s allowed to pull the trigger.

Reference Architecture Implications

The pattern the guidance describes puts the access broker in a security-controlled DMZ between enterprise IT and OT, with every external session terminating there and nothing on the OT side exposed to the outside.

Vendors authenticate through the enterprise identity provider and can reach only the SRA broker. The broker checks approval, time window and scope, injects vaulted credentials, and opens a session to the specific assets that were approved. Vistaro watches the OT zones passively, maps normal communication, enforces segmentation through existing network infrastructure, and sends session and flow telemetry to the SOC alongside SRA’s session records.

Forescout SRA can be deployed on premises, in the cloud, or hybrid. Multi-site operators usually put a broker in each region or at each critical site, all managed centrally. That covers Principle 3’s call for a repeatable pattern and Principle 8’s need to isolate one site without affecting the rest.

At the discovery layer, identification can’t depend on whether the asset cooperates or not. A lot of an OT estate can’t host an agent, can’t tolerate active scanning, and won’t answer a credentialed query. In these environments, passive methods and careful sensor placement aren’t a compromise. They’re the only responsible option, and they’re what make an inventory of protocols, firmware, and end-of-life status possible without putting the process at risk.

At the decision layer, identity, device posture, asset criticality, and observed behavior come together into policy a security leader can actually read and govern. This is where exposure management stops being analysis and starts being operational. The question isn’t just whether an asset has a weakness, but whether it’s reachable from outside, whether compensating controls are already in place, and whether access should be narrowed while remediation catches up.

At the enforcement layer, decisions have to become conditions in the network. That means the broker for admission and session control, segmentation and micro-segmentation for containment, and orchestration across the switches, wireless infrastructure and firewalls the operator already owns. Ripping out that infrastructure is neither necessary nor realistic. What’s required is driving it from a single policy view.

At the governance layer, the architecture needs approval records, exception handling, pre-authorized containment actions, and metrics that show whether control is actually improving. Architecture without governance drifts into brittle configuration. Governance without architecture remains difficult to enforce. The value comes from connecting the two, so an operator can show that a policy was applied and the exposure went down — not only that a risk was identified.

Several layers of this design are intentionally not software, and an honest reading of the guidance means saying so. Data diodes and cross-domain solutions provide hardware-enforced one-way flows for high-threat environments like replicating an OT historian into the DMZ or shipping logs out of an isolated network. Passive monitoring complements them by confirming that flows designed to be one-way actually stay that way. Next-generation firewalls and protocol gateways handle the deep packet inspection and schema validation that Principles 4 and 6 expect at the boundary. Secure protocol migration is an engineering program run with automation vendors. External attack surface management of public IP ranges is its own discipline. In each case, the platform contributes context and evidence, not the control itself.

From Guidance to Evidence

For electric sector entities, several controls described in the joint principles overlap with NERC CIP obligations. The table below maps the requirements most affected by remote access to the relevant principle and capability. Compliance remains the registered entity’s responsibility. The capabilities below provide the technical controls and the evidence.

Read the crosswalk one way and it shows how much overlap already exists. Identity, attribution, session control, logging and the ability to disable vendor access aren’t new expectations for anyone operating under CIP-004, CIP-005, and CIP-007. Nobody’s being asked to adopt an unfamiliar model. They’re being asked to do what they already document through an architecture that produces the documentation as a byproduct instead of a quarterly fire drill.

Read it the other way and it’s a useful check on ambition. A brokered architecture that supports CIP-005 R2.1 through R2.5 also advances parts of Principles 2, 3, 5, 7, and 8. Regulatory work and exposure reduction can reinforce each other.

Table 4  ·  NERC CIP Crosswalk

The strongest fit is CIP-005 R2 and R3. Plenty of entities meet R2.4 and R2.5 today with manual processes, such as checking VPN concentrator logs or picking up the phone and calling the vendor. A brokered model turns both into one view and one action — which also happens to be what an auditor wants to see.

That matters more than it looks. When an auditor asks whether you can determine active vendor remote access sessions, what they’re really asking is whether you can answer quickly, repeatably, and with evidence. A process that depends on one particular person checking three consoles might pass on a good day and fail on a bad one. A process that comes down to one view doesn’t have good days and bad days.

CIP-003 Attachment 1, Section 6 deserves a closer look because it extends vendor electronic remote access controls to low impact assets — which is exactly where the improvised arrangements described earlier tend to pile up. A governed path that works the same way at a small unstaffed site as it does at a control center is worth a lot more than one that needs a different answer for every tier.

The Leadership Mandate

Remote access decisions usually get made two or three levels below the people who’ll answer for the consequences. An engineering manager approves a vendor request because a turbine needs servicing. A site lead installs a modem because the alternative is a four-hour drive. Neither decision is unreasonable, and neither is visible to the executive who’ll be asked – after an incident – why there was an internet-reachable path into a control system in the first place.

The joint principles take this on directly by asking for a documented business case and a named senior risk owner for every connection. It reads like bureaucracy. It works like a forcing function. A connection nobody can justify in writing to someone accountable is usually one that accumulated rather than one that was chosen, and the act of trying to write that justification is often how the unnecessary ones get found.

Leadership starts with operational truth. Most operators hold pieces of the picture scattered across network diagrams, firewall rules, vendor contracts, purchase orders, and the memory of a few long-serving engineers. Very few have it in a form they could use during an incident. The first executive move is to insist on a living inventory of assets, access paths, and third-party dependencies, not an administrative one that looks orderly right up until somebody tests it.

Leadership also means being honest about a tradeoff. Reducing exposure has an operational cost. A vendor who used to connect whenever they felt like it now has to request access. A maintenance window has to be scheduled instead of improvised. Some of that friction is the whole point, and some of it is waste that good design removes. Leaders who pretend there’s no cost lose the trust of the operations teams they rely on. Leaders who treat every objection as a veto never reduce exposure at all.

Operational ambition and security architecture have to stay in step. Operators are chasing remote monitoring, predictive maintenance, fleet-wide analytics, outsourced operations, and fast partner integration all at once. Every one of those creates value, and every one creates a trust relationship, a data flow, and a pathway that didn’t exist before. Operational expansion shouldn’t permanently outrun governance, because growth you can’t govern is just risk you’ve postponed.

Acquisitions deserve special attention. Generation portfolios, water utilities and manufacturing groups grow by buying sites, and every site shows up with its own vendor relationships, its own remote access arrangements and its own undocumented edges. Treating integration as a trust design problem instead of a networking exercise is often what separates a clean combination from an inherited liability.

The metrics should change too. Counting firewall rules, VPN accounts, or completed scans generates plenty of operational data and tells a board very little about readiness. Better questions include:

• How many remote access paths into OT exist, and who owns each one?
• What proportion of vendor access is brokered, time-bound and attributable to a named individual?
• How long does it take to revoke one vendor’s access across every site?
• How much of the OT estate is segmented by function and trust level rather than by history?
• When was the isolation plan last tested, and what did the test reveal?

These are leadership metrics because they measure controllability, not activity. An organization that can answer them under pressure is in a very different position from one that needs a week of investigation to answer them. Regulators will notice that difference long before an attacker does.

The Secure Connectivity Roadmap

The guidance acknowledges that few organizations can do everything at once, and recommends prioritizing by operational impact, redundancy, cost and active threat. That’s sound advice, and it deserves a practical sequence, not a program plan measured in years.

Treating this as one big transformation initiative is the most reliable way to fail. Big programs bring delay, budget fatigue, and fuzzy accountability. But remote access exposure doesn’t wait for a steering committee to finish meeting. The operators who get this right break the work into staged gains that build on each other: early work cuts immediate exposure, the middle stretch builds control maturity, and the later work produces an operating model that holds up under pressure.

The first ninety days should establish operational truth. Deploy passive discovery to build a definitive view of OT assets and communication, and run remote access discovery to find every existing path into the environment, sanctioned or otherwise. The findings may reveal paths missing from current diagrams. That inventory produces the business case inputs Principle 1 asks for, and it’s what makes everything afterward measurable. Use the same window to name a risk owner for every path you’ve found and to settle who has the authority to revoke access during an incident. Decision latency is an avoidable weakness, and it’s cheapest to fix before you need it.

The next six months should turn that picture into a governed path. Start with the most exposed sites and the highest-risk vendors, not the easiest ones. Move each vendor onto brokered access, then retire the VPN, modem or jump host it replaces. Retirement is the step people skip most often, and it’s the one that produces the measurable result because a governed path running alongside an ungoverned one reduces exactly nothing. Once sessions are flowing through a single place, forward session records and asset telemetry to the SOC, tie maintenance windows to approved requests, and set break-glass access to trigger the highest-severity alert you have.

The 12 months after that should mature into containment. Use observed communication to design zones and micro-segments, test them in monitor mode, then enforce. Write isolation plans at the three scopes the guidance names and rehearse every one of them. The organizations that struggle most during incidents are rarely short on tools. They’re short on a pre-decided authority model, and they’re holding a plan nobody has ever tried.

Sector realities should shape the order. Electric utilities may put CIP-005 evidence and control center pathways first. Water and wastewater operators may start by pulling direct internet exposure off controllers at unstaffed sites, which is exactly the pattern CISA found. Manufacturers may focus first on vendor access to production lines and isolating legacy controllers. Same roadmap in principle, tailored in execution.

Forescout SRA is available standalone or as part of the Vistaro platform, so operators can start with brokering where remote access is the urgent risk, then add visibility and segmentation as the program matures. Starting matters a lot more than starting perfectly.

The Window Is Open

The message from CISA and its international partners is consistent: remote access to OT is necessary, and it has to be deliberate. That means one brokered, time-bound, monitored path, built on an accurate picture of the environment, backed by segmentation, and paired with a tested way to shut it off.

Nothing in that description requires technology that doesn’t exist yet. The obstacles are rarely technical. They’re the difficulty of untangling 15 years of accumulation, the awkwardness of telling a long-time vendor that their comfortable arrangement is changing, and the organizational habit of treating connectivity decisions as local when the consequences are enterprise wide.

None of those obstacles gets easier with time. Estates get more complex, vendor relationships multiply, acquisitions add new unknowns, and the dependence on remote support keeps deepening. Whatever you don’t fix now through deliberate design, you’ll end up fixing during an incident, and the cost difference between those two paths is not small.

There’s also a regulatory angle worth reading carefully. The joint principles are framed as desirable end states, not mandates. The guidance was issued by eight national agencies and may influence how supervisors, insurers, and auditors assess OT connectivity. Building toward those end states now gives operators time to test controls against operational needs.

Forescout SRA delivers the governed path, and the Forescout Vistaro platform delivers the visibility, segmentation and monitoring that make it trustworthy. Together they directly address most of the requirements in the Secure Connectivity Principles, support most of the others, are upfront about the few that belong elsewhere, and give electric sector operators a clear line from the guidance to their NERC CIP evidence.

The advantage here won’t look dramatic. It’ll look like a vendor session that closed when the maintenance window did, an auditor who got an answer in a minute, and an incident that stayed put at one site. The window to build that on purpose is open right now. It won’t stay open forever.

[1] CISA: Internet Exposure Reduction Guidance. https://www.cisa.gov/resources-tools/resources/exposure-reduction

[2] NCSC, CISA, FBI et al.: Secure Connectivity Principles for Operational Technology (2026). https://www.ncsc.gov.uk/collection/operational-technology/secure-connectivity

[3] Forescout Vedere Labs: RDP Security: CPS Threats Spark Need for Secure Remote Access. https://www.forescout.com/blog/rdp-security-cps-threats-spark-need-for-secure-remote-access/

[4] NERC CIP reliability standards (CIP-003, CIP-004, CIP-005, CIP-007, CIP-008, CIP-013). https://www.nerc.com/standards/reliability-standards/cip

[5] Forescout Secure Remote Access. https://www.forescout.com/solutions/secure-remote-access/

[6] Forescout Vistaro Platform. https://www.forescout.com/solutions/

[7] Forescout: agentless segmentation press release. https://www.forescout.com/press-releases/forescout-4d-platform-advances-universal-zero-trust-network-access-with-cloud-native-agentless-segmentation/