INSM Just Got Clearer: Key Takeaways from the NATF Guidance
By Patrick Miller
NATF has released new CIP-015 INSM guidance that confirms a risk-based approach for collection points, clarifies scope around ESP boundaries, contains numerous useful reference models, and reinforces practical retention strategies. It aligns closely with our INSM playbook, especially on passive visibility, multicast deduplication, and EACMS/BCSI determinations for INSM platforms.
Overview
NATF has released Version 2.0 of its CIP-015 Internal Network Security Monitoring (INSM) Implementation Guidance, offering practical clarity for entities preparing for enforcement. The guidance validates a risk-based approach to visibility, prioritizes monitoring where operational impact and adversary movement intersect, and introduces reasonable expectations for retention and data protection. It also acknowledges real-world architecture challenges such as multicast-heavy generation networks and vendor-remote access pathways, while raising important scope considerations when INSM tools intersect with EACMS or BCSI classifications. This blog takes a deep dive into what matters, what changed, and how to apply it in a way that is defensible to auditors and still operationally sustainable.
What Changed and Why It Matters
NATF’s CIP-015 INSM Implementation Guidance v2.0 (Open Distribution, approved 2025-09-24) provides concrete, risk-based patterns for meeting CIP-015-1 R1 through R3. It focuses on ESP-bounded monitoring for High and Medium with ERC, and acknowledges the ongoing policy discussion about monitoring EACMS and PACS outside the ESP.
The guidance is listed on NERC’s website as “Proposed Implementation Guidance,” meaning there is still approval required by NERC before it becomes official “ERO Enterprise-Endorsed Implementation Guidance.”
Three things in the new Implementation Guidance to note:
Explicit risk-based rationale for collection points under R1.1, with architecture patterns for substations, control centers, and generation.
Retention guidance that distinguishes short-lived full PCAP from longer-value metadata and investigation artifacts for R2.
Protection of INSM data examples for R3 and how INSM systems may intersect with EACMS and BCSI decisions.
The drafting team for this guidance document is comprised of many people who drafted the actual INSM CIP-015 standard, so there is strong alignment between the guidance and the regulation. Further, the guidance document is chock full of network reference models you can use to validate or design your architecture.
How This Maps to Our Ampyx INSM Playbook
From our earlier work on INSM, we’ve emphasized:
Passive-first monitoring with ICS-protocol awareness, integrating with preventive controls where it helps, but not relying on them to meet CIP-015 intent. NATF aligns with this framing.
Risk-based collection placement that prefers switches and gateways with the richest operational context and interactive traffic, while avoiding blind duplication. NATF’s Appendix 1 table mirrors these value calls.
Generation multicast realities and the need for deduplication if you collect at multiple layers. NATF calls this out in both the architecture and appendices.
Evidence that tells a story: short-term high-volume payload capture, long-term low-volume metadata plus carved artifacts, and retention aligned with incident response. NATF’s R2 table supports the same approach.
Scope boundaries with commingled platforms: when EACMS or PACS licensing/hardware spans CIP and non-CIP zones, only the data and functions supporting the CIP system are in scope for CIP evidence, while non-CIP use remains outside unless it directly services a CIP function. NATF flags that entities must evaluate whether INSM tooling becomes EACMS or a BCSI repository under your CIP-002 and CIP-011 processes.
Quick Architecture Takeaways You Can Adopt Now
Substations: where to collect and why
Managed switch mirror/SPAN to a local sensor usually provides sufficient coverage when Ethernet predominates. NATF CIP-015 INSM Implementatio…
Unmanaged environments often require inline taps on links to medium BCAs. NATF CIP-015 INSM Implementatio…
SDN-enabled topologies can baseline and punt off-baseline traffic to centralized analysis, reducing local footprint. NATF CIP-015 INSM Implementatio…
Control centers: breadth with intent
Collect at core, distribution, and DMZ switches to see user-interactive, inter-tier, and north-south flows. Decide VLAN inclusion using the Risk-Based Considerations in Appendix 1. NATF CIP-015 INSM Implementatio…
Generation: deduplicate and prioritize
Prefer core/plant and DMZ collection to avoid massive multicast duplication. If remote HMI use is common for operations, augment with access-layer collection there. Enable deduplication if you must collect at multiple layers. NATF CIP-015 INSM Implementatio…
Risk-based placement checklist (condensed from NATF Appendix 1)
| Candidate collection point | Why it scores high/medium/low | Priority |
|---|---|---|
| EAP, remote access gateway, jump host | User-interactive chokepoint with rich context for anomalous connections | Very High |
| Engineering Workstations and programming traffic | Logic loads, firmware updates, vendor tools | High |
| HMIs used for active operations | Operator actions, setpoints, user sessions | High |
| Clear-text ICS protocols (DNP3, ICCP, NTP, telnet, ftp) | Visibility into commands and insecure services | High |
| Broadcast/multicast heavy DCS unit networks | First vantage has value; duplicates add little without dedupe | First: High, Additional: Low |
| Encrypted or storage/virtualization traffic (vSAN, backups) | High bandwidth with low payload security value | Flow: Low, Payload: Very Low |
Adapted from NATF Appendix 1 Risk-Based Considerations.
Retention That Supports Investigations and Audits
The NATF guidance suggests using short-term payload and longer-term metadata and artifacts, then aligning durations with your IR playbooks and corporate records rules. Use the table below to help set baselines per R2.
| Data type | Investigation value over time | Relative cost | Suggested baseline |
|---|---|---|---|
| Full PCAP payloads | High initially, fades quickly. Encrypted payloads add little value. | High | Short spillover buffer sized to your IR triage window |
| Targeted PCAP tied to alerts | Retains value for replay and validation | Low | Keep per case until IR closure plus review window |
| Flows and derived metadata | Useful for patterning and scoping across months | Low | Months to years, aligned to audit look-backs |
| Carved files and hashes | Malicious samples and hashes hold value for TI enrichment | Medium to Low | Retain artifacts and hashes longer than payloads |
Protecting INSM Data and Systems Without Creating New Risk
For R3, NATF recommends safeguards you already favor in your program: isolated INSM management plane, PoLP for users and apps, strong authentication, and segmentation away from production BCS. Evaluate whether your INSM platform becomes an EACMS or BCSI repository under CIP-002 and CIP-011, and treat it accordingly.
Scope Boundaries When Platforms Are Commingled (EACMS/PACS with non-CIP)
We have discussed this in detail before in our blog on FERC Order 907-A. The most practical approach:
If a commingled EACMS or PACS platform services CIP functions, the CIP-relevant components, configurations, data paths, and evidence are in scope.
Non-CIP use that does not service CIP functions remains out of scope for CIP evidence, though you may still monitor it for enterprise risk.
Your INSM system’s role may influence whether parts of the platform are treated as EACMS or BCSI. Make that determination through your CIP-002 impact identification and CIP-011 data protection processes.
What Your Auditor Will Likely Ask to See
The risk-based rationale for each collection point and why it delivers “enough” visibility.
How anomalous activity is detected and then evaluated to determine further action, including roles and handoffs.
Data retention decisions by type and how they align to incident response and audit look-backs.
Protections on INSM data and whether the platform is treated as EACMS or BCSI where applicable.
Final Thoughts
NATF’s INSM guidance reinforces a direction that has been building across the industry: visibility inside operational networks is necessary. With CIP-015 enforcement approaching, the essential tasks are now clear. Build monitoring around operational risk, start at the EAP and remote access paths, avoid wasted data collection, and retain what supports investigations and compliance evidence. The more difficult work is not technology selection. It is defining scope and making defensible decisions.
This is consistent with everything we have covered in our INSM series. In our INSM Playbook we laid out a risk-based strategy for collection design and evidence generation. In Monitoring as Control Reality we focused on fitting INSM into a live OT environment without breaking operations. In CIP-015 Clarified: Commingled PACS and EACMS and What is Actually in Scope, we addressed one of the biggest traps teams fall into: confusing platform footprint with compliance scope and unintentionally expanding CIP obligations. NATF’s guidance validates these positions and supports a practical path forward that entities can defend to both internal stakeholders and auditors.
Don’t wait. Now is the moment to finalize architecture decisions, close documentation gaps, and operationalize INSM without overextending program scope (do it smart without breaking the network or the bank). Our position has not changed. A focused program that monitors where operational risk lives and produces clear, repeatable evidence will outperform a complex over-deployment every time. This guidance confirms that practicality, clarity, and defensibility are the right path.
