Many critical infrastructure operators, and the smaller suppliers around them, need a short list of the controls that stop the most common intrusions, not another thousand-line framework. CISA's Cross-Sector Cybersecurity Performance Goals (CPGs) are that list: a voluntary, prioritised baseline of 38 goals, each tied to a specific risk and attacker technique, with IT and OT guidance side by side. This guide explains what the CPGs are, how they are structured, which goals deal with identities and credentials (including service accounts and default device passwords), how to implement and evidence them, and how they map to NIST CSF 2.0, SP 800-53 and MITRE ATT&CK. It is written for security leads, OT engineers and executives in critical infrastructure organisations and their suppliers, and for anyone using the CPGs as a quick-start baseline before a fuller framework.
Key takeaways
- A floor, not a ceiling. CISA describes the CPGs as a minimum baseline of high-impact practices, not a complete programme, a risk management framework or a maturity model.
- Version 1.0.1 is the published text. CISA first released the CPGs in October 2022 and updated them in March 2023 (v1.0.1), reordering the goals to the NIST CSF functions and strengthening the MFA goal to phishing-resistant MFA; CISA states it is updating the CPGs to align with NIST CSF 2.0.
- Credentials dominate the baseline. At least eight goals (2.A to 2.E, 2.G, 2.K, 2.N) deal directly with passwords, accounts, MFA and secrets, and goal 2.C explicitly requires service and machine accounts to have unique passwords.
- Every goal states the threat it addresses. Each CPG lists the risk and the ATT&CK techniques it mitigates, which makes prioritisation and board reporting straightforward.
- Sector goals build on top. CISA and the Sector Risk Management Agencies have begun publishing sector-specific goals (for example energy and healthcare) that extend the cross-sector set.
What it is and who it applies to
The CPGs were developed by CISA at the direction of the July 2021 National Security Memorandum on improving cybersecurity for critical infrastructure control systems, with input from industry through a public GitHub discussion. They are voluntary: CISA does not mandate them, and no penalty attaches to non-adoption. Their value lies in prioritisation. Each goal was selected because it addresses a risk that CISA and its partners see repeatedly in real intrusions, and because it can be adopted at reasonable cost by organisations of any size.
- Primary audience: owners and operators in the 16 US critical infrastructure sectors, especially small and medium organisations without a mature programme.
- Secondary audience: suppliers and managed service providers to those sectors, since several goals (1.G, 1.H, 1.I) push requirements into contracts.
- Outside the US: the goals are written generically enough to serve as a baseline anywhere; organisations under NIS2 or similar regimes can use them as a starting checklist before a full risk-based programme. See the NIS2 Directive Guide.
- Relation to NIST CSF: each CPG maps to a CSF subcategory, but the CPGs do not cover every subcategory. Organisations already running a CSF programme will meet many CPGs already and can use the CPGs as a short list of what to fix first. See the NIST CSF 2.0 Guide.
Status note: the CISA CPG page now presents the goals under the six CSF 2.0 functions, including Govern, and states that CISA is in the process of updating the CPGs to CSF 2.0. Check the CPG page for the current version before formal adoption; the goal IDs in this guide follow v1.0.1.
Structure and key requirements
In v1.0.1 the 38 goals are numbered by CSF function: 1 Identify (9 goals), 2 Protect (24), 3 Detect (1), 4 Respond (3) and 5 Recover (1). Each goal has a title, an outcome, the TTP or risk addressed, a recommended action, and, in the CPG Worksheet, rough estimates of cost, impact and complexity.
| Function | Goals | What they cover |
|---|---|---|
| Identify (1) | 1.A to 1.I | Accountable cybersecurity leader (1.A) and OT leader (1.C); asset inventory updated at least monthly (1.B); IT/OT relationships (1.D); mitigating known exploited vulnerabilities (1.E); third-party validation such as penetration tests and tabletops (1.F); supplier incident reporting, vulnerability disclosure and security requirements in procurement (1.G to 1.I) |
| Protect (2) | 2.A to 2.X | Account and credential hygiene (2.A to 2.E, 2.G, 2.K, 2.N); network segmentation (2.F); training (2.H, 2.I); encryption (2.J); disabling macros (2.L); configuration and topology documentation (2.M, 2.P); email security (2.O); hardware and software approval (2.Q); backups (2.R); incident response plans (2.S); log collection and secure storage (2.T, 2.U); unauthorised devices (2.V); no exploitable services on the internet (2.W); limiting OT internet connections (2.X) |
| Detect (3) | 3.A | Documenting relevant threats and TTPs and keeping the ability to detect them |
| Respond (4) | 4.A to 4.C | Public vulnerability disclosure (4.A); security.txt on public web domains (4.B); incident reporting to CISA, regulators and ISACs (4.C) |
| Recover (5) | 5.A | Recovery planning and preparedness for business- or mission-critical assets |
Several recommended actions carry concrete values that make them testable: an asset inventory refreshed at least monthly (1.B); passwords of at least 15 characters where technically feasible (2.B); credentials revoked by the day an employee leaves (2.D); new staff trained within 10 days (2.H); DMARC set to "reject" with SPF, DKIM and STARTTLS (2.O); backups of critical systems at least annually, stored separately and tested (2.R); incident response plans exercised at least annually (2.S). Goal 1.E ties vulnerability work to the CISA Known Exploited Vulnerabilities Catalog for internet-facing systems, with compensating controls for OT assets that cannot be patched. See the Zero-Day and Exploited Vulnerabilities Guide.
Identity and NHI requirements
The identity goals are the heart of the baseline, because valid accounts remain the most reliable way into both IT and OT. The table summarises them with the ATT&CK techniques CISA lists or that they most directly counter.
| Goal | Recommended action | Non-human identity angle | ATT&CK |
|---|---|---|---|
| 2.A Changing default passwords | Policy requiring vendor default passwords to be changed before devices join a network; document compensating controls and monitor logins where a default (for example hard-coded) cannot be changed | PLCs, HMIs, network appliances and appliances' built-in admin and service accounts | T1078.001 Default Accounts |
| 2.B Minimum password strength | 15+ character passwords where technically feasible; plan to replace assets that cannot support them | Service account passwords should be long, random and vaulted, not human-memorable | T1110 Brute Force |
| 2.C Unique credentials | No reuse across services or between IT and OT; service and machine accounts have passwords unique from user accounts | Explicit NHI requirement: one credential per service, never shared with a person | T1078 Valid Accounts |
| 2.D Revoking credentials for departing employees | Disable accounts and collect badges and tokens by the day of departure | Rotate any secrets, API keys or service account passwords the leaver knew or owned; reassign NHI ownership | T1078 Valid Accounts |
| 2.E Separating user and privileged accounts | Admins use a separate unprivileged account for daily tasks; privileges reviewed regularly | Service accounts should not hold interactive or domain admin rights by default | T1078 Valid Accounts |
| 2.G Detection of unsuccessful automated login attempts | Log failed logins, alert on repeated failures, temporary lockout | Alert on failures for service accounts too, but avoid lockouts that break production; prefer alerting plus investigation | T1110 Brute Force |
| 2.K Phishing-resistant MFA | Strongest available MFA, hardware-based first, SMS only as a last resort; MFA for remote access to OT | Workloads cannot use MFA: replace static secrets with federated, short-lived credentials | T1133 External Remote Services, T1110 |
| 2.N Secure sensitive data | No credentials in plaintext; use a password manager or secrets vault; restrict access | Covers API keys, tokens, connection strings and certificates in scripts, configuration and code | T1552 Unsecured Credentials, T1003 OS Credential Dumping |
Three identity points are easy to miss. First, goal 2.C is the only place in the baseline that names service and machine accounts, but goals 2.A, 2.B, 2.D and 2.N apply to them just as much. Second, the CPG on departing employees is written for people; for NHIs the equivalent trigger is an owner leaving or an application being retired, which needs its own process. See the Service Account Security Guide and the Secrets Management Guide. Third, MFA (2.K) protects people only. A service account with a static password on a VPN or remote access gateway bypasses it entirely, so remote access for automation should use certificate or federated workload credentials, scoped and monitored. The Colonial Pipeline ransomware attack began with an unused VPN account that had never been disabled and did not require MFA: goals 2.D and 2.K together would have closed that path.
Implementation steps
The CPGs are short enough to adopt as a single programme, but not all at once. CISA's Worksheet ranks goals by cost, impact and complexity; most organisations should start with the cheap, high-impact identity and exposure goals.
- Appoint owners (1.A, 1.C): name one accountable cybersecurity leader and, where OT exists, one OT security leader. Without this, nothing else has an owner.
- Baseline the checklist: download the CPG Checklist and Matrix, record current state per goal with evidence, and use the Worksheet's cost, impact and complexity estimates to rank gaps. Plan to repeat the exercise after 12 months, as CISA suggests.
- Close external exposure first (2.W, 2.X, 1.E): remove internet-exposed RDP and other risky services, take OT off the public internet unless required, and patch or mitigate KEV-listed vulnerabilities on internet-facing assets.
- Fix credentials (2.A to 2.E, 2.K, 2.N): enforce phishing-resistant MFA on remote access, email and administrator accounts; change defaults on new devices before connection; inventory service accounts and move their secrets to a vault; separate admin accounts. Roll out MFA in pilot groups with a break-glass account held offline, and keep the old policy available for rollback during the first weeks.
- Inventory and document (1.B, 2.M, 2.P, 2.Q): build an asset inventory with IP addresses refreshed monthly, baseline device configurations and network topology, and require approval for new hardware and software. See the Asset Inventory and CMDB Security Guide.
- Segment and log (2.F, 2.T, 2.U, 2.G): deny IT to OT connections by default and route required flows through a monitored intermediary; collect access and security logs centrally with restricted write access and alerting if a critical log source stops. See the Network Segmentation Guide and the Log Management and Retention Guide.
- Prepare to respond and recover (2.R, 2.S, 4.C, 5.A): separate and test backups, exercise IT and OT incident response plans at least annually, and document who must be notified and when. See the Incident Response Plan Template.
- Push requirements to suppliers (1.G to 1.I, 4.A, 4.B): add incident and vulnerability notification clauses and security requirements to procurement, publish a vulnerability disclosure policy and a security.txt file on public web domains.
Small vs large organisations
- Small organisations and utilities: concentrate on 2.A, 2.C, 2.K, 2.W, 2.R and 1.E. These are mostly configuration changes and policy, and they remove the commonest entry points. A managed service provider can deliver many goals, but the contract should then carry 1.G and 1.H obligations. See the Water and Wastewater Cybersecurity Guide for a sector where this matters.
- Large organisations: most goals will already be met somewhere; the work is proving they are met everywhere, including OT sites, acquired businesses and non-human identities. Use the CPGs as an assurance lens over an existing CSF or ISO/IEC 27001 programme rather than a separate project.
- OT-heavy operators: expect compensating controls for 2.A, 2.B and 1.E on legacy assets that cannot change passwords or be patched; document each one, monitor logins and track the asset for replacement.
Evidence and assessment
Because the CPGs are voluntary, there is no formal certification. Evidence still matters: boards, customers and auditors will want to see which goals are met. Keep evidence per goal in a form a third party can verify (goal 1.F expects independent validation).
| Goal | Evidence to keep | Metric |
|---|---|---|
| 1.B Asset inventory | Inventory export with last-updated date and IP addresses, IT and OT | Percentage of discovered assets present in the inventory |
| 1.E Known exploited vulnerabilities | Scan results for internet-facing assets cross-checked against KEV; compensating control records | Median days to remediate KEV-listed vulnerabilities on internet-facing assets |
| 2.A, 2.C Default and unique credentials | Device commissioning checklist; credential scan results; service account inventory | Number of devices or accounts with default or shared credentials |
| 2.D Revocation | HR leaver report reconciled with directory disable timestamps | Percentage of leavers disabled by day of departure |
| 2.K Phishing-resistant MFA | Identity provider policy export and authentication method report | Percentage of remote access and admin sign-ins using phishing-resistant methods |
| 2.N Secure sensitive data | Secret scanning results for repositories and file shares; vault inventory | Plaintext secrets found per scan, trending to zero |
| 2.T, 2.U Logging | Log source inventory, retention settings, alert on source failure | Percentage of critical systems sending logs to central storage |
| 2.R Backups | Restore test records including OT configurations and PLC logic | Successful restore tests in the last 12 months |
For identity monitoring under 2.G and 3.A, alert on repeated failures against service accounts, interactive logons by service accounts, use of a dormant account, and new MFA method registrations for administrators. On Windows, failed logons appear as event ID 4625 and successful logons as 4624 in the Security log. See the Windows Event Log Guide.
Mapping to other frameworks
CISA maps each v1.0.1 goal to a NIST CSF 1.1 subcategory (for example 2.C to PR.AC-1). The table gives the nearest CSF 2.0 outcomes and SP 800-53 Rev. 5 controls for the main goals, so the CPGs can be tracked within an existing control set.
| CPG | NIST CSF 2.0 | SP 800-53 Rev. 5 |
|---|---|---|
| 1.A, 1.C Leadership | GV.RR-02 | PM-2 |
| 1.B Asset inventory | ID.AM-01, ID.AM-02 | CM-8 |
| 1.E Known vulnerabilities | ID.RA-01 | RA-5, SI-2 |
| 1.G to 1.I Supply chain | GV.SC-05, GV.SC-07 | SR-8 |
| 2.A to 2.E, 2.K Credentials and accounts | PR.AA-01, PR.AA-03, PR.AA-05 | AC-2, AC-6, IA-2, IA-5 |
| 2.F, 2.W, 2.X Segmentation and exposure | PR.IR-01 | SC-7 |
| 2.H Training | PR.AT-01 | AT-2 |
| 2.J Encryption | PR.DS-02 | SC-8 |
| 2.M, 2.P Configuration and topology | PR.PS-01, ID.AM-03 | CM-2 |
| 2.R Backups | PR.DS-11 | CP-9 |
| 2.S, 5.A Response and recovery plans | RC.RP-01 | IR-8, CP-2 |
| 2.T, 2.U Logging | PR.PS-04 | AU-6, AU-9 |
| 3.A Threat detection | DE.CM-01 | SI-4 |
| 4.C Incident reporting | RS.CO-02 | IR-6 |
The CPGs also sit naturally under the CISA Zero Trust Maturity Model: goals 2.C, 2.E and 2.K correspond to the Traditional to Initial move in its Identity pillar. See the CISA Zero Trust Maturity Model Guide. Financial institutions can read them alongside the FFIEC Cybersecurity Guidance Guide, and OT operators alongside the OT Security Maturity Model.
Common pitfalls
- Treating the baseline as the destination: the CPGs are deliberately minimal. Meeting all 38 does not make a programme mature, and CISA says so.
- Human-only credential coverage: MFA and leaver processes are applied to staff while service accounts keep static, shared, never-rotated passwords, often with VPN or remote access rights. The Microsoft Midnight Blizzard breach started with a password spray on a legacy test account without MFA.
- Unused accounts left enabled: goal 2.D is checked for leavers but not for accounts belonging to retired projects, contractors and vendors, which is how the Colonial Pipeline intrusion began.
- Undocumented compensating controls: OT teams correctly decide a legacy device cannot change its default password, then record nothing and monitor nothing, so the exception becomes permanent and invisible.
- Self-assessment without validation: a checklist marked "implemented" without third-party testing (1.F) tends to overstate coverage, especially for segmentation and logging.
- Ignoring the version change: mapping work done against CSF 1.1 identifiers needs translating to CSF 2.0 as CISA updates the CPGs; keep a mapping table rather than hard-coding IDs in reports.
Practitioner checklist
- Name an accountable cybersecurity leader and, if you run OT, an OT security leader.
- Complete the CPG Checklist with evidence for each of the 38 goals and re-assess every 12 months.
- Remove internet-exposed RDP and similar services, and remediate KEV-listed vulnerabilities on internet-facing assets first.
- Enforce phishing-resistant MFA for remote access, email and administrators, with a tested break-glass account.
- Inventory service and machine accounts, give each a unique vaulted credential and an owner, and remove interactive and VPN rights they do not need.
- Change default passwords before devices connect, and document and monitor every exception.
- Disable accounts and rotate known secrets by the day of departure, for leavers and for retired applications.
- Centralise logs with restricted write access and alert when a critical source stops sending.
- Add incident and vulnerability notification clauses and security requirements to supplier contracts.
- Track the CISA CPG page for the CSF 2.0 aligned update and your sector-specific goals.
Standards and references
- CISA: Cross-Sector Cybersecurity Performance Goals
- CISA: Cross-Sector Cybersecurity Performance Goals v1.0.1 Report
- CISA: Known Exploited Vulnerabilities Catalog
- NIST: Cybersecurity Framework 2.0
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Valid Accounts: Default Accounts
Related NHI Mgmt Group resources: NIST CSF 2.0 Guide · OT Security Maturity Model · Service Account Security Guide · Phishing-Resistant MFA Guide · Zero Trust Identity Guide