NIST Cybersecurity Framework (CSF) 2.0 Applied to OT

OT Cybersecurity Fundamentals – Estimated reading time: 7 minutes

Introduction

In the first article, we discussed why OT cybersecurity cannot simply be treated as IT cybersecurity (with industrial devices).

In the second article, we looked at the Purdue Model to understand where OT systems sit, how they connect, and where trust boundaries may exist.

Now we can move to the next question:

How do we organize all of this cybersecurity work into a practical risk-management approach?

This is where the NIST Cybersecurity Framework (CSF) 2.0 becomes useful.

The NIST CSF 2.0 provides a common language for organizations to understand, assess, prioritize, and communicate cybersecurity risk. It is designed to be applicable across sectors and organizational sizes, rather than being tied to one specific technology or industry.

For OT environments, this makes CSF 2.0 particularly useful as a management and communication framework.

But there is an important distinction:

CSF 2.0 tells us what cybersecurity outcomes we should work toward. It does not tell us exactly which technical control must be installed.

That distinction becomes very important when applying the framework to OT.

What is the NIST Cybersecurity Framework?

The NIST Cybersecurity Framework 2.0 is a risk-management framework designed to help organizations manage cybersecurity risk.

At its highest level, the CSF is organized into six Functions:

Function	Main question
Govern	How do we establish and oversee cybersecurity risk management?
Identify	What do we have, and what risks do they present?
Protect	What safeguards should be in place?
Detect	How do we know when something is happening?
Respond	What do we do when an incident occurs?
Recover	How do we restore capabilities and improve afterward?

NIST describes these six Functions as the highest level of organization for cybersecurity outcomes in CSF 2.0.

The addition of Govern is one of the important changes introduced in CSF 2.0. It places cybersecurity risk governance at the center of the framework rather than treating governance as something separate from the operational cybersecurity lifecycle.

For an OT organization, this is especially relevant because cybersecurity decisions often involve more than the cybersecurity team.

Operations, engineering, maintenance, safety, IT, management, vendors, and asset owners may all have a role in deciding how cybersecurity risks should be managed.

The Six Functions Applied to OT

The six Functions are broad by design. Their value comes from translating them into outcomes that make sense for the environment being protected.

Let’s look at what it can mean in an OT environment.

1. Govern — Establish the Direction

Govern asks:

How should cybersecurity risk be managed, who is responsible, and how does it support organizational objectives?

In OT, governance is particularly important because cybersecurity decisions can affect production, reliability, safety, maintenance, and business continuity.

For example, an organization may need to establish:

• OT cybersecurity policies and responsibilities
• Risk-management objectives
• Roles of operations, engineering, safety, IT, and cybersecurity teams
• Requirements for third-party and vendor access
• Cybersecurity requirements for new OT projects
• Risk acceptance and escalation processes
• Requirements for cybersecurity changes and exceptions
• Reporting and performance expectations

Consider a simple situation as following:

A vulnerability is discovered in a controller used in a production process. The cybersecurity team may want immediate remediation. The operations team may be concerned about production interruption. Engineering may need to validate the proposed change. The vendor may need to confirm compatibility. Management may need to decide whether temporary risk acceptance is appropriate.

Governance provides the structure for making that decision.

It helps move the conversation from:

“Cybersecurity says this must be fixed.”

to:

“How should this risk be evaluated, prioritized, owned, and treated?”

2. Identify — Understand What You Have

Identify asks:

What assets, processes, dependencies, and risks do we need to understand?

This Function is particularly important in OT because organizations cannot protect what they do not understand.

A practical OT implementation may include:

• OT asset inventory
• Process and system mapping
• Asset ownership
• Criticality assessment
• Communication and dependency mapping
• Identification of external connections
• Vendor and remote-access dependencies
• Vulnerability and exposure assessment
• Business, operational, safety, and environmental consequences

This connects directly to the work introduced in the previous article.

The Purdue Model can help us understand where systems sit.

The Identify Function helps us understand what those systems do, what they depend on, and what risks they introduce.

For example:

PLC → HMI → Historian → Business Reporting

The architecture tells us that these systems are connected.

The Identify Function asks additional questions:

• Who owns each system?
• What process does it support?
• What happens if the connection fails?
• Which communications are required?
• Which system is critical?
• What external dependencies exist?
• What could happen if the asset is compromised?

The result is more than an asset list.

It becomes a foundation for understanding “cybersecurity risk in operational context”.

3. Protect — Put Safeguards in Place

Protect asks:

What safeguards are needed to reduce cybersecurity risk?

In OT, this may involve familiar cybersecurity practices such as:

• Identity and access management
• Least-privilege access
• Network segmentation
• Firewall rules
• Secure remote access
• Secure configuration
• Backup and recovery preparation
• Patch and vulnerability management
• Application white-listing
• Security awareness and training

But OT changes the way these safeguards need to be implemented.

For example, segmentation may sound straightforward:

“Separate the OT network from the enterprise network.”

But a real implementation requires understanding:

• Which systems actually need to communicate?
• Which protocols are required?
• Is the communication bidirectional?
• What happens if the connection is blocked?
• Could the firewall introduce operational problems?
• How will the change be tested?
• What is the rollback procedure?

So, the Protect Function should not be interpreted as:

Install more security controls.

A better interpretation is:

“Implement appropriate safeguards that reduce risk without creating unacceptable operational consequences”

4. Detect — Know When Something Is Happening

Detect asks:

How can we identify cybersecurity events or conditions that may require attention?

In OT, detection can include:

• Network monitoring
• Security event monitoring
• Authentication monitoring
• Configuration-change monitoring
• Controller or system alarms
• Remote-access monitoring
• Anomalous communication detection
• Endpoint or server monitoring
• Monitoring of critical OT assets

But detection in OT has another important dimension: Context.

A network event by itself may not tell the whole story. Suppose an engineering workstation suddenly communicates with a controller.

Is that malicious?

Maybe.

But it could also be a legitimate maintenance activity.

Without operational context, security monitoring may generate large amounts of noise.

Effective OT detection therefore requires coordination between cybersecurity monitoring and operational knowledge.

The objective is not simply to generate more alerts.

It is to recognize “meaningful deviations that could affect the security or operation of the process”.

5. Respond — Coordinate the Reaction

Respond asks:

What should we do when a cybersecurity incident occurs?

In IT environments, incident response may focus heavily on isolating systems, investigating evidence, removing malicious activity, and restoring services.

Those activities can also apply to OT.

But OT response requires additional coordination.

For example:

Should an affected system immediately be disconnected?

That may be the correct decision in one scenario.

In another scenario, disconnecting the system could remove operator visibility, interrupt a required control function, or create additional operational consequences.

Therefore, OT incident response may require coordination among cross sectional teams, such as:

• Cybersecurity
• Operations
• Control engineering
• Maintenance
• Safety
• Management
• Vendors or system integrators

Response plans should therefore consider not only:

“How do we contain the cyber incident?”

but also:

“How do we contain the incident while maintaining safe and stable operation?”

This is one of the areas where OT-specific guidance becomes particularly important.

6. Recover — Restore and Learn

Recover asks:

How do we restore capabilities and improve after an event?

Recovery in OT may involve:

• Restoring servers and workstations
• Restoring controller configurations
• Recovering engineering project files
• Restoring historian or operational data
• Re-establishing network communications
• Validating system functionality
• Confirming process stability
• Coordinating safe return to operation
• Reviewing lessons learned

A backup alone does not guarantee successful OT recovery.

The organization needs confidence that:

The backup exists → the backup is usable → the restoration process works → the restored system can be safely returned to operation.

This is why recovery planning should be tested rather than treated as a document that only exists for compliance purposes.

NIST’s current OT work also emphasizes the importance of backup and recovery capabilities for OT environments.

Putting the Six Functions Together

The six Functions should not be treated as six independent cybersecurity projects.

They form a connected risk-management cycle.

A simplified OT view could look like this:

CSF Function	OT Application
Govern	Establish ownership, risk decisions, policies, and accountability
Identify	Inventory assets, understand processes, dependencies, and criticality
Protect	Apply appropriate access, segmentation, configuration, and other safeguards
Detect	Monitor systems, communications, changes, and abnormal activity
Respond	Coordinate cyber incident response with operations and safety considerations
Recover	Restore systems, validate operation, and improve recovery capability

The important point is that the Functions are interconnected.

For example:

If an organization does not properly Identify its critical OT assets, it becomes difficult to determine what should be Protected.

If critical assets are not understood, it becomes harder to establish effective Detection requirements.

If detection is weak, Response may be delayed.

If recovery requirements were never identified, Recover may take much longer than expected.

And all of these activities require Governance to establish ownership, priorities, and decision-making.

---

CSF 2.0 Is Not a Technical Control Checklist

This is one of the most important points when introducing CSF 2.0 to an OT audience.

The CSF does not prescribe a specific technical implementation.

NIST describes CSF 2.0 as a taxonomy of high-level cybersecurity outcomes. It does not prescribe exactly how those outcomes must be achieved. Instead, the framework can connect organizations to additional standards, guidelines, implementation examples, and other resources.

For example:

CSF outcome:
Control access to systems and assets.

That does not automatically mean:

“Deploy MFA everywhere.”

The actual solution depends on the environment.

In OT, implementation could involve a combination of:

• Account management
• Role-based access
• Privileged access controls
• Network segmentation
• Jump servers
• Remote-access controls
• Physical access restrictions
• Compensating controls for legacy systems

The appropriate approach depends on the asset, process, architecture, risk, technology constraints, and operational requirements.

This is why CSF 2.0 works well as a framework for decision-making, but should not be treated as the entire technical answer.

Profiles: Turning the Framework into Something Relevant

One of the most useful CSF 2.0 concepts for organizations is the Organizational Profile.

A Profile describes cybersecurity outcomes that are relevant to a specific organization or situation.

NIST defines:

Current Profile
What cybersecurity outcomes the organization is currently achieving.

Target Profile
The cybersecurity outcomes the organization wants to achieve.

Comparing the two helps identify gaps and prioritize improvements.

This can be particularly useful for OT.

Imagine a facility where:

Current state:

• Asset inventory is incomplete
• Vendor remote access is inconsistently managed
• OT network monitoring is limited
• Backups exist but restoration has not been tested

The organization can define a Target Profile that describes the desired outcomes.

The resulting gap analysis can then help answer:

What should we improve first?

This is much more useful than simply saying:

“We need better OT cybersecurity.”

The Profile turns a broad ambition into a structured conversation about current state, target state, gaps, priorities, and progress.

Tiers: Understanding the Rigor of Risk Management

CSF 2.0 also introduces Tiers that can be used to characterize the rigor of an organization’s cybersecurity risk governance and management practices. NIST defines four Tiers:

• Tier 1 — Partial
• Tier 2 — Risk Informed
• Tier 3 — Repeatable
• Tier 4 — Adaptive

Tiers can be applied to Organizational Profiles to provide context around how an organization manages cybersecurity risk and to help monitor improvement over time.

For OT organizations, this can support maturity discussions.

For example, an organization may have cybersecurity procedures, but those procedures may not be consistently applied across all facilities.

Another organization may have repeatable processes across multiple sites, with defined ownership, metrics, reviews, and continuous improvement.

The Tier concept helps provide a common language for discussing these differences.

However, the objective should not simply be:

“We need to reach Tier 4.”

The appropriate level of rigor should depend on organizational objectives, risk, threat landscape, regulatory requirements, operational needs, and other factors.

The framework is there to support risk decisions—not to turn cybersecurity maturity into a race for a particular number.

Why CSF 2.0 Works Well for OT Leadership

One of the strongest advantages of CSF 2.0 is that it provides a language that can be understood by different stakeholders.

An OT engineer may think about:

Process → Control Logic → PLC → HMI → Historian → Network → Business Environment

A cybersecurity team may think about:

Identity → Vulnerability → Segmentation → Monitoring → Incident response

Management may think about:

Risk → Business impact → Investment → Resilience → Accountability

CSF 2.0 can help connect those perspectives.

Instead of discussing cybersecurity only in terms of technologies, teams can discuss:

• What outcome are we trying to achieve?
• What risk are we trying to reduce?
• Who owns that risk?
• What is our current capability?
• Where do we want to be?
• What gap prevents us from getting there?

That makes the framework useful not only for cybersecurity professionals, but also for leadership, asset owners, engineering teams, and other stakeholders involved in OT risk decisions.

The Strength of Being Sector-Agnostic

CSF 2.0 is intentionally broad.

It can be used by organizations across different sectors and technology environments.

This is useful for organizations that operate multiple types of facilities.

For example, a company may have:

• Manufacturing plants
• Utilities
• Warehouses
• Building automation
• Remote facilities

Each environment may have different technologies and operational characteristics.

The same high-level cybersecurity language can still be used to communicate risk across those environments.

This creates an important advantage:

The technical implementation can vary, while the risk-management language remains consistent.

But CSF 2.0 has a Limitation for OT

The same characteristic that makes CSF 2.0 powerful also creates its limitation.

Because CSF 2.0 is intentionally broad, it does not provide all the engineering detail required to secure a specific OT environment.

It does not by itself answer questions such as:

• How should an industrial control network be segmented?
• Where should an Industrial DMZ be placed?
• How should a particular PLC environment be protected?
• How should remote vendor access be engineered?
• How should legacy OT systems be handled?
• What technical safeguards are appropriate for a particular architecture?
• How should security requirements be validated against the operational process?

Those questions require more specialized guidance.

This is where NIST SP 800-82 Rev. 3 becomes important.

NIST SP 800-82 Rev. 3 specifically addresses OT security while considering the unique performance, reliability, and safety requirements of OT. It also provides guidance on OT topologies, threats, vulnerabilities, and security safeguards.

In other words:

• CSF 2.0 helps organize the cybersecurity conversation.
• SP 800-82 helps make that conversation OT-specific.

A Simple Way to Think About the Relationship

A useful mental model is:

• CSF 2.0 → What cybersecurity outcomes should we achieve?
• OT architecture → Where do those outcomes need to be applied?
• OT risk assessment → What matters most and why?
• NIST SP 800-82 → What OT-specific practices and safeguards can help achieve them?

This is not about choosing one framework and ignoring everything else.

The strength comes from using the right reference for the right question.

A Practical Starting Point

If an OT organization wants to begin applying CSF 2.0, it does not need to immediately build a complicated framework implementation.

Start with a manageable scope.

For example, choose one production area, process unit, or OT system.

Then ask:

Govern – Who owns the cybersecurity risk?

Identify – What assets and processes are involved?

Protect – What safeguards are already in place?

Detect – How would we know if something abnormal happened?

Respond – Who would make the operational and cybersecurity decisions during an incident?

Recover – How would we safely restore the affected capability?

Then document the Current Profile.

After that, define the Target Profile.

The difference between the two becomes the starting point for a practical improvement roadmap.

This approach also helps prevent a common mistake:

Trying to secure everything at once without understanding which risks matter most.

Key Takeaway

The NIST Cybersecurity Framework 2.0 provides something valuable for OT cybersecurity:

“A common language for managing cyber risk”

It helps connect leadership, cybersecurity, engineering, operations, and other stakeholders around common outcomes.

But CSF 2.0 should not be treated as a technical blueprint.

For OT, the framework needs to be interpreted through the realities of the physical process, operational requirements, architecture, safety considerations, asset lifecycle, and risk consequences.

A simple way to remember it is:

• CSF 2.0 gives us the language
• OT engineering gives us the context
• Risk assessment helps us set the priorities

And that brings us to the next step.

Next Step

In this article, we used NIST CSF 2.0 as a high-level framework for organizing OT cybersecurity risk.

But how do we translate those high-level outcomes into practical OT security considerations?

The next article will introduce NIST SP 800-82 Rev. 3 — Guide to Operational Technology (OT) Security, including its OT-specific perspective, architectures, threats, vulnerabilities, and security recommendations.

“NIST SP 800-82 Rev. 3 — From Cybersecurity Framework to OT-Specific Guidance”

---

References

• NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29, February 2024.
• NIST CSF 2.0: Quick-Start Guide for Creating and Using Organizational Profiles, NIST SP 1301.
• NIST CSF 2.0: Quick-Start Guide for Using the CSF Tiers, NIST SP 1302.
• NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security, September 2023.