CISA Cross-Sector Cybersecurity Performance Goals (CPGs), explained

CISA's Cross-Sector Cybersecurity Performance Goals (CPGs) are, in the agency's own words, "a prioritized subset of information technology (IT) and operational technology (OT) cybersecurity practices aimed at meaningfully reducing risks to both critical infrastructure operations and the American people." They were built from "the most common and impactful threats and adversary tactics, techniques, and procedures (TTPs) observed by CISA and its government and industry partners," which CISA says makes them "a common set of protections that all critical infrastructure entities — from large to small — should implement." Unlike a certification scheme or a full risk-management framework, CISA is explicit that the CPGs are meant to be "a floor — not a ceiling" of cybersecurity protections.

Where the CPGs came from

In July 2021, President Biden signed National Security Memorandum (NSM)-5, Improving Cybersecurity for Critical Infrastructure Control Systems. Per CISA's own documentation, NSM-5 "required CISA, in coordination with the National Institute for Standards and Technology (NIST) and the interagency community, to develop baseline CPGs that are consistent across all critical infrastructure sectors." CISA ran a public comment period in early 2022, published CPG version 1.0 in October 2022 with an initial structure mapped to cybersecurity standards and best practices, and then reorganized the goals around the NIST Cybersecurity Framework's functions in the March 2023 version 1.0.1 release, after sector partners asked for clearer CSF alignment.

CISA's statutory basis for the program is 6 U.S.C. §652: the CPG 2.0 report states CISA "collaborates with the National Institute of Standards and Technology (NIST) and other federal partners to maintain baseline cybersecurity goals for critical infrastructure," alongside a related but separate workstream of sector-specific goals (SSGs) developed since 2023 with federal sector risk management agencies.

Version 2.0: a sixth function, GOVERN

CISA released CPG Version 2.0 to "align with the NIST Cybersecurity Framework 2.0, incorporate three years of operational feedback, and address emerging threats with data-driven recommendations." The headline structural change is a new sixth function, GOVERN, mirroring NIST CSF 2.0's own addition of a governance function (see our NIST CSF 2.0 guide). CISA's change log describes the goal: "The new GOVERN function integrates leadership accountability, oversight, and risk management into everyday cybersecurity practices."

Alongside the new function, CISA's report documents three other kinds of change from version 1.0.1:

• Consolidation. OT-only goals were folded into universal ones that now cover IT, IoT and OT together (for example, the old 1.B/1.C/1.D became a single 1.A), because, as CISA puts it, "modern infrastructures blur IT, internet of things (IoT), and OT."
• Four net-new goals, filling gaps CISA says 1.0.1 didn't explicitly address: Proactive Program Management (1.B), Managed Service Provider Risk (1.E), Least-Privilege Enforcement (3.H), and Incident Communication Procedures (5.A).
• Three deletions, with each one's intent folded into a broader goal rather than dropped: Security.txt Deployment merged into Maintain Vulnerability Disclosure/Reporting Process; Detect Relevant Threats/TTPs merged into Identify Adverse Events; and Vendor/Supplier Cybersecurity Requirements merged into Supply Chain Incident Reporting & Vulnerability Disclosure.

CISA also replaced the old "Complexity" rating with "Ease of Implementation" and added worked definitions for the Cost/Impact/Ease-of-Implementation scoring that accompanies every goal.

The six functions and their goals

Counting the lettered goals in CISA's CPG 2.0 report:

Function	Goals	Example
GOVERN	1.A–1.E (5)	1.A Establish Cybersecurity Responsibilities; 1.E Manage Risks from Managed Service Providers
IDENTIFY	2.A–2.E (5)	2.A Manage Organizational Assets; 2.B Mitigate Known Vulnerabilities
PROTECT	3.A–3.S (19)	3.A Change Default Passwords; 3.F Implement Multifactor Authentication (MFA)
DETECT	4.A–4.B (2)	4.A Establish Malicious Code Detection; 4.B Identify Adverse Events
RESPOND	5.A–5.B (2)	5.A Establish Incident Communication Procedures; 5.B Establish Incident Reporting Procedures
RECOVER	6.A (1)	6.A Execute Incident Recovery Plan

Each goal in the report is documented with the same fixed structure: an Outcome, a Recommended Action, the Risk Addressed and its Scope, a NIST CSF 2.0 Reference, additional NIST SP 800-53/800-82 cross-references, Support Resources, and ratings for Cost, Impact, and Ease of Implementation. CISA's selection criteria require every goal to have "demonstrated value in reducing the risk or impact of commonly observed, cross-sector threats," be "clear, actionable, and easily definable," and be "reasonably straightforward and not cost-prohibitive for small- and medium-sized entities to successfully implement" — CISA's own worked example is "ensuring that none of an organization's internet-facing systems have any known exploited vulnerabilities (KEVs)" as a CPG, versus "implement zero trust" as not currently suitable because many small organizations can't absorb it before finishing the more basic goals.

CISA's goal-count conventions have shifted across published versions as items were split, merged, or renumbered, and the agency states a targeted revision cycle of roughly 24 to 36 months for CPG 2.0 (the original 1.0.1 slick sheet cites a faster 6–12 month cycle). Treat any specific total as a snapshot of the version reviewed, and confirm against the current CPG List and CPG Checklist on cisa.gov before building compliance tooling around an exact count.

Not mandatory, not comprehensive, not a maturity model

CISA's report is direct about what the CPGs are not. Under a list titled "Importantly, the CPGs are not," it states they are not Comprehensive ("do not identify all the cybersecurity practices needed to protect every organization"), not a risk management or full cybersecurity program ("do not cover broader approaches to risk management or risk prioritization that other frameworks, such as the NIST CSF, articulate"), not Mandated by CISA ("CISA intends for organizations to voluntarily adopt the CPGs"), and not a maturity model (the practices apply uniformly rather than being tiered, though the companion CPG Worksheet does let organizations rank goals by Cost, Impact, and Ease of Implementation for internal prioritization).

How the CPGs relate to the NIST CSF

CISA frames the CPGs as complementary to, not a substitute for, the NIST Cybersecurity Framework: "The CPGs are a prioritized subset of the NIST CSF categories and subcategories and do not identify all the cybersecurity practices needed to protect every organization." Every CPG practice maps to a corresponding NIST CSF subcategory, and CISA states that "organizations that have already adopted and implemented the NIST CSF will not need to perform additional work to implement the relevant CPGs." In practice CISA positions the CPGs as a quick-start layer — identify which practices yield the greatest risk reduction, prioritize investment, and communicate that prioritization to non-technical leadership — before or alongside building a fuller program on the CSF (see our NIST CSF 2.0 guide) or on sector-specific standards such as ISA/IEC 62443 for OT environments (see our IEC 62443-3-3 guide).

A workable starting point

1. Run the self-evaluation first. CISA's own four-step process starts with reviewing existing controls against the CPG list — organizations already following NIST CSF or ISA/IEC 62443 may already satisfy several goals without extra work.
2. Use the Cost/Impact/Ease-of-Implementation ratings to sequence investment, not just to check a box — CISA designed these ratings specifically to help communicate trade-offs to non-technical executives and boards.
3. Don't treat the CPGs as a finish line. CISA calls them a floor; a mature program should use them as the first layer under a broader NIST CSF-based program.
4. Revisit the goal list on CISA's own cadence. With a stated 24–36 month revision cycle (and a track record of structural changes, like the GOVERN function in 2.0), hard-coding a specific goal count into internal tooling risks drifting out of date.

SoftWSP's device and firmware security work can help map a connected product's security program against the CPGs and adjacent frameworks like the NIST CSF and ISA/IEC 62443: see device & firmware security services.

This guide summarises CISA's own published CPG reports; it does not constitute legal or compliance advice, and exact goal counts should be verified against the current CPG List and CPG Checklist on cisa.gov before relying on them.