How to Assess Software Suppliers With C2M2 at a US Electric Utility

To assess the software your utility buys with C2M2, use the model's Third-Party Risk Management (THIRD-PARTIES) domain as a ladder: identify and rank suppliers first (MIL1), then write cybersecurity requirements into contracts and evaluate suppliers by a defined method (MIL2), then ask for bills of material, secure development evidence and end-of-support dates for your most important assets (MIL3). If you own medium or high impact BES Cyber Systems, NERC CIP-013 is the floor under that ladder, and CIP-010 adds a software integrity check before every baseline change.

The rest is making supplier software risk measurable: what you ask for, how you check what comes back, and how you notice when a component inside a product you bought lands on CISA's Known Exploited Vulnerabilities (KEV) catalog after go-live. This post uses the primary texts and a method you can run with spreadsheets; Safeguard appears near the end. Nothing here is legal or compliance advice.

Key takeaways

• C2M2 Version 2.1 (June 2022) is still the current model on DOE's site as of October 2026. Its THIRD-PARTIES domain has 25 practices across three objectives; the software-specific ones sit at MIL2 and MIL3.
• CIP-013-2 asks for a documented supply chain risk management plan for high and medium impact BES Cyber Systems and their EACMS and PACS, covering six vendor topics in Part 1.2, including vulnerability disclosure (1.2.4) and software integrity and authenticity (1.2.5). The plan must be reviewed and approved at least once every 15 calendar months.
• CIP-010-4 Part 1.6 requires verifying the identity of the software source and the integrity of the software before a baseline change, when the source makes a method available.
• FERC Order No. 912 (effective 24 November 2025) directed NERC to develop new or modified supply chain standards, so expect CIP-013 to change.
• Ask suppliers for an SBOM per release meeting CISA's 2026 Minimum Elements, vulnerability notification terms, an integrity verification method, secure development evidence and support end dates, then match their SBOMs against KEV daily.
• In Safeguard, the Third-Party Risk Manager (TPRM, GA) handles SBOM requests, validation and monitoring; SBOM analysis of uploaded and existing SBOMs is GA; Portal's Find & Review SBOMs is GA; attestation and signing is GA; the compliance and GRC suite (GA) has NERC CIP and NIST SP 800-161 framework pages; on-prem and air-gapped deployment is GA; the CLI and local runner are GA; the desktop app is generally available. Autonomous remediation is GA and ships switched off, with every category set to Manual.
• Safeguard covers the open source inside software you are supplied and the code you write yourself. It does not assess OT device firmware or hardware, and it does not run your C2M2 self-evaluation or a NERC audit.

Why supplier software is a utility problem

A utility buys far more software than it writes. Control center applications, distribution management, outage management, meter data and head-end systems, historians, GIS, work management, billing and customer portals all arrive from suppliers, often with their own update servers, remote support tools and embedded open source libraries that nobody at the utility chose.

C2M2's introduction to the THIRD-PARTIES domain names software of unknown provenance and counterfeit hardware as serious threats, and warns that requests for proposal often give suppliers only rough specifications without security requirements.

DOE's Supply Chain Cybersecurity Principles, developed by DOE's CESER office with Idaho National Laboratory and industry partners, are written for both suppliers and end users and treat supply chain security as a shared responsibility. They are a useful reference when you write supplier expectations, because suppliers have seen them too.

The usual gap is not policy. It is that supplier evidence is rarely checked at contract time and almost never re-checked after purchase. For the broader safety context, see our earlier piece on electric utility software supply chain risk and physical safety.

What C2M2 is and how maturity indicator levels work

The Cybersecurity Capability Maturity Model (C2M2) is a free, voluntary DOE model for evaluating your own cybersecurity capabilities. DOE's C2M2 page, updated in October 2026, still links Version 2.1 (June 2022) as the latest model, with a self-evaluation guide, practices workbook, HTML and PDF self-evaluation tools, and mappings to NIST CSF 1.1; DOE says CSF 2.0 mappings are coming.

Three ideas from the model matter for supplier work.

The function. You evaluate one function at a time, such as a distribution operation. That choice decides which assets, and therefore which suppliers, are in scope.

Maturity indicator levels. The model defines four levels, MIL0 to MIL3. MIL0 means practices are not performed. MIL1 means initial practices are performed but may be ad hoc. MIL2 and MIL3 add both more complete practices and management characteristics, such as documented procedures, adequate resources, policies, assigned responsibility and tracked effectiveness.

Cumulative scoring within a domain. MIL2 needs every MIL1 and MIL2 practice in the domain; MIL3 needs all three levels. You can sit at MIL1 in one domain and MIL3 in another.

C2M2 is a self-evaluation, not a certification or an audit. That is why it works as a ladder: it shows the next practice to adopt without telling you that you have passed.

What the THIRD-PARTIES domain asks at each maturity level

The domain's stated purpose is to establish and maintain controls that manage cyber risks from suppliers and other third parties, commensurate with the risk to critical infrastructure and organizational objectives. Third parties here is broad: suppliers, vendors, service providers, infrastructure dependencies such as telecommunications and water, and government bodies such as emergency services. This post focuses on the software suppliers within that set.

The domain has three objectives. Practice IDs below follow C2M2's own convention (domain, objective number, practice letter), so THIRD-2k is objective 2, practice k.

Objective 1: Identify and prioritize third parties

Objective 2: Manage third-party risk

Objective 3: Management activities

There is no MIL1 practice. At MIL2, THIRD-3a asks for documented procedures that are followed and maintained, and THIRD-3b asks for adequate people, funding and tools. At MIL3, THIRD-3c to THIRD-3f ask for up-to-date policies, assigned responsibility and authority, staff with the right skills, and evaluation and tracking of how effective the domain's activities are.

Where software sits in the ladder

Read the table with a software lens and a pattern appears. MIL1 is about knowing who your suppliers are. MIL2 is about putting promises in writing (THIRD-2f) and getting suppliers to restate them periodically (THIRD-2g). MIL3 is where the software evidence lives: secure development requirements (THIRD-2h), support end dates (THIRD-2i), protection against compromised software (THIRD-2j), bills of material (THIRD-2k) and security in acceptance testing (THIRD-2m).

The domain narrative names independent testing, code review, vulnerability scanning and evidence of a secure development process as ways to manage supplier risk, and its worked example has the buyer verify digital signatures on delivered software and firmware. That is a direct bridge to CIP-010. The RISK domain also has a MIL3 practice that feeds THIRD-PARTIES information into cyber risk, so supplier findings belong in your risk register.

How C2M2 lines up with CIP-013 and CIP-010

Not every utility is subject to CIP-013. It applies to registered entities that own high or medium impact BES Cyber Systems, and its scope is those systems plus their Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS). Many distribution cooperatives and municipals have only low impact assets or none. For them, C2M2 and contracts are the whole program. For entities in scope, CIP-013 is mandatory and enforceable, and C2M2 shows how far above the floor you are.

What CIP-013-2 requires

The current version on NERC's site is CIP-013-2, with its effective date set by the implementation plan for Project 2019-03. It has three requirements.

R1 requires one or more documented supply chain cyber security risk management plans. Part 1.1 covers planning for procurement: processes to identify and assess risk to the Bulk Electric System from vendor products or services, both from procuring and installing vendor equipment and software, and from transitions between vendors. Part 1.2 covers the procurement itself, with six topics to address as applicable:

• 1.2.1 vendor notification of vendor-identified incidents that pose risk to you;
• 1.2.2 coordination of responses to those incidents;
• 1.2.3 vendor notification when remote or onsite access for its staff should end;
• 1.2.4 vendor disclosure of known vulnerabilities in the products or services it provides;
• 1.2.5 verification of software integrity and authenticity of all software and patches the vendor provides for use in the covered systems;
• 1.2.6 coordination of controls for vendor-initiated remote access.

R2 requires you to implement the plan. NERC's note says you need not renegotiate existing contracts, and that contract terms and vendor performance are outside R2's scope. CIP-013 judges whether you have and use a process, not whether every supplier agreed.

R3 requires a review of the plan and approval by the CIP Senior Manager or a delegate at least once every 15 calendar months.

What CIP-010-4 Part 1.6 adds

CIP-010-4 Part 1.6 applies to high and medium impact BES Cyber Systems and their EACMS and PACS. Before a change that deviates from the baseline for operating system or firmware, commercially available or open source application software, or applied security patches (Parts 1.1.1, 1.1.2 and 1.1.5), and when the software source makes a method available, you must verify the identity of the software source (1.6.1) and the integrity of the software obtained from it (1.6.2). NERC's example evidence is a change record showing the check was done before the baseline change, or a documented automated mechanism that does it.

That is why "how do we verify this" belongs in every software purchase. If the supplier offers no hash, no signature and no authenticated download channel, Part 1.6 has nothing to verify against, and you have to document that.

What FERC has ordered

FERC approved the first supply chain standards (CIP-013-1, with related changes to CIP-005 and CIP-010) in Order No. 850, published in the Federal Register in October 2018. In September 2025 FERC issued Order No. 912 in Dockets RM24-4 and RM20-19, effective 24 November 2025. It directs NERC to develop new or modified Reliability Standards addressing whether entities' supply chain risk management plans are sufficient to identify and respond to supply chain risks, and to develop modifications on supply chain protections for protected cyber assets. It also terminated a related notice of inquiry.

The practical reading: write your CIP-013-2 plan to identify and respond to risk, not only document process, and check NERC's project status before your next 15-month review.

Mapping the two frameworks

The rows with no direct CIP requirement are where C2M2 goes beyond the floor. For more on how the CIP family treats software, see energy sector software security and NERC CIP.

What NIST SP 800-161 adds

NIST SP 800-161 Rev. 1 (May 2022, updated November 2024) is the federal guide to cybersecurity supply chain risk management. Utilities are not bound by it, but controls such as SR-4 (provenance), SR-8 (notification agreements) and SR-11 (component authenticity) give sharper contract wording than C2M2.

What to ask a software supplier for

A useful request is short, specific and tied to a decision you will make. Here is a request set that covers the C2M2 MIL3 software practices and CIP-013-2 Part 1.2, grouped by what you will do with each item.

1. A software bill of materials for each release you run

Ask for a machine-readable SPDX or CycloneDX SBOM for every version you deploy, including transitive dependencies, refreshed with each release or patch. This answers THIRD-2k and feeds monitoring. For an appliance, ask whether it covers the operating system image too.

2. A vulnerability disclosure and notification commitment

Ask how the supplier tells customers about vulnerabilities, how fast and through what channel, whether it will tell you when a shipped component is added to KEV, and whether it publishes VEX statements. This maps to CIP-013-2 Parts 1.2.1, 1.2.2 and 1.2.4 and to THIRD-2f.

3. An integrity and authenticity method for software and patches

Ask how you verify that what you install is what the supplier built: published hashes over a separate channel, code signing, an authenticated download portal, and what happens when a signing key is revoked. This is the evidence CIP-013-2 Part 1.2.5 and CIP-010-4 Part 1.6 depend on, and it answers THIRD-2j.

4. Secure development evidence

Ask for secure development practice in a checkable form, such as a self-attestation against NIST's Secure Software Development Framework and how it manages third-party components. This answers THIRD-2h.

5. Support and end-of-life dates

Ask for the support end date of each product and major version (THIRD-2i). It is the field most often missing when a product is still running fifteen years later.

6. Remote access and hosting

Ask how vendor-initiated remote access works and how the supplier will tell you when one of its people should lose access (CIP-013-2 Parts 1.2.3 and 1.2.6). If any part runs in the supplier's hosting environment, ask where and how it is secured (THIRD-2l).

7. A periodic attestation

Ask the supplier to restate, annually or at renewal, that it still meets the requirements above. This is THIRD-2g and gives you dated R2 evidence.

A request you can paste into an RFP

Software transparency and integrity requirements

1. Provide an SBOM in SPDX or CycloneDX (machine readable) for each
   release we deploy, covering all components including transitive
   dependencies, meeting CISA's 2026 Minimum Elements for an SBOM.
   Provide an updated SBOM with every release and patch.
2. Describe your vulnerability disclosure process. Notify us within
   [agreed period] of any vulnerability affecting our deployed versions,
   and within [shorter period] if it is listed in CISA's KEV catalog.
   Provide VEX statements where a listed vulnerability does not affect us.
3. Describe how we verify the identity of the source and the integrity of
   every software package and patch you provide (hashes, signatures,
   authenticated download).
4. Provide evidence of your secure development practices.
5. State the end of support date for each product and major version.
6. Describe vendor remote access and how you notify us when access
   for your personnel should end.
7. Re-attest to items 1 to 6 annually.

The bracketed periods are yours to set. Our post on how to write an SBOM request to a supplier goes deeper on wording.

How to check a supplier SBOM against the CISA 2026 minimum elements

Receiving an SBOM is not the same as receiving a useful one. CISA published the 2026 Minimum Elements for a Software Bill of Materials on 29 July 2026, replacing the 2021 NTIA minimum elements, with a long list of partner agencies sealing the document. It splits the elements into data fields and practices and processes.

The data fields

The 2026 document adds SBOM Author Signature, SBOM Data Format Name, SBOM Data Format Version, SBOM Generation Context, SBOM Tool Name, SBOM Tool Version, SBOM Version, Component Hash Value, Component Hash Algorithm and Component License as new elements. It makes major updates to SBOM Author, Component Producer, Component Identifiers and Component Version, and minor updates to SBOM Timestamp, Component Name and Component Dependency Relationship.

Two distinctions matter. The SBOM Author generated the file and may differ from the Component Producer who made the software. SBOM Generation Context says which lifecycle phase the SBOM came from, which tells you how far to trust it about what is installed.

The practices and processes

These include Coverage, Accommodation of Updates to SBOM Data, Explicitly Identifying Unknown Information, Machine-Processable Data, Distribution and Delivery, and Frequency. The 2026 update removed the old Access Controls element and folded access considerations into Distribution and Delivery.

Coverage is the one to read closely. CISA says an SBOM should include all components of the target software including transitive dependencies, with no minimum depth. An SBOM that lists only the top-level packages fails it.

A review checklist

Then check by hand: pick a component you know the product uses and confirm it is listed. If not, the SBOM is incomplete in a way no schema check catches. Our checklist post on checking a supplier SBOM against minimum elements walks through more of these tests.

How to monitor purchased software for exploited vulnerabilities

The value of an SBOM shows up after purchase. CISA describes its Known Exploited Vulnerabilities catalog as the authoritative source of vulnerabilities exploited in the wild, and recommends that organizations use it as an input to vulnerability management prioritization. CISA's binding directives on remediating KEV entries apply to federal civilian agencies, not utilities, but the catalog itself is public and has a JSON feed you can match against automatically.

A workable loop looks like this:

1. Keep every supplier SBOM in one place, indexed by product, version and the systems that run it.
2. Match components against new KEV entries daily, on package identifiers rather than names.
3. On a match, ask the supplier first: is the vulnerable code present and reachable, and is there a patch, workaround or VEX statement?
4. Decide compensating controls for systems you cannot patch quickly, and record the decision.
5. Feed the patch into patch management. For BES Cyber Systems it goes through your CIP-007 patch evaluation and the CIP-010 Part 1.6 integrity check.
6. Record the episode. Correspondence and decisions are CIP-013-2 R2 evidence and the kind of external event THIRD-1f says should trigger re-prioritization.

Also watch the quieter signals: stale SBOMs, products passing support end dates, and suppliers that stop answering. If you want to trace risk one level further down, see fourth-party risk: your vendors' vendors.

How smaller cooperatives and municipals can run this

A small utility may have one or two people covering all of IT and OT security. The ladder still works; you just climb it slowly and pick your rungs.

Start with MIL1. List the suppliers whose software runs SCADA, metering, outage and billing, and note which have remote access or custody of your data (THIRD-1a and 1b). A spreadsheet is fine.

Rank by consequence, not spend. The supplier of a low-cost remote access tool can matter more than the supplier of your most expensive application. Single-source suppliers and suppliers with privileged access go to the top (THIRD-1e).

Use renewal as your trigger. You do not need to renegotiate every contract this year. CIP-013-2's own note says existing contracts need not be reopened. Add the request set above to every new purchase and every renewal, and the coverage builds itself over a contract cycle.

Ask for SBOMs only where they will be used. Start with your top five suppliers by consequence. An SBOM you never match against KEV is paperwork.

Automate the matching, not the judgement. Software matches SBOMs against KEV; a person who knows the system decides whether a match matters.

A labelled worked example, not a measured result: a cooperative with 25 software suppliers tiers 5 as high priority, asks them for SBOMs and integrity methods at renewal, gets 3 usable SBOMs in year one and matches those against KEV daily. It records the other 2 as gaps with compensating controls. It has moved THIRD-1 toward MIL2 and started on THIRD-2k, with evidence.

How Safeguard does this job, step by step

Everything above can be done with spreadsheets, email and a scheduled script against the KEV feed. It gets harder as suppliers and versions multiply. Safeguard's Third-Party Risk Manager (TPRM, GA) is built for the software part of this work: request, validate and monitor what suppliers ship you. The steps below follow Safeguard's offering documentation and the docs pages for TPRM SBOM requests and monitoring, existing SBOM upload, the NERC CIP and NIST SP 800-161 framework pages, and air-gapped deployment. Where the docs do not show a screen, we describe the outcome rather than invent one.

1. Decide where Safeguard runs

Many utilities will not send control system SBOMs to a multi-tenant cloud. Besides SaaS and dedicated tenancy, Safeguard runs on-prem and air-gapped (GA). The air-gapped docs describe a signed snapshot bundle on a cadence from hourly to quarterly, carrying vulnerability feed deltas including NVD, OSV, CISA KEV and daily EPSS. A receiver in your DMZ verifies signatures, no component inside the perimeter calls outbound, and delivery options include a one-way diode, which the docs list for NERC CIP environments, or signed removable media. TPRM, the CLI, the desktop app and the local runner are all listed as available air-gapped.

2. Build the supplier directory and tiers

TPRM's vendor management keeps a supplier directory with contracts and SLAs, risk tiers and a self-service vendor portal where suppliers can update their own information. Enter the suppliers from your THIRD-1a list, set the tier from your THIRD-1d criteria, and attach the contract terms you negotiated, such as notification periods. This directory is your CIP-013-2 R1 Part 1.1 inventory if you keep it current.

3. Request SBOMs, one supplier or many

Per Safeguard's SBOM Requests docs:

1. For one supplier, open the vendor, click Request SBOM, select the products, choose a request template, optionally customise the message, set a deadline and click Send.
2. For several, go to Vendors, select the suppliers, click Bulk Request, configure the request settings, then review and send.
3. The standard template asks for SPDX or CycloneDX, lists required fields aligned to EO 14028, and includes submission instructions and the deadline.
4. To add your own wording, go to Settings › Request Templates, click Create Template, customise the content and save it for reuse.

Build a custom template from the RFP request above so the CISA 2026 items (hashes, generation context, author signature) are named; the standard template's fields predate them.

4. Track responses and let follow-ups run

Each request moves through Sent, Viewed, In Progress, Submitted, then Validated or Rejected. The docs describe a reminder 7 days before the deadline, another at the deadline, and an escalation 7 days after. Suppliers can submit by email attachment or a secure upload portal.

5. Validate what arrives

When an SBOM is received, Safeguard runs format validation (valid SPDX or CycloneDX), a completeness check of required fields, an EO 14028 compliance check and an automatic vulnerability scan, then notifies the requester. If it falls short, review the validation failures, click Request Revision, specify the corrections, and the supplier receives the request.

Validation checks the file. It does not prove the file describes the software the supplier actually built and shipped to you. Keep the manual spot check from the review checklist above.

6. Upload SBOMs that arrive another way

Suppliers will send SBOMs by email, on a portal, or bundled with a release. Per Safeguard's Existing SBOM docs:

1. Go to the Integrations page and click Connect on the Upload SBOM card.
2. Enter the project name, version, an optional description and the format (SPDX or CycloneDX, auto-detected if you leave it blank).
3. Drag and drop the file or click Browse. Accepted file types are .json, .xml, .spdx and .rdf, up to 100 MB.
4. Review the detected format and component count, then click Upload SBOM.

The docs list CycloneDX 1.3 to 1.6 and SPDX 2.2 and 2.3. After upload, Safeguard validates format, schema and required fields, enriches each component with CVE matches, EPSS, KEV status, license and supplier data, and scores attestation and risk. SBOM analysis of uploaded and existing SBOMs is GA.

The docs page also shows /v1 REST upload calls, but carries a banner saying those endpoints are not yet available, so use the in-app upload. The CLI does not upload SBOMs to the platform, but an analyst can check one locally before loading it:

# Check the document against its specification
safeguard validate sbom.json
# Scan it for vulnerabilities, writing results under ./output
safeguard scan --sbom sbom.json

7. Review the SBOM in Portal

Portal's Find & Review SBOMs (GA) is where you search and read what suppliers sent, by product, supplier or component. Portal's SBOM repository keeps versions and tags with diffing, so you can see what changed between the release you run and the one the supplier wants you to install. Portal's compliance view checks EO 14028 and the NTIA minimum elements.

"Portal" is also the name of Safeguard's free entry tier; here it means the SBOM review surface. The NTIA check reflects the 2021 elements, so check the 2026 fields with the review checklist above.

8. Use attestation scores as an integrity signal

Attestation and signing is GA. Each project has Attestation and Provenance tabs, and SCAL (component) and LCAL (package) scores rate integrity evidence for the open source components a supplier declared. It does not verify the supplier's installer or patch; CIP-010-4 Part 1.6 still needs your own hash or signature check at change time.

9. Turn on the NERC CIP framework page

The compliance and GRC suite is GA and has a NERC CIP framework page that is on in your workspace unless you switch it off in Compliance › Manage. Each scan of a product checks these requirements against the scan results, including the product's SBOM:

The Controls tab adds catalog controls across the CIP family, and policy templates include a NERC CIP Supply Chain Risk Management Policy. Check the CIP version numbers in that list against those effective for your entity.

A pass means the SBOM carries the data CIP-010 and CIP-013 processes depend on. It is not a finding that you comply with CIP.

10. Add the NIST SP 800-161 framework page

The SP 800-161 page works the same way, checking for a component inventory (CM-8), provenance and dependency traceability (SR-4), named suppliers (SR-3), integrity hashes (SR-11) and package URLs or CPEs for vulnerability monitoring (RA-5). Its policy templates include a supply chain risk management program policy and an ICT supplier security controls policy, which can be a starting point for your THIRD-3c policy.

11. Turn on monitoring

Per Safeguard's TPRM Monitoring docs, TPRM watches for new vulnerabilities affecting supplier SBOMs, severity changes, exploit availability updates, CISA KEV additions and component health changes. Configure alerts under Settings › Monitoring:

Alerts go to email, Slack, Microsoft Teams, PagerDuty or a webhook. Re-analysis runs daily (the docs suggest this for critical vendors), weekly, monthly or quarterly, and re-assessment can trigger on new disclosures, major version updates, contract renewals and incidents. Scheduled weekly, monthly, quarterly and annual reports export as PDF or Excel, which makes dated R2 evidence and R3 review input.

12. Read the supplier risk score

Each supplier gets a 0 to 100 risk score, higher is better, from vulnerability, compliance, component and operational risk, using EPSS and KEV. Use it to sort attention, not as a pass mark: an incomplete SBOM can flatter a supplier. Component scores elsewhere in Safeguard run the other way, so keep them apart.

13. Cover the code you write yourself

For integration code and scripts your team writes, the Safeguard CLI (GA) scans a directory with safeguard scan --dir . and writes JSON under ./output, and the local runner (GA) runs scans on your own machine. Autonomous remediation (GA) can open fix pull requests on those repositories; it ships switched off with every category set to Manual.

What each obligation maps to

What stays outside the software review

Some of the supplier risk C2M2 and CIP-013 care about is not software composition at all, and no SBOM program reaches it.

OT device firmware and field equipment. Relays, RTUs, meters and inverters run manufacturer firmware. An SBOM program reaches them only if the manufacturer supplies one, and hardware authenticity needs physical inspection and manufacturer channels.

Hosted services. THIRD-2l asks you to evaluate a supplier's hosting environment; that is a questionnaire and audit job.

The self-evaluation and access controls. C2M2 scoring is your own people discussing your own practices, and CIP-013-2 Parts 1.2.3 and 1.2.6 are about people and access paths.

What Safeguard does not do

• It does not assess OT devices, firmware or hardware. Safeguard analyses software: SBOMs, source repositories and container images. It has no hardware bill of materials (HBOM) analysis and does not test field devices or verify hardware authenticity.
• It does not run your C2M2 self-evaluation or a NERC audit. The NERC CIP framework page checks SBOM data that CIP processes depend on. It is not a compliance determination, and only your Regional Entity's audit decides that.
• It only knows what supplier SBOMs declare. If a supplier leaves components out, Safeguard cannot see them, and a sparse SBOM can produce a better-looking score than the product deserves.
• It cannot make a supplier send anything. Suppliers who send no SBOM leave a gap that only contract terms, procurement decisions and compensating controls can close. TPRM can chase a supplier; it cannot compel one.
• It does not verify the supplier's installer or patch at deployment. Attestation scores cover declared components. The CIP-010-4 Part 1.6 check of the file you are about to install remains your change process.
• It does not fix a supplier's product. When a vulnerable component sits inside software you buy, the fix comes from the supplier. Safeguard tells you it is there and helps you track the conversation.
• Its SBOM element checks follow EO 14028 and NTIA expectations today. Check the newer CISA 2026 fields yourself until that changes.

Common mistakes

• Treating CIP-013 compliance as maturity. CIP-013-2 asks for a plan and its use. C2M2 MIL3 practices such as bills of material and end-of-support review go further, and Order No. 912 signals that the standard will ask more.
• Asking for SBOMs nobody reads. An SBOM sitting in a contract file has no value until it is matched against KEV and reviewed against the minimum elements.
• Accepting the first SBOM as permanent. Tie SBOM refresh to each deployment, not the contract date.
• Skipping the integrity method at purchase. If you do not ask how to verify software before you buy, CIP-010-4 Part 1.6 leaves you documenting why you could not verify.
• Ignoring support end dates. Record them at selection. A product past end of support is a vulnerability management problem with no fix path.

FAQ

What is the latest version of C2M2?

As of October 2026, DOE's C2M2 page lists Version 2.1, released in June 2022, as the latest model document. DOE also publishes mappings from V2.1 to NIST CSF 1.1 and says mappings to CSF 2.0 are coming.

Does C2M2 require an SBOM from suppliers?

C2M2 does not require anything; it is voluntary. Practice THIRD-2k, at MIL3, says selection criteria for higher priority assets include evaluating bills of material for key elements such as hardware and software. So an SBOM is needed to reach MIL3 in the THIRD-PARTIES domain for those assets.

Does NERC CIP-013 require an SBOM?

No. CIP-013-2 requires processes for vendor vulnerability disclosure (Part 1.2.4) and software integrity verification (Part 1.2.5); an SBOM is one practical way to support the first.

Who has to comply with CIP-013?

Registered entities with high or medium impact BES Cyber Systems, for those systems and their associated EACMS and PACS. Many small distribution utilities have only low impact assets and are outside its scope, though C2M2 still applies as a voluntary model.

What did FERC Order No. 912 change?

It did not change CIP-013 directly. Effective 24 November 2025, it directed NERC to develop new or modified standards on whether supply chain risk management plans are sufficient to identify and respond to supply chain risks, and on supply chain protections for protected cyber assets.

What are the CISA 2026 SBOM minimum elements?

CISA's 29 July 2026 document lists SBOM-level and component-level data fields, including author signature, generation context, hashes and licenses, plus practices such as coverage and frequency. It replaces the 2021 NTIA elements.

How do we monitor vendor software for known exploited vulnerabilities?

Keep each supplier's current SBOM, match it against CISA's KEV catalog daily, contact the supplier on any match, and record the decision.

Can a small cooperative do this without a dedicated team?

Yes, if it narrows scope to its top suppliers by consequence, asks at renewal and automates KEV matching.

The same KEV matching applies to the open source in code your utility builds around purchased systems. The block below covers fixing those dependencies yourself; components inside a supplier's product still need that supplier's fix.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real session in the Safeguard desktop app. The CLI session appears in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with a dependency upgrade done and tests passing. For a utility, the same flow fits the integration code and scripts your team writes around purchased systems, with an engineer approving every change.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. For a utility that keeps supplier files and code inside a restricted network, that is how scans run on hardware you control.

Click through it at your own pace, or open it full screen.

To try it with your own supplier SBOMs, download the app and CLI at https://safeguard.sh/download and read the setup guides at https://docs.safeguard.sh/docs .

Quick check

Sources

• DOE: Cybersecurity Capability Maturity Model (C2M2)
• DOE: Cybersecurity Capability Maturity Model Version 2.1 (PDF, June 2022)
• DOE: Supply Chain Cybersecurity Principles
• NERC: CIP-013-2 Cyber Security, Supply Chain Risk Management (PDF)
• NERC: CIP-010-4 Cyber Security, Configuration Change Management and Vulnerability Assessments (PDF)
• Federal Register: FERC Order No. 912, Supply Chain Risk Management Reliability Standards Revisions (September 2025)
• Federal Register: FERC Order No. 850, Supply Chain Risk Management Reliability Standards (October 2018)
• Federal Register: FERC proposed rule, Supply Chain Risk Management Reliability Standards (October 2024)
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: 2026 Minimum Elements for a Software Bill of Materials (PDF)
• CISA: Known Exploited Vulnerabilities Catalog
• Safeguard Docs: TPRM SBOM Requests
• Safeguard Docs: TPRM Monitoring
• Safeguard Docs: Existing SBOM
• Safeguard Docs: NERC CIP framework
• Safeguard Docs: NIST SP 800-161 framework
• Safeguard Docs: Air-Gapped Deployment

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.