NERC CIP Technical Feasibility Exceptions (TFE) explained

When can an NERC CIP Technical Feasibility Exception replace strict compliance?

A Technical Feasibility Exception (TFE) under Appendix 4D of the NERC Rules of Procedure authorizes an alternative means of compliance with compensating or mitigating measures, but it does not relieve the entity of the requirement. If a CIP requirement cannot be met as written on a specific system, such as an Intermediate System that cannot be deployed on a particular medium impact network path or a legacy Cyber Asset that cannot support a required control, the question is whether that system's situation fits one of the approval grounds in Appendix 4D section 3.1 and whether the compensating design achieves at least a comparable level of security. The answer differs by organization. It depends on the specific requirement part, the system's role and impact rating, the entity's own technical justification, and the compliance date it is working against. The burden of justifying the request sits with the Responsible Entity, so the justification has to be specific to the system rather than generic.

The organization owns the TFE request and the decisions about which compensating measures it will run and sustain. The Regional Entity decides whether to approve or disapprove it, and must act within 60 days of receipt unless it extends that period by notice. A TFE may also be approved without an expiration date, which makes the request's evidence and monitoring design matter more. An implementation partner can help document system configurations, network diagrams, compensating control records and the operational cost of the proposed alternative, but it cannot approve, issue or certify anything. Before drafting, confirm with your Regional Entity which requirement parts it has already accepted as TFE-eligible, and check the current eligibility list against the standard version your system falls under.

Which CIP requirements are TFE-eligible today?

NERC's March 2021 eligibility list names specific sub-requirements across CIP-005, CIP-006, CIP-007 and CIP-010 where a Technical Feasibility Exception may be requested. Each card below groups one standard's eligible parts, and every request still has to justify itself on its own facts.

CIP-005 electronic security perimeter parts

CIP-005 R1 Part 1.4 and R2 Parts 2.1 to 2.5 cover the Electronic Access Points and Interactive Remote Access controls at the perimeter, including the encryption and Intermediate System requirements. Teams often assume these are the most common TFE candidates because legacy gateways and older remote access products may not support required features. Check each listed part against your exact asset and access path before drafting a request.

CIP-006 physical access part

CIP-006 R1 Part 1.3 concerns the physical access controls for Physical Security Perimeters. It is the only physical security part on the list, so a request here usually depends on whether an access control mechanism can be deployed at a specific location. Document the physical constraints, such as building design or outage limits, and the alternative physical measures you would apply.

CIP-007 ports, patching and access parts

CIP-007 R1 Part 1.1 covers ports and services, R4 Part 4.3 covers event log retention, and R5 Parts 5.1, 5.6 and 5.7 cover system access controls, password complexity and password-change limits. These parts often collide with embedded or legacy devices that cannot enforce a setting. Inventory which device classes lack the feature and record the vendor's stated limitation.

CIP-010 configuration and software parts

CIP-010 R1 Part 1.5 addresses baseline configuration elements for certain systems, and R3 Part 3.2 covers vulnerability assessment steps. Eligibility here turns on whether the baseline or assessment cannot be produced by the tooling the device supports. Confirm the exact part text with NERC before scoping, because the eligibility list names sub-parts and not whole requirements.

Eligibility is a starting point

Appearing on the list does not approve anything. The Responsible Entity must still show why strict compliance is not possible, and the burden of that justification stays with the entity under Appendix 4D. Treat the list as a filter that tells you where to look, then build a separate technical record for each asset and part.

Confirm the list before scoping

The list is dated March 2021, so ask the Regional Entity and check NERC's current CIP pages for any update before you rely on it. Also confirm whether a newer CIP version has changed the part numbering that your request cites. A request that cites a retired part number will not hold up in review.

What grounds support approval of a TFE?

Can a TFE be approved if strict compliance is not technically possible?

Yes. Strict compliance that is not technically possible is the most direct ground for a Technical Feasibility Exception under Appendix 4D section 3.1. The entity must show that the device, software or platform cannot perform the requirement as written, even after reasonable configuration and vendor options are exhausted. The evidence usually includes vendor documentation or written vendor statements, test results showing the capability is absent, and a description of the system's architecture. Illustrative example: a legacy relay supports only a fixed set of ports and cannot run the required software, so the entity documents the vendor's written limitation, a lab test and the network segment where the device sits. Compensating measures are still required, because a TFE authorizes an alternative means of compliance rather than removing the obligation. The Responsible Entity carries the burden of justifying the request.

What evidence shows that compliance is operationally infeasible or would harm reliability?

The entity must show that meeting the requirement would be operationally infeasible or would degrade reliability of the Bulk Electric System. This ground differs from technical impossibility: the requirement could be met, but doing so would disrupt control room operations, cause instability or break a function the system must perform. Strong evidence ties the harm to specific operating data, such as load flow or control system behavior under test, and includes an engineering analysis from qualified staff. Illustrative example: applying a required control to a real-time monitoring system would add latency that the operator's own studies show could delay alarms, so the entity presents those studies and the reliability impact analysis. The request should also describe the compensating measures that keep security at a comparable level. Ask your Regional Entity which analyses it expects before you start the request.

Does a scarce resource or outage timing justify a TFE?

It can, but only when the requirement cannot be achieved by its compliance date because of scarce resources, equipment or outage timing. This ground is about time and availability, not about whether the requirement is possible in principle. The entity should show the specific constraint, such as equipment on backorder with a documented delivery date, a planned outage window that falls after the compliance date, or a staffing shortage that the entity has tried to address. Illustrative example: a replacement device is scheduled for installation during the next planned outage, which falls after the compliance date, so the entity documents the purchase order, the outage schedule and the interim compensating controls. Evidence should show the entity acted in good faith, because a delay caused by poor planning is unlikely to support approval. Expect the Regional Entity to ask for a schedule and a path to full compliance.

When would a safety risk support a Technical Feasibility Exception?

A safety risk supports a TFE when meeting the requirement would endanger personnel or the public. The entity must show the specific hazard, how it arises from the required action, and why no safer alternative exists. Typical evidence includes a documented hazard analysis, input from the entity's safety or occupational health function, and vendor or engineering statements on the risk. Illustrative example: installing a required security update on a device in an energized area would require a procedure that exposes technicians to arc flash hazards, so the entity submits its hazard assessment, the safety procedure it reviewed and the alternative compensating measures for that asset. The safety argument must be concrete. General statements that a change carries some risk are unlikely to meet this ground, and the Responsible Entity still carries the burden of justification.

Can a conflict with another legal requirement support a TFE?

Yes, when complying with a CIP requirement would conflict with another legal obligation the entity must follow. The entity must identify the other law or regulation, explain the conflict in specific terms, and show that it cannot satisfy both. Counsel should review this argument, because the Regional Entity will test whether the conflict is real and whether the entity has explored ways to meet both obligations. Evidence typically includes the text of the other requirement, a written legal analysis, and correspondence with the authority that governs it, where available. Illustrative example: a state or federal records rule requires a log to be retained in a form that the CIP requirement would prohibit, so the entity documents both obligations, its legal opinion and the compensating controls it applies to protect the affected data. Confirm with your legal team and regulator which obligations apply to your entity before you rely on this ground.

How do you show that compliance would cost far more than its reliability benefit?

This ground applies when meeting the requirement would cost far more than the reliability benefit it provides. The entity must quantify both sides of the comparison: the cost of compliance, including capital, labor, outage and recurring costs, and the reliability or security benefit the requirement would deliver for that specific asset. Evidence usually includes a documented cost estimate from vendors or internal engineering, a benefit analysis that considers the asset's role in the system, and the compensating measures that reduce risk at lower cost. The cost estimate should break down one-time and recurring expenses and state who bears each cost. Ask your Regional Entity whether it expects a particular analysis format. Because this argument turns on judgment, the comparison must be transparent and supported by data rather than general claims about budgets.

Who carries the burden of justifying a TFE request?

The Responsible Entity carries the burden of justifying the request under Appendix 4D sections 3.2 and 3.3. Approval does not depend on the Regional Entity proving that compliance is possible. The entity must present enough evidence for each ground it relies on, and it must describe compensating or mitigating measures that achieve at least a comparable level of security. The Regional Entity must approve or disapprove a request within 60 days of receipt unless it extends that period by notice, so a complete and well-organized submission shortens review. Illustrative example: an entity that submits a request with vendor statements, test data and a compensating control plan is far less likely to need follow-up than one that submits a general explanation. Your compliance team and, if you use one, your implementation partner can prepare the package, but only the entity can make the request and own the controls.

How a TFE request moves from submission to decision

The sequence turns a requirement that cannot be met as written into a documented, justified alternative that the Regional Entity has reviewed and either approved or disapproved. Each step produces a record you can point to in an audit.

Confirm the requirement and eligibility
Start by checking that the specific requirement part is on NERC's TFE eligibility list, and that the barrier is one of the grounds in Appendix 4D, such as technical impossibility, operational infeasibility, scarce resources or equipment, safety risk, a conflicting legal requirement or cost far out of proportion to the reliability benefit. Responsible Entity staff, usually compliance and the affected system owners, do this together. The output is a short written scope note naming the requirement part, the affected BES Cyber Systems and the ground you are relying on.
Prepare the written justification
Write the technical justification explaining why strict compliance cannot be achieved, including the system design, vendor documentation or test results that support the claim. Because the burden of justifying the request sits with the Responsible Entity, the justification should be specific enough that a reviewer can test it without more information. The output is a signed justification package that is ready for the Regional Entity.
Define and document compensating measures
Describe the alternative means of compliance you will use in place of the requirement part. These compensating or mitigating measures must achieve at least a comparable level of security. Record each measure, the system it protects, who operates it and how you will show it is working, such as logs, configuration records or periodic reviews. The output is a compensating measures record that sits alongside the justification.
Submit the TFE Request to the Regional Entity
Send the justification and compensating measures record to the Regional Entity that is the Compliance Enforcement Authority for your entity, following its submission format. Keep proof of the submission date, because the 60-day review period runs from receipt. The output is a submission record with the receipt date that you can later match against the decision timing.
Respond to Regional Entity questions
The Regional Entity may ask for clarification, more evidence or changes to the compensating measures before it decides. Treat each question as a formal item, answer it in writing and update the record version. Confirm with your Regional Entity how it tracks these exchanges and whether any question changes the receipt date. The output is a dated log of questions and responses.
Receive the approve or disapprove decision
The Regional Entity must approve or disapprove the request within 60 days of receipt, unless it extends that period by notice. Ask how an extension notice will reach you and what it will say. If the request is disapproved, you must still meet the requirement or pursue another route, so plan the remediation before the decision arrives. The output is a written decision that you file with the TFE record.
Operate and evidence an approved TFE
An approval authorizes the alternative means of compliance; it does not remove the requirement. Operate the compensating measures as documented, keep evidence that they run, and review them when systems or the environment change. A TFE may be approved without an expiration date, so confirm with your Regional Entity what periodic review, reporting or re-submission it expects. The output is an ongoing evidence set that an auditor can sample against the approved record.

What compensating measures must achieve for a TFE to hold up

An approved Technical Feasibility Exception does not excuse the requirement. It authorizes an alternative means of compliance built from compensating or mitigating measures that achieve at least a comparable level of security to the requirement as written. The Responsible Entity carries the burden of showing that comparability, so the request has to explain, control by control, what the blocked requirement was meant to prevent and what runs in its place. Start with the specific sub-part under the TFE, such as the CIP-007 R5 password part or the CIP-005 Intermediate System part, and write down the risk that sub-part addresses in your environment before naming any substitute measure.

Comparability is shown by mapping each compensating measure to that risk. For each one, document the asset or BES Cyber System it protects, the threat it counters, how it detects misuse of the blocked control, and how quickly staff are alerted and respond. Monitoring and detection usually carry most of the weight where the preventive control cannot be applied, so confirm which logs, alerts and review cadence replace the blocked control, and whether they cover the same assets and accounts. Keep dated evidence that each measure is running: configuration exports, alert samples, review records and test results. A measure that exists on paper but has no operating record is hard to defend at audit.

Your organization owns and operates these measures, and the Regional Entity judges whether they are comparable. An implementation partner can build the logging pipelines, monitoring rules, alert routing and compensating-control documentation, and can help assemble the evidence set, but the partner cannot certify comparability or act as the approving party. Before submitting, confirm with your Regional Entity which evidence format and review period it expects, and plan for measures to be reviewed again if the system or the requirement changes.

Who does the work on a TFE, and who decides

The registered entity is the Responsible Entity and owns the whole TFE. It decides whether a requirement cannot be met as written, writes the request, accepts the burden of justifying it, and designs and runs the compensating measures. A TFE does not relieve the entity of the underlying requirement, so the entity remains accountable for the alternative means of compliance for as long as the exception applies.

The request and justification: The entity identifies the specific requirement part, explains the technical, operational, safety or cost reason strict compliance is not possible, and shows why the proposed alternative achieves a comparable level of security.
Compensating measures: The entity selects, configures, staffs and operates the controls that stand in for the requirement.
Ongoing evidence: The entity keeps records that the compensating measures run as described, because those records are what an auditor tests later.
Internal approvals and signatures: The entity's senior leadership should own the risk acceptance inside its own governance.
Vendor and contractor dependencies: If a vendor product blocks compliance, the entity must still own the request and its outcome.

Before you engage anyone, confirm internally which person signs the request and who maintains the evidence after approval.

How per system capability replaces TFEs from 2028

FERC Order No. 919 approved replacing the phrase "where technically feasible" with "per system capability" in the virtualization standards, which NERC lists as effective 1 July 2028. For entities that expect to rely on the new wording, the practical change is that a requirement qualified by capability will no longer send you to a Technical Feasibility Exception request under Appendix 4D for that qualifier. Order No. 919 did not, however, hand entities an open door. It directed NERC to build the criteria for invoking the exception, a mandatory reporting obligation to the ERO Enterprise, and an annual anonymized report to FERC. Until those criteria are published, the exact test an entity must pass to invoke "per system capability" is not known, so confirm the wording and the criteria directly with NERC and your Regional Entity when they are issued rather than assuming the current TFE process carries over unchanged.

NERC's 2024 TFE annual report counted 94 registered entities with approved TFEs across the ERO Enterprise, a figure NERC described as stable from prior years. That count tells you how widely the current process is used, but it does not predict how the successor process will work or how many entities will invoke it. Treat it as background. The decisions that matter sit in your own environment: which virtualized or capability-qualified requirements apply to your BES Cyber Systems, where you already depend on a TFE, and which of those compensating measures you can describe in terms a reviewer would accept as a comparable level of security.

Start by inventorying every active TFE and sorting it by the requirement it touches, the compensating measures it relies on, and the evidence you collect to show those measures operate. Keep the approval records, the compensating control configurations, monitoring output and review dates in a form that remains usable if the process changes. Before the 2028 effective date, map which of your systems are virtualized, which will be covered by the revised standards, and where the capability wording would matter for your assets. Then ask your compliance team to confirm, once NERC's criteria are published, what documentation the new reporting obligation requires, so the evidence you build now does not need to be recreated later.

What usually delays or weakens a TFE request

Most TFE requests fail for process reasons rather than technical ones. The pitfalls below share a pattern: the entity treats the exception as an exemption instead of an alternative means of compliance that it must justify, document and keep current.

Filing without a documented ground

A TFE must rest on one of the grounds listed in section 3.1 of Appendix 4D, such as technical impossibility, operational infeasibility, a safety risk or a cost far exceeding the reliability benefit. Requests that describe a difficulty without tying it to a named ground are the most common reason for delay. Before drafting, confirm which ground applies, state it in the first paragraph, and show the specific system, requirement part and constraint involved.

Weak comparability analysis

The burden of showing that compensating measures achieve at least a comparable level of security sits with the Responsible Entity. A request that lists controls without explaining how each one addresses the risk the original requirement targets will be questioned. For each compensating measure, document the threat it addresses, how it is monitored and what it would detect, then compare that result against the requirement as written.

Late filing without a plan

A request that reaches the Regional Entity after the compliance date, with no interim controls or timeline, signals that the entity has not managed the gap. Where scarce resources, equipment or outage windows are the reason, show when the entity expects to meet the requirement, what compensating measures run in the meantime and which outage or procurement milestones drive the schedule. Confirm the Regional Entity's expectations on timing before you file.

Treating the TFE as a permanent fix

A TFE authorizes an alternative means of compliance, but the underlying requirement remains owed. Approval may be granted without an expiration date, which makes it easy to forget that the system is still out of step with the standard. Record each approved TFE in the compliance program, assign an owner, and set a review point to reassess whether the technical or operational constraint has changed.

Missing audit evidence

Regional Entity auditors test whether the approved compensating measures run as described. Entities often hold a signed TFE but cannot show logs, configuration records, review sign-offs or change history for the alternative controls. Define the evidence for each compensating measure when the request is drafted, retain it on the same schedule as other CIP evidence, and rehearse pulling it before an audit notice arrives.

Overlooking per system capability

FERC Order No. 919 replaces 'where technically feasible' with 'per system capability' in the 2028 virtualization standards, but NERC must still set criteria, reporting and annual reporting to FERC for invoking it. Entities that plan new virtualized deployments around a TFE may file requests that the new language would have handled differently. Before filing for virtualized systems, check the 1 July 2028 effective date and the criteria NERC issues for the new exception.

Common questions about NERC CIP TFEs

Does it cost a fee to request a NERC CIP technical feasibility exception?

The Appendix 4D procedure does not set a fee for submitting a TFE Request, so confirm the current position directly with your Regional Entity before you file. The costs you should plan for are internal and external effort: engineering time to document why strict compliance is not possible, the compensating measures you propose, and the monitoring and evidence those measures need after approval. If you hire a consultant to draft the request, that fee is set by your written scope, not by NERC. Ask any provider to itemize the drafting, technical analysis and evidence work separately so you can compare quotes on the same basis.

How long does NERC take to review a TFE request?

The Regional Entity must approve or disapprove a TFE Request within 60 days of receiving it, unless it extends that period by notice. The clock therefore depends on the quality of the first submission, because an incomplete request invites follow-up questions and possible extensions. Plan the review window into any project that depends on the exception, and do not assume approval will arrive before a compliance date. Ask the Regional Entity early how it prefers requests to be structured and whether it expects a pre-submission discussion.

Does an approved TFE expire?

A TFE may be approved without a TFE Expiration Date, so an approval does not automatically end on a fixed date. Whether your approval carries an expiration date depends on the request and the decision, so read the approval terms closely. Even without an expiration date, the compensating measures must keep operating and the conditions of the approval must still be met. Track any changes to the affected system, since a material change can require you to revisit the justification.

What does a TFE require from our internal staff?

A TFE request is justified by your own system knowledge, so internal staff own the facts. Expect to involve:

Engineers who can describe the affected BES Cyber Systems, their configuration and why the standard cannot be met as written
Operations staff who can explain outage constraints, safety risks or reliability effects
Compliance staff who track the requirement, the evidence and the compensating measures after approval
Procurement or vendor managers, where equipment or supplier limits block compliance

The burden of justifying the request sits with the Responsible Entity, so your team must be able to defend every claim in front of the Regional Entity.

Can we prepare a TFE request ourselves?

Yes. Appendix 4D is a procedure that a Responsible Entity can follow directly, and nothing in the supplied procedure requires outside preparation. Doing it yourself works best when your team already understands the requirement language, the eligibility list and the grounds for approval. Bring in outside help if the requirement touches many systems, if you lack staff who can document the technical limits, or if you want an independent review of the compensating measures before submission. Either way, the request and its accountability stay with your organization.

What does an implementation partner do for a TFE?

An implementation partner can prepare the systems, configurations and evidence that support a TFE and the compensating measures that replace strict compliance. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the work might include building the monitoring, access controls or logging that the alternative means depend on, and documenting how they operate. DeployOpen does not decide whether a TFE is granted and does not submit determinations on your behalf. Your organization owns the requirement and the request, and the Regional Entity makes the decision. Scope, deliverables and timelines are agreed in writing before work starts.

Does a TFE remove the CIP requirement?

No. A TFE does not relieve your organization of the requirement. It authorizes an alternative means of compliance using compensating or mitigating measures that achieve at least a comparable level of security. You remain responsible for operating those measures, producing evidence of them and meeting the conditions of the approval. Treat a TFE as a documented, approved route to an equivalent outcome, not as an exemption, and budget for the ongoing monitoring it requires.

How DeployOpen prepares systems and evidence for a TFE

DeployOpen works on NERC CIP Technical Feasibility Exceptions inside the client's own infrastructure, preparing the systems, compensating measures and evidence that support a request. The organization remains responsible for its controls and for the TFE request, and the Regional Entity makes the approval decision.

How we scope

Engagements are fixed-scope, with the requirement parts, systems and sites agreed in writing before work starts.
We map each TFE-eligible requirement part to the specific system where strict compliance is not technically possible.
The written scope records the compensating measures to be built and the evidence each one will produce.

How we build

We design compensating measures that aim for at least a comparable level of security to the requirement as written.
We configure and harden the affected systems inside your cloud accounts, data centers or air-gapped networks.
We test each compensating measure against its stated objective and record the results before it is relied on.

How we hand over

We document the justification, compensating controls and monitoring routines in a form your team can present to the Regional Entity.
We deliver evidence packages that show each compensating measure operating over time, with clear ownership for each item.
We train your operators on the procedures so the exception is run and reviewed without depending on us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainer work can keep compensating measures current when systems are upgraded or the TFE is reviewed.
Ask any provider to confirm which tasks they perform and which remain with your compliance team and the independent auditor.

NERC CIP Technical Feasibility Exceptions (TFE)