New NERC CIP Rules Are Tightening Remote Access to the Grid

Key takeaway: NERC CIP is raising the bar on OT secure remote access — new vendor-access rules for low-impact systems, internal monitoring requirements, and virtualization standards all phase in between 2028 and 2030. The cloud isn't barred for medium- and high-impact remote access; the blocker is CIP's device-level evidence requirements, not data exposure.

Every industrial control system has a back door for outsiders. Engineers need to tune equipment, integrators to configure it, vendors to patch it, often from a laptop hundreds of miles away. That convenience is also the grid’s most closely watched weakness. In North America, the rules governing who may reach operational technology (OT) from afar — the substance of OT secure remote access — sit at the heart of the NERC Critical Infrastructure Protection (CIP) standards. They are also the rules that are changing the fastest. 

The past two years have brought a cluster of them. CIP-003-9, which extends vendor remote-access controls to “low impact” systems, became enforceable on April 1, 2026. CIP-015-1, mandating internal network security monitoring, cleared the Federal Energy Regulatory Commission (FERC) in 2025. CIP-002-8 rewrote how assets are categorized, control centers especially, and was approved in 2026. That March, FERC also blessed a set of virtualization standards that begin to haul the framework’s assumptions out of 2008, when its first version was approved. 

None of this is a coincidence. The framework is quietly raising its demands on remote access and on evidence, while straining to keep pace with how infrastructure is now built. Making sense of it means following four threads: the tiers that set an operator’s obligations, the controls that apply to each, the vexed question of the cloud, and the direction of travel. 

A Matter of Consequence: NERC CIP Impact Tiers and ERC

CIP-002 sorts BES Cyber Systems into three tiers — high, medium and low impact — according to what their loss or capture would do to grid reliability. Almost everything else follows from that ranking. Large utilities and oil and gas operators typically span all three tiers at once, so a remote-access arrangement that satisfies one may fall short at another. 

High impact means the major control centers and transmission facilities whose failure would be felt across the grid; it carries the heaviest burden. Medium impact covers large generation, important substations and critical operational technology. Low impact — distributed substations, the many renewable sites, edge devices — long carried the lightest requirements. That is changing. 

The most consequential term in this corner of the rulebook is External Routable Connectivity, or ERC. In plain terms it means a system can be reached from outside its Electronic Security Perimeter over a routable network — the kind of IP-based path most computers use — rather than sitting isolated or reachable only through non-routable serial links. That distinction works like a switch. A medium-impact system with ERC must meet the full remote-access regime that follows; one without it is spared most of it. Two substations of identical importance can therefore face very different obligations, determined by nothing more than how each is wired to the outside world. 

Gatekeepers: What CIP-005 Requires for OT Secure Remote Access 

For high-impact systems, CIP-005 is unforgiving. Every interactive remote session must pass through an Intermediate System, a controlled gateway outside the Electronic Security Perimeter, so that no outsider touches a BES Cyber System directly. Multi-factor authentication is compulsory. Sessions must be encrypted, watched and, where necessary, cut off. Medium-impact systems with External Routable Connectivity face the same regime; those without it do not. 

Vendors draw particular scrutiny. CIP-005 obliges operators to know when a vendor holds a live remote session and to be able to sever it. The supply-chain revisions that produced CIP-005-7 went further, adding a requirement (R3) covering vendor access to the systems that guard the perimeter itself: Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS). The logic never varies. Any route a third party takes into a protected network must be visible and severable. 

Low impact is the tier in flux. CIP-003-9 brought vendor electronic remote-access controls to it and took effect on April 1, 2026, a marked step up for a category that had largely escaped notice. More follows. CIP-003-11, approved by FERC in March 2026, adds authentication for low-impact remote users and detection of malicious traffic, with compliance due in 2029. The direction is unmistakable: low impact no longer means low scrutiny, at least where remote access is concerned. 

Grounded, for Now: Can Secure Remote Access Run in the Cloud?

The most common question operators ask is whether secure remote-access tooling can run in the cloud. The pull is easy to understand: the cloud promises speed, scale and lower cost — attractions that only sharpen as operators race to build the new generation and grid capacity that surging data-center demand requires. For medium- and high-impact systems, though, the answer for now is mostly no, and the reason is not the obvious one. 

The standards do not forbid the cloud. The obstacle is evidence. Patch management under CIP-007 and configuration-change management under CIP-010 both demand records tied to specific devices, retained across a multi-year audit window. Public cloud, by design, shuffles workloads across shared hardware. Producing a device-by-device evidence trail on top of that, under a compliance model built for physical kit, is onerous. 

Evidence, not exposure, is the catch — which cuts against the usual assumption that the cloud is barred because sensitive information cannot leave the building. That assumption is out of date. The clearest example: CIP-011-3 and CIP-004-7, in force since January 1, 2024, made it workable to keep BES Cyber System Information (BCSI) in the cloud with suitable controls. What they did not do was permit running an actual BES Cyber System, or an EACMS, there. And an Intermediate System, the heart of any remote-access tool, is precisely an EACMS. The information may live in the cloud; the machinery that protects it may not. 

Hence the present divide. The cloud suits low-impact environments well enough, while medium- and high-impact remote access stays on-premises. That is not a matter of taste. It is where the evidence rules leave things. 

The Thaw: NERC's Virtualization Standards Are Changing the Rules

The hardware-bound assumptions beneath all this are beginning to loosen. In March 2026 FERC approved a suite of virtualization standards: revised CIP rules accompanied by new glossary terms, among them Shared Cyber Infrastructure and Virtual Cyber Asset. The commission’s stated aim was to protect virtual and cloud-based technology in the bulk power system; the requirements phase in around 2028. Separately, NERC’s Project 2023-09 is drafting a compliance framework for third-party cloud services specifically. 

For anyone settling on an architecture today, the sensible course is to hold two ideas at once: build for the rules as they stand, and assume they will move. The framework is slowly abandoning the notion that a “device” is always a physical box an auditor can be shown. 

Letting Data Out: Does OT Data Sharing Violate CIP-011?

The appetite to feed OT data into operational AI and predictive-maintenance tools is growing fast, and with it a nagging question: does moving that data out of the OT environment run afoul of CIP-011? The answer turns on a distinction. CIP-011 governs BES Cyber System Information (BCSI) — network diagrams, configurations and similar material that would help an adversary map or rebuild a critical system. What it demands is protection, not confinement: BCSI may leave the premises, the cloud included, provided the safeguards travel with it. Operational telemetry is a different category altogether. Sensor readings, performance figures and diagnostic signals are not BCSI at all; sending them to analytics platforms does not engage CIP-011. The discipline is simply to keep BCSI out of the pipe, and to log what leaves. 

One fear deserves to be laid to rest: that sending OT data to a cloud platform automatically enlarges the attack surface. Where data is hosted matters far less than the quality of the Electronic Security Perimeter around it and the discipline of access control. The question was never cloud or no cloud, but what data, through what perimeter, under what safeguards. 

The Burden of Proof: The Real Cost of NERC CIP Audit Evidence

A maxim governs every CIP audit: if it was not documented, it did not happen. But the maxim does not wait for the audit. It attaches to every action — each remote session, each change, each vendor login owes its own proof at the moment it is made. The real cost is not the audit but the friction of producing that proof continuously. 

Running a plant makes three demands of a single act. Operations need engineers and vendors to get in and work, sometimes urgently. The rules require the access to be tightly controlled: an Intermediate System, multi-factor authentication, monitoring and the power to terminate. And proof requires all of it to be documented. Where those demands pull against one another, friction builds: access slows, work waits, staff hours vanish into documentation, and corners get cut — the surest route to a finding. 

The way out is not heroic audit preparation but less friction: an arrangement in which granting access and recording it are one motion. When session records, access events, authentication data and configuration states are produced as work happens, compliance stops being a tax on operations and becomes a by-product of them. That is a matter of how work is organized, not of any single product; in principle almost any toolset can be pushed toward it. 

Fit for Purpose: Choosing the Right OT Secure Remote Access Tool

It is tempting to treat remote access as a matter of plumbing: run a VPN, stand up a jump host, connect the laptop to the plant. But under NERC CIP a working connection is not a compliant one; the standard cares less about the connection than about who may use it, how it is controlled and whether every use can be proved. The tool worth having starts from control, not connection. Dispel does: the Dispel Zero Trust Engine is the Intermediate System that CIP-005 makes every session cross, on-premises for medium- and high-impact assets, cloud-managed for low, so an operator whose assets span all three tiers runs them from a single platform. Standing in the path of every session, it records who connected, from what device and to what, so the proof accrues as access happens rather than after the fact. Dispel Compliance measures the platform’s own posture against the standard at each impact level and produces the evidence to match. 

A general-purpose tool can be aimed at the same job, but it was built for none of it. It makes the connection and leaves the rest to the operator: access granted and revoked, firewall rules rewritten to match, sessions recorded and kept, every step documented — and, because the jump host it leans on is itself an EACMS, one more in-scope system to patch, monitor and evidence. Once that labor is counted, the purpose-built platform is the economical choice, not the indulgent one. It answers by default the question the standard has pressed from the start: not whether a tool can reach a plant, but who controls the remote once it can. The duty does not lift; on-premises it stays the operator’s. What shrinks is the work of proving it — and the remote stays in the operator’s hands. 

The Test 

NERC CIP is no paper tiger. Its penalties are substantial, its audits exacting, and it is tightening on several fronts at once: CIP-003-9 and CIP-003-11 on low impact, CIP-015-1 on monitoring, CIP-002-8 on categorization and the virtualization standards recasting the definitions on which the rest depends. Remote access is where much of this becomes tangible, the daily business of admitting people and vendors to systems they must never be able to harm. 

The operators who handle it best treat compliance as a matter of architecture rather than documentation: evidence a system yields as it runs, not a record reconstructed on demand. For anyone weighing a remote-access tool, that reframing collapses into a single test — not whether the tool can secure a connection, but how it produces NERC CIP audit evidence, continuously and without a person assembling it by hand. An answer that runs through a consultant, a white paper or a project every third year is the wrong answer. In a regime where the undocumented counts as undone, that is the difference between a remote-access tool and a liability.