Earlier this year, DeNexus wrote about the NERC CIP Roadmap 2026: What's Changing and How CRQ Helps as a perspective for OT cyber leaders, CIP compliance teams, and senior decision makers.

On 10 August 2026, the Federal Energy Regulatory Commission (FERC) approved NERC Reliability Standard CIP-015-2 — Cyber Security — Internal Network Security Monitoring, completing the latest regulatory step in the introduction of mandatory Internal Network Security Monitoring (INSM) for the Bulk Electric System.^[1][2]

For utilities, the important point is that this does not create a new 2027 compliance deadline. The first enforceable CIP-015 milestone remains 1 October 2028 under CIP-015-1. CIP-015-2 then becomes effective on 1 October 2029, with its expanded scope phased in through October 2031.^[3]

The transition is therefore best viewed as a four-step programme: establish INSM for the highest-priority networks under CIP-015-1 in 2028, expand monitoring to associated access-control and shared systems at Control Centers in 2029, bring the remaining applicable Medium Impact BCS into scope in 2030, and complete the EACMS/PACS expansion at those Medium Impact sites in 2031.

What is CIP-015?

CIP-015 introduces mandatory Internal Network Security Monitoring (INSM) into the NERC CIP framework.

Existing CIP controls have historically placed considerable emphasis on defining and protecting the Electronic Security Perimeter (ESP). CIP-015 adds another dimension: visibility into network activity occurring inside trusted environments, particularly east-west communications that may reveal an attacker who has already crossed, bypassed or entered through a trusted path at the perimeter. FERC identified this lack of east-west visibility as a security gap when directing NERC to develop an INSM standard.^[4]

The basic control model is deliberately technology-neutral. Under CIP-015-2, a Responsible Entity must:

• Collect appropriate network data. Requirement R1.1 requires network data feeds selected using a documented, risk-based rationale, covering network activity such as connections, devices and communications.
• Detect anomalous activity. R1.2 requires one or more methods to identify anomalous network activity from those feeds.
• Evaluate it and determine what to do. R1.3 requires the entity not merely to generate alerts, but to evaluate detected anomalies and determine further action.
• Retain relevant evidence. R2 requires INSM data associated with an anomaly to be retained at least until the action supporting R1.3 is complete. It does not require indefinite retention of all normal network traffic.
• Protect the monitoring data. R3 requires the collected and retained INSM data to be protected against unauthorised deletion or modification.^[2]
• CIP-015-1 establishes INSM inside the applicable ESP. CIP-015-2 retains that model but extends visibility into the associated EACMS, PACS and shared cyber infrastructure that support the CIP environment.
• 2028: establish INSM for the applicable Control Center environments under CIP-015-1.
• 2029: expand those Control Center programmes into associated EACMS, PACS and SCI under CIP-015-2.
• 2030: bring the remaining applicable Medium Impact BCS with ERC, PCA and supporting SCI into the programme.
• 2031: complete the EACMS/PACS/SCI expansion for those Medium Impact environments.

In other words, CIP-015 is not simply a requirement to install network sensors. It creates a process extending from visibility → detection → investigation → decision → evidence.

What changed between CIP-015-1 and CIP-015-2?

The core INSM model changes relatively little. The major change is scope.

CIP-015-1 applies INSM to network activity within the ESPs of High Impact BCS and Medium Impact BCS with External Routable Connectivity (ERC). FERC approved that standard in Order 907 in June 2025 but simultaneously concluded that it did not cover the entire CIP-networked environment originally contemplated in Order 887.^[4]

FERC's concern was that Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS) can sit outside the ESP while maintaining trusted communication paths towards systems inside it. Compromise of those systems could therefore provide a route into the protected environment. FERC directed NERC to close that gap.^[4]

CIP-015-2 does so by applying the R1 monitoring framework to network activity between Cyber Systems that are part of:

High Impact BCS and their associated EACMS, PACS and Protected Cyber Assets (PCA); Medium Impact BCS with ERC and their associated EACMS, PACS and PCA; and Shared Cyber Infrastructure (SCI) supporting those Applicable Systems.^[2]

The inclusion of SCI is particularly relevant for utilities using virtualisation, shared storage and similar architectures. NERC added SCI to ensure that shared infrastructure supporting BCS, EACMS or PACS does not create an unintended monitoring gap simply because the underlying architecture is virtualised or shared.^[5]

At the same time, CIP-015-2 places important boundaries around the expansion. Its R1 note expressly puts three categories outside scope: traffic to or from non-CIP devices, traffic to or from Low Impact BCS, and traffic between discrete ESPs.^[2] FERC Order 907-A had already clarified that on shared segments outside the ESP, the CIP-networked environment is intended to cover the communication paths between the applicable CIP systems rather than every device and every packet on the shared network.^[3]

The practical distinction is therefore:

The implementation timeline

For entities under FERC jurisdiction, the approved implementation sequence is:

This sequencing matters. CIP-015-2 does not simply replace a 2028 deadline with a later one. Utilities with applicable Control Centers still have to implement the original CIP-015-1 scope by October 2028. They then have another year to extend the programme into the Phase 1 EACMS/PACS/SCI scope.

Likewise, the October 2030 date should not be interpreted as a one-year postponement for all Medium Impact systems. It is specifically Phase 2a for the remaining Medium Impact BCS with ERC, PCA and supporting SCI. Their associated EACMS/PACS layer follows in Phase 2b in October 2031.^[3]

For jurisdictions outside FERC authority, adoption and effective dates can differ. The dates above are the FERC-jurisdiction implementation dates in NERC's approved implementation structure.

What are practitioners saying?

Tom Alrich: do not ignore the cloud/EACMS problem

Tom Alrich's latest relevant commentary is not a direct review of the final CIP-015-2 approval. His focus is the parallel NERC effort to make the CIP standards workable for cloud-hosted services.

Alrich argues that the most urgent unresolved cloud-CIP problem is the use of cloud-based EACMS and PACS. Under the existing "classic" CIP construct, a utility using a cloud service that meets the EACMS or PACS definition can face the practical problem of demonstrating compliance with device-oriented CIP requirements across infrastructure operated by the cloud provider.^[7]

That issue is increasingly relevant to CIP-015. SIEM, security monitoring, access-control and other cybersecurity services are increasingly cloud-delivered, while CIP-015-2 explicitly brings EACMS and PACS deeper into the INSM scope. Alrich's concern is that utilities remaining on the existing CIP standards may still be unable to use some cloud-based EACMS/PACS services without moving affected systems into the proposed CIP "100-Series" framework.^[7]

CIP-015-2 itself does not resolve that issue. Utilities considering cloud-hosted INSM, SIEM, access monitoring or related services should therefore evaluate classification and evidence implications before committing to the architecture.

Nozomi: CIP-015 is a programme, not a sensor project

Nozomi Networks has been publishing a detailed 2026 series based on practical experience with utilities implementing CIP-015. Its latest instalment, published on 18 August 2026, concentrates on R1.3: investigating anomalies and determining further action.^[8]

The practical point is that detecting an anomaly is not the end of the requirement. Utilities need a repeatable process for evaluating it, reaching a disposition, documenting the action taken, and aligning escalation criteria with CIP-008 incident response. Nozomi also stresses tuning: repeatedly generating and clearing the same benign alerts consumes the resources needed to identify genuinely important activity.^[8]

Across the wider series, Nozomi identifies sensor placement, data-feed selection, system classification and audit evidence as recurring implementation problems. Its field guidance treats physical network validation as important: a collection point that works on a diagram may encounter missing switch capacity, cabling, bandwidth or other constraints when implementation reaches the facility.^[9]

Dragos: design for the expanded environment now

Dragos similarly recommends planning the architecture beyond the immediate CIP-015-1 ESP requirement. Its CIP-015-2 implementation guidance focuses on extending visibility into EACMS, PACS and SCI and using flexible collection methods — including SPAN/port mirroring, TAPs, remote mirroring and virtual collection — rather than assuming one physical sensor model fits every site.^[10]

For utilities already building their 2028 solution, the implication is straightforward: a design optimised solely for the minimum CIP-015-1 footprint may require significant rework when CIP-015-2 Phase 1 and Phase 2 arrive.

Claroty: baseline normal operational behavior

Claroty has made a related point: INSM depends on understanding normal operational behaviour well enough to identify meaningful deviations. It characterises this as more than a plug-and-play technology deployment because baselining, change management and operational context all affect anomaly detection quality.^[11]

These vendor and practitioner publications are not NERC requirements or compliance guidance, but they show considerable consistency around the practical challenges utilities are encountering.

Nozomi Networks, Dragos, and Claroty are all DeNexus technology partners, allowing native integration of their network and vulnerability telemetry into DeRISK Cyber Risk Quantification (CRQ) to produce financial quantification of OT cyber risk. The output is Annual Expected Loss and Value at Risk, calculated facility by facility and rolled up to the portfolio, not a qualitative score.

What are utilities worried about?

The formal Project 2025-02 comments provide a useful view of the issues utilities themselves expect to face.

Implementation time is one concern. Santee Cooper argued that 12 months between the initial CIP-015-1 Control Center implementation and the expanded EACMS/PACS obligation could be too short for the required network changes and coordination. ACES raised similar concerns about budgeting, vendor and equipment availability, possible redesign of solutions already procured for CIP-015-1, and the time required to tune monitoring systems and reduce false positives.^[12]

EACMS and PACS can be architecturally harder to monitor. Unlike assets contained within clearly defined ESPs, these systems may be distributed across different networks and organisational functions. American Transmission Company specifically observed that EACMS/PACS traffic may be more difficult to normalise.^[12]

Scope has direct cost consequences. AEP commented that adding substantially more assets and traffic can become extremely expensive. Other comments repeatedly sought clarity over mixed CIP/non-CIP network segments and the precise communications that must be monitored.^[12]

The final standard addresses some of that concern through its explicit R1 exclusions, but utilities will still need to demonstrate a defensible interpretation of their own architecture.

NERC itself recognises the implementation constraints. Its final plan explicitly cites the limited pool of vendors, sensor procurement and supply-chain constraints, network modifications, potential operational outages, the ability to ingest large volumes of network information, geographically distributed systems with different connectivity, and the longer design and testing periods that may be required at generating facilities.^[3]

There is also an audit and governance challenge. An INSM tool generating alerts is not, by itself, evidence that the requirement has been implemented. Utilities need to preserve the documented risk rationale, monitoring configuration, detection methodology, anomaly evaluations, resulting actions, retention controls and protection of the monitoring data. The classification of the monitoring components themselves can also determine which additional CIP requirements apply.^[8][9]

What utilities should be doing now

The October 2028 deadline may appear distant, but utilities that have not moved beyond product evaluation should treat the remaining period as implementation time rather than waiting time.

Start with scope and communications, not the tool. Identify the applicable High Impact and Medium Impact BCS with ERC, their PCA, EACMS, PACS and SCI, and map the communications among them. Apply the exclusions in CIP-015-2 deliberately rather than assuming that every device sharing a segment becomes part of the monitoring scope.

Design the 2028 architecture with the 2029–2031 endpoint in mind. CIP-015-1 compliance comes first, but collection points, data architecture and monitoring platforms should be assessed against the later EACMS/PACS/SCI expansion before large procurement and network-design decisions become difficult to reverse.

Validate collection points in the real environment. Confirm switch capabilities, SPAN or TAP availability, bandwidth, power, cabling, virtualisation visibility, encrypted traffic and operational constraints. A logical network diagram is not necessarily an implementation plan.

Build the anomaly-management process alongside detection. Define who investigates, what information they use, how an anomaly is dispositioned, when operations becomes involved, when escalation reaches CIP-008, and what evidence is retained. Detection without a repeatable decision process does not complete R1.3.

Decide how every INSM component will be classified. Sensors, management servers, data repositories and cloud services can create different CIP implications depending on their function and placement. Those decisions should be made before the architecture hardens.

Engineer audit evidence from the beginning. The documented risk-based rationale, configuration evidence and investigation records should be outputs of the operating process rather than something reconstructed shortly before an audit.

Finally, utilities evaluating cloud-delivered security monitoring should track the parallel NERC cloud/100-Series work. CIP-015-2 is now approved, but the relationship between existing CIP classifications and cloud-hosted EACMS/PACS remains an important architectural issue.

The takeaway

CIP-015-2 should not be viewed as a new standard beginning in 2029. For affected utilities, it is the second stage of a programme whose first compliance deadline is 1 October 2028.

The direction is clear:

The technical requirement is risk-based rather than prescriptive. That flexibility is valuable, but it also puts more responsibility on each utility to understand its architecture, select meaningful data feeds, establish defensible monitoring boundaries, tune anomaly detection, integrate investigation with incident response, and maintain evidence demonstrating that the programme operates as designed.

The utilities likely to have the easiest transition will not necessarily be those that collect the most data. They will be those that can clearly explain what they monitor, why they monitor it, how they recognise abnormal behaviour, and what happens next.

DeNexus DeRISK CRQ

Did you know DeNexus' cyber risk quantification (CRQ) platform natively supports telemetry from INSM platforms like Nozomi Networks, Forescout eyeInspect, Claroty CTD, and Dragos? This allows OT cyber risk quantification without being subject to the compliance requirements of EACMS or PCAs, because DeRISK is not connected into the ESP.

That matters because CIP-015-2 measures compliance by what a utility can prove about its network activity — and DeRISK™ CRQ turns that same INSM telemetry into a financial risk number the business can act on.

DeRISK CRQ is DeNexus's cyber risk quantification platform for industrial operators, including power generation and electrical transmission and distribution utilities. It ingests OT network and asset data — the same connections, devices and communications an INSM programme collects under R1.1 — and runs it through a proprietary risk model calibrated on 300+ industrial deployments across the US and EU. The output is Annual Expected Loss and Value at Risk, calculated facility by facility and rolled up to the portfolio, not a qualitative score.

Utilities connecting their INSM programme to a financial risk model can talk to DeNexus about a DeRISK CRQ assessment.

Turn INSM telemetry into a financial risk number. DeRISK CRQ ingests the same connections, devices and communications your INSM programme already collects under R1.1 — with native support for Nozomi Networks, Claroty, Dragos and Forescout eyeInspect — and runs it through a risk model calibrated on 300+ industrial deployments across the US and EU. Because DeRISK sits outside the ESP, it delivers that quantification without pulling another system into EACMS or PCA scope. The output is Annual Expected Loss and Value at Risk, facility by facility and rolled up to the portfolio — not a qualitative score.

Explore the DeRISK Platform → https://www.denexus.io/derisk-platform