NIST CSF 2.0 Applied to OT: Using It as a Roadmap for Manufacturing SMEs

NIST CSF 2.0: what changes compared to the previous version

The NIST Cybersecurity Framework has played an important role in giving structure to the conversation about cybersecurity, including outside the United States. Version 2.0, published in 2024, introduces several significant changes compared to version 1.1.

The most relevant is the addition of a sixth function: Govern. The five original functions (Identify, Protect, Detect, Respond, Recover) described technical and operational capabilities. Govern recognizes that cybersecurity is not just a technical problem: it requires governance, accountability, policies, defined roles, and integration with business strategy. An excellent technical detection capability in an organization with no governance is fragile: it depends on the right people in the right place, not on stable processes.

Other notable changes: CSF 2.0 explicitly expands its coverage to OT systems and operational technologies, which were mentioned only marginally in version 1.1. Version 2.0 includes sector-specific profiles, with examples for critical infrastructure and industrial environments. This is not a framework designed only for enterprise IT.

One thing that does not change: NIST CSF is not a mandatory standard. It is not legally required in Italy (unlike NIS2). It is a voluntary tool for self-assessment and planning. This characteristic is a strength: you can use it as a compass to prioritize investments without having to demonstrate compliance to an external auditor.

Govern: building OT governance before the technologies

The Govern function cuts across the other five: it defines the organizational context in which security capabilities operate. For a manufacturing OT environment, Govern includes:

Defining roles and responsibilities: who is responsible for OT security? Not necessarily a dedicated CISO (many SMEs do not have one), but a person or team with the explicit responsibility to manage cyber risk in the plant. Without this clarity, OT security decisions are postponed indefinitely or delegated to people who do not have the mandate to make them.

Risk management strategy: what is the organization's risk appetite? How much is it willing to invest to reduce cyber risk compared to other operational investments? This is not a technical decision: it is a business decision that must involve management. The Govern function of NIST CSF 2.0 requires this strategy to be explicit and documented.

Policies and procedures: written rules on how OT security is managed. Not volumes of regulations: a few clear pages on access, vulnerability management, and incident reporting. The value of policies is not bureaucratic: it is to provide an explicit reference that allows you to check whether actual behavior is aligned.

Oversight and review: governance requires mechanisms for periodic verification. Does management know how OT security is going? Are there metrics that are brought to meetings periodically? The Govern function requires cybersecurity to be integrated into the ordinary management of the organization, not relegated to an invisible technical activity.

Identify: knowing what you have

The Identify function is the logical starting point for any OT security program. NIST CSF 2.0 breaks it down into: asset management, risk assessment, and improvement (the last one is new in 2.0).

OT asset management: building and maintaining an inventory of industrial control assets. What devices are on the OT network? PLCs, HMIs, SCADA servers, historians, intelligent field devices, engineers' workstations. For each asset: model, firmware version, operational criticality, owner. Without this inventory, subsequent security decisions have no foundation.

Dependency mapping: knowing that the assets exist is not enough. You need to understand the relationships among them: which PLC depends on which configuration server? Which process stops if a certain historian goes offline? Critical dependencies must be mapped to understand where to concentrate priority protection measures.

Risk assessment: an OT risk assessment is not the same as an IT risk assessment. The consequences of an incident in a production plant include line stoppages, physical damage, risks to operator safety, and environmental impact. The risk assessment must take these specific consequences into account, not limit itself to the confidentiality and integrity of data.

A well-conducted Identify self-assessment answers the question: "If a cyberattack were to hit our plant, where would it strike hardest? Which critical assets are most vulnerable?"

Protect: reducing the attack surface

The Protect function covers the preventive measures that limit the impact of a potential incident. In an OT environment, the main categories are:

Access control: who can access OT systems, how, and from where. Physical access to control cabinets, vendor remote access, PLC administration credentials. Effective access control in OT requires moving away from the logic of shared passwords and generic accounts, toward named accounts with the minimum necessary access.

Network segmentation: physically or logically separating the OT networks from the IT network and from the internet. Not just a firewall between IT and OT: also internal segmentation between OT zones with different criticality levels. A field device should not be able to communicate directly with an engineering workstation without passing through a control point.

System hardening: disabling unnecessary services, changing default credentials, applying available patches where possible. On legacy systems where patching is not feasible, documenting the compensating measures adopted.

Removable media management: USB sticks are still one of the most common attack vectors in air-gapped or partially segmented OT networks. Policies and technical controls for managing the removable devices that come into contact with OT systems are a fundamental protective measure.

Awareness and training: the people who interact with OT systems (operators, maintenance technicians, external integrators) must have a minimum awareness of security practices. There is no need for an ethical hacking course: it is enough to understand why you do not plug a USB stick found in the parking lot into a SCADA workstation.

Detect: seeing before it is too late

The Detect function is where many manufacturing SMEs have the most obvious gap. Protect and Identify get addressed, with variable quality. Detect is often ignored entirely: you install the firewall, you segment the network, and you expect this to be enough.

The problem is that preventive measures fail. Always. The question is not whether an attacker will manage to bypass the defenses: it is when they will do so, and how quickly it will be detected.

Continuous monitoring of the OT network: passive sensors that capture OT network traffic and analyze it to detect anomalies. New devices appearing on the network, communications toward unusual destinations, changes to PLC configuration outside maintenance windows, unusual protocol behavior.

Baseline-based anomaly detection: establishing the normal behavior profile for each OT asset (who it communicates with, on which protocols, with what frequency) and detecting deviations. This is the fundamental logic of passive OT monitoring.

Alert management: detecting is not enough. Alerts must be examined by someone with the context to interpret them. A process for triaging OT alerts, even a simple one, is necessary to turn detection into response.

OT threat intelligence: knowing the threats relevant to your sector and updating detection rules accordingly. APT campaigns targeting European manufacturing leave documented indicators of compromise; using them to configure alerting rules is a way to increase the probability of early detection.

Respond and Recover: preparing before it happens

The Respond and Recover functions are often neglected in favor of Protect, on the implicit assumption that if the defenses hold there will be nothing to manage. This reasoning is dangerous.

OT incident response: having an incident response plan specific to OT scenarios. Responding to an incident in a production plant is different from IT response: "shut down and isolate" can cause physical damage or stop production in an uncontrolled way. The plan must define who decides to stop a production process during an incident, with what authority, and how.

OT system recovery: having backups of PLC and SCADA system configurations, tested periodically. Restoring a PLC from a backup is a technical operation that requires specific skills: it is better to discover this in a planned test than during an emergency.

Communication during the incident: who is informed internally (management, operations, production), who is informed externally (customers, authorities such as ACN for NIS2 notification, OT vendors). Communications during an incident must be managed in a coordinated way to avoid contradictory information and reputational damage.

Post-incident review: after every incident, even minor ones, conduct a review to understand what worked and what did not. The lessons learned must update the plans and procedures.

CSF 2.0 as a roadmap tool

The most practical way to use NIST CSF 2.0 as a roadmap is the profile: creating a "current profile" that describes the present state of capabilities for each function, and a "target profile" that describes where you want to get to within a defined time horizon (12 to 24 months).

The gap between the current profile and the target profile becomes the investment roadmap: what to do first, what can wait, where to concentrate limited resources. SMEs with limited budgets have to prioritize, and NIST CSF 2.0 provides a structure for doing so in a reasoned rather than reactive way.

A practical approach to get started: a half-day workshop with the technical lead and management, using the six functions as a guide, to answer honestly the question "where are we?" for each area. The result does not have to be perfect: it has to be honest and shared. From there you build a realistic improvement plan, with priorities based on actual risk and available resources.

---

NIST CSF 2.0 is not a compliance tool in the traditional sense: there is no audit that certifies conformity to the framework. It is a risk management tool that helps structure thinking and communicate the security posture in a way that management can understand. For manufacturing SMEs looking for a starting point to address OT security systematically, this is its main value.

The MON5 angle

The CSF 2.0 functions map naturally onto the MON5 journey: Identify corresponds to the DISCOVER phase (passive asset discovery, topology, dependencies) and to ANALYZE (continuous inventory, correlation of CVEs with EPSS and real exposure); Detect corresponds to PROTECT, with continuous monitoring and ML-based anomaly detection on native OT protocols. The Detect gap, which the article identifies as the most widespread among manufacturing SMEs, can therefore be closed in phases, without a monolithic project.

The framework's current profile also requires data: truly knowing what is on the network. A good way to build it on real measurements is to start from an OT assessment.