Legal Status This site displays a prototype of a “Web 2.0” version of the daily
Federal Register. It is not an official legal edition of the Federal
Register, and does not replace the official print version or the official
electronic version on GPO’s govinfo.gov.

The documents posted on this site are XML renditions of published Federal
Register documents. Each document posted on the site includes a link to the
corresponding official PDF file on govinfo.gov. This prototype edition of the
daily Federal Register on FederalRegister.gov will remain an unofficial
informational resource until the Administrative Committee of the Federal
Register (ACFR) issues a regulation granting it official legal status.
For complete information about, and access to, our official publications
and services, go to About the Federal Register on NARA's archives.gov.

The OFR/GPO partnership is committed to presenting accurate and reliable
regulatory information on FederalRegister.gov with the objective of
establishing the XML-based Federal Register as an ACFR-sanctioned
publication in the future. While every effort has been made to ensure that
the material on FederalRegister.gov is accurately displayed, consistent with
the official SGML-based PDF version on govinfo.gov, those relying on it for
legal research should verify their results against an official edition of
the Federal Register. Until the ACFR grants it official status, the XML
rendition of the daily Federal Register on FederalRegister.gov does not
provide legal notice to the public or judicial notice to the courts.

Legal Status

Rule

You may be interested in this older document that published on 09/23/2025 with action 'Notice of proposed rulemaking.' View Document

Order No. 919; Virtualization Reliability Standards

A Rule by the Federal Energy Regulatory Commission on 03/24/2026

• 1.

1.

• Document Details Published Content - Document Details Agencies Department of Energy Federal Energy Regulatory Commission Agency/Docket Number Docket No. RM24-8-000 CFR 18 CFR 40 Document Citation 91 FR 13957 Document Number 2026-05716 Document Type Rule Pages 13957-13965
  (9 pages) Publication Date 03/24/2026 Published Content - Document Details

• PDF Official Content

  • View printed version (PDF) Official Content

• Document Details Published Content - Document Details Agencies Department of Energy Federal Energy Regulatory Commission Agency/Docket Number Docket No. RM24-8-000 CFR 18 CFR 40 Document Citation 91 FR 13957 Document Number 2026-05716 Document Type Rule Pages 13957-13965
  (9 pages) Publication Date 03/24/2026 Published Content - Document Details

• Document Dates Published Content - Document Dates Effective Date 2026-05-26 Dates Text his action is effective May 26, 2026. Published Content - Document Dates

• Table of Contents Enhanced Content - Table of Contents This table of contents is a navigational tool, processed from the
  headings within the legal text of Federal Register documents.
  This repetition of headings to form internal navigation links
  has no substantive legal effect.

  • AGENCY:
  • ACTION:
  • SUMMARY:
  • DATES:
  • FOR FURTHER INFORMATION CONTACT:
  • SUPPLEMENTARY INFORMATION:
  • I. Background
  • A. Section 215 of the FPA and Mandatory Reliability Standards
  • B. Virtualization
  • C. Technical Feasibility Exceptions and Order No. 706
  • D. NERC Petition and Supplement
  • E. NOPR
  • II. Discussion
  • A. Virtualization Reliability Standards
  • 1. NOPR
  • 2. Comments
  • 3. Commission Determination
  • B. Per System Capability Exception Process
  • 1. NOPR
  • 2. Comments
  • 3. Commission Determination
  • C. NERC Glossary Definitions
  • 1. NOPR
  • 2. Comments
  • 3. Commission Determination
  • III. Information Collection Statement
  • IV. Environmental Analysis
  • V. Regulatory Flexibility Act
  • VI. Document Availability
  • VII. Regulatory Planning and Review
  • VIII. Effective Date and Congressional Notification
  • Footnotes Enhanced Content - Table of Contents

• Related Documents Enhanced Content - Related Documents FederalRegister.gov uses the agency dockets published with the document to display related documents.

| Docket No. RM24-8-000
(2 Documents) | | | |
| --- | | | |
| Date | | Action | Title |
| | 2026-03-24 | Final action. | Order No. 919; Virtualization Reliability Standards |
| | 2025-09-23 | Notice of proposed rulemaking. | Virtualization Reliability Standards |

Enhanced Content - Related Documents

• Public Comments Enhanced Content - Public Comments This feature is not available for this document.

Enhanced Content - Public Comments
- Regulations.gov Data Enhanced Content - Regulations.gov Data Additional information is not currently available for this document.

Enhanced Content - Regulations.gov Data

- Sharing Enhanced Content - Sharing Shorter Document URL https://www.federalregister.gov/d/2026-05716 Email Email this document to a friend Enhanced Content - Sharing

• Print Enhanced Content - Print
  • Print this document Enhanced Content - Print
• Other Formats Enhanced Content - Other Formats This document is also available in the following formats:

JSON Normalized attributes and metadata XML Original full text XML MODS Government Publishing Office metadata More information and documentation can be found in our developer tools pages.

Enhanced Content - Other Formats
- Public Inspection Public Inspection This PDF is FR Doc. 2026-05716 as it appeared on Public Inspection on
03/23/2026 at 8:45 am.

It was viewed
19
times while on Public Inspection.

If you are using public inspection listings for legal research, you
should verify the contents of the documents against a final, official
edition of the Federal Register. Only official editions of the
Federal Register provide legal notice of publication to the public and judicial notice
to the courts under 44 U.S.C. 1503 & 1507. Learn more here.

Public Inspection
Published Document: 2026-05716 (91 FR 13957) This document has been published in the Federal Register. Use the PDF linked in the document sidebar for the official electronic format.

Document Headings Document headings vary by document type but may contain
the following:

1. the agency or agencies that issued and signed a document
2. the number of the CFR title and the number of each part the document amends, proposes to amend, or is directly related to
3. the agency docket number / agency internal file number
4. the RIN which identifies each regulatory action listed in the Unified Agenda of Federal Regulatory and Deregulatory Actions See the Document Drafting Handbook for more details.

Department of Energy

Federal Energy Regulatory Commission

1. 18 CFR Part 40
2. [Docket No. RM24-8-000]

AGENCY:

Federal Energy Regulatory Commission, Department of Energy.

ACTION:

Final action.

SUMMARY:

The Federal Energy Regulatory Commission (Commission) approves 11 modified Critical Infrastructure Protection (CIP) Reliability Standards. The Commission also approves four new definitions and 18 modified definitions in the North American Electric Reliability Corporation (NERC) Glossary of Terms Used in Reliability Standards. To address concerns regarding a proposed self-implementing exception phrase (“per system capability”) that appears in multiple provisions of the modified CIP Reliability Standards, the Commission directs NERC to develop a clear set of criteria that satisfies the fundamental needs for oversight, consistency, and alternative mitigation when a responsible entity invokes the per system capability exception. NERC, the Commission-certified Electric Reliability Organization (ERO), submitted the proposed modifications to update the CIP Reliability Standards to enable the application of virtualization and other new technologies in a secure manner.

DATES:

his action is effective May 26, 2026.

FOR FURTHER INFORMATION CONTACT:

Mayur Manchanda (Technical Information), Office of Electric Reliability, Federal Energy Regulatory Commission, 888 First Street NE, Washington, DC 20426, (202) 502-6166, Mayur.Manchanda@ferc.gov.

Hampden T. Macbeth (Legal Information), Office of General Counsel, Federal Energy Regulatory Commission, 888 First Street NE, Washington, DC 20426, (202) 502-8957, Hampden.Macbeth@ferc.gov.

SUPPLEMENTARY INFORMATION:

1. Pursuant to section 215(d)(2) of the Federal Power Act (FPA), [1 ] the Federal Energy Regulatory Commission (Commission) approves 11 Critical Infrastructure Protection (CIP) Reliability Standards as well as the addition of four new and 18 proposed revisions to the North American Electric Reliability Corporation (NERC) Glossary of Terms Used in Reliability Standards (NERC Glossary). We also approve the associated violation risk factors, violation severity levels, implementation plans, and effective dates for the proposed Reliability Standards. In addition, we approve the retirement of the currently effective version of each proposed Reliability Standard. We approve the proposed definitions and 11 proposed Reliability Standards because collectively they will allow responsible entities the opportunity to adopt virtualization, improving the reliability of the Bulk-Power System by providing significant cyber security benefits and flexibility in responding to cyber threats.

2. NERC submitted the proposed modifications to update the CIP Reliability Standards to enable the ( printed page 13958) application of virtualization and other new technologies in a secure manner. [2 ] As stated in the notice of proposed rulemaking (NOPR), [3 ] we support NERC's efforts to update the CIP Reliability Standards to accommodate virtualization and other nascent technologies. These proposed updates will allow responsible entities to enhance their reliability and security posture by adapting to emerging risks with forward-looking security models. As NERC explains, “[T]echnology supporting and enabling the industrial control systems that operate the Bulk-Power System has evolved rapidly.” [4 ] To accommodate this evolution, NERC has updated the CIP Reliability Standards to provide responsible entities the flexibility to adopt virtualization and other new technologies “to operate their systems effectively and efficiently while maintaining a robust security posture.” [5 ] The proposed modifications do not obligate entities to adopt virtualization; rather, if approved, the proposed CIP Reliability Standards would accommodate responsible entities that choose to do so. We agree that these potential reliability benefits are worth pursuing, and we continue to support efforts by NERC and responsible entities to facilitate the use of technological advancements that enhance the reliability and security of the Bulk-Power System.

3. However, as explained in the NOPR, we remain concerned that the proposed language (repeated in multiple Requirements) that would replace the phrase “where technically feasible” [6 ] with the phrase “per system capability” [7 ] would eliminate transparency and meaningful Commission and NERC oversight by introducing a self-implementing exceptions process with no reporting obligations. [8 ] To address this concern, the Commission directs NERC to (1) develop a clear set of criteria that promote consistency and ensure that responsible entities understand the parameters for invoking the per system capability exception and the obligation to implement alternative mitigation; (2) develop mandatory reporting requirements to the Electric Reliability Organization (ERO) Enterprise (i.e., the relevant Regional Entity, NERC, or both) for responsible entities that invoke the per system capability language; and (3) submit an annual report to the Commission that includes anonymized, aggregated data that indicates how entities are utilizing the exception language. These three elements will provide adequate ERO and Commission oversight, consistency in application, and assurance that entities implement appropriate alternative mitigation when invoking the per system capability exception. As discussed later, we are not directing NERC to modify the CIP Reliability Standards but rather leave to NERC's discretion the mechanism for development of the required criteria, i.e., through changes to the NERC Rules of Procedure, changes to the NERC guidance documents, modifications to the Reliability Standards, or some other mechanism. Moreover, while we direct NERC to develop mandatory reporting, we do not require that NERC develop an approval process akin to the current CIP technical feasibility exception process.

I. Background

A. Section 215 of the FPA and Mandatory Reliability Standards

1. Section 215 of the FPA provides that the Commission may certify an ERO, the purpose of which is to develop mandatory and enforceable Reliability Standards, subject to Commission review and approval. [9 ] Reliability Standards may be enforced by the ERO, subject to Commission oversight, or by the Commission independently. [10 ] Pursuant to section 215 of the FPA, the Commission established a process to select and certify an ERO, [11 ] and subsequently certified NERC. [12 ]

B. Virtualization

1. Virtualization is the process of creating virtual, as opposed to physical, versions of computer hardware to minimize the amount of physical computer hardware resources required to perform various functions. [13 ] Virtualization allows the sharing of hardware, central processing units, memory, storage, and other resources among various operating systems (i.e., guest operating systems). [14 ] A virtual machine is a software version of a single physical computer and performs all the same functions. [15 ] Containers are a virtualization concept and are considered software that encapsulate applications and their dependencies in isolated environments, separate from other applications or containers. [16 ]

C. Technical Feasibility Exceptions and Order No. 706

1. As implemented by NERC in its Rules of Procedure, a technical feasibility exception is an alternative to strict compliance with a CIP Requirement through compensating measures and/or mitigating measures that achieve a comparable level of security for the bulk electric system (BES). [17 ] Order No. 706 established technical feasibility exceptions to prevent the premature retirement or costly replacement of long-life, legacy operational technology that lacked the inherent technical capability to comply with Requirements in version 1 of the CIP Reliability Standards. [18 ] Further, to assure accountability, the Commission in Order No. 706 directed NERC to develop procedures for an entity to seek ( printed page 13959) approval by submitting an application to the ERO that includes justification for the technical feasibility exception, plans for alternative mitigation, and remediation plans to eventually eliminate use of the technical feasibility exception. [19 ] As a result, when it is not able to satisfy strict compliance with a CIP Requirement, a responsible entity may now request and obtain approval for a technical feasibility exception that will not compromise safety in one of six listed circumstances. [20 ]

D. NERC Petition and Supplement

1. On July 10, 2024, as supplemented on May 20, 2025, [21 ] NERC submitted for Commission approval 11 proposed CIP Reliability Standards and the associated violation risk factors and violation severity levels, implementation plans, and effective dates for the relevant CIP Standards. [22 ] NERC also submitted four newly defined terms (Cyber System, Management Interface, Shared Cyber Infrastructure, and Virtual Cyber Asset) to support the virtualization-related modifications to the proposed CIP Reliability Standards. Likewise, NERC submitted proposed revisions to 18 defined terms within the NERC Glossary. [23 ] Finally, NERC proposed the retirement of the corresponding versions of the currently effective Reliability Standards. [24 ]

2. Specifically, NERC seeks Commission approval of the following 11 modified CIP Reliability Standards:

• CIP-002-7 (Cyber Security—BES Cyber System Categorization) [25 ]

• CIP-003-10 (Cyber Security—Security Management Controls) [26 ]

• CIP-004-8 (Cyber Security—Personnel & Training)

• CIP-005-8 (Cyber Security—Electronic Security Perimeter(s))

• CIP-006-7.1 (Cyber Security—Physical Security of BES Cyber Systems) [27 ]

• CIP-007-7.1 (Cyber Security—Systems Security Management)

• CIP-008-7.1 (Cyber Security—Incident Reporting and Response Planning)

• CIP-009-7.1 (Cyber Security—Recovery Plans for BES Cyber Systems)

• CIP-010-5 (Cyber Security—Configuration Change Management and Vulnerability Assessments)

• CIP-011-4.1 (Cyber Security—Information Protection)

• CIP-013-3 (Cyber Security—Supply Chain Risk Management)

• According to NERC, the Reliability Standards would allow responsible entities to fully implement virtualization and address risks associated with virtualized environments. [28 ] NERC also stated that the use of security objectives within the CIP Reliability Standards would establish a framework adaptable to newer technologies. [29 ]

1. NERC explained that its revisions would: (1) support different security models by adjusting language around perimeter-based models to accommodate other security models; (2) recognize “virtualization infrastructure and virtual machines through new and revised terms in the NERC Glossary;” (3) broaden “change management approaches beyond a baseline-only configuration to recognize the dynamic nature of virtualized technologies,” e.g., where such virtualized systems are no longer installed on specific servers; and (4) manage “accessibility and attack surfaces of a virtualized configuration.” [30 ]

2. In addition to the virtualization modifications described above, NERC proposed to replace the phrase technical feasibility, which appears in nine Requirements of the currently effective CIP Standards, with the phrase per system capability. [31 ] NERC also proposed to add the phrase per system capability in six Requirements with no existing technical feasibility exception language. NERC explained that the phrase per system capability means that if a responsible entity can demonstrate that the applicable system is incapable of performing a required action (e.g., a firmware-based “black box” device with limited configuration capabilities), then the responsible entity does not have to meet the CIP Requirement and will determine on its own an equally effective alternative mitigation measure. [32 ] NERC explained that the phrase per system capability is used to “account for the different types of technology that will be expected to meet the security objective” of a particular CIP Reliability Standard. [33 ] According to NERC, “should a Responsible Entity choose to rely on that term, the Responsible Entity will need to document the limit to the system's capability and demonstrate during compliance monitoring activities that the system's incapability prevents the Responsible Entity from implementing the control within the requirement.” [34 ] NERC added that it and the Regional Entities have observed a significant decrease in the number of submitted technical feasibility exceptions and replacement with the phrase per system capability would ease the administrative burden associated with the current process.

3. NERC's implementation plan provides that the Reliability Standards and definitions will 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 the applicable governmental authority's order approving the Reliability Standards and definitions, or as otherwise provided for by the applicable governmental authority. The implementation plan also allows responsible entities to comply with the proposed Reliability Standards prior to their effective date, after Commission approval, by notifying their Regional Entities. Early adoption can occur on ( printed page 13960) one of three instances: six, 12, or 18 months after the effective date of this final rule. NERC stated that the implementation plan balances the urgency to implement the requirements with the time needed to develop any relevant capabilities. [35 ]

E. NOPR

1. On September 18, 2025, the Commission issued the NOPR, proposing to approve the 11 modified virtualization Reliability Standards; the associated violation risk factors, violation severity levels, implementation plans, and effective dates for the proposed Reliability Standards; the retirement of the currently effective version of each proposed Reliability Standard; and 22 new or modified definitions in the NERC Glossary. [36 ] The NOPR stated that the Commission supported NERC's work to update the CIP Reliability Standards to accommodate virtualization to enhance reliability. [37 ] However, the Commission expressed concern that the replacement of the technical feasibility exception program in the current CIP Reliability Standards with the proposed phrase per system capability would eliminate transparency and oversight. [38 ] Consequently, the Commission sought comments on the efficacy of the technical feasibility exception program and on the proposed per system capability language. [39 ] In response, the following seven entities submitted timely comments: Bonneville Power Administration (BPA); Edison Electric Institute (EEI); GE Vernova; Midcontinent Independent System Operator (MISO); Midwest Reliability Organization NERC Standards Review Forum (MRO NSRF); NERC; and Portland General Electric (PGE).

II. Discussion

1. Pursuant to section 215(d)(2) of the FPA, we adopt the NOPR proposal and approve the 11 proposed modified virtualization Reliability Standards and the four new proposed definitions and 18 proposed modified definitions in the NERC Glossary. Below, we discuss the following matters: (A) our approval of the virtualization Reliability Standards; (B) directives related to the per system capability exception; and (C) our approval of the NERC Glossary definitions.

A. Virtualization Reliability Standards

1. NOPR

1. In the NOPR, the Commission proposed to approve NERC's petition as supplemented as just, reasonable, not unduly discriminatory or preferential, and in the public interest. [40 ] The Commission supported NERC's efforts to allow responsible entities to take advantage of the efficiencies and flexibilities afforded by virtualization and other emerging technologies, and encouraged interested responsible entities to do so, while being mindful of the need for a secure electric grid. The Commission saw NERC's proposed modifications as a necessary and forward-looking progression of cybersecurity requirements for the bulk electric system, designed to enhance reliability and accommodate technological advancements. The Commission also proposed to approve the associated violation risk factors, violation severity levels, implementation plans, and effective dates of the 11 modified CIP Reliability Standards, as well as to approve the retirement of the associated currently effective Reliability Standards. [41 ]

2. Comments

1. Commenters generally support approval of the 11 modified CIP Reliability Standards. [42 ] Specifically, commenters support the package of modifications because the modifications will allow responsible entities to adopt virtualization, which provides significant cyber security benefits and flexibility in responding to cyber threats and allows for the secure adoption of emerging technology. [43 ] For example, EEI states “The Commission should adopt these modifications because . . . [v]irtualization offers significant benefits including improved security posture through isolation and segmentation, greater resilience by reducing hardware dependency, and enhanced flexibility for adapting to evolving threats and operational needs.” [44 ]

3. Commission Determination

1. Pursuant to section 215(d)(2) of the FPA, we approve the 11 proposed modified CIP Reliability Standards as just, reasonable, not unduly discriminatory or preferential, and in the public interest. Specifically, the 11 proposed virtualization Reliability Standards provide the opportunity for responsible entities to take advantage of the efficiencies and flexibilities afforded by virtualization in a secure manner. Further, we determine that the package of Reliability Standards is a forward-looking progression of cybersecurity requirements for the Bulk-Power System, which will enhance the current reliability of the Bulk-Power System and accommodate future technological developments. We also approve the associated violation risk factors, violation severity levels, implementation plans, and effective dates of the 11 modified CIP Reliability Standards, as well as approve the retirement of the associated currently effective Reliability Standards.

B. Per System Capability Exception Process

1. NOPR

1. The Commission expressed concern in the NOPR that the proposed per system capability language “would allow responsible entities to self-implement an exception with marginal oversight and no alternative mitigation obligation, in contrast to the current accountability-based process for technical feasibility exceptions.” [45 ] The Commission further explained that “under NERC's proposal neither the ERO nor the Commission would have any information on the number of exceptions that entities have taken and in what circumstances, except for those that were identified during an audit.” [46 ]

2. The Commission asked for comments on: (1) the efficacy of the existing technical feasibility exception program; (2) the parameters of the proposed per system capability language; and (3) alternative approaches “that would streamline the process while also satisfying the need for effective regulatory oversight.” [47 ] The Commission stated that the comments would assist the Commission in determining the need for a directive in a final rule and its content.

2. Comments

1. Commenters claim that an exception process is still necessary 15 years after the development of the technical feasibility exception process to accommodate legacy and emerging technologies. [48 ] EEI explains that ( printed page 13961) existing and emerging technologies cannot satisfy certain CIP Reliability Standards requirements due to “inherent design limitations.” [49 ] MRO NSRF states satellite clocks and door control panels for physical access control systems are unable to meet some of the CIP Requirements and would have no opportunity for mitigation without an exception. [50 ] BPA asserts that exceptions are also necessary because immediately replacing legacy equipment to comply with the CIP Reliability Standards on a particular system could affect a specific security control's interoperability with other systems. [51 ]

2. Consequently, commenters believe that the per system capability language should be approved to ease burdens associated with the current technical feasibility exception process and to speed the adoption of new technologies. [52 ] EEI urges the adoption of the proposed per system capability language because it will enable utilities to “self-assess and document inherent limitations” rather than seeking approval or re-approval of formal exceptions under the technical feasibility exception process that may delay implementation of security measures, [53 ] while preserving oversight, and enabling operational flexibility for utilities deploying virtualization. [54 ] MISO notes that its technical feasibility exception process is burdensome because it requires a lengthy, multistep process for securing an exception. [55 ] NERC asserts that the per system capability language will help ensure that the proposed CIP Reliability Standards are forward-looking and enable the secure adoption of new technologies. [56 ]

3. MISO, MRO NSRF, and NERC believe that the adoption of the per system capability language will not lead to an increase in new exception requests from responsible entities beyond those under the technical feasibility exception process. MISO suggests that the proposed changes to the NERC CIP Standards to accommodate virtualization will allow entities “the ability to build their infrastructure in a manner that reduces the need for [exceptions].” [57 ] NERC points to the stability of the technical feasibility exceptions in recent years and states that it does not anticipate the trend significantly shifting with the change to per system capability. [58 ] In contrast, EEI indicates the use of new exceptions is necessary because some emerging technologies will not be able to meet CIP requirements. [59 ] Using the example of protective relays, EEI avers that “[a]s standards evolve to mandate [advanced cybersecurity] capabilities, entities will increasingly need [an] exceptions process” to accommodate equipment limitations. [60 ]

4. MISO proposes that NERC establish and maintain “a centralized repository of common, industry-wide exceptions” for monitoring new system capability exceptions other than through CIP compliance activities (i.e., audits) by cataloging Cyber Assets that have historically been unable to comply with CIP Requirements, documenting accepted mitigation strategies and compensating controls; and facilitating knowledge sharing. [61 ] MISO claims the proposed repository would minimize redundant technical feasibility exception submissions; promote consistency and transparency in the application and review of exceptions; and enable the retirement of exceptions as capabilities evolve or new solutions are identified. [62 ]

5. MISO additionally proposes that NERC develop a System Capability Exception Program (SCEP), which responsible entities can implement internally with the support of new and existing guidance documents. MISO suggests that NERC could develop implementation guidance to support such a program. [63 ] MISO asserts that the SCEP would need to include program expectations (e.g., scope of exceptions), required program elements (e.g., compensating controls), and management tools.

6. However, other commenters indicate that new system capability exceptions can be sufficiently monitored through traditional CIP Reliability Standards compliance activities. EEI and MRO NSRF assert that NERC can use existing compliance mechanisms, such as audits, spot-checks, evidence reporting, and data gathering through NERC's evidence request tool to monitor implementation. [64 ] NERC states that Regional Entities could use the Align tool to collect information on devices that do not have the capability to implement CIP requirements in the context of audit preparation, self-certifications, and development of Inherent Risk Assessments. [65 ]

7. EEI and MRO NSRF recommend that, if the Commission retains the current technical feasibility exception process, the process be streamlined by eliminating the requirement that responsible entities seek re-approval when adding assets to an existing technical feasibility exception because the mitigation measures and risk rationale would remain unchanged, while enabling timely upgrades and preserving security. [66 ] PGE recommends adopting the per system capability language and developing a streamlined process that would require responsible entities to provide data on the number of, and reasoning for, self-identified exceptions to the ERO Enterprise for visibility with no pre-approval requirement. PGE asserts that its proposed streamlined approach would avoid delays in the implementation of virtualization and eliminate both: (1) the need to modify the CIP Reliability Standards through the standard development process; and (2) the re-approval requirement for technical feasibility exceptions. [67 ]

3. Commission Determination

1. We are persuaded by commenters that an exception process is still needed for existing and emerging technologies. Indeed, some existing technologies are unable to meet certain CIP Requirements and would be out of compliance with no mitigation opportunity without an exception process. [68 ] Additionally, we recognize BPA's concern that eliminating an exception for legacy equipment may pose a risk to reliability because implementing a specific security control on a particular system could affect its ( printed page 13962) interoperability with other systems needed to ensure reliability. [69 ]

2. Further, we believe that the exception process merits streamlining. As noted by commenters, the current technical feasibility exception process requires responsible entities to seek approval or re-approval of exceptions from the ERO that can delay implementation of security measures that strengthen reliability. [70 ] Accordingly, with our approval of the package of 11 proposed virtualization Reliability Standards, NERC's proposed per system capability exception will replace the technical feasibility exception process.

3. However, we are not persuaded by the explanation of NERC and other commenters that the per system capability language adequately addresses the concerns raised in the NOPR regarding the fundamental needs for oversight, consistency, and alternative mitigation in a CIP exceptions program. [71 ] These concepts stem from the Commission's initial approval of the version 1 CIP Reliability Standards in Order No. 706, in which the Commission explained that the technical feasibility exceptions “must be governed by a clear set of criteria.” [72 ]

4. NERC proposed the use of the phrase per system capability after recognizing the significant administrative burden the technical feasibility exception process places on responsible entities and the Regional Entities. [73 ] While NERC's proposed per system capability exception language does reduce the administrative burden placed on responsible entities and Regional Entities, we find that currently it lacks clearly defined parameters in which responsible entities can invoke a per system capability exception. We determine that the lack of clearly defined parameters for invoking a per system capability exception denies the Commission, the ERO Enterprise, and responsible entities the certainty needed to oversee, administer, and participate in the per system capability exception program, respectively.

5. We are not persuaded by arguments that the Commission should rely solely on NERC's Compliance Monitoring and Enforcement Program engagements, such as compliance audits and spot-checks of responsible entities, to provide adequate oversight of the use of the per system capability language. Moreover, at the outset of the self-implementing exception program, there is no track record on the circumstances in which responsible entities will invoke per system capability exceptions or parameters for acceptable mitigation measures implemented by responsible entities as an alternative to strict compliance with the CIP Requirements where a per system capability exception will be invoked. We are not assuaged by the statements of NERC and other commenters that the per system capability language will simply carry on the legacy exceptions from the technical feasibility exception program, [74 ] as the proposed CIP Standards add per system capability language to six additional CIP Standards that previously lacked exception language. [75 ] Moreover, while NERC asserts that per system capability necessarily encompasses alternative mitigation actions that achieve the underlying objective of a CIP Requirement, [76 ] an express obligation for alternative mitigation does not appear in the CIP Standards or other NERC documents (e.g., the NERC Glossary or the NERC Rules of Procedure) other than NERC's petition and NOPR comments.

6. In light of these uncertainties surrounding the self-implementing exception process, we determine that greater oversight is needed than proposed by NERC. Exclusive reliance on audits and other compliance tools will not necessarily ensure timely feedback on basic information such as how many exceptions are being invoked and for what CIP Requirements, and the alternative mitigation measures implemented. Further, documentation of the exception process is needed to eliminate potential confusion and better assure consistent usage among responsible entities relying on the per system capability exception and across the Regional Entities when conducting audits and other compliance activities.

7. Consequently, we direct NERC to develop a program for the per system capability exceptions to satisfy the fundamental needs for oversight, consistency, and alternative mitigation. We decline to adopt any specific proposal offered by commenters. Rather, we allow NERC the latitude to develop a program provided that it includes the following three elements: (1) a clear set of criteria that promote consistency and ensure that responsible entities understand the parameters for invoking the per system capability exception, documentation requirements, [77 ] and the obligation to implement alternative mitigation; (2) mandatory reporting requirements to the ERO Enterprise (i.e., the relevant Regional Entity, NERC, or both) for responsible entities that invoke the per system capability language; and (3) submission of an annual report to the Commission that includes anonymized, aggregated data that indicates how entities are utilizing the exception language. We discuss each of these elements below.

8. First, NERC must develop a clear set of criteria that promote consistency and ensure that responsible entities understand the parameters for invoking the per system capability exception, documentation requirements, and the obligation to implement alternative mitigation. As mentioned earlier, while NERC discusses these elements in its petition and comments in this docket, there is no NERC document that provides responsible entities, Regional Entities, and the Commission a comprehensive understanding of the expectations of the per system capability process. We believe that clear guidance is vital to ensure (1) that responsible entities properly identify, document and mitigate per system capability exceptions and (2) consistency across Regional Entities when conducting audits and other compliance activities.

9. NERC has the discretion to choose an appropriate format to develop the required criteria, e.g., changes to the NERC Rules of Procedure, development of new or modified guidance documents, or modifications to the CIP Reliability Standards. We also direct NERC to ensure the per system capability exception program with the above criteria is available in time for the early adoption of the 11 proposed CIP Reliability Standards by responsible entities that choose to comply early. [78 ] This approach will ensure that the program is in place by the time responsible entities are self-implementing per system capability exceptions.

10. Second, the ERO Enterprise must develop mandatory reporting requirements through a request for data—through Align or another reporting mechanism—on basic information from entities using the per system capability exceptions, including the relevant CIP Reliability Standard ( printed page 13963) and Requirement, an explanation of the need for the exception, description of alternative mitigation, and any other fields of information that NERC determines are useful for monitoring exceptions. To be clear, while we direct the ERO to collect data on the exceptions, we do not require an approval process akin to the technical feasibility exception program. Moreover, as discussed earlier, legacy technical feasibility exceptions have been steady for a number of years and are well understood. [79 ] Therefore, NERC at its discretion may craft an appropriate less detailed data collection for legacy exceptions, while collecting more detailed information for newly invoked exceptions. This approach could provide the necessary insight into the volume and circumstances of new per system capability exceptions while reducing the burden with regard to legacy technical feasibility exceptions.

11. Third, NERC must submit an annual report to the Commission that provides adequate data and analysis on responsible entity usage of the per system capability exception for the Commission to fulfill its oversight role. Similar to reporting on technical feasibility exceptions directed in Order No. 706, NERC's annual report should provide an anonymized, aggregated, wide-area analysis. [80 ] The report must include at a minimum the following data:

• The total number of registered entities with active per system capability exceptions, the total number of reported per system capability exceptions that are still in effect (nationally and by region), and a comparison of these numbers over the previous reporting period;
• Categorization of active per system capability exceptions by applicable Requirements covered;
• Generalized discussion indicating the types of assets and/or systems for which new per system capability exceptions are claimed; and
• Discussion on types of mitigation measures employed. The report should include any other information or analysis that NERC believes will assist the Commission in understanding the usage and efficacy of the per system capability exception program.

1. The annual report should be filed with the Commission 12 months after compliance with the 11 virtualization Reliability Standards becomes mandatory. Initial annual reports will provide the Commission and NERC visibility into the exception process and help the Commission conduct oversight to ensure that the new process is appropriately implemented. We are open to revisiting the frequency of the reports to the Commission after the initial three reporting cycles, if it is shown that the per system capability exception process is adequately executed and supporting Bulk-Power System security.

C. NERC Glossary Definitions

1. NOPR

1. In the NOPR, the Commission proposed to approve NERC's petition as supplemented, including the package of four proposed new definitions and 18 modified definitions in the NERC Glossary, as just, reasonable, not unduly discriminatory or preferential, and in the public interest. The Commission stated that the proposed new and modified definitions should provide a clear and consistent understanding of the terms across all Reliability Standards. [81 ]

2. Comments

1. Commenters generally support approval of NERC's package of 11 Reliability Standards without mentioning the four proposed new definitions and 18 modified definitions in the NERC Glossary. [82 ] GE Vernova states that modernizing the definitions “will enable utilities to adopt virtualized designs.” [83 ]

3. Commission Determination

1. Pursuant to section 215(d)(2) of the FPA, we approve the proposed four new definitions and 18 modified definitions in the NERC Glossary. We find that the proposed new and modified definitions will establish a consistent understanding of the meaning of those terms across Reliability Standards. Additionally, we find that the package of proposed new and revised definitions and proposed Reliability Standards will allow responsible entities the opportunity to adopt virtualization, improving the reliability of the Bulk-Power System by providing significant cyber security benefits and flexibility in responding to cyber threats.

III. Information Collection Statement

1. The Commission bases its paperwork burden estimates on the additional paperwork burden presented by the revisions to Reliability Standards that the Commission has approved. The approved revisions focus on security objectives rather than specific controls for system security management to accommodate virtualized environments. The Reliability Standards approved by this final rule are objective-based and allow registered entities to choose compliance approaches best tailored to their systems. The Reliability Standards approved by this final rule will allow responsible entities the opportunity to take advantage of the benefits of advanced virtualization features while also preserving their choice to maintain current secure perimeter-based network architecture, which continues to be a valid network security model.

2. The Reliability Standards approved by this final rule do not require responsible entities to submit any filings with either the Commission or NERC as the ERO. Responsible entities, however, will be required to maintain documentation adequate to demonstrate compliance with the Reliability Standards approved by this final rule. Commission and NERC staff conduct periodic audits of registered entities, and auditors rely on the entity's documentation in determining compliance with Reliability Standards. While registered entities retain flexibility on how they choose to demonstrate compliance, the Reliability Standards include Compliance Measures providing examples of the type of documentation an entity may want to develop and maintain to demonstrate compliance. The reporting burden below is based on the Compliance Measures provided in the Reliability Standards approved by this final rule.

3. As of June 2025, the NERC Compliance Registry identifies approximately 1,673 unique U.S. entities that are subject to mandatory compliance with CIP Reliability Standards. All 1,673 entities would need to conform to modifications in Reliability Standard CIP-002-7. However, as stated in the NERC petition, the revisions in Reliability Standard CIP-002-7 are minor, mostly aligning the standard with updates to ( printed page 13964) the NERC Glossary. [84 ] Therefore, we do not envision an increased paperwork burden specifically pertaining to any modifications in Reliability Standard CIP-002-7. However, of the 1,673 total entities, we estimate that 400 entities will face an increased paperwork burden under the revisions in Reliability Standards 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. Based on these assumptions, the estimated reporting burden is as follows:

| | Number of
respondents | Annual number of responses per
respondent | Total number of
responses | Average burden & cost per

                            response 86 | Total annual
                         burden hours & 
                         total annual cost | Cost per
                         respondent 
                         ($) |

| --- | --- | --- | --- | --- | --- | --- |
| | (1) | (2) | (1) * (2) = (3) | (4) | (3) * (4) = (5) | (5) ÷ (1) |
| Conforming to modifications proposed under Reliability Standard CIP-002-7 | 1,673 | 1 | 1,673 | The Commission does not anticipate any material information collection costs associated with CIP-002-7 | The Commission does not anticipate any material information collection costs associated with CIP-002-7 | The Commission does not anticipate any material information collection costs associated with CIP-002-7. |
| Update compliance related documentation of one or more process(es) pertaining to proposed Reliability Standards: 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 | 400 (per standard) | 1 | 400 (per standard) | 57.7 hrs. (Burden per Response per Respondent); $4,905 (Cost per Response per Respondent) | 23,080 hrs. (Burden per Response across all Respondents); $1,961,800 (Cost per Response across all Respondents) | $4,905 (Cost per Response per Respondent). |
| Total burden | | | 4,000 | 577 hrs | 230,800 hrs.; $19,618,000 | $49,045. |
The estimated responses and burden hours for Years 1-3 will total respectively as follows:

• Year 1-3 total: 400 responses; 23,080 hours for each CIP Standard. The estimated annual cost burden for each year One to Three is $6,539,333.

1. Title: Mandatory Reliability Standards, Revised Critical Infrastructure Protection Reliability Standards

Action: Revision to FERC-725B information collection.

OMB Control No.: 1902-0248.

Respondents: Businesses or other for-profit institutions; not-for-profit institutions.

Frequency of Responses: On occasion.

Necessity of the Information: This final rule approves the requested modifications to Reliability Standards pertaining to critical infrastructure protection. As discussed above, the Commission approves proposed 11 virtualization Reliability Standards pursuant to section 215(d)(2) of the FPA because it allows responsible entities the opportunity to adopt virtualization, improving the reliability of the Bulk-Power System by providing significant cyber security benefits and flexibility in responding to cyber threats.

Internal Review: The Commission has reviewed the proposed Reliability Standards and made a determination that its action is necessary to implement section 215 of the FPA.

1. Interested persons may obtain information on the reporting requirements by contacting the following: Federal Energy Regulatory Commission, 888 First Street NE, Washington, DC 20426 [Attention: Kayla Williams, Office of the Executive Director, email: DataClearance@ferc.gov, phone: (202) 502-8663, fax: (202) 273-0873].

2. For submitting comments concerning the collection(s) of information and the associated burden estimate(s), please send your comments to the Commission, and to the Office of Management and Budget, Office of Information and Regulatory Affairs, Washington, DC 20503 [Attention: Desk Officer for the Federal Energy Regulatory Commission, phone: (202) 395-4638, fax: (202) 395-7285]. For security reasons, comments to the Office of Management and Budget should be submitted by email to: oira_submission@omb.eop.gov. Comments submitted to the Office of Management and Budget should include Docket Number RM24-8-000 and OMB Control Number 1902-0248.

IV. Environmental Analysis

1. The Commission is required to prepare an Environmental Assessment or an Environmental Impact Statement for any action that may have a significant adverse effect on the human environment. [87 ] The Commission has categorically excluded certain actions from this requirement as not having a significant effect on the human environment. Included in the exclusion are rules that are clarifying, corrective, or procedural or that do not substantially change the effect of the regulations being amended. [88 ] The action approved herein falls within this categorical exclusion in the Commission's regulations.

V. Regulatory Flexibility Act

1. The Regulatory Flexibility Act of 1980 (RFA) [89 ] generally requires a description and analysis of final rules ( printed page 13965) that will have significant economic impact on a substantial number of small entities. The Small Business Administration's (SBA) Office of Size Standards develops the numerical definition of a small business. [90 ] The SBA revised its size standard for electric utilities (effective March 17, 2023) to a standard based on the number of employees, including affiliates (from the prior standard based on megawatt hour sales). [91 ]

2. The SBA sets the threshold for what constitutes a small business. Under SBA's size standards, transmission owners all fall under the category of Electric Bulk Power Transmission and Control (NAICS code 221121), with a size threshold of 950 employees (including the entity and its associates). Based on the NERC Compliance Registry, we have selected a combination of 288 Generator Owners (GO) and Generator Operators (GOP) as applicable entities and we have determined that approximately 87% GOs and 67% GOPs of the listed entities are small entities (i.e., with fewer than 950 employees).

3. According to SBA guidance, the determination of significance of impact “should be seen as relative to the size of the business, the size of the competitor's business, and the impact the regulation has on larger competitors.” [92 ]

4. Moreover, this final rule approves Reliability Standards that permit voluntary actions by registered entities for the purpose of accommodating virtualized environments. The Reliability Standards approved in this final rule do not mandate or require action by any registered entity other than updating compliance documentation for processes related to the approved Reliability Standards. As a result, we certify that the Reliability Standards approved in this final rule will not have a significant economic impact on a substantial number of small entities. Accordingly, no regulatory flexibility analysis is required.

VI. Document Availability

1. In addition to publishing the full text of this document in the Federal Register, the Commission provides all interested persons an opportunity to view and/or print the contents of this document via the internet through the Commission's Home Page (http://www.ferc.gov).

2. From the Commission's Home Page on the internet, this information is available on eLibrary. The full text of this document is available on eLibrary in PDF and Microsoft Word format for viewing, printing, and/or downloading. To access this document in eLibrary, type the docket number excluding the last three digits of this document in the docket number field.

3. User assistance is available for eLibrary and the Commission's website during normal business hours from FERC Online Support at 202-502-6652 (toll free at 1-866-208-3676) or email at ferconlinesupport@ferc.gov, or the Public Reference Room at (202) 502-8371, TTY (202) 502-8659. Email the Public Reference Room at public.referenceroom@ferc.gov.

VII. Regulatory Planning and Review

1. Executive Orders 12866 and 13563 direct agencies to assess the costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). Executive Order 13563 emphasizes the importance of quantifying both costs and benefits, of reducing costs, of harmonizing rules, and of promoting flexibility. The Office of Information and Regulatory Affairs (OIRA) has determined this regulatory action is not a “significant regulatory action,” under section 3(f) of Executive Order 12866, as amended. Accordingly, OIRA has not reviewed this regulatory action for compliance with the analytical requirements of Executive Order 12866.

VIII. Effective Date and Congressional Notification

1. This final action is effective May 26, 2026. The Commission has determined, with the concurrence of the Administrator of the Office of Information and Regulatory Affairs of the Office of Management and Budget, that this action is not a “major rule” as defined in section 351 of the Small Business Regulatory Enforcement Fairness Act of 1996.

By the Commission.

Issued: March 19, 2026.

Carlos D. Clay,

Deputy Secretary.

Footnotes

1. 16 U.S.C. 824o(d)(2).

Back to Citation 2.

                     
                    See 
                     NERC Petition at 2-5.

Back to Citation 3. Virtualization Reliability Standards, Notice of Proposed Rulemaking, 90 FR 45679 (Sept. 23, 2025), 192 FERC ¶ 61,228 (NOPR).

Back to Citation 4.

                     NERC Petition at 2.

Back to Citation 5. Id.

Back to Citation 6.

                     
                    See 
                     NERC Rules of Procedure, app. 4(d) (Procedure for Requesting and Receiving Technical Feasibility Exceptions to NERC Critical Infrastructure Protection Standards), Section 3.0 (setting forth circumstances in which a technical feasibility exception may be warranted). *See also id.* Section 3.2 (“[A] TFE authorizes an alternative (to Strict Compliance) means of compliance with the Applicable Requirement through the use of compensating measures and/or mitigating measures that achieve at least a comparable level of security.”).

Back to Citation 7.

                     While NERC does not propose to define the term per system capability for the NERC Glossary, NERC explains in its Petition that “[t]he phrase `per system capability' means that if a Responsible Entity can demonstrate that the applicable system is incapable of performing a required action (*e.g.,* a firmware-based “black box” device with limited configuration capabilities),” then the responsible entity does not have to meet the CIP Requirement and will determine on its own an equally effective alternative mitigation measure. NERC Petition at 46-47.

Back to Citation 8.

                     
                    See 
                     NOPR, 192 FERC ¶ 61,228 at PP 21-26.

Back to Citation 9. 16 U.S.C. 824o(c).

Back to Citation 10. Id. 824o(e).

Back to Citation 11. Rules Concerning Certification of the Elec. Reliability Org.; & Procs. for the Establishment, Approval, & Enf't of Elec. Reliability Standards, Order No. 672, 71 FR 8662 (Feb. 17, 2006), 114 FERC ¶ 61,104, order on reh'g, Order No. 672-A, 71 FR 19814 (Apr. 18, 2006), 114 FERC ¶ 61,328 (2006); see also 18 CFR 39.4(b).

Back to Citation 12. N. Am. Elec. Reliability Corp., 116 FERC ¶ 61,062, order on reh'g and compliance, 117 FERC ¶ 61,126 (2006), aff'd sub nom. Alcoa, Inc. v. FERC, 564 F.3d 1342 (D.C. Cir. 2009).

Back to Citation 13. See Virtualization & Cloud Computing Servs., Notice of Inquiry, 170 FERC ¶ 61,110, at P 4 (2020) (citing NIST Virtualization Security Special Publication).

Back to Citation 14.

                     NOPR, 192 FERC ¶ 61,228 at P 5 (citing NERC Petition at 13).

Back to Citation 15. Id.

Back to Citation 16. Id.

Back to Citation 17.

                     NERC Rules of Procedure, app. 4(d), § 3.2.

Back to Citation 18. Critical Infrastructure Protection, Order No. 706, 73 FR 7368 (Feb. 7, 2008), 122 FERC ¶ 61,040, at P 181, order on clarification, Order No. 706-A, 123 FERC ¶ 61,174 (2008), order on clarification, Order No. 706-B, 74 FR 12544 (Mar. 25, 2009), 126 FERC ¶ 61,229, order deny'g request for clarification, Order No. 706-C, 74 FR 30067 (Jun. 24, 2009), 127 FERC ¶ 61,273 (2009)).

Back to Citation 19.

                     NOPR, 192 FERC ¶ 61,228 at P 19 (citing Order No. 706, 122 FERC ¶ 61,040 at PP 192-194, 209-211, 222).

Back to Citation 20.

                     NERC Rules of Procedure, app. 4(d), § 3.0.

Back to Citation 21.

                     On May 20, 2025, NERC submitted a supplemental petition identifying errata to proposed Reliability Standards CIP-006-7, CIP-007-7, CIP-008-7, CIP-009-7, and CIP-011-4, as well as additional justifications for technical concepts within the proposed Standards.

Back to Citation 22.

                     The proposed Reliability Standards are not attached to this final rule. The proposed Reliability Standards are available on the Commission's eLibrary document retrieval system in Docket No. RM24-8-000 and on the NERC website, *[www.nerc.com](http://www.nerc.com/).*

Back to Citation 23.

                     The 18 defined terms subject to revision include: BES Cyber Asset, BES Cyber System, BES Cyber System Information, CIP Senior Manager, Cyber Assets, Cyber Security Incident, Electronic Access Control or Monitoring Systems, Electronic Access Point, External Routable Connectivity, Electronic Security Perimeter, Interactive Remote Access, Intermediate System, Physical Access Control Systems, Physical Security Perimeter, Protected Cyber Asset, Removable Media, Reportable Cyber Security Incident, and Transient Cyber Asset.

Back to Citation 24.

                     
                    See 
                     NERC Petition at 2. In addition to the virtualization-related modifications in the proposed Reliability Standards, NERC included administrative revisions throughout the proposed Reliability Standards. For example, some revisions aligned the proposed Reliability Standards to other Standards or NERC initiatives. *Id.* at 55-56.

Back to Citation 25.

                     On December 20, 2024, NERC submitted a petition for approval of the modification of the definition of control center in the NERC Glossary and Reliability Standard CIP-002-8 (Cyber Security—BES Cyber System Categorization). We are approving the proposed control center definition and proposed Reliability Standard CIP-002-8 in a concurrent order. *N. Am. Elec. Reliability Corp.,* 194 FERC 61,211 (2026).

Back to Citation 26.

                     On December 20, 2024, NERC submitted a petition for approval of proposed Reliability Standard CIP-003-11 (Cyber Security—Security Management Controls). We are approving proposed Reliability Standard CIP-003-11 in a concurrent order. *Critical Infrastructure Protection Reliability Standard CIP-003-11,* 194 FERC ¶ 61,210 (2026).

Back to Citation 27.

                     
                    See 
                     NERC Supp. Petition at 3 (making errata corrections to several CIP Standards, designated with a “.1” in the version number, *e.g.,* CIP-006-7.1).

Back to Citation 28.

                     NERC Petition at 4.

Back to Citation 29. Id. at 5.

Back to Citation 30. Id.

Back to Citation 31. Id. at 28-29.

Back to Citation 32. Id. at 46-47.

Back to Citation 33. Id. at 29.

Back to Citation 34.

                     NERC Supp. Petition at 26.

Back to Citation 35.

                     NERC Petition at 59-60.

Back to Citation 36.

                     NOPR, 192 FERC ¶ 61,228 at P 1.

Back to Citation 37. Id. P 2.

Back to Citation 38. Id. P 3.

Back to Citation 39. Id. PP 24-26.

Back to Citation 40. Id. P 17.

Back to Citation 41. Id.

Back to Citation 42.

                     
                    See 
                     BPA Comments at 1; EEI Comments at 3; GE Vernova at 1; MISO Comments at 1; NERC Comments at 2; PGE Comments at 1 (supporting the entirety of EEI Comments).

Back to Citation 43.

                     EEI Comments at 3; NERC Comments at 2.

Back to Citation 44.

                     EEI Comments at 3.

Back to Citation 45.

                     NOPR, 192 FERC ¶ 61,228 at P 20.

Back to Citation 46. Id. P 21.

Back to Citation 47. Id. P 26.

Back to Citation 48.

                     BPA Comments at 1; EEI Comments at 1, 5; MISO Comments at 2; MRO NSRF Comments at 1; *see also* PGE Comments at 2 (stating its preference for per system capability exceptions).

Back to Citation 49.

                     EEI Comments at 5.

Back to Citation 50.

                     
                    See 
                     MRO NSRF Comments at 1.

Back to Citation 51.

                     BPA Comments at 3.

Back to Citation 52.

                     EEI Comments at 1; MRO NSRF Comments at 2; PGE Comments at 4.

Back to Citation 53.

                     EEI Comments at 4. EEI states that responsible entities must seek re-approval when adding assets to an existing technical feasibility exception, even when mitigation strategies remain unchanged. *Id. See also* MRO NSRF Comments at 4.

Back to Citation 54.

                     EEI Comments at 3.

Back to Citation 55.

                     MISO Comments at 3.

Back to Citation 56.

                     NERC Comments at 3. NERC maintains that the terminology “does not act like an exception” because the language “does not absolve an entity from implementing methods to achieve the security objective for applicable systems.” *Id.*

Back to Citation 57.

                     MISO Comments at 4.

Back to Citation 58.

                     NERC Comments at 4-5.

Back to Citation 59.

                     EEI Comments at 5.

Back to Citation 60. Id.

Back to Citation 61.

                     MISO Comments at 4-5.

Back to Citation 62. Id. at 5.

Back to Citation 63. Id. at 6.

Back to Citation 64.

                     EEI Comments at 6-7; MRO NSRF Comments at 3. *See also* BPA Comments at 4.

Back to Citation 65.

                     NERC Comments at 6.

Back to Citation 66.

                     Both EEI and MRO NSRF provide the same example: when installing a new physical access control systems door controller panel in a newly established physical security perimeter, the same technical feasibility exceptions conditions and mitigations apply. EEI Comments at 7; MRO NSRF Comments at 4.

Back to Citation 67.

                     PGE Comments at 3-4.

Back to Citation 68.

                     EEI Comments at 5; MRO NSRF Comments at 1.

Back to Citation 69.

                     BPA Comments at 3.

Back to Citation 70.

                     EEI Comments at 4; MRO NSRF Comments at 4.

Back to Citation 71.

                     NOPR, 192 FERC ¶ 61,228 at PP 19-21, 25.

Back to Citation 72.

                     Order No. 706, 122 FERC ¶ 61,040 at P 209.

Back to Citation 73.

                     
                    See 
                     NERC Petition at 29.

Back to Citation 74.

                     NERC Comments at 4-5.

Back to Citation 75.

                     
                    See 
                     NOPR, 192 FERC ¶ 61,228 at P 15. *See also* EEI Comments at 5 (“Some existing and emerging technologies cannot fully meet certain CIP requirements due to inherent design limitations.”).

Back to Citation 76.

                     NERC Comments at 4.

Back to Citation 77.

                     The documentation requirements in this element may be more extensive than the mandatory reporting requirements to the ERO in the second element.

Back to Citation 78.

                     NERC Petition at 59-60.

Back to Citation 79.

                     
                    See 
                     NERC Comments at 4. *See also* NERC, *Annual Report of the North American Electric Reliability Corporation on Wide-Area Analysis of Technical Feasibility Exceptions,* Docket Nos. RR10-1-000 & RR13-3-000, at 5 (filed Sept 26, 2025) (“The data . . . indicates that the number of registered entities that are engaging in the TFE program remains stable from prior reporting years.”).

Back to Citation 80.

                     Order No. 706, 122 FERC ¶ 61,040 at PP 220-221.

Back to Citation 81.

                     NOPR, 192 FERC ¶ 61,228 at P 17.

Back to Citation 82.

                     BPA Comments at 1; EEI Comments at 3; PGE Comments at 1 (supporting the entirety of EEI Comments).

Back to Citation 83.

                     GE Vernova Comments at 1. The rest of GE Vernova's comments recommend that the final rule explicitly address issues associated with cloud deployment models, which are outside of the scope of this proceeding and thus not considered.

Back to Citation 84.

                     NERC Petition at 38.

Back to Citation 85.

                     The paperwork burden estimate includes costs associated with the initial development of a policy to address the requirements.

86.

                     This burden applies in Year One to Year Three.

The loaded hourly wage figure (includes benefits) is based on the average of three occupational categories for May 2024 Wages found on the Bureau of Labor Statistics website (http://www.bls.gov/​oes/​current/​naics2_​22.htm). The loaded hourly wage includes fringe benefits divided by 81.70 percent. See https://data.bls.gov/​oes/​#/​industry/​000000:

Legal Occupations (90th percentile) (Occupation Code: 23-0000): $140.76.

Electrical Engineer (mean) (Occupation Code: 17-2071): $71.19.

Office and Administrative Support (90th percentile) (Occupation Code: 43-0000): $43.83.

($140.76 + $71.19 + $43.83) ÷ 3 = $85.26.

The figure is rounded to $85.00 for use in calculating wage figures in this final rule.

Back to Citation 87. Reguls. Implementing the Nat'l Env't Pol'y Act, Order No. 486, 52 FR 47897 (Dec. 17, 1987), FERC Stats. & Regs. Preambles 1986-1990 ¶ 30,783 (1987) (cross-referenced at 41 FERC ¶ 61,284).

Back to Citation 88. 18 CFR 380.4(a)(2)(ii).

Back to Citation 89. 5 U.S.C. 601-612.

Back to Citation 90. 13 CFR 121.101.

Back to Citation 91. 13 CFR 121.201, Subsector 221 (Utilities).

Back to Citation 92.

                     U.S. Small Business Admin., *A Guide for Government Agencies How to Comply with the Regulatory Flexibility Act,* 18 (Aug. 2017), *[https://advocacy.sba.gov/​wp-content/​uploads/​2019/​06/​How-to-Comply-with-the-RFA.pdf](https://advocacy.sba.gov/wp-content/uploads/2019/06/How-to-Comply-with-the-RFA.pdf).*

Back to Citation [FR Doc. 2026-05716 Filed 3-23-26; 8:45 am]

BILLING CODE 6717-01-P

Published Document: 2026-05716 (91 FR 13957)