What software integrity verification for NERC CIP requires before a baseline change
If your organization installs firmware, operating system updates, application software or security patches on high or medium impact BES Cyber Systems, CIP-010-4 Part 1.6 requires you to verify the identity of the software source and the integrity of the software before the baseline change, whenever the source makes a verification method available. The registered entity owns this control and must be able to show it operates, while the Regional Entity or NERC tests it. The rule applies to the EACMS and PACS associated with those systems as well as to the BES Cyber Systems themselves, so the scope is wider than the control room equipment many teams first picture.
The answer is not the same for every update. It depends on three things: the verification method the vendor actually publishes (for example, signed packages, published hashes or a vendor-controlled repository), the systems in scope for each change, and the procurement terms agreed under CIP-013. Confirm with each vendor which methods it offers for each product and patch channel, and record where no method exists, since the requirement only attaches where the source provides one. Ask whether the vendor will notify you of key changes and whether it will support verification of its releases in the contract, because those terms decide what you can actually check.
There is no CIP certificate for this control. The Compliance Enforcement Authority, either a Regional Entity or NERC, monitors compliance through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and investigations. Auditors will ask for the baseline record, the verification step performed before each change, and the exceptions process for updates where the vendor offered no method. Build that trail into your change tickets from the start, and confirm with your Regional Entity which evidence format it expects, because the record of a single change is easy to reconstruct only if it was captured when the change happened.
Which verification methods vendors actually provide
CIP-010-4 Part 1.6 applies only when the source makes a verification method available, so the first question for each vendor is what it actually publishes. The mechanisms below are the ones an entity can check, and each one needs a documented result whether the vendor provides it or not.
Cryptographic signatures on packages
A vendor signs each release package with a private key, and the entity checks the signature against the vendor's published public key before installation. The check produces a stored verification record tied to the specific package version and the date it was run. Confirm which key signs releases, where the public key is published, how it is rotated, and whether revoked keys are announced so older packages can still be assessed.
Published checksums on the vendor site
A checksum such as a SHA-256 hash is published alongside the download, and the entity compares its copy against that value. This confirms the file was not altered in transit, but it proves little if the checksum sits on the same server as the download. Ask whether checksums are signed, whether they are published on a separate channel, and whether the vendor documents the hash algorithm it uses.
Signed firmware images
Field devices often verify their own firmware at install time, and the vendor signs images with a key held in its build environment. The entity confirms that the device rejects unsigned or mismatched images and records the image identifier in the baseline. Ask which device versions enforce signature checks, whether that enforcement can be disabled by a local setting, and how the vendor handles devices that cannot verify an image.
Vendor attestations and release notes
Vendors often provide a release document that lists the components, versions and security patches in a build, sometimes with an attestation of how the build was produced. The entity compares those contents with what it installs and keeps the document with the change ticket. Confirm that the release notes name every component the baseline must record, and ask whether the attestation is independently assessed or only self-declared.
Secure update channels
Some vendors deliver patches through an authenticated, encrypted channel that the entity's system pulls from directly. The entity documents which source it monitored for each patch, which CIP-007-6 Part 2.1 expects, and confirms the channel's authentication before accepting content. Confirm the channel's authentication method, which hostnames or addresses it uses, and how the vendor announces a change to that channel.
Documented gaps where no method exists
Some vendors offer no verification method for a given product, especially older or legacy software. The entity must still record what it did in that case, such as obtaining the file from an authorized source, comparing it with a known-good copy, or restricting installation to a controlled environment. Ask the vendor in writing to confirm that no method exists, and record the response, since the gap itself becomes evidence of how the entity handled the requirement.
How verification fits into a baseline change
Each software or firmware change follows the same chain: the package is traced to its source, checked for integrity, recorded, and only then reflected in the baseline that CIP-010-4 requires. The sequence leaves a trail an auditor can follow from the vendor download to the installed version.
Obtain the package from the vendor channel
The engineer responsible for the change downloads the operating system, firmware, application or patch only from the channel the vendor publishes for it, such as its support portal or a documented update repository. The change ticket records the channel, the file name, the version and the date of retrieval. Packages received by email, USB media or a third party's copy are routed back to the vendor channel before they go further. The ticket entry is the first piece of evidence for the change.
Confirm the identity of the software source
Where the vendor publishes a method, the entity confirms that the package really comes from that vendor. This may mean checking a digital signature against the vendor's published certificate or key, or confirming the publisher on a signed package. The entity must confirm the method the vendor actually offers, since not every vendor provides one. The output is a signature verification result or a note in the ticket stating which vendor method was used and its outcome.
Verify integrity against the vendor method
The entity compares the package against the integrity value the vendor publishes, such as a cryptographic hash, or validates the package's signature end to end. Hash comparisons are run with a tool the entity trusts and the output is kept as is. A mismatch stops the change until the source is resolved with the vendor. The hash comparison log, with the file name, the published value and the computed value, becomes the integrity evidence for the change.
Record the verification result in the change record
The verification outcome is written into the change ticket with the person who performed it, the date, the method, and the approval to proceed. Where the vendor offers no method, the record states that fact and documents the compensating steps the entity chose, such as obtaining the package from a verified channel or escalating through its supply chain process. Approval is given by the person the entity's change management process designates. The signed record or ticket entry closes the verification step.
Update the baseline with name and version
Once the package is verified and approved, the baseline entry for each affected Cyber Asset is updated. CIP-010-4 R1 Part 1.1 requires the baseline to list the operating system or firmware with its version, commercially available or open-source application software intentionally installed with its version, custom software, logical network accessible ports, and security patches applied. The baseline is kept individually or by group, as the entity has defined. The updated baseline entry is the record that shows what the system is expected to run after the change.
Install the change and check the result
The approved package is installed under the change ticket, and the installed state is compared with the updated baseline. Installed software names, versions, patch levels and ports are checked against what was approved, and any difference is investigated before the change is closed. The post-change comparison is retained with the ticket. Confirm with your own configuration monitoring process how these checks are scheduled and retained for each system category in scope.
What CIP-013 procurement terms should say about software integrity
CIP-013-2 Part 1.2 requires the entity's procurement process to address, as applicable, six vendor topics, and one of them is verification of software integrity and authenticity. The entity writes its own supply chain cyber security risk management plan and decides which terms it needs. The vendor agrees to those terms in the contract or in a completed questionnaire. The entity stays responsible for the plan and for how it is carried out, so a vendor's promise does not discharge the entity's duty. Confirm with your compliance lead which of the six topics your plan treats as applicable to each product or service before you draft any clause.
For software integrity, a buyer typically asks the vendor to state in writing the verification method it uses for each delivered item, such as published hash values, digital signatures on binaries, or a signed code-signing certificate chain, along with where the verifying material is published. Terms usually also require notice before the vendor changes that method, including changes to signing keys, certificate authorities or the distribution channel, so the entity can update its verification steps before the next install. Where the vendor provides a method, the entity can then use it in the verify source and integrity before baseline change step that CIP-010-4 Part 1.6 requires for operating system or firmware, application software and security patches on high and medium impact systems and their EACMS and PACS.
The contract should also fix what evidence arrives with each release, for example the artifact name and version, the digest or signature file, and release notes that identify the patches included. Procurement questionnaires should ask whether the vendor discloses known vulnerabilities and how quickly it issues patches, and whether it coordinates incident response with the buyer. These answers feed the entity's CIP-007-6 Part 2.1 patch tracking and the baseline entries in CIP-010-4 Part 1.1, which record versions and security patches. Ask the vendor to confirm in writing that it will not change these release practices without notice, and keep a record of each answer so it can be produced at audit.
How scope changes by impact level and system type
Part 1.6 applies to high impact BES Cyber Systems, the most heavily scoped category under CIP-002-5.1a. These are mainly the BES Cyber Systems at Control Centers of Reliability Coordinators and at qualifying Balancing Authority, Transmission Operator and Generator Operator Control Centers. For these systems, the software source and integrity check is a gate on every baseline change that brings in new operating system or firmware, application software or security patches. The verification must be recorded alongside the change, so the entity can show an assessor what was checked, when, and by whom.
- Operating system and firmware changes: Every firmware upgrade or operating system image needs a documented source check before it enters the baseline.
- Application software and security patches: Vendor patches are covered when the vendor offers a verification method, so the change record should name the method used.
- Change records: Expect more change tickets than medium impact systems, because each baseline change in scope needs its own verification evidence.
- Associated EACMS and PACS: Access control and physical access systems tied to these BES Cyber Systems follow the same verification pattern.
- Testing environments: Confirm with your auditor how staging and test copies of high impact systems are treated if they are used to prepare baseline changes.
Before relying on this tab, confirm with your CIP-002 categorization which Control Center and BES Cyber Systems are rated high impact.
Part 1.6 also applies to medium impact BES Cyber Systems. The medium impact category covers systems such as generation of 1500 MW or more at one plant and Transmission Facilities at 500 kV or higher, using the bright-line criteria in CIP-002-5.1a Attachment 1. Within medium impact, the verification duty applies to the same change types as high impact, but the scope differs in one important way: many requirements in CIP-005, CIP-007 and CIP-010 are split by whether a medium impact system has External Routable Connectivity. Confirm which of your medium impact systems fall into that group before you set the scope of the verification step.
- Same change types: Operating system or firmware, application software and security patches are covered in the same way as high impact systems.
- Routable connectivity split: Systems without External Routable Connectivity still carry the Part 1.6 duty, but confirm with your categorization how the related requirements apply to them.
- Lighter change volume: Medium impact estates often have fewer baseline changes, so the verification record can sit inside a standard change template.
- Associated EACMS and PACS: Remote access gateways and badge or door systems linked to medium impact systems are in scope for the verification duty.
- Mixed portfolios: If one site contains both high and medium impact systems, keep separate scope lists so the evidence can be pulled by impact rating.
Check your CIP-002 categorization for the medium impact list and the External Routable Connectivity status of each system before the audit period begins.
Electronic Access Control or Monitoring Systems (EACMS) and Physical Access Control Systems (PACS) are scoped by their association with high or medium impact BES Cyber Systems, not by their own rating. Part 1.6 covers them, so a team that updates only the control systems and forgets the access systems creates a gap an assessor can find. The verification applies to firmware and software that controls who can reach the BES Cyber Systems, both over the network and through physical doors and readers. The practical change is that access systems need the same source and integrity checks as the operational systems they protect.
- Identify associations: Build a list that links each EACMS and PACS to the BES Cyber Systems it serves, because scope follows that link.
- Remote access gateways: Intermediate Systems and other EACMS used for vendor or staff remote sessions need documented verification before updates.
- Badge and door controllers: PACS firmware and access control software need the same source check as other in-scope firmware.
- Monitoring tools: Security monitoring platforms that qualify as EACMS are included, so their update records belong in the evidence set.
- Vendor-supplied images: Where a vendor ships a packaged appliance for an access system, record the method used to verify the image.
Confirm with your CIP-002 categorization and your Regional Entity's interpretation which access systems are associated with each in-scope BES Cyber System.
Part 1.6 is written for high and medium impact systems and their associated EACMS and PACS. Low impact BES Cyber Systems are governed by CIP-003, which sets the cyber security plan and the controls that apply at low impact assets. That means the verification duty in CIP-010-4 does not apply to a low impact asset in the same way it applies to higher categories. Entities with only low impact assets should not assume that no software integrity practice is needed, because the CIP-003 plan and any vendor remote access controls it requires still shape how vendor software reaches those systems.
- Plan-based approach: Low impact obligations are set through the entity's CIP-003 cyber security plan, so the software practice is documented there.
- Vendor remote access: CIP-003-9 adds vendor electronic remote access controls for low impact BES Cyber Systems, which can affect how vendor software is delivered.
- Categorization first: Confirm that the assets are truly low impact under your CIP-002 categorization before applying this tab.
- Future changes: CIP-003-11 adds remote user authentication and malicious communication detection for low impact assets with a later effective date, so the plan will change.
- Voluntary practice: Verifying source and integrity for low impact software is a sound practice even where the rule does not require the same record.
Review your CIP-003 plan and CIP-002 categorization with your Regional Entity or compliance advisor to confirm exactly which obligations apply.
What evidence an auditor will ask to see
A Compliance Enforcement Authority, meaning the Regional Entity or NERC, will ask for records that show the Part 1.6 check happened on each relevant change, not just a written procedure. For a software or firmware change to an in-scope system, expect to be asked for the baseline configuration record showing the operating system or firmware version, each application and its version, and the security patches applied, since CIP-010-4 R1 Part 1.1 requires that content. Expect the auditor to pick a sample of changes from the audit period and trace each one back to a change ticket, the baseline before and after the change, and the record of the verification performed. Ask your team now whether your change tickets have a required field for the source identity check and the integrity check, and whether those fields are completed for every change, including emergency and patch changes.
For each change, the record should name the vendor verification method used, such as a published hash or signature check, and the result. Where the vendor offers no method, the record should say so and show the alternative you used or the reason no check was possible, since Part 1.6 applies when the source makes a method available. Verification logs or tool output, such as the hash comparison or signature validation output retained with the ticket, are the strongest form of this evidence. Documented exceptions need a stated reason, an approver, and a date, and an auditor will test whether exceptions are rare and justified. Procurement terms that commit the vendor to providing a verification method and to notifying you of changes in signing practices should also be retrievable, because they show the CIP-013 plan was implemented. Confirm with your compliance lead which evidence retention period applies to your audit period, since that is set by your Regional Entity's process rather than by this page.
Where FERC's 2025 order points next
FERC's supply chain order and the virtualization revisions that follow it point the same way: vendor software must be traceable and verifiable through the CIP-005, CIP-010 and CIP-013 controls. The cards below cover what the order names, where plans tend to be thin, how to treat verification, and which dates to confirm before you set vendor deadlines.
Three standards named in Order 912
Order No. 912 names CIP-005-7, CIP-010-4 and CIP-013-2 as the supply chain standards. Each one covers a different part of the vendor relationship: remote access in CIP-005-7, software verification and baselines in CIP-010-4, and procurement terms in CIP-013-2. For software integrity, confirm that your CIP-013 plan, your CIP-010 baseline process and your remote access design describe the same vendor update path. Gaps between those three documents are the ones to close first.
Gaps from the 2023 report
Order No. 912 cites gaps in supply chain plans described in FERC audit staff's 2023 Lessons Learned report. Read that report directly before you revise your plan, and test the plan against its findings. For software integrity, check whether your CIP-013 plan names who verifies a vendor's published hash or signature, what happens when a check fails, and where the result is recorded. A plan that stops at a general statement about integrity leaves the gap the report describes.
Verification above the minimum
FERC declined to require entities to validate data received from vendors, and encouraged that validation as a voluntary practice. Treat verification as a sound practice above the minimum. Part 1.6 of CIP-010-4 sets the floor where a vendor provides a method. Record which vendors offer hashes, signatures or attestations, and for any update you do not verify, document the reason and the compensating control. That record is what you will need when you explain the decision to an auditor.
The 2028 virtualization set
Order No. 919 approved revised standards that accommodate virtualization, and NERC lists CIP-010-5 and CIP-013-3 among them with an effective date of 1 July 2028. If your vendors ship virtual appliances, container images or cloud templates, the baseline and source verification steps will need to cover those artifacts. Ask vendors now how they publish image digests, signing keys and update channels, so the 2028 changes do not surprise your procurement files.
Confirm dates on NERC's page
Version numbers and effective dates for these standards change through 2029, and the NERC standards page is the authority for which version is enforceable on a given date. Before you set a vendor deadline or schedule a baseline change, check the status of CIP-005, CIP-010 and CIP-013 there. Record the date you checked and keep a copy of the status page with your compliance records.
Questions about software integrity verification for NERC CIP
Is software integrity verification required if the vendor offers no method?
No. Part 1.6 of CIP-010-4 R1 applies when the software source makes a method available, so the verification step is tied to what the vendor provides. If a vendor offers no method, the obligation to verify identity and integrity before a baseline change does not switch on for that item in the same way. The gap still matters for procurement. Under CIP-013-2, the procurement process should address software integrity and authenticity as applicable, so the entity should ask vendors in writing whether a method exists, record the answer, and decide how it will manage the risk where none is offered. Ask your compliance lead to confirm how the entity documents that decision.
Do hash values alone satisfy the software integrity requirement?
Not by themselves in every case. Part 1.6 asks the entity to verify both the identity of the software source and the integrity of the software, so a checksum that arrives from the same channel as the download does not prove the source. A stronger approach checks the hash against a value the vendor publishes through a separate, trusted route, or verifies a digital signature that chains to the vendor. Whether a particular method meets the requirement is an assessment question, so confirm the approach with your auditor or Regional Entity before relying on it. Keep the method, the values checked and the result for each change.
How do patches differ from firmware for this requirement?
Both fall under the verification step before a baseline change, but they reach a baseline through different paths. CIP-010-4 R1 Part 1.1 requires the baseline to record the operating system or firmware with its version, application software with its version, and security patches applied. Security patches are also handled by CIP-007-6 R2 Part 2.1, which requires a patch management process that tracks, evaluates and installs patches and names the sources monitored for released patches. In practice, the patch process tells you when a patch is available, and the change process verifies its source and integrity before it is installed. Firmware often requires more care because it can be harder to roll back and may be applied through vendor tools, so document the verification step for each firmware package.
Is open-source software covered by the verification requirement?
Yes, when it is part of an applicable system. The baseline in CIP-010-4 R1 Part 1.1 covers commercially available or open-source application software that is intentionally installed, so open-source components are in scope for the baseline. The source-verification step applies where the source makes a method available, and many open-source projects publish checksums, signatures or signed release metadata. The entity owns the decision about which sources it trusts. Record the upstream project, the release version, the method used to verify it, and who approved the component. Your implementation partner can prepare that record, but the entity remains responsible for the baseline.
What evidence should we keep to show software integrity checks?
Keep evidence that links each change to a verification step. For each software, firmware or patch change, retain the baseline entry with its version, the source the package came from, the verification method and the result, the date, and the approver. Also keep the procurement record that shows the vendor's answer on integrity and authenticity methods, and the patch tracking record that shows which sources are monitored. Evidence should be retrievable without rebuilding it from memory. Ask your auditor which formats and retention periods they expect, and confirm the audit period with your Regional Entity, since the NERC Rules of Procedure set how monitoring works.
Can an implementation partner prepare the integrity evidence for us?
Yes, within a written scope. An implementation partner such as DeployOpen can build the change workflow, configure the baseline records and verification steps, document the procedures and assemble the evidence on self-hosted platforms inside your own environment. The entity still owns its controls, and the partner does not decide whether the entity is compliant. Agree in writing who will perform each verification, who reviews the records and how the work is handed over. Ask any partner to show how the evidence will be produced, stored and kept under your control.
Does an auditor certify that we comply with the integrity requirement?
No. There is no CIP certificate. The Compliance Enforcement Authority, which is a Regional Entity or NERC, monitors compliance through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and other mechanisms. An outside assessor or consultant can test your controls and prepare you for that monitoring, but only the enforcement authority makes compliance findings. Your internal team, or an outside firm you engage, can review evidence before a monitoring engagement, and the Regional Entity reaches its own conclusions. Plan around that, and confirm the process with your Regional Entity.
How DeployOpen prepares software integrity evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the software you run can carry the source verification and baseline records CIP-010 Part 1.6 asks for. We prepare the systems and evidence; your organization owns its controls, and only an independent auditor issues findings on compliance.
How we scope
- The written scope lists which systems, impact categories and software sources fall under your CIP-010 and CIP-013 processes.
- We inventory each platform component and the vendor methods available to verify its source and integrity before any change.
- Scope names the baseline fields to capture, including operating system or firmware versions and installed application versions.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We configure verification steps for vendor-published checksums or signatures where the vendor provides a method.
- Installation procedures record the verification result before a baseline change is made to the system.
- Patch intake follows a documented process that identifies monitored sources for released security patches.
- Where a vendor offers no verification method, we document that gap so your procurement and risk team can decide how to address it.
How we hand over
- You receive documented verification procedures, baseline records and the configuration of each platform component in scope.
- Deliverables include test records showing the verification steps were run and what each one produced.
- We walk your compliance and operations staff through the evidence so they can reproduce the steps and answer assessor questions.
- Your organization retains ownership of the controls, the evidence and the decisions made from them.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for platforms changed after handover.
- Retained support can refresh verification records when vendors publish new releases, patches or signing methods.
- Ask us to confirm in writing which verification steps are covered by the retainer and which remain with your team.
