Does 'per system capability' end the CIP TFE process?
Order No. 919 replaces 'where technically feasible' with 'per system capability' in the 2028 virtualization set, and FERC directed NERC to build criteria for invoking it, mandatory reporting to the ERO Enterprise, and an annual anonymized report to FERC. A registered entity that holds TFEs today, or expects to need one under a virtualized environment, should not read that wording change as an automatic exit from the TFE process. The 11 revised standards are FERC-approved and listed by NERC as effective 1 July 2028, but until that date existing TFEs remain governed by Appendix 4D of the NERC Rules of Procedure. Whether a given TFE falls away, moves to the new mechanism or needs to be re-justified depends on which standards and requirements the entity applies to. Confirm that mapping with NERC's published implementation materials and with your Regional Entity before planning around it.
The organization owns the decision and the justification in either case. Under Appendix 4D, the burden of justifying a request sits with the Responsible Entity, and an approved exception still requires compensating or mitigating measures that achieve at least a comparable level of security. Under the 'per system capability' approach, the criteria NERC develops will define when the exception can be invoked and what must be recorded and reported. Those criteria are the document to track. Ask your compliance lead to identify each current TFE by requirement part and system, then note which ones touch the 2028 virtualization standards, such as CIP-005, CIP-007 and CIP-010.
An independent auditor or the Compliance Enforcement Authority tests the result, not the wording. Expect the reviewer to ask for the system-level capability assessment, the compensating controls, the evidence those controls operate, and the reporting trail. Assemble that evidence per system now, while the existing TFE files are still the operative record. Where NERC's build-out details are not yet final, treat them as open items to confirm rather than as settled requirements.
What FERC asked NERC to build around the new exception
FERC's Order No. 919 directs NERC to build three layers around 'per system capability': criteria for when entities may invoke it, mandatory reporting to the ERO Enterprise, and an annual anonymized report to FERC. Together they replace the open-ended feasibility language with a checkable process. The detailed criteria and forms are NERC's to publish, so confirm them with NERC and your Regional Entity.
Confirm the criteria for invoking the exception
NERC is directed to develop criteria that define when a Responsible Entity may rely on 'per system capability' in place of a full requirement. These criteria set the threshold an entity must show before it can claim the exception for a given system. The output to expect is a published criteria document or procedure from NERC, which becomes the test you measure each affected system against. Until that document is final, confirm its status and scope directly with NERC and your Regional Entity rather than assuming the criteria match the old TFE eligibility list.
Map affected systems against the criteria
Before invoking the exception, the entity identifies which BES Cyber Systems, EACMS, PACS and PCA would need it and tests each one against the published criteria. The output is a system-by-system record showing which requirement parts apply, whether the criteria are met, and what evidence supports the claim. This record is the entity's own work product, prepared by its staff or an implementation partner, and it should be reviewed by compliance leadership before any reporting begins.
Document compensating or alternative measures
Where a system meets the criteria, the entity documents how it will still protect the system, including any compensating or alternative measures it applies in place of the full requirement part. The output is a written description of each measure, the reason the requirement cannot be met as written, and how the measure preserves the security intent. Ask your Regional Entity which documentation format it expects, because the detailed content requirements are set in NERC's forthcoming procedures.
Report use of the exception to the ERO Enterprise
Order No. 919 requires mandatory reporting of use of the exception to the ERO Enterprise, which includes NERC and the Regional Entities. The entity submits its reports through the channel and on the schedule NERC specifies. The output is an accepted submission on record with the Regional Entity, and the entity should keep a copy with its evidence package. Confirm the reporting form, frequency and portal with NERC and your Regional Entity, since these details are not set out in the researched facts.
Track exception use through the audit period
Because reporting is mandatory, the entity needs an internal register of every system where the exception is in use, with dates, criteria checks and reports submitted. The output is a current register that matches the reports on file and can be produced during a Compliance Audit, Spot Check or Self-Certification. Auditors will compare the register with the submissions, so gaps between the two are a common source of findings. Review the register whenever a system's status changes.
Support NERC's annual anonymized report to FERC
Order No. 919 directs NERC to prepare an annual anonymized report to FERC on use of the exception. Entities do not file this report, but their reporting feeds the aggregate data it draws on. The output for the entity is a consistent record that supports the aggregate picture, and entities should confirm with NERC how the anonymization is handled and what identifying detail is removed. Keep the records accurate, because the annual report can only be as reliable as the submissions behind it.
What happens to existing TFEs under each scenario
An approved TFE on a requirement that the 2028 standards revise is tied to wording that will no longer be in force on that date. The revised standard may change the qualifying phrase, the parts that carry it, or how the obligation is measured, so an exception written against current language may not map cleanly to new language. The Regional Entity decides how the approval carries forward, so treat the mapping as an open question for that office to answer.
- Current approval terms: Pull the approved TFE and confirm the requirement part, the alternative measures and any stated end date.
- Revised text: Compare each affected part against its 2028 counterpart and note any change to the qualifying phrase or the measured obligation.
- Transition treatment: Ask in writing whether the TFE continues, is reviewed, expires, or must be replaced by a per system capability justification on the effective date.
- Compensating measures: Keep records showing the alternative measures still achieve a comparable level of security under the revised wording.
Confirm every transition answer in writing with the Regional Entity before the 1 July 2028 effective date, because an assumption made during planning carries no weight in an audit.
Where the revisions leave a requirement untouched, the approved exception usually still rests on the same text. That does not make the exception self-renewing. Approvals run under the procedure in Appendix 4D of the NERC Rules of Procedure, and each approval carries its own terms, so the expiry and reporting conditions in the approval letter still govern your position.
- Expiry and renewal: Confirm whether the TFE has an end date and what renewal or reporting it requires.
- Surrounding definitions: Check how the revised Control Center definition in CIP-002-8, effective 1 July 2028, affects which systems the exception covers.
- Scope drift: Verify that any system added, virtualized or moved since approval still falls within the approved scope.
- Evidence trail: Keep compensating measure records current, including configuration baselines, monitoring output and access logs, so an auditor can test them.
Ask the Regional Entity to confirm in writing that an unchanged exception carries forward unchanged, including the effect of any change to defined terms.
An entity with no approved TFEs has no transition exception to rely on. Requirement text as written applies, so the 2028 wording governs compliance from its effective date for every system in scope. The absence of an exception is also a position that should be documented, because an auditor will ask how each requirement was met.
- Applicable parts: Record which requirement parts apply to each system, so you can show that no exception is needed for the current environment.
- Early gap decisions: If a system cannot meet a qualifying requirement, document the gap now and ask the Regional Entity whether a TFE or per system capability path applies before the effective date.
- Criteria development: Track NERC's work on the criteria for invoking per system capability and the reporting duties that Order No. 919 directed, since these will shape any future request.
- Eligibility review: Check the current TFE eligibility list to see whether any listed parts appear in your environment at all.
Confirm with your Regional Entity whether any interim obligation or the 2028 timeline applies to your systems, and get that answer in writing.
How to prepare an inventory of TFE-dependent systems now
The 2028 virtualization standards replace "where technically feasible" with "per system capability," so any system you currently cover with a TFE needs a documented answer before that date. The four to six items below are parallel steps that build one inventory, and each one produces evidence an auditor will ask to see. DeployOpen can help prepare the systems and records, but the organization makes the determinations and an independent auditor or the Regional Entity judges the result.
Inventory every feasibility-qualified requirement
Start with a list of every CIP requirement your program relies on that is qualified by "where technically feasible," then list the BES Cyber Systems, EACMS, PACS and PCA each one covers. The NERC eligibility list for TFEs names specific parts in CIP-005, CIP-006, CIP-007 and CIP-010, so check those first. Record the asset, the part, the owner and whether a TFE is currently approved. Confirm the list against your own CIP-002 categorization, not from memory.
Map each item to its 2028 standard
For each inventoried item, identify the revised standard version that will apply from 1 July 2028, such as CIP-005-8 or CIP-007-7.1, and compare the requirement text side by side with the current version. Note where "per system capability" replaces the older phrase and where the requirement itself changes. Flag any item where the mapping is unclear so it can be raised with the Regional Entity or your compliance counsel early.
Document the technical limitation
For each system, write down what prevents full compliance, supported by engineering evidence such as vendor documentation, configuration records, firmware versions, test results and change tickets. Describe the limitation in terms of the specific system and not the general product line. Include who evaluated it and when. Under the TFE process the burden of justifying the request sits with the Responsible Entity, so treat this file as the proof you would need to show, even though the "per system capability" criteria are still being built by NERC.
Define compensating controls and monitoring evidence
For each limitation, define the compensating or mitigating measures you would use and the logs, alerts or reports that show they operate. Examples include network segmentation, restricted access paths, additional monitoring and documented manual review. Ask whether each measure gives at least a comparable level of security, and record that reasoning. Assign a retention period for the monitoring evidence that covers the audit period, and confirm it with your auditor or Regional Entity.
Assign owners and review dates
Every inventory row needs a named accountable owner, a technical owner for the system and a review date. Set review dates that fall before the 2028 effective date and recur afterward, so changes to firmware, virtualization platforms or vendor support update the record. Tie reviews to change management so a system that gains or loses a limitation is reflected in the inventory. Keep a record of who approved each entry and when.
Set a go or no-go replacement plan
For each system, decide whether it will be upgraded, replaced, isolated or retained with a documented limitation. Set a go or no-go gate that states what evidence would trigger each choice, such as vendor support for a required capability or a successful test. Include procurement lead times and outage windows in the plan, and ask suppliers for written statements of their capabilities. Revisit any system marked no-go at each review date so the decision stays current.
What drives the effort of moving off TFEs
Moving from a Technical Feasibility Exception to a per system capability position is less a single project than a set of linked workstreams. The drivers below determine how much work lands on engineering, procurement, operations and compliance, and each one is controlled by decisions the Responsible Entity makes early.
Affected systems and impact categories
The number of BES Cyber Systems, EACMS, PACS and PCAs that rely on a TFE today sets the size of the whole effort. Work on a high impact Control Center differs from work on a medium impact substation with External Routable Connectivity, so start by listing each affected system with its CIP-002 categorization. Check which TFE-eligible parts (such as CIP-005 R2 remote access or CIP-010 R1 Part 1.5) apply to each system. Narrowing the list before design begins usually reduces work more than any other single step.
Vendor support for the replacement
Many TFEs exist because a vendor product cannot run a required control. Whether the vendor now supports the control, or has a dated roadmap for it, determines whether the entity can meet the requirement directly or must keep a compensating measure. Ask each vendor in writing which capability it supports, in which firmware or software version, and what it requires for licensing and upgrades. Do not assume that a newer product line resolves an older device's limitation.
Engineering time to demonstrate capability
Under 'per system capability' the entity must show that a specific system can or cannot perform a control, so engineers need to test, document and record evidence for each system rather than rely on a general statement. Test results, configuration captures and vendor responses all become evidence. Plan for test environments that match production configurations, and confirm with the Regional Entity how much testing it expects before it accepts a capability determination. The cost is mostly internal labor and outside engineering time, and it recurs whenever a system is upgraded.
Compensating controls build and monitoring
Where a system cannot meet a control, the TFE model required an alternative means of compliance with at least comparable security, and the same engineering judgment will still be needed for any system that cannot meet its requirement. Each compensating measure needs to be built, operated and monitored, which adds recurring labor and tooling. Identify which measures monitor the gap, who reviews their output, and how alerts are logged. The burden of justifying the approach stays with the Responsible Entity.
Change control and testing windows
Changes to firmware, software, configurations or network paths on BES Cyber Systems have to go through the entity's change management process, and outages on operational systems can only happen in approved windows. Plan the sequence so that each system's upgrade or control change lands in a window that the operations team can support. Build a rollback plan for each change, and record the baseline before and after. Scheduling conflicts, not technical complexity, often set the calendar.
Reporting volume and regulator follow-up
Under Order No. 919, NERC must create criteria for the new exception, mandatory reporting to the ERO Enterprise and an annual anonymized report to FERC, so entities should expect reporting duties that did not exist for TFEs in the same form. Track each exception in a single register with its system, criteria applied, compensating measures and review dates. Confirm with the Regional Entity which fields it will require, since the final reporting format depends on NERC's implementation.
Who owns the decision, who prepares evidence, and who issues findings
The Responsible Entity owns the CIP program, including every decision to rely on a technical limitation instead of meeting a requirement as written. Under the Technical Feasibility Exception process in Appendix 4D of the NERC Rules of Procedure, the burden of justifying a request sits with the entity, and that burden does not move to a vendor or consultant when a system is later reviewed. The entity also owns the compensating or mitigating measures, the reporting to the ERO Enterprise and the records that show the decision was made by accountable people.
- Decision ownership: Leadership decides whether a system will rely on a limitation, and that decision is documented with its rationale and approver.
- Justification: The entity writes the technical basis, the alternative measures and the expected level of security, and it must be able to defend them.
- Reporting: The entity submits required reports and keeps the data behind them consistent with its asset inventory.
- Ongoing operation: The entity reviews the compensating measures, retires them when the limitation changes, and keeps them current as systems change.
Confirm with your Regional Entity which reporting and documentation expectations apply to your systems before you rely on any alternative approach.
An implementation partner such as DeployOpen can plan, configure, harden and document the systems that the entity relies on, and it can run technical testing that produces evidence. It works inside the entity's own infrastructure and prepares material the entity reviews and adopts. The partner does not decide whether a limitation is acceptable, does not approve a TFE or equivalent, and does not sign statements of compliance on the entity's behalf.
- System preparation: The partner configures the systems, documents baselines and implements the compensating measures the entity has chosen.
- Configuration evidence: The partner captures configuration exports, logs, test results and change records that show what is in place.
- Documentation drafts: The partner drafts procedures, justification write-ups and reporting templates for the entity to review, edit and approve.
- Testing: The partner runs security testing against the systems in scope and reports the results to the entity.
Ask any partner to state in writing which deliverables are drafts for your review and which decisions remain yours.
The Compliance Enforcement Authority, which is a Regional Entity or NERC, monitors compliance through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports, self-logging, data submittals and investigations. The Regional Entity reviews whether the entity's claims hold up against evidence, and it is the body that determines findings. There is no CIP certificate, so the output of monitoring is a finding or a disposition, not a badge that the entity can display.
- Testing claims: The auditor checks the justification, the alternative measures and the evidence against the requirement as written.
- Issuing findings: The Compliance Enforcement Authority issues findings, dispositions and any required mitigation.
- Evidence review: The auditor samples records, interviews staff and may request data through its evidence process.
- Scheduling: Audit timing follows Section 403.10.1 of the NERC Rules of Procedure for some entities and a risk-based schedule for others.
Check with your Regional Entity how it expects to receive and review TFE or per system capability documentation before any audit begins.
Questions about TFEs and 'per system capability'
Do existing TFEs stop on 1 July 2028?
Not automatically from the supplied facts, and the transition details should be confirmed with NERC and your Regional Entity. The 11 virtualization standards in FERC Order No. 919 are listed as effective 1 July 2028, and they are the standards that replace 'where technically feasible' with 'per system capability.' A Technical Feasibility Exception under Appendix 4D is an approved alternative means of compliance, and it does not relieve you of the requirement. Ask your Regional Entity how existing approvals carry forward once the revised standards take effect, and whether any filings or updates are needed before that date. Keep your current TFE records complete until you receive that answer in writing.
Does per system capability mean no more exceptions?
No. The phrase changes how the standard qualifies a requirement, but the supplied facts show that FERC directed NERC to build criteria for invoking it, mandatory reporting to the ERO Enterprise and an annual anonymized report to FERC. That means the qualification must be justified, documented and reported. Where a system truly cannot meet a requirement, you still need a documented basis and an alternative control with at least comparable security. Expect the burden of justification to remain with the Responsible Entity, as it does under the current TFE process. Confirm the final criteria with NERC before you rely on the new phrase in your program.
Who decides if a system can meet a requirement?
Your organization decides, and it must be able to show the decision to the Compliance Enforcement Authority. Under the current TFE process, the Responsible Entity bears the burden of justifying a request, and the Regional Entity reviews it. Under the 2028 standards, the criteria NERC develops will define what a valid per system capability qualification looks like. An implementation partner can prepare the technical analysis, system inventories and evidence, but only your registered entity can make the determination and accept the risk. Independent assessment bodies do not certify these decisions, and the Regional Entity is the authority that monitors them.
How much effort does this take and what drives it?
The supplied facts do not give a per-entity effort figure for this change, so ask NERC or your Regional Entity for the current estimate before you budget. Effort is driven mainly by the number of BES Cyber Systems and their EACMS, PACS and PCA that rely on qualified requirements, the number of requirement parts currently under a TFE, and how well your system inventory and baselines already document each system. Requirements with a long list of affected assets take more effort than a few well-documented exceptions. Recurring work includes annual reporting, reviewing compensating measures when systems change, and keeping evidence current for each Compliance Audit. Ask any provider to price the inventory, analysis, documentation and recurring reporting as separate line items.
Can we do this in-house?
Yes, if your staff have the CIP knowledge, system visibility and time to run the analysis and documentation themselves. Many registered entities keep ownership of the decisions and use outside help for specific tasks. The work includes mapping each system to its requirement parts, documenting technical limits, designing compensating measures, collecting evidence and preparing reporting for the ERO Enterprise. Check whether your team can maintain this on a recurring basis as systems change, not only for the first filing. A gap in any of these areas is usually where external help adds the most value. Whatever you decide, the registered entity remains accountable for the compliance outcome.
What should we ask a partner before signing?
Ask for a written scope that names the systems, requirement parts and deliverables covered, plus the evidence each deliverable will produce. Confirm that the partner prepares analysis and documentation but does not issue compliance determinations, reports or attestations, since only the registered entity and the Compliance Enforcement Authority hold those roles. Ask how the partner will track the final NERC criteria and Regional Entity guidance as they change, and whether ongoing support is offered as a separate retainer. DeployOpen works under fixed-scope agreements with scope, deliverables and timelines agreed in writing before work starts, and it prepares systems, controls and evidence for assessments without issuing reports or certifications. Request a quote built from that written scope.
How DeployOpen prepares systems and evidence for CIP changes
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. For the shift from TFEs to per system capability, that means DeployOpen can help a registered entity prepare the systems and records that a future assessment will examine. It does not decide whether a system has the capability to meet a requirement, and it does not issue audit reports or attestations. Those decisions remain with the Responsible Entity, and any finding is made by the Compliance Enforcement Authority.
Most engagements are fixed-scope. Before work starts, the scope, the deliverables and the timeline are agreed in writing. For this topic, a written scope might list which Applicable Systems are being reviewed, which configurations or platform components will be documented, how the entity's justification for each per system capability decision will be recorded, and which evidence artifacts will be produced for the Compliance Enforcement Authority. Ask any provider to name each deliverable in the scope document, so you can check the output against what your compliance team needs in the first place.
Some work continues after the initial scope closes. Ongoing support, upgrades and continuous testing are available as retainers, which suit entities that must keep platform configuration, patch records and documentation current through the 1 July 2028 effective date and beyond. Before you sign, confirm with any implementation partner who will own each control, who holds the keys and records, and how changes to the written scope are priced and approved. Your internal compliance team should keep ownership of the program, and the partner should be accountable for the systems and evidence it delivers.
