Energy and industrial operators are asked "how mature is our cybersecurity?" by boards, regulators and insurers, and most cannot answer in a way that is repeatable from one year to the next. The Cybersecurity Capability Maturity Model (C2M2), published by the US Department of Energy (DOE), gives a structured, free way to answer it across both IT and operational technology (OT). This guide explains what C2M2 Version 2.1 contains, how its ten domains and three maturity indicator levels work, what it expects for identities including service and device identities, and how to run a self-evaluation that produces a prioritised plan rather than a score that sits in a drawer. It is for security leads, OT engineers, risk teams and assessors. Status and content were checked against DOE pages on 27 October 2026.
Key takeaways
- Version 2.1 is current. DOE's Office of Cybersecurity, Energy Security, and Emergency Response (CESER) released it on 30 June 2022, following Version 2.0 in July 2021, with more than 350 practices across 10 domains.
- Maturity is measured per domain and is cumulative. To earn a maturity indicator level (MIL) in a domain, an organisation must perform all practices in that level and in the preceding level, so one weak MIL1 practice caps the whole domain.
- It is a self-evaluation, not a certification. There is no C2M2 certificate, no required artefacts and, as DOE's own CMMC supplement states, C2M2 has no reciprocity with CMMC.
- Identity is explicitly broader than people. ACCESS-1a covers identities for personnel and "other entities such as services and devices", and ACCESS-1h treats privileged, service, shared and remote access as higher risk needing stronger credentials or MFA.
- The value is in the target profile. Results only matter when compared with a target MIL per domain, turned into a prioritised plan with an owner, and re-evaluated after major business, technology or threat changes.
What it is and who it applies to
C2M2 is a voluntary maturity model maintained by DOE CESER and developed with industry. The 2.1 update was built with an Energy Sector C2M2 Working Group of 145 experts from 77 energy and cybersecurity organisations and piloted with nine organisations from the electricity, oil and natural gas subsectors. DOE describes industry "support and ownership of the C2M2" and offers no-cost self-evaluations for US energy sector organisations.
- Energy companies: electricity, oil and natural gas operators are the core audience, and the model's language on OT segments and service delivery reflects that.
- Other sectors: nothing in the model is energy-specific in structure. Its assets definition covers IT, OT and information assets, including cloud, virtualised and third-party managed assets, so water, manufacturing and transport operators use it too.
- Defence suppliers: DOE published C2M2-CMMC Supplemental Guidance (January 2024) for C2M2 users who also need CMMC. It maps C2M2 practices to CMMC requirements but states there is "no direct correlation" between MILs and CMMC levels and that C2M2 results cannot replace a CMMC self-assessment or certification. See the NIST SP 800-171 and CMMC 2.0 Guide.
- Regulated operators: C2M2 is not itself a regulation. Mandatory regimes such as NERC CIP for the bulk electric system or TSA directives for pipelines sit alongside it. See the NERC CIP Guide and the TSA Pipeline and Rail Cybersecurity Directives Guide.
The unit of evaluation is the function: "the part of the organization that is being evaluated based on the model." A function can be a department, business line, facility, network zone, asset grouping or set of externally managed assets. Choosing the function sets which assets are in scope and who must attend the self-evaluation, so it is the single most important scoping decision.
Structure and key requirements
The model has ten domains. Each domain has a purpose statement, a set of approach objectives containing practices, and a final Management Activities objective. Domain short names are used as practice ID prefixes (for example ACCESS-1h).
| Domain (short name) | Objectives in Version 2.1 | What practitioners use it for |
|---|---|---|
| Asset, Change, and Configuration Management (ASSET) | ASSET-1 Manage IT and OT Asset Inventory; ASSET-2 Manage Information Asset Inventory; ASSET-3 Manage IT and OT Asset Configuration; ASSET-4 Manage Changes to IT and OT Assets; ASSET-5 Management Activities | Inventory, baselines and change control across IT and OT |
| Threat and Vulnerability Management (THREAT) | THREAT-1 Reduce Cybersecurity Vulnerabilities; THREAT-2 Respond to Threats and Share Threat Information; THREAT-3 Management Activities | Vulnerability handling and threat information sharing (absorbed the old Information Sharing domain) |
| Risk Management (RISK) | RISK-1 Establish and Maintain Cyber Risk Management Strategy and Program; RISK-2 Identify Cyber Risk; RISK-3 Analyze Cyber Risk; RISK-4 Respond to Cyber Risk; RISK-5 Management Activities | Connecting cyber risk to enterprise risk management, significantly updated in 2.1 |
| Identity and Access Management (ACCESS) | ACCESS-1 Establish Identities and Manage Authentication; ACCESS-2 Control Logical Access; ACCESS-3 Control Physical Access; ACCESS-4 Management Activities | Human, service and device identities, credentials, MFA, least privilege, physical access |
| Situational Awareness (SITUATION) | SITUATION-1 Perform Logging; SITUATION-2 Perform Monitoring; SITUATION-3 Establish and Maintain Situational Awareness; SITUATION-4 Management Activities | Logging, monitoring and a shared operating picture |
| Event and Incident Response, Continuity of Operations (RESPONSE) | RESPONSE-1 Detect Cybersecurity Events; RESPONSE-2 Analyze Cybersecurity Events and Declare Incidents; RESPONSE-3 Respond to Cybersecurity Incidents; RESPONSE-4 Address Cybersecurity in Continuity of Operations; RESPONSE-5 Management Activities | Detection, triage, response and continuity, including coordination with vendors |
| Third-Party Risk Management (THIRD-PARTIES) | Purpose: establish and maintain controls to manage cyber risks arising from suppliers and other third parties | Renamed from Dependencies in 2.1; DOE highlights sensitive data in the cloud and vendors with privileged access |
| Workforce Management (WORKFORCE) | Workforce practices for cybersecurity | Culture, training and personnel security |
| Cybersecurity Architecture (ARCHITECTURE) | New domain in 2.1 for planning and managing the security control environment | Segmentation and security architecture across IT and OT |
| Cybersecurity Program Management (PROGRAM) | Programme strategy and governance | Strategy, sponsorship and programme oversight |
For THIRD-PARTIES, WORKFORCE, ARCHITECTURE and PROGRAM this guide gives the domain purpose only; read the objectives and practice text in the Version 2.1 model or the DOE Help Text and Practices workbook before scoring.
Maturity indicator levels
| Level | Name | Approach | Management characteristics |
|---|---|---|---|
| MIL0 | Not performed | Practices are not performed | None |
| MIL1 | Initiated | Initial practices are performed but may be ad hoc | No Management Activities practices at MIL1 |
| MIL2 | Performed | Practices are more complete or advanced than at MIL1 | Practices are documented; adequate resources (people, funding, tools) are provided |
| MIL3 | Managed | Practices are more complete or advanced than at MIL2 | Guided by policies; responsibility, accountability and authority assigned; personnel have adequate skills and knowledge; effectiveness is evaluated and tracked |
Three rules drive every score. MILs apply independently to each domain, so a profile of ten separate levels is normal. MILs are cumulative, so all MIL1 and MIL2 practices must be performed before MIL3 counts. And a practice counts as performed when it is scored Fully Implemented or Largely Implemented on the four-point scale (Not, Partially, Largely, Fully Implemented). Largely means complete with a recognised opportunity for improvement; Partially means incomplete with multiple opportunities for improvement.
What changed in Version 2.1
- Practice rewrite: about two thirds of practices were revised, and some were added, deleted or combined. Every practice now has help text.
- New and renamed domains: Cybersecurity Architecture was added; Dependencies became Third-Party Risk Management; Information Sharing was folded into THREAT and SITUATION.
- NIST CSF alignment: practices were added for closer alignment with the NIST Cybersecurity Framework.
- Threat drivers: DOE cites ransomware, supply chain risk, zero trust principles, cloud and mobile technology among the reasons for the update.
- Migration aids: DOE publishes V1.1 to V2.1 and V2.0 to V2.1 mapping workbooks.
Identity and NHI requirements
The ACCESS domain purpose is to "create and manage identities for entities that may be granted logical or physical access to the organization's assets." The word entities matters: the model does not limit identity to staff. For non-human identities (service accounts, API credentials, device identities in OT) the relevant practices are below.
| Practice | MIL | Requirement (paraphrased from Version 2.1) | What it means for service and device identities |
|---|---|---|---|
| ACCESS-1a | 1 | Identities are provisioned, at least ad hoc, for personnel and other entities such as services and devices | Service accounts and device identities must be known and created deliberately. Shared identities are not precluded but may need compensating measures |
| ACCESS-1b | 1 | Credentials are issued to personnel and other entities that need access | Keys, certificates and passwords for services are issued, not copied from another system |
| ACCESS-1c | 1 | Identities are deprovisioned, at least ad hoc, when no longer required | Retired integrations and decommissioned devices lose their accounts |
| ACCESS-1d | 2 | Password strength and reuse restrictions are defined and enforced | Covers service account passwords, which are often the weakest in the estate |
| ACCESS-1e | 2 | Identity repositories are reviewed and updated periodically and on triggers such as system or organisational changes | Directories, PAM vaults and OT local account lists are reconciled, not just HR-driven user lists |
| ACCESS-1f | 2 | Identities are deprovisioned within organisation-defined time thresholds | Set a measurable SLA for removing orphaned service identities |
| ACCESS-1g | 2 | Privileged credentials are used only by processes that require them | No domain admin or root credentials embedded in scripts that do not need them |
| ACCESS-1h | 2 | Stronger credentials, MFA or single-use credentials are required for higher-risk access: privileged, service, shared and remote | Service access is named as higher risk. Where MFA is impossible, use stronger credentials (certificates, managed or vaulted secrets) or single-use credentials |
| ACCESS-1i | 3 | Multifactor authentication is required for all access, where feasible | Record infeasible cases (legacy OT, machine-to-machine) and the compensating control |
| ACCESS-1j | 3 | Identities are disabled after a defined inactivity period, where feasible | Dormant service accounts are found and disabled, which requires last-use telemetry |
| ACCESS-2c to 2e | 2 | Logical access requirements cover allowed entity types, access limits, remote access constraints and authentication parameters, and incorporate least privilege and separation of duties | Write requirements for service identities explicitly: which entity types may hold which privileges |
| ACCESS-2g | 2 | Higher-risk privileges receive additional scrutiny and monitoring | Privileged non-human accounts belong in PAM scope and monitoring |
| ACCESS-2h | 3 | Privileges are reviewed periodically, on triggers, and after any temporary elevation | Access reviews must include service accounts and their owners |
| ACCESS-2i | 3 | Anomalous logical access attempts are monitored as indicators of cybersecurity events | Baseline normal behaviour for service accounts; they are predictable, so anomalies stand out |
Most organisations that score themselves honestly find ACCESS-1h and ACCESS-1j are where non-human identities fail first: service accounts are excluded from MFA and stronger credential schemes, and there is no inactivity data to disable them. See the Non-Human Identity (NHI) Guide and the Energy Sector Identity and OT Access Guide. DOE's description of the THIRD-PARTIES domain also calls out vendors with privileged access, which links third-party scoring directly to how vendor remote access accounts are issued and reviewed. See the Privileged Access Management Guide.
Implementation steps
- Choose the function and the assets. Pick one function for the first evaluation (one plant, one control centre, the corporate IT estate). List the important IT, OT and information assets, including cloud and third-party managed ones, and record anything deliberately excluded.
- Set target MILs before scoring. Leadership agrees a target profile per domain based on the function's criticality. Not every domain needs MIL3; a target of MIL2 with MIL3 in ACCESS and RESPONSE is a common, defensible shape for an operations site.
- Prepare the material. Download the Version 2.1 model, the Help Text and Practices workbook and the Self-Evaluation Guide. Use the HTML tool at c2m2.doe.gov or request the PDF tool from [email protected].
- Run a facilitated workshop. A facilitator familiar with the model leads operational staff, management stakeholders and the people who actually perform the practices. DOE's guide aims to complete a single-function evaluation in one day. Participants reach consensus on Not, Partially, Largely or Fully Implemented for each practice.
- Analyse gaps. Compare the scoring report with the target profile. Because MILs are cumulative, start with MIL1 and MIL2 gaps in domains below target, since they block everything above them.
- Prioritise. Rank actions by effect on business objectives, cost and resource availability. Identity gaps (ACCESS-1c, 1f, 1h) are usually cheap relative to their risk reduction.
- Plan with an owner. Turn the priorities into a plan with a named plan owner and regular leadership reviews. Map each action to the practice ID it closes.
- Implement and re-evaluate. Track progress, and re-run the evaluation periodically and after major changes in business, technology or threat conditions.
Evidence and assessment
C2M2 does not require artefacts. That makes it fast, but it also means scores are only as reliable as the conversation in the room. DOE's CMMC supplement contrasts the two directly: CMMC requires documentation such as a System Security Plan, asset inventory and network diagram, while C2M2 does not. Organisations that want their scores to stand up to an auditor, regulator or insurer add their own evidence rule.
| Practice area | Evidence that supports "Largely" or "Fully" | Typical weak evidence |
|---|---|---|
| ASSET-1 inventory | Current IT and OT inventory export with owner and last-seen date | A spreadsheet last updated at the previous evaluation |
| ACCESS-1a, 1e | Reconciled list of human and service identities per repository, with owners | Directory user count only, with no service accounts |
| ACCESS-1f, 1j | Deprovisioning SLA and report of dormant accounts disabled in the period | Policy statement with no report |
| ACCESS-1h, 1i | MFA coverage report by access type, plus an exceptions register with compensating controls | "MFA is enabled" for VPN only |
| ACCESS-2h | Completed access review records including privileged and service accounts | Reviews of human users only |
| SITUATION-1 | Log sources list showing coverage of assets important to the function | SIEM licence without source coverage |
| Management Activities (MIL2, MIL3) | Documented procedures, policy, RACI, training records, effectiveness metrics | Practices performed by one expert with nothing written |
A practical rule: any practice scored Fully Implemented should have at least one artefact a third party could inspect, and every Largely Implemented score should name the improvement opportunity, since that is what the definition requires.
Mapping to other frameworks
C2M2 2.1 was revised for closer alignment with the NIST Cybersecurity Framework, but DOE does not present it as a control catalogue. The mapping below is an indicative, practitioner mapping at domain level; use the official DOE and NIST material for detailed crosswalks.
| C2M2 domain | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | Notes |
|---|---|---|---|
| ASSET | ID.AM-01, ID.AM-02 | CM family | Inventory of hardware, software, services |
| RISK | GV.RM-01, GV.RM-02, GV.RM-03, ID.RA-05, ID.RA-06 | PM-9, PM-28, RA-3, RA-7 | Cyber risk in enterprise risk management |
| ACCESS | PR.AA-01, PR.AA-05 | AC-2, AC-6, IA-2, IA-5 | PR.AA-01 also covers identities for services and hardware |
| SITUATION | DE.CM-01 | AU-6, CA-7 | Logging and monitoring |
| THIRD-PARTIES | GV.SC-07 | SR-6, PM-30 | Supplier risk, vendor privileged access |
| PROGRAM | GV.OV-01 | PM-9 | Strategy review and oversight |
- CMMC: DOE's supplement maps C2M2 practices to CMMC requirement codes and is the authoritative crosswalk; there is no MIL to level equivalence.
- Other maturity views: the CISA Cross-Sector Cybersecurity Performance Goals (CPGs) Guide sets a baseline of goals rather than levels, and the OT Security Maturity Model gives a broader OT maturity view.
- OT control depth: use C2M2 to measure, and the NIST SP 800-82 OT Security Guide for the controls to implement.
Detection and measurement
A MIL score changes once a year at best. Track a few operational measures between evaluations so the next score is not a surprise:
- Domains at or above target: count of the ten domains meeting the agreed target MIL, trended across evaluations.
- Blocking gaps: number of MIL1 and MIL2 practices below Largely Implemented, the gaps that cap domain scores.
- Service identity hygiene: percentage of service and device identities with a named owner, and dormant identities disabled within the ACCESS-1j threshold.
- Higher-risk access coverage: share of privileged, service, shared and remote access using MFA, stronger or single-use credentials (ACCESS-1h).
- Deprovisioning time: median days from "no longer required" to removal, against the ACCESS-1f threshold.
- Plan delivery: percentage of plan actions closed on schedule since the last evaluation.
See the Identity Security Metrics Guide for how to collect identity measures reliably.
Common pitfalls
- Scoring the whole company as one function. A single enterprise-wide score averages a well-run IT estate with a neglected substation and hides both. Evaluate functions separately.
- Treating Largely as Fully. Because tools count both as performed, teams drift to Largely to pass the level. Require the named improvement opportunity for every Largely score.
- Leaving service accounts out of ACCESS. Scoring ACCESS on employee joiners and leavers only ignores ACCESS-1a's "services and devices" and ACCESS-1h's service access.
- Dormant accounts with no MFA. In the Colonial Pipeline Ransomware Attack 2021, attackers used a legacy VPN account that was no longer used, had never been disabled and had no MFA, against a leaked password. That single account touches ACCESS-1c, 1f, 1h and 1j.
- Skipping Management Activities. Practices performed by one engineer with nothing documented can reach MIL1 but cannot reach MIL2. Write the procedures early.
- Presenting C2M2 as compliance. It is a self-evaluation with no reciprocity with CMMC and no regulatory status. Report it as a maturity measure next to mandatory obligations, not instead of them.
Practitioner checklist
- Confirm you are using Version 2.1 (June 2022) material and retire older workbooks.
- Define the function and list in-scope IT, OT, information, cloud and third-party managed assets.
- Agree a target MIL per domain with leadership before the workshop.
- Invite the people who perform the practices, not only managers, and appoint a trained facilitator.
- Score ACCESS with service, device, shared and remote identities in scope.
- Set an evidence rule for Fully and Largely Implemented scores.
- Fix MIL1 and MIL2 gaps first, since MILs are cumulative.
- Assign a plan owner, map actions to practice IDs and review them with leadership regularly.
- Re-evaluate periodically and after major business, technology or threat changes.
Standards and references
- US Department of Energy: Cybersecurity Capability Maturity Model (C2M2) Version 2.1
- US Department of Energy CESER: Cybersecurity Capability Maturity Model (C2M2)
- US Department of Energy: Version 2.1 update announcement
- US Department of Energy: C2M2 V2.1 Self-Evaluation Cheat Sheet
- US Department of Energy: C2M2-CMMC Supplemental Guidance
Related NHI Mgmt Group resources: Energy Sector Identity and OT Access Guide · OT Security Maturity Model · NERC CIP Guide · NHI Governance Maturity Model