Why the OT Cybersecurity Framework Discussion Has Changed

In 2021, a threat actor accessed the water treatment facility in Oldsmar, Florida, and attempted to increase sodium hydroxide levels to potentially lethal concentrations. The intrusion lasted just minutes. The consequences, had an operator not noticed the cursor moving on his screen, could have affected over 15,000 residents. The attack vector was a legacy remote access tool. The industrial control system had no network segmentation and no OT-specific monitoring.

Before we move forward don’t forget to check out our last blog post on Decoding the latest CISA advisory on Zero Trust for Operational Technology here.

This was not an isolated incident. The 2022 Industroyer2 malware, engineered to interact directly with IEC 104 protocol-speaking substations in Ukraine, demonstrated that adversaries are now building tools purpose-designed for operational technology environments. When Mandiant and CISA published their joint advisory, one finding stood out: many targeted organizations had no baseline OT security posture to return to.

This is the environment in which the NIST Cybersecurity Framework for OT must be understood. Not as a compliance checkbox, but as a structural foundation for organizations whose systems, if disrupted, can affect public safety, national security, or economic continuity.

The NIST Cybersecurity Framework (CSF) 2.0, released in February 2024, marks the first time NIST explicitly expanded the framework's scope beyond critical infrastructure to all organizations, while simultaneously introducing governance as a first-class function. For OT security professionals, this shift is consequential.

Understanding NIST CSF in the Context of ICS & SCADA Security

The Core Tension: IT Security Logic in OT Environments

The most common failure mode when organizations apply a cybersecurity framework to OT environments is the assumption that IT security principles translate directly. They do not. In IT, confidentiality is the primary security concern. In OT, availability and integrity dominate-a Modbus write command that falsifies sensor data is far more dangerous than an exfiltrated spreadsheet.

SCADA systems managing high-voltage transmission lines, Distributed Control Systems (DCS) in chemical processing plants, and PLCs on automotive assembly floors operate on real-time communication protocols-DNP3, Modbus, PROFINET, EtherNet/IP-that predate modern cybersecurity thinking. Many of these systems cannot tolerate the latency introduced by inline security appliances. Some cannot be patched. Firmware updates on safety instrumented systems (SIS) may require full process shutdowns lasting days.

Applying the NIST CSF to ICS and SCADA security, therefore, requires a deliberate translation layer-one that preserves process continuity while building defensible architectures.

NIST CSF 2.0: What Changed and Why It Matters for OT

The 2024 update to the framework introduced six core functions: Govern, Identify, Protect, Detect, Respond, and Recover. For organizations securing industrial environments, the addition of Govern (GV) is particularly significant. It formalizes what many mature OT security programs already understood intuitively: sustainable security requires organizational commitment, not just technical controls.

NIST CSF 2.0 also introduced tiered implementation profiles more amenable to OT constraints, and its associated resources now explicitly reference NIST SP 800-82 Rev.3 as the companion guide for industrial control systems. This integration signals NIST's recognition that OT security cannot be addressed through a single generalist document.

The Six Core CSF Functions Applied to Industrial Environments

1. Govern (GV): Building the Organizational Foundation

The Govern function establishes the policies, roles, and risk management strategies that give all other security activities their direction. In OT/ICS environments, this means formalizing the intersection between operational risk and cyber risk-a dialogue that has historically been difficult because engineering teams and IT/security teams often speak different risk languages.

Practical implementation here involves creating an OT Cybersecurity Policy that explicitly accounts for process availability requirements, defining ownership for OT assets (often split between IT, OT engineering, and plant operations), and establishing a risk management strategy aligned with relevant compliance frameworks such as NERC CIP for electric utilities, IEC 62443 for industrial automation, or TSA Security Directives for pipeline operators.

• Establish an OT-specific risk governance committee with representation from operations, engineering, and security.

• Define acceptable risk thresholds for operational disruptions, not just data breach scenarios.

• Align cybersecurity governance with sector-specific regulatory requirements from the outset.

2. Identify (ID): Knowing What You Are Protecting

You cannot secure what you cannot see. In OT environments, asset inventory is notoriously difficult. Unlike IT environments where Active Directory provides a starting point, OT networks often contain assets that have never been formally documented-legacy RTUs installed a decade ago, engineering workstations running Windows XP, field devices added during capital projects with no security review.

The Identify function, applied to ICS, requires cataloguing PLCs, RTUs, HMIs, engineering workstations, historian servers, and all network infrastructure in the OT environment. Critically, this inventory must capture communication patterns-what talks to what, using which protocol, and on which network segment.

Passive network monitoring tools such as Claroty, Nozomi Networks, Dragos Platform, and Microsoft Defender for IoT can discover assets without sending packets that might disrupt process communications. Active scanning, standard practice in IT, can cause PLC fault states and should be avoided or carefully scoped in OT environments.

A major North American electric utility discovered over 2,400 previously untracked OT assets during their first passive network discovery engagement. The majority were in the operational technology network but had never appeared in any CMDB entry.

3. Protect (PR): Implementing Layered Defenses

The Protect function covers access control, identity management, data security, protective technology, and security training. In OT environments, this function requires a layered approach built on the Purdue Model or ISA/IEC 62443 zone-and-conduit architecture.

Network segmentation remains the single highest-value protective control in industrial environments. Proper implementation means DMZ zones between IT and OT networks, strict traffic filtering at each Purdue level boundary, and protocol-aware firewalls that inspect industrial protocols rather than simply passing them based on port numbers alone.

Remote access has become a critical attack vector. Engineering vendors, integrators, and remote monitoring services all require connectivity to OT systems. Best practice mandates dedicated jump servers in OT DMZs, MFA for all remote access sessions, session recording, and just-in-time access provisioning-eliminating always-on VPN tunnels to operational networks.

• Implement unidirectional security gateways (data diodes) where real-time bidirectional communication is not required.

• Harden HMI and engineering workstation configurations: disable USB ports, restrict application whitelisting, remove unnecessary services.

• Apply MFA to all privileged and remote access paths into OT networks.

• Conduct periodic security awareness training tailored to OT operators, not generic phishing simulations.

4. Detect (DE): Recognizing Threats in OT-Specific Contexts

Detection in OT environments requires a fundamentally different approach from IT security monitoring. Standard SIEM deployments looking for Windows event logs and failed authentication attempts miss the most dangerous ICS-specific behaviors: unauthorized PLC reprogramming, unexpected changes in process setpoints, anomalous communication between components that should not be communicating.

ICS-aware intrusion detection systems-platforms that understand DNP3, Modbus, EtherNet/IP, and OPC communications at the protocol level-are essential. These systems establish baselines of normal process communication and generate alerts on deviations. Dragos, Claroty, and Nozomi Networks have built detection logic that accounts for the specific behaviors associated with ICS malware families including TRITON/TRISIS (targeting safety instrumented systems), Industroyer, and BlackEnergy.

Effective detection programs in OT environments also require integration between process historians and security monitoring-correlating control system data with network events to identify scenarios where a cyberattack may be manifesting as a process anomaly rather than a network alarm.

In the TRITON/TRISIS attack against a Middle Eastern petrochemical facility, the malware specifically targeted the Triconex Safety Instrumented System-the last line of defense before a physical catastrophe. Detection came through a failed redeployment attempt, not a security tool.

5. Respond (RS): OT-Specific Incident Response Planning

Incident response in OT environments carries constraints that do not exist in IT. A security team cannot simply isolate a compromised server running a batch chemical process without potentially triggering a hazardous condition. Response procedures must be developed in close collaboration with operations and safety engineering teams, and must account for the operational impact of every response action.

OT incident response plans must define clear decision-making authority: who can authorize network isolation, who must be notified before shutting down a control system, and what the manual operating procedures are if automated systems are unavailable. Tabletop exercises simulating ICS-specific attack scenarios-ransomware encrypting historian servers, unauthorized PLC logic modification, HMI compromise-are essential to validating these plans before they are needed.

Organizations covered by NERC CIP, CISA advisories, or sector-specific frameworks should also understand their regulatory notification obligations-timelines for reporting cyber incidents to CISA, sector ISACs, and regulators vary by industry and incident type.

6. Recover (RC): Restoring Operations Safely

The Recover function focuses on maintaining resilience and restoring capabilities after an incident. For OT environments, recovery planning must address three distinct requirements: restoring the cybersecurity controls, restoring process data integrity, and restoring operational continuity-in an order that ensures safety is never compromised.

Secure, offline backups of PLC logic, HMI configuration, historian data, and network device configurations are foundational recovery assets. These backups must be stored in environments isolated from production networks and tested regularly through restoration exercises. Many organizations discover during an actual incident that their backups are incomplete, outdated, or incompatible with current hardware versions.

Recovery also includes post-incident analysis: understanding how the adversary gained access, what they did within the environment, and what changes were made to process configurations during the intrusion period.

7-Step Implementation Roadmap for OT Security Teams

Translating the NIST CSF into an actionable OT security program requires a structured implementation approach. The following seven-step roadmap, adapted from NIST's own implementation guidance and aligned with ISA/IEC 62443 requirements, provides a practical path from initial assessment to measurable security improvement.

Step 1: Prioritize and Scope Critical OT Systems

Before any security investment is made, organizations must establish which OT systems are in scope and why. This is not simply a technical exercise-it requires input from operations, engineering, legal, and executive leadership. Systems that support safety functions, production continuity, or regulatory compliance should receive the highest prioritization.

Scoping should align with ISA/IEC 62443 zone definitions. Define which systems constitute Zone 0 (field devices), Zone 1 (basic control), Zone 2 (supervisory control), and Zone 3 (manufacturing operations)-and establish which zones are within the security program's immediate scope versus deferred phases.

Step 2: Understand Systems and Compliance Requirements

Understanding the threat landscape for your specific sector is essential. A natural gas compression station faces different threat actor profiles than an automotive manufacturing facility. CISA's ICS-CERT advisories, sector-specific ISACs (E-ISAC for electricity, WaterISAC for water utilities, A-ISAC for aviation), and Dragos's annual Year in Review report provide sector-specific threat intelligence that should inform your security requirements.

ISA/IEC 62443 defines Security Levels (SL 1-4) that describe resistance to increasing adversary capability-from casual attackers to nation-state actors with inside knowledge. Establishing which SL your critical systems should target is a foundational requirement of this step.

Step 3: Create the Current Cybersecurity Profile

A current profile is a snapshot of the organization's current implementation of the CSF categories and subcategories. In OT environments, this assessment must be conducted with OT-specific context-not simply imported from an IT security assessment. An IT team that has never worked in a control system environment will systematically underestimate risks and recommend controls that are operationally impractical.

Assessments conducted against NIST SP 800-82 Rev.3 controls provide a structured baseline that maps directly to CSF functions and is recognized by regulators including CISA, EPA (for water utilities), and FERC (for electric utilities).

Step 4: Conduct the OT Risk Assessment

OT risk assessment methodology must incorporate consequence analysis that reflects operational reality. A risk model that treats all control system compromises as equal misses the critical distinction between, say, unauthorized access to a historian server versus unauthorized access to a safety PLC managing burner management logic.

CISA's Consequence-Driven Cyber-Informed Engineering (CCE) methodology provides an excellent framework for consequence analysis in critical infrastructure. By starting with the highest-consequence scenarios-what actions by an adversary could cause the most damage-and working backward to identify the cyber pathways that could enable those scenarios, organizations build risk assessments that reflect physical world consequences rather than abstract scoring matrices.

Steps 5-7: From Target Profile to Implementation

Defining a target profile requires honest acknowledgment of operational constraints. In environments where patching a specific PLC firmware requires a 72-hour planned outage, security teams must build compensating controls-network monitoring, strict access control, application whitelisting on adjacent HMI systems-rather than simply noting the vulnerability as unmitigated.

Gap analysis transforms the delta between current and target into a prioritized remediation roadmap. Prioritization should weight risk reduction potential heavily-a low-cost network segmentation improvement that eliminates a high-severity attack path delivers more security value than an expensive endpoint security deployment on systems with low exposure.

Industrial Cybersecurity Best Practices by Sector

Electric Utilities: NERC CIP and CSF Alignment

Electric utilities operating Bulk Electric System (BES) assets in North America are subject to NERC CIP reliability standards-one of the most mature and prescriptive OT security regulatory frameworks in existence. For these organizations, the NIST CSF serves as a higher-level framework that demonstrates security program maturity beyond NERC CIP compliance minimums, which regulators and boards increasingly expect.

NERC CIP-007 (Systems Security Management), CIP-010 (Configuration Change Management), and CIP-013 (Supply Chain Risk Management) map directly to CSF Protect and Identify functions. However, NERC CIP has traditionally been binary-either you meet the standard or you do not. The CSF's tiered maturity model helps utilities understand their security posture on a continuum rather than simply as a compliance status.

Oil & Gas: Protecting Distributed Field Operations

Oil and gas operations present unique challenges: geographically distributed assets, extensive reliance on legacy RTUs in remote pipeline monitoring stations, satellite and cellular communications with limited bandwidth for security tooling, and complex contractor and vendor relationships. The CSF's Identify function-particularly asset inventory and risk assessment-is often the area of lowest maturity in this sector.

TSA's 2021 and 2022 Security Directives for pipeline operators mandated specific OT cybersecurity measures following the Colonial Pipeline ransomware incident, which while primarily an IT compromise, demonstrated the operational impact of IT/OT interconnection. Organizations covered by these directives find that CSF-aligned programs provide a practical structure for meeting directive requirements while building a sustainable long-term security posture.

Water & Wastewater: Resource-Constrained OT Security

The water sector is among the most resource-constrained critical infrastructure sectors from a cybersecurity perspective. Most water utilities are small, publicly-operated systems with limited IT/OT security staff and budgets. CISA's WaterISAC and EPA's 2024 Cybersecurity Best Practices provide sector-specific guidance aligned with CSF functions.

The Oldsmar incident highlighted a recurring vulnerability in the sector: remote access through consumer-grade tools (TeamViewer in that case), shared credentials, and no OT network segmentation. CSF Protect function implementation-specifically access control (PR.AC) and protective technology (PR.PT)-addresses these most critical gaps even within tight resource constraints.

Manufacturing: IIoT Expansion and the Evolving Attack Surface

Smart manufacturing initiatives-digital twins, IIoT sensor networks, predictive maintenance platforms-are expanding the OT attack surface faster than security programs are adapting. Each new connected device is a potential entry point, and manufacturing environments often lack the mature change management processes that would subject new OT connections to security review.

The CSF Govern function is particularly relevant here: organizations with clear cybersecurity policies governing IIoT device procurement, deployment, and security configuration reviews before production connectivity are substantially better positioned than those treating IIoT as a pure engineering decision.

Common Implementation Pitfalls and How to Avoid Them

Building a Sustainable OT Security Program

The NIST Cybersecurity Framework, applied with OT-specific discipline, provides industrial organizations with a structured path from reactive, fragmented security measures to a proactive, risk-managed security posture. The framework's strength lies not in its prescriptiveness, but in its flexibility-it accommodates the enormous diversity of industrial control system environments, from high-voltage substations to pharmaceutical batch processing systems to offshore oil platforms.

The organizations that successfully implement CSF-aligned OT security programs share several characteristics: they treat security as an operational discipline, not an IT function bolted onto engineering systems; they invest in OT-specific expertise, either internally or through specialist partners; and they build programs that can demonstrate measurable risk reduction rather than simply audit readiness.

NIST CSF 2.0's new Govern function, combined with the technical depth of SP 800-82 Rev.3 and the industrial specificity of ISA/IEC 62443, provides the most comprehensive publicly available foundation for OT security program development. The question is no longer whether the guidance exists-it is whether organizations will invest in applying it with the rigor that critical infrastructure protection demands.

Adversaries are not waiting for organizations to complete their framework assessments. In 2024, CISA documented over 500 known exploited vulnerabilities affecting ICS and OT components. The gap between adversary capability and defender readiness in OT environments remains one of the most consequential security challenges in critical infrastructure protection.

Recommended Next Steps for Security Teams

1. Conduct a passive OT asset discovery engagement to establish a complete inventory baseline.

2. Perform an OT-specific risk assessment aligned with NIST SP 800-82 Rev.3 and IEC 62443-3-2 to identify and prioritize your highest-consequence vulnerabilities.

3. Develop or review your current OT incident response plan-specifically validate that response procedures account for operational impact and include tabletop exercises.

4. Assess remote access controls: eliminate always-on VPN tunnels to OT networks, implement MFA, and deploy session recording for all third-party access.

5. Deploy an ICS-aware detection platform capable of protocol-level monitoring across your OT network segments.

6. Establish or mature your supply chain cybersecurity program, focusing on ICS vendor software integrity and third-party access governance.

Key Takeaways

• NIST CSF 2.0 introduces a new Govern function, making it directly applicable to OT/ICS environments.

• Applying the framework to SCADA, PLCs, and RTUs requires sector-specific adaptation, not a direct IT security overlay.

• NIST SP 800-82 Rev.3 and ISA/IEC 62443 are the companion standards that bridge the gap between CSF guidance and field implementation.

• A 7-step implementation roadmap helps security teams move from aspiration to measurable operational resilience.

At Shieldworkz, we work side-by-side with utilities, energy, manufacturing, and critical infrastructure operators to turn framework requirements into real-world, field-tested defenses.

Contact us today to schedule a no-pressure discussion about your specific OT/ICS environment. The systems you protect power our world, they deserve the strongest possible security.