CISA Cross-Sector Cybersecurity Performance Goals for OT

01Key takeaways

1. 01

   The CISA CPGs are a voluntary, prioritized baseline of cybersecurity practices for critical infrastructure, mapped to the NIST Cybersecurity Framework and tagged by cost, complexity and impact.

2. 02

   The CPGs are organized into Identify, Protect, Detect, Respond and Recover, with several goals written specifically for OT realities such as legacy assets, default credentials and limited downtime.

3. 03

   OT-relevant goals include asset inventory, mitigating known exploited vulnerabilities, changing default passwords, multifactor authentication, network segmentation, and limiting OT connections to public internet.

4. 04

   The CPGs are a floor, not a ceiling. They point toward deeper standards such as NIST SP 800-82 Rev. 3 and ISA/IEC 62443 for a full OT security program.

5. 05

   Goals that aim to limit external and bidirectional connectivity are where one-way transfer and segmentation help operators meet the intent without exposing control systems.

02What the CISA Cross-Sector CPGs are

The Cross-Sector Cybersecurity Performance Goals are a set of baseline cybersecurity practices published by the U.S. Cybersecurity and Infrastructure Security Agency (CISA). They were created in response to a 2021 national security memorandum that directed CISA, working with NIST, to develop common performance goals for critical infrastructure across all sectors.

The CPGs are deliberately short. Rather than restating an entire framework, CISA selected a prioritized subset of practices that deliver high risk reduction relative to the cost and effort required. Each goal is written in plain language, tied to a real-world threat, and mapped to the NIST Cybersecurity Framework (CSF) so an organization can see where it fits a larger program.

Short version: the CPGs are a voluntary, prioritized floor of cybersecurity practices for critical infrastructure, including a clear set of goals that apply to OT and ICS environments.

03Why the CPGs matter for OT and ICS

Most cybersecurity guidance is written with IT in mind. The CPGs are unusual because CISA built them with OT realities in view. Several goals acknowledge that industrial systems run for years, that patching windows are scarce, that downtime can affect safety and physical operations, and that many field devices still ship with default credentials.

That framing makes the CPGs a useful starting conversation for plants that are early in their security journey. They give an operator a defensible, ordered list of what to do first, without requiring a full ISA/IEC 62443 program on day one. They also help a board or regulator understand maturity in terms that are consistent across the water, energy, manufacturing and transportation sectors.

The threat context is concrete. CISA and partners have repeatedly warned about adversaries targeting exposed OT, from opportunistic attacks on internet-facing programmable logic controllers and human-machine interfaces to state-aligned activity against water and energy systems. Many of those incidents trace back to a CPG that was not yet in place: a default password, an unpatched known exploited vulnerability, or an OT device reachable from the public internet.

04How the CPGs are organized

The CPGs are grouped under the five NIST CSF functions, which keeps them aligned with the framework most critical infrastructure programs already reference. Each goal carries a short outcome, the threat it addresses, recommended actions, and a set of TTP or risk references so teams can see the underlying attacker behavior.

Identify

Know what you have. Asset inventory, including OT assets, and a process to act on vendor and CISA vulnerability information.

Protect

Reduce exposure. Default password changes, multifactor authentication, network segmentation, and limiting connections from OT to the public internet.

Detect

See activity. Log collection, detection of relevant threats and TTPs, and security awareness across the workforce.

Respond

Act on incidents. An incident response plan, defined reporting paths, and the ability to coordinate with vendors and CISA.

Recover

Restore operations. System backups, an incident recovery plan, and tested procedures to bring OT back to a known good state.

Each goal is also rated for cost, complexity and impact. That rating is what makes the CPGs practical: a small utility can sort the list and start with high-impact, low-cost actions such as changing default credentials before tackling harder items like full network segmentation.

05The OT-relevant goals that matter most

Not every CPG is OT-specific, but a clear cluster speaks directly to industrial environments. These are the goals an OT security lead should be able to evidence first.

• Asset inventory: maintain an inventory of OT and IT assets, because you cannot protect, patch or segment what you have not catalogued.
• Mitigating known exploited vulnerabilities: track CISA's Known Exploited Vulnerabilities (KEV) catalog and remediate or compensate for the flaws attackers are actively using.
• Changing default passwords: replace default and shared credentials on field devices, HMIs and engineering workstations, a recurring root cause in OT intrusions.
• Multifactor authentication: require MFA for remote and administrative access, including vendor and engineering access into OT.
• Network segmentation: separate OT from IT and from the public internet so a compromise on one side cannot freely reach control systems.
• Limiting OT connections to the public internet: remove or tightly control any direct exposure of OT assets, and prefer one-way or disconnected paths where data only needs to leave the environment.

These goals reinforce each other. An accurate asset inventory feeds vulnerability management; segmentation makes default-credential exposure less catastrophic; and limiting external connectivity reduces the number of places where MFA and patching have to be perfect.

06Mapping the CPGs to NIST CSF, SP 800-82 and IEC 62443

The CPGs are not a standalone standard. They are a curated entry point that maps upward into the frameworks most OT programs are measured against. Understanding the mapping prevents teams from treating the CPGs as the finish line.

NIST CSF

Every CPG is mapped to a CSF subcategory. Use the CSF as the organizing model and the CPGs as the prioritized starting subset within it.

NIST SP 800-82 Rev. 3

The Guide to Operational Technology (OT) Security provides the depth the CPGs do not, including OT-specific risk management, architecture and control overlays based on SP 800-53.

ISA/IEC 62443

The IACS standard adds zones and conduits, security levels and supplier requirements. CPG segmentation goals translate naturally into 62443 zone-and-conduit design.

CISA KEV catalog

The Known Exploited Vulnerabilities catalog operationalizes the CPG vulnerability-management goal by naming the flaws attackers are actively exploiting.

A practical sequence is to use the CPGs to establish and evidence a baseline, then adopt NIST SP 800-82 Rev. 3 and ISA/IEC 62443 to mature the program toward a defensible, auditable target state.

07Putting the OT CPGs into practice

Adopting the CPGs is less about buying products and more about establishing repeatable practices. A workable sequence for an OT environment looks like this.

• Build and maintain an asset inventory, capturing OT devices, firmware versions, protocols and network paths, ideally using passive discovery to avoid disrupting fragile equipment.
• Cross-reference assets against the CISA KEV catalog and vendor advisories, then patch where feasible or apply compensating controls where it is not.
• Eliminate default and shared credentials on field devices, HMIs and engineering workstations, and enforce MFA for all remote and administrative access.
• Map data flows across the IT/OT boundary, then segment so OT zones do not have unnecessary reachability to IT or the internet.
• Identify boundaries where OT only needs to publish data outward, and replace bidirectional links with one-way or scheduled-disconnect transfer.
• Forward OT logs to monitoring, and document an incident response and recovery plan that includes tested backups and a known-good restore path.

Treat the CPGs as a living checklist. Re-run the asset inventory and KEV cross-reference on a schedule, because both your environment and the threat landscape change.

08Common pitfalls when adopting the CPGs

The CPGs are simple to read but easy to misapply. Most failures come from treating a voluntary baseline as either a comprehensive program or a checkbox exercise.

• Treating the CPGs as the ceiling rather than the floor, and stopping before adopting SP 800-82 or IEC 62443 depth.
• Running active scans against fragile OT to build an inventory, and causing the outage you were trying to prevent.
• Claiming segmentation while leaving a management interface, jump host or maintenance VPN that quietly restores a two-way path.
• Enforcing MFA on IT remote access but exempting vendor and engineering access into OT, which is exactly where adversaries aim.
• Backing up systems without ever testing restoration, so the recover goal exists on paper but not in reality.
• Confusing the IT-focused CPGs with the OT realities and applying patch cadences that ignore safety and availability constraints.

09Where one-way transfer and segmentation fit the CPGs

Two of the most impactful OT goals, network segmentation and limiting connections from OT to the public internet, are about reducing reachability. That is the same problem space where one-way data transfer is strongest.

Many OT boundaries exist only to send data out: telemetry to enterprise reporting, logs to a SOC, historian data to analytics, or backups to a recovery environment. None of those flows require the destination to initiate traffic back into the plant. A firewall can restrict that return path by policy, but the path still technically exists and can drift open. A data diode removes the return path itself, which makes the intent of the connectivity-limiting goals easier to evidence.

For teams aligning architecture to the CPGs, an AIRGAPNET controlled connectivity pattern can be evaluated alongside firewall segmentation and data diodes. The deciding question is which OT boundaries must be online and two-way, which only need to publish data one way, and which can be disconnected by default and connected only on a defined schedule. A data diode is one control among many; it does not replace inventory, patching, identity, monitoring or recovery.

10Voluntary today, referenced in regulation tomorrow

The CPGs are voluntary. CISA is explicit that they do not create binding requirements. But they increasingly serve as the common language for sector-specific expectations, and several regulators and sector risk-management agencies point to them when describing baseline cyber hygiene.

For operators, that means adopting the CPGs is rarely wasted effort even where no rule applies. The same practices underpin sector regulations such as TSA security directives for pipelines and rail, NERC CIP for the bulk electric system, and EPA expectations for water systems. Documenting CPG adoption builds evidence that translates across audits and toward more prescriptive standards as they emerge.

11Closing thought

The value of the CISA CPGs is that they make prioritization defensible. They tell an OT team what to do first, why it matters, and how it maps to the frameworks they will eventually be measured against.

Start with the goals that reduce exposure the most for the least disruption: inventory, default credentials, known exploited vulnerabilities, MFA, segmentation, and limiting OT's reach to the internet. Where a boundary only needs to publish data, ask whether a one-way path would satisfy the goal more cleanly than a rule that has to be maintained forever.

FAQFrequently asked questions

SRCSources of record