Published September 2, 2026Blog

NERC CIP MFA Requirements: Secure Utility Applications Without Code Changes

Table of contents

Does NERC CIP require multi-factor authentication? Yes, but the requirement is scoped. Under the currently enforceable NERC CIP-005-7, Requirement R2.3 requires MFA for applicable Interactive Remote Access sessions involving high-impact BES Cyber Systems and medium-impact BES Cyber Systems with External Routable Connectivity, including the associated Protected Cyber Assets named by the standard.

That does not mean every application used by an electric utility is automatically subject to NERC CIP MFA requirements. Applicability depends on the Responsible Entity, the system classification, its connectivity, and the actual access path.

Once a web application or access path is determined to be in scope, a practical problem remains: how do you enforce MFA when a stable, custom, packaged, or legacy application cannot support modern authentication? Datawiza Access Proxy can place MFA in front of an existing web application using either the organization's identity provider or Datawiza built-in MFA, without rewriting the application's source code.

Important: This article provides general technical information, not legal or regulatory advice. Each Responsible Entity should confirm applicability, architecture, evidence, and implementation requirements with its NERC compliance, cybersecurity, legal, and Regional Entity teams.

For a broader comparison of regulatory obligations, see the Datawiza MFA compliance requirements hub.

NERC CIP MFA requirements at a glance

Current requirement: CIP-005-7 Requirement R2.3 requires MFA for all applicable Interactive Remote Access sessions.
Systems named by R2.3: high-impact BES Cyber Systems and associated Protected Cyber Assets, plus medium-impact BES Cyber Systems with External Routable Connectivity and associated Protected Cyber Assets.
Related architecture: R2.1 requires an Intermediate System for applicable Interactive Remote Access, and R2.2 requires session encryption to terminate at that Intermediate System.
Not a universal utility-app rule: a department name, business importance, or utility ownership does not by itself place an application in CIP-005 scope.
Future standard: CIP-005-8 is scheduled to take effect July 1, 2028, and retains MFA to the Intermediate System for applicable Interactive Remote Access.

Where NERC CIP explicitly requires MFA

CIP-005-7 governs Electronic Security Perimeters and remote-access management for applicable high- and medium-impact BES Cyber Systems. Requirement R2 is framed by the standard's where technically feasible language. Part 2.1 requires applicable Interactive Remote Access to use an Intermediate System, Part 2.2 addresses where encryption terminates, and Part 2.3 requires MFA.

The NERC Glossary defines Interactive Remote Access around user-initiated access by a person using remote-access technology over a routable protocol. It excludes system-to-system process communications. That distinction matters: a person signing into a web interface may present a different compliance question from an automated integration exchanging data.

A technical limitation should not be treated as an automatic exemption. The Responsible Entity should document how technical feasibility applies and validate the full remote-access design. MFA is one required control in that architecture, not the entire architecture.

Does every utility application fall within CIP-005 MFA scope?

No. A document repository, reporting tool, or workflow application does not become a BES Cyber System simply because a Transmission Compliance team uses it. Start with the system and access path, not the department name.

Useful scoping questions include:

Is the organization a Responsible Entity for the applicable standard?
How has the system or supported environment been categorized under CIP-002?
Does the application provide access to, support, or sit within the security boundary of an applicable BES Cyber System?
Does a human user reach it through a path that meets the definition of Interactive Remote Access?
Can another hostname, direct IP address, local login page, VPN route, vendor path, or administrative interface bypass the intended MFA control?

In simplified terms:

Remote human access to an applicable high-impact BES Cyber System through a web interface may fall under CIP-005 when it meets the Interactive Remote Access definition.
The same is true for applicable medium-impact BES Cyber Systems with External Routable Connectivity.
A repository that stores compliance evidence is not automatically in scope based only on its content or users.
A vendor portal that creates a path into an applicable environment needs review under both interactive and vendor remote-access requirements.
An automated service exchange is not automatically Interactive Remote Access, although other CIP controls may still apply.

Current and upcoming NERC CIP standards

CIP-005-7 is the current remote-access standard

CIP-005-7 remains the enforceable version until the next approved version takes effect. Its Requirement R2.3 expressly requires MFA for all applicable Interactive Remote Access sessions. The standard also gives architecture documents detailing the authentication factors used as an example of compliance evidence.

CIP-005-8 takes effect July 1, 2028

The NERC effective-date schedule lists CIP-005-8 for July 1, 2028. Its Requirement R2.3 requires MFA to the Intermediate System for applicable Interactive Remote Access communications between the initiating Cyber Asset or Virtual Cyber Asset and that Intermediate System.

Low-impact requirements are different

CIP-003-9, effective April 1, 2026, requires security-management controls for low-impact BES Cyber Systems, including electronic-access and vendor-access controls. It does not impose a universal MFA requirement on every low-impact system.

CIP-003-11, scheduled for July 1, 2029, adds user-authentication requirements for specified user-initiated electronic access. Its evidence examples include MFA, but MFA is not stated as the only acceptable mechanism. Do not copy the explicit CIP-005 mandate onto every low-impact or business application without a scope analysis.

Why existing utility web applications create an MFA gap

Corporate SaaS platforms are often connected to Microsoft Entra ID, Okta, Ping, Duo, or another enterprise identity platform. The harder gap is the long tail of existing web applications built before SAML, OpenID Connect, and modern MFA became common.

Operations, planning, reporting, and asset-management web applications.
Maintenance, engineering, vendor, and contractor portals.
Custom Java, .NET, PHP, and other internally developed systems.
Packaged applications with local authentication or limited identity support.
Web interfaces associated with operational environments, subject to architecture and applicability review.

Adding MFA inside these applications can mean source-code changes, vendor upgrades, new SDKs, regression testing, and a production release. Utility change control, network segmentation, availability requirements, and vendor dependencies can extend that timeline. No-code MFA moves enforcement to the access layer instead.

How Datawiza enforces MFA for a utility web application

Datawiza Access Proxy sits in front of the application as an identity-aware reverse proxy. The user requests the application's normal URL, completes the configured authentication and MFA flow, and is evaluated against application or path policy. Only approved traffic reaches the application, while authentication and access events can be recorded for operations and evidence collection.

Datawiza Access Proxy enforcing MFA before access to a utility web application

The diagram shows the access-layer pattern, not a complete NERC CIP reference architecture. The Responsible Entity must validate Datawiza's placement, the Intermediate System design, and applicability to the specific environment.

Mode 1: use the enterprise identity provider

For employees already managed in an enterprise identity platform, Datawiza can redirect authentication to Microsoft Entra ID, Okta, Ping, Duo, or another supported provider. The identity provider applies authentication, MFA, and conditional-access policy. Datawiza bridges that modern flow to an application that may not natively support SAML or OpenID Connect, while the application keeps its existing roles and authorization model.

Mode 2: use Datawiza built-in MFA

Some utility applications serve vendors, contractors, or other users who do not belong in the corporate identity provider. In built-in mode, users keep signing in with the application's existing username and password. Datawiza then enforces an MFA challenge before protected access continues. There is no identity-provider migration, identity mapping, or change to the application's primary authentication.

Choose factors and recovery procedures according to the organization's risk assessment. Where feasible, favor phishing-resistant methods; CISA recommends phishing-resistant MFA and highlights FIDO/WebAuthn and PKI-based approaches.

How Datawiza can support a NERC CIP program

MFA before application access: require the configured challenge before protected web traffic proceeds.
No source-code changes: avoid embedding authentication libraries or rewriting the application's login flow.
Two authentication modes: use an existing identity provider or built-in MFA for users outside it.
Central access policy: apply consistent application and path rules across multiple web applications.
Operational visibility: record authentication, policy, allowed-access, and denied-access events for review and troubleshooting.
Phased deployment: begin with one application and access path before expanding.

These capabilities can support an implementation and evidence strategy. They do not, by themselves, establish NERC CIP compliance.

What an MFA proxy does not replace

Depending on the applicable standard and architecture, the Responsible Entity may also need to address:

BES Cyber System categorization and scope.
Intermediate System placement and configuration.
Electronic Security Perimeters and Electronic Access Points.
Confidentiality and integrity of remote-access communications.
Controls that prevent direct or alternate paths from bypassing MFA.
Vendor-session monitoring, disabling, and reconnection controls.
Account lifecycle, emergency access, logging, evidence retention, testing, and documented processes.

Datawiza is therefore an MFA and web access-control component within the utility's broader NERC CIP architecture, not a one-product compliance certification.

Frequently asked questions

Does NERC CIP require MFA?

Yes. CIP-005-7 Requirement R2.3 requires MFA for all applicable Interactive Remote Access sessions involving the high- and medium-impact systems and associated assets identified by the standard. It is not a blanket requirement for every application used by a utility.

Which NERC CIP standard contains the MFA requirement?

The explicit current remote-access MFA requirement is CIP-005-7 Requirement R2.3. CIP-005-8, scheduled for July 1, 2028, retains MFA to the Intermediate System for applicable Interactive Remote Access.

What counts as MFA under CIP-005?

CIP-005 describes three authenticator categories: something the individual knows, has, or is. MFA combines authenticators from different categories. A password and PIN are both knowledge factors and should not be treated as two independent factors.

Does NERC CIP require MFA for low-impact BES Cyber Systems?

Current CIP-003 requirements do not create a universal MFA mandate for every low-impact BES Cyber System. CIP-003-11 expands authentication requirements beginning July 1, 2029 and includes MFA among its evidence examples, but it does not prescribe MFA as the only mechanism.

Can a utility add MFA without changing application code?

Yes, for HTTP and HTTPS applications. An access proxy can enforce authentication and MFA before protected traffic reaches the application. Datawiza supports this pattern with an existing identity provider or built-in MFA. See MFA for legacy applications for the broader implementation model.

Does deploying Datawiza automatically make an application compliant?

No. Datawiza can provide MFA, access policy, and logging within a broader architecture. The Responsible Entity must validate applicability, Intermediate System placement, encryption, ESP and EAP controls, bypass prevention, vendor controls, evidence, and all other applicable requirements.

Close the utility application MFA gap

NERC CIP MFA requirements follow defined access paths to applicable systems, not a generic label such as critical utility application. Once an existing web application is determined to be in scope, Datawiza can provide an access-layer path to MFA without changing its source code.

Bring one application URL, its login flow, user populations, network diagram, identity provider, and NERC CIP classification to a technical review. Book a demo to map the two MFA modes while your compliance team validates the complete architecture.