FERC Issues Orders on Virtualization and Low Impact: What Changed and What You Need to Do
By Patrick Miller
FERC unanimously approved Order Nos. 918 and 919 on March 19, 2026, finalizing CIP virtualization standards and new low-impact BES Cyber System controls, plus an updated "Control Center" definition. All CIP-registered entities are affected. Implementation windows are 24 and 36 months respectively. Compliance programs should begin gap assessments now.
Overview
On March 19, 2026, FERC unanimously approved two final rules and a concurrent reliability standard order representing the most significant update to the NERC CIP framework in years. Order No. 919 finalizes eleven virtualization-enabled CIP Reliability Standards, introducing new definitions for Shared Cyber Infrastructure and Virtual Cyber Assets to address the reality that modern grid-supporting technology no longer maps onto the hardware-centric assumptions the CIP framework was built around. Order No. 918 finalizes CIP-003-11, establishing new baseline cybersecurity controls for low-impact BES Cyber Systems, specifically remote user authentication, protection of authentication credentials in transit, and expanded detection of malicious communications. A third concurrent order approves CIP-002-8, updating the definition of "Control Center" in the NERC Glossary in ways that may affect how entities categorize high-impact assets.
Order No. 919's most contested issue was NERC's proposal to replace the existing Technical Feasibility Exception process with a self-implementing "per system capability" exception. FERC approved the replacement but directed NERC to develop a formal program governing it, requiring published invocation criteria, mandatory reporting to the ERO Enterprise when entities invoke the exception, and annual aggregated reporting to the Commission. The administrative burden of the old TFE process is reduced, but the compliance risk shifts: entities will self-certify rather than seek prior approval, which raises the documentation bar considerably.
Order No. 918 addresses the threat of coordinated attacks exploiting distributed low-impact assets, the Volt Typhoon threat model in regulatory language. The new controls target the specific vectors adversaries use to gain and maintain access through externally routable low-impact systems: weak authentication, exposed credentials, and unmonitored communications paths. FERC acknowledged comments arguing the standard's detection-focused approach leaves response gaps but declined to condition approval on adding response requirements, noting NERC's CIP Roadmap already addresses those issues. Entities should treat CIP-003-11 as a regulatory floor, not a security ceiling.
All NERC-registered U.S. entities are in scope for both orders. Implementation windows are 24 months for the virtualization standards and 36 months for CIP-003-11, running from the orders' effective dates following Federal Register publication. Both windows are shorter in practice than they appear on paper. Efforts like gap assessments, technology deployments, policy updates, and evidence development all take time. The work should start now.
Order No. 919: Virtualization Reliability Standards (Docket No. RM24-8-000)
The Problem the Order Solves
The CIP framework was designed around a premise that no longer describes how the bulk electric system's supporting technology actually works: that software runs on discrete hardware, that hardware sits in a defined physical location, and that security boundaries can be drawn around those physical assets. That model has been increasingly disconnected from operational reality for years. Utilities and grid operators have been deploying virtualized server environments, hypervisors, containerized applications, and shared compute infrastructure, often in tension with CIP requirements that were never written to accommodate them.
What the Order Approves
Order No. 919 approves eleven modified CIP Reliability Standards: CIP-002-7, CIP-003-10, CIP-004-8, CIP-005-8, CIP-006-7.1, CIP-007-7.1, CIP-008-7.1, CIP-009-7.1, CIP-010-5, CIP-011-4.1, and CIP-013-3. It also approves four new NERC Glossary definitions: Cyber System, Management Interface, Shared Cyber Infrastructure (SCI), and Virtual Cyber Asset; along with eighteen revised definitions covering foundational terms including BES Cyber Asset, BES Cyber System, Electronic Security Perimeter, Interactive Remote Access, Physical Access Control Systems, Protected Cyber Asset, Transient Cyber Asset, and others. The currently effective version of each standard is retired upon the new standards' effective dates.
The new definitions are doing significant work here. BES Cyber Asset and BES Cyber System have been updated to accommodate virtual assets that don't have a fixed hardware address. Shared Cyber Infrastructure is an entirely new concept describing the virtualization infrastructure (hypervisors, management planes, underlying physical compute) that hosts or supports multiple BES Cyber Systems. Virtual Cyber Asset describes software-defined assets running on that shared infrastructure. These definitional changes flow through every modified standard and reorient the compliance analysis away from physical asset identification toward functional and logical boundaries.
The standards themselves reflect four structural changes NERC described in its petition. First, the perimeter-based security model in CIP-005 has been substantially reworked to accommodate other security models like zero trust architectures, micro-segmentation, and software-defined boundaries, while preserving the traditional ESP model as explicitly valid for entities that retain it. Second, change management requirements in CIP-010 have been broadened beyond baseline configuration tracking to reflect the dynamic nature of virtualized environments, where software-defined systems don't have fixed configurations in the traditional sense. Third, access management, training, and physical security requirements in CIP-004 and CIP-006 have been updated to address virtual asset lifecycles, including provisioning, deprovisioning, and shared infrastructure access. Fourth, supply chain risk management in CIP-013 has been updated to address virtualization vendors and software-defined infrastructure procurement.
The standards do not mandate virtualization. Entities that operate entirely on perimeter-based, hardware-defined architectures have no new obligations other than documentation updates to reflect the revised glossary terms where they appear in asset inventories and security plans. The order is permissive, not prescriptive, on the technology side.
The Per System Capability Debate and How FERC Resolved It
This was the most contested substantive issue in the proceeding. NERC proposed replacing the phrase "where technically feasible," which appears in nine requirements across the currently effective standards, with the phrase "per system capability," and adding the same phrase to six additional requirements that previously had no exception language at all. The practical effect would be to allow entities to self-determine when a system is incapable of meeting a requirement, document that determination, implement alternative mitigation, and move forward, without seeking ERO approval or reapproval as they would under the existing Technical Feasibility Exception process.
NERC's argument was straightforward: the TFE process is administratively burdensome, entities must seek reapproval even when adding new assets to an existing exception under identical conditions, and the per system capability approach modernizes compliance flexibility to match the pace of technology change. Industry commenters largely agreed.
FERC approved the per system capability replacement. The TFE program, as it existed under the old standards, is retired along with those standards. But the Commission was equally clear that NERC's proposal as submitted lacked the oversight structure required for a self-implementing exception process. The order directs NERC to develop a formal program with three mandatory elements before entities begin self-implementing exceptions.
The first element is a published set of clear criteria defining when a per system capability exception can be invoked, what documentation an entity must maintain to support that invocation, and what the obligation to implement alternative mitigation requires. As the order notes, NERC described these concepts in its petition and comments, but no NERC document, not the Glossary, not the Rules of Procedure, not the standards themselves, actually contains them in binding form. NERC has discretion over the vehicle: it can use rules of procedure revisions, new or modified guidance documents, or standard modifications. But the criteria must exist and be available before any entity adopts the new standards early.
The second element is mandatory reporting. When an entity invokes the per system capability exception, it must report to the ERO Enterprise, the relevant Regional Entity, NERC, or both, on basic parameters: which standard and requirement is at issue, the basis for the invocation, and the alternative mitigation being implemented. This is not a pre-approval process; FERC explicitly stated it is not requiring an approval mechanism comparable to TFE. But it is not a silent self-determination either. Reporting is mandatory.
The third element is an annual report from NERC to FERC containing anonymized, aggregated data showing the total number of active per system capability exceptions nationally and by region, categorization by applicable requirement, the types of assets and systems for which new exceptions are being claimed, and the types of alternative mitigation being employed. The first annual report is due 12 months after mandatory compliance begins. FERC indicated it is open to reducing reporting frequency after three cycles if the program is demonstrated to be working appropriately.
The compliance implication of this structure is significant for entities with legacy equipment that currently hold approved TFEs or that have been managing CIP compliance around legacy assets using interpretive flexibility. Those entities need to map their current exception posture against the per system capability framework, ensure that the alternative mitigation they are implementing actually achieves the security objective of each affected requirement, and build the documentation to support that position. The ERO will not have a prior approval on file. Auditors will look for documentation that demonstrates the entity understood when the exception applied, what it required, and what it did about it.
Implementation Timeline
Both the new standards and definitions become effective on the later of April 1, 2026, or the first day of the first calendar quarter that is 24 months after the effective date of FERC's order. The order's effective date is 60 days after Federal Register publication [that date is not yet set as of the writing of this blog]. Early adoption is permitted at 6, 12, or 18 months post-order effective date, with notification to the Regional Entity required.
Order No. 918: CIP-003-11 (Docket No. RM25-8-000)
The Risk Picture
Under the CIP tiered categorization structure, most BES Cyber Systems are low impact. That means the majority of the digital and computer infrastructure supporting the grid carries the lightest compliance requirements. The classification reflects a reasonable engineering judgment about individual asset criticality. The problem is that the threat model has shifted. A coordinated attack exploiting distributed, externally routable low-impact assets, not for their individual impact, but as a coordinated campaign or as a pivot point into higher-impact systems, produces consequences that the individual asset classification does not capture. The order cites this explicitly: the aggregate impact of a coordinated attack leveraging multiple low-impact BES Cyber Systems could be much greater than the sum of their individual classifications.
This is the Volt Typhoon and Poland DER threat scenario in formal regulatory language. Nation-state adversaries have demonstrated the capability and intent to pre-position access inside grid infrastructure using exactly this approach: targeting assets with lighter security controls, establishing persistent access, and using those footholds either to cause disruption across a large number of distributed assets simultaneously or to move laterally toward more critical systems. CIP-003-11 is a direct regulatory response to that threat profile.
What the Order Approves
CIP-003-11 adds three categories of new controls to Attachment 1 of the standard, which governs low-impact BES Cyber Systems with external routable connectivity.
The first category is remote user authentication. Entities must implement controls to verify the identity of users accessing low-impact BES Cyber Systems remotely. The standard requires authentication of remote users, protection of authentication information in transit, and controls on what remote access is permitted. Section 3.1 of Attachment 1 carries the most significant compliance burden.
The second category is protection of authentication information in transit. Credentials used for remote access to low-impact systems cannot traverse network paths unprotected (e.g., legacy Telnet, FTP protocols). This requirement addresses the risk of credential interception across external or partially trusted network paths, which is a documented technique in adversary playbooks targeting industrial control environments.
The third category is detection of malicious communications. This is an expansion of existing detection requirements. Under prior standards, detection obligations for low-impact systems were largely limited to vendor-based electronic access. CIP-003-11 extends detection to cover all traffic into or out of a low-impact BES Cyber System with external routable connectivity. The scope change is meaningful: entities must now implement capabilities to detect malicious communications across the full envelope of externally routable connections to these assets, not just through defined vendor access channels.
Several commenters argued the standard does not go far enough. Their position was that a detection-focused approach without mandatory response requirements, explicit lateral movement controls, or cryptographic baselines leaves exploitable gaps, citing Volt Typhoon and Colonial Pipeline as evidence that detection without response enables adversaries to persist and escalate. FERC acknowledged these concerns and declined to condition approval on adding response requirements. The Commission's reasoning is that NERC's CIP Roadmap, published January 2026, already identifies response plan maturity and lateral movement risk as priorities for the near-term standards development cycle, and that the existing standard contains incident response planning requirements in Requirement R2 and Section 4 of Attachment 1 for Cyber Security Incidents. FERC stated it will continue monitoring NERC's progress under the CIP Roadmap and expects to be kept informed of material findings.
This is worth flagging... The Commission approved a detection-focused standard while acknowledging the response gap. Entities that treat compliance with CIP-003-11 as the ceiling of their low-impact security program rather than a regulatory floor are accepting risk that the Commission itself has identified as not fully addressed by this standard. Incident response plans for low-impact systems that consist of boilerplate language are not adequate for the threat environment these requirements are designed for.
Implementation Timeline and Scale
The implementation period is 36 months from the effective date, longer than the virtualization standards, reflecting the scale of the low-impact population and the practical challenges of deploying new controls across such a large number of geographically distributed assets. All NERC-registered U.S. entities are in scope.
A sequencing note is important: CIP-003-10, which was approved as part of Order No. 919's virtualization package in the same meeting, is superseded by CIP-003-11 before it ever becomes mandatory. NERC designed CIP-003-11 to incorporate and build on the virtualization-related revisions in CIP-003-10. Entities should not plan compliance programs around CIP-003-10 as a stable baseline for the low-impact standard going forward. CIP-003-11 is the operative standard.
CIP-002-8 and the Updated "Control Center" Definition (Docket No. RD25-8-000)
The third concurrent action today is smaller in page count but operationally consequential for a subset of entities. FERC approved Reliability Standard CIP-002-8 and an updated definition of "Control Center" in the NERC Glossary.
The definition of "Control Center" is not incidental. It is one of the primary criteria used in CIP-002's bright-line categorization methodology to classify BES Cyber Systems as high, medium, or low impact. The prior definition covered Control Centers for Reliability Coordinators (RC), Balancing Authorities (BA), Transmission Operators (TOPs), and Generator Operators (GOPs). The new definition retains that language, including an update from "reliability tasks" to "functional obligations" throughout, and adds a second, distinct pathway. Under CIP-002-8, the definition now also covers:
"One or more facilities of a Transmission Owner (TO) that have the capability to control transmission Facilities at two or more locations in real-time using Supervisory Control and Data Acquisition (SCADA), including their associated data centers, and excluding field Cyber Assets used for telemetry."
This is the material change. Transmission Owners with real-time SCADA control capability over transmission facilities at two or more locations are now explicitly within the Control Center definition, regardless of whether they are also registered as a Transmission Operator or hold a functional delegation agreement with one. Under prior standards, a TO facility that didn't perform TOP functional obligations could argue it fell outside the Control Center definition. That argument is no longer available.
The carve-out for "field Cyber Assets used for telemetry" is an important limiting principle. Not every device with a SCADA connection pulls a TO facility into Control Center status. The definition requires actual real-time control capability at two or more locations. Telemetry-only field devices are explicitly excluded. The threshold question is capability, not authority.
New Criterion 2.12: The AWV Threshold for TO/TOP Control Centers
The revised Control Center definition works in tandem with an entirely new Criterion 2.12 in Attachment 1. This criterion is new. It did not exist in CIP-002-5.1a. (The prior standard's Criterion 2.12, which covered Balancing Authority Control Centers, is renumbered to 2.13 to make room.)
New Criterion 2.12 introduces an Aggregated Weighted Value (AWV) calculation to determine whether a TO or TOP Control Center is medium impact. Entities sum weight values for each BES Transmission Line their Control Center monitors and controls, by voltage class:
If the AWV reaches or exceeds 6,000, the Control Center's BES Cyber Systems are Medium Impact. If it falls below, they default to Low Impact, but the Control Center still exists under the new definition, which matters for low-impact compliance obligations.
Criterion 2.12 also includes a Group of Contiguous Elements (GCE) exclusion that allows certain local, load-serving control footprints to back out below the 6,000 threshold, subject to specific conditions. We covered the AWV calculation mechanics, the counting rules for tapped versus parallel lines, the GCE exclusion criteria, and worked examples in detail in our earlier post: CIP-002-8, Decoded: Who's In, Who's Out Under the New 2.12. That analysis is now operative. The standard has been approved.
Implementation Timeline
CIP-002-8 moves on a faster clock than the other orders approved today. The standard and the revised Control Center definition become effective on the later of the effective date of CIP-002-7 (approved concurrently in Order No. 919) or the first day of the first calendar quarter that is three calendar months after today's order effective date, not 24 or 36 months. For entities that land in medium impact under new Criterion 2.12, that compressed timeline makes the categorization analysis urgent, not eventual.
if this affects you, then do this
This is a targeted review, not a wholesale reassessment, but for some entities it carries real compliance consequences. The priority actions are:
Transmission Owners with any SCADA-capable facility that can control transmission assets at two or more locations in real time need to determine whether that facility meets the revised Control Center definition. If it does, run the AWV calculation.
Entities at or near the 6,000 AWV threshold need to evaluate whether the GCE exclusion applies and, if so, begin building the boundary documentation and 12-month export data now.
Entities that land in medium impact for the first time need to scope the full compliance gap. CIP-003 through CIP-013 medium-impact obligations are substantial and the timeline to get there is short.
All registered entities should confirm that the "reliability tasks" to "functional obligations" language update in high-impact criteria 1.1 through 1.4 is reflected in their categorization documentation, even if the substantive result doesn't change.
What Your Program Needs to Do
FOUR parallel workstreams should start immediately.
On virtualization: If your organization operates any virtualized OT environments, IT/OT converged infrastructure, or shared compute platforms that support BES Cyber Systems, the priority is a gap assessment against the new SCI-aware definitions and modified standards. The new definitional framework changes how those systems are classified, how access controls must be structured, and how change management must be documented. That gap assessment will drive your implementation planning for a 24-month window that is not as long as it sounds once architecture work, policy updates, training, and evidence development are factored in. If your organization is planning a technology transition to virtualized infrastructure, start that planning with the new standards in scope from day one rather than retrofitting compliance obligations later.
On per system capability: Every entity that currently holds Technical Feasibility Exceptions should map those exceptions to the per system capability framework now, before NERC issues its implementation criteria. The objective is to understand whether your current alternative mitigation clearly achieves the security objective of the affected requirements and whether your documentation supports that conclusion. When NERC publishes its per system capability program criteria, which must be in place before early adoption can begin, you want to be positioned to assess and update your approach against a known standard, not starting from scratch.
On CIP-003-11: Every registered entity needs a low-impact BES Cyber System inventory assessment focused on two questions: which assets have external routable connectivity, and what remote access mechanisms are currently in place for those assets? The three new control categories: authentication, credential protection in transit, detection; each require technology and/or configuration changes that take time. Detection of all traffic into and out of externally routable low-impact systems is not a software policy change; it requires deployed capability. Scope that work now. The 36-month window is real time, but it is not unlimited time.
On CIP-002-8: This is a targeted review, not a wholesale reassessment, but for some entities it carries real compliance consequences. The revised Control Center definition adds a new pathway: Transmission Owner (TO) facilities with real-time SCADA control capability over transmission assets at two or more locations now explicitly meet the definition, independent of whether the TO is also registered as a Transmission Operator (TOP) or has a functional delegation agreement with one. If your organization is a Transmission Owner (TO) with any SCADA-capable facility that can control transmission assets at two or more locations in real time, you need to evaluate whether that facility now meets the revised definition and what that means for the CIP-002 categorization of BES Cyber Systems located there. Entities that have previously relied on the absence of TOP functional obligations to avoid Control Center classification for SCADA facilities should treat today's order as a direct compliance trigger. The telemetry carve-out in the new definition (field Cyber Assets used only for telemetry are excluded) provides some limiting principle, but the threshold question is whether your facility has actual real-time control capability, not just visibility. If it does, the analysis needs to happen before the standard's effective date.
Note on effective dates: Both Order Nos. 918 and 919 contain placeholder effective dates pending Federal Register publication "[INSERT DATE 60 DAYS AFTER DATE OF PUBLICATION IN THE FEDERAL REGISTER]." The implementation windows run from those dates. This post will be updated when Federal Register publication occurs and the calendar dates are confirmed.
