OT patch management under NERC CIP-007, explained.

OT patch management explained: keeping up with every supplier's security fixes for the devices that run the grid

One supplier notice, from the portal to an install record

1. The supplier publishes a noticeHCSA-2026-14 goes up on the RTU supplier's customer portal on September 22, as a 4-page PDF.
2. The utility finds it on its next checkThe source was last checked September 12, so its 35 days run to October 17, whenever the notice appeared.
3. An engineer evaluates it, device by device14 RTUs of that model, 11 on affected firmware, 3 already fixed. This is where a deadline is kept or missed.
4. Installs go into outages, or a dated plan is writtenSeven RTUs in three outages before November 17; four under a plan because their outage comes on November 24.
5. The plan is carried out, and the evidence is keptControls in place, firmware installed, versions recorded, every date ready for the audit.

Step 3 and step 4 are the subject of this guide. The utility, supplier, devices and dates in this example are fictional.

Why 35 days is shorter than it looks, and three more surprises

Four terms every CIP-007 patch record uses

Fourteen terms are defined in the one-page summary.

What CIP-007-6 R2 asks: a source list, an evaluation every 35 days, and an install or a dated plan 35 days later

In shortRequirement R2 has four parts. Part 2.1 is the process and the list of patch sources. Part 2.2 is the evaluation clock: every source checked at least once every 35 calendar days. Part 2.3 is the action clock: within 35 days of finishing an evaluation, each applicable patch is installed or covered by a dated mitigation plan. Part 2.4 says every plan must be carried out on time, unless the CIP Senior Manager or a delegate approves a change.

The two clocks on one RTU notice

The first clock belongs to the source, the second to the evaluation. In the example, the RTU supplier's portal was last checked on September 12, so its next evaluation was due by October 17, even though the notice itself appeared on September 22. The engineer finished the evaluation on October 13, which started the second clock: every applicable patch installed or planned by November 17.

What the standard leaves to the utility

The standard sets the two 35-day limits and the approval rule, and leaves the rest to each utility's documented process. Its own guidance says the intent is to "be aware of in a timely manner and manage all known vulnerabilities", and that R2 "is not strictly an 'install every security patch' requirement".4 Three choices follow from that.

• Not applicable is a valid answer, with a reason. "If the patch is determined to be non-applicable, that is documented with the reasons why and the entity is compliant."4
• A plan can cover many patches. "The remediation plan measures may be cumulative": disabling one service can answer several vulnerabilities at once.4
• A plan has no maximum length. "There is no maximum timeframe in this requirement", and a timeframe can be an event, such as "at next scheduled outage of at least two days duration".4 Many utilities set their own limit and ask a senior approver for anything longer.

CIP-007-6 in force, CIP-007-7.1 approved for 2028: the patch rules as of November 2026

In shortCIP-007-6 is the version in force. In March 2026 FERC approved eleven revised cybersecurity standards that allow virtualization, including CIP-007-7.1; they become mandatory on July 1, 2028. The maximum penalty stays at the 2025 figure of $1,584,648 per violation per day, because the 2026 inflation adjustment was cancelled. NIST's OT security guide is being revised.

What the 2028 virtualization standards mean for patching

Order No. 919 approves CIP-002-7, CIP-003-10, CIP-004-8, CIP-005-8, CIP-006-7.1, CIP-007-7.1, CIP-008-7.1, CIP-009-7.1, CIP-010-5, CIP-011-4.1 and CIP-013-3, with new defined terms such as Virtual Cyber Asset and Shared Cyber Infrastructure.9 NERC's implementation plan lets a utility adopt them early, six, twelve or eighteen months after the order took effect, by telling its regional entity.9

The patch requirement itself carries over: CIP-007-7.1 keeps R2's four parts and both 35-day clocks in the same words, and adds Shared Cyber Infrastructure (SCI) that supports a covered system, such as the hypervisors and shared hardware under virtual control-center servers, to the devices each part covers.13 A utility that plans to virtualize should add those platforms to its source list.

Which control-system devices need a patch source, and where suppliers actually publish their fixes

In shortR2 covers the devices in High and Medium Impact BES Cyber Systems, and the firewalls, monitoring systems, badge systems and other devices tied to them. Each one that can be updated, and whose supplier still publishes fixes, needs a named source. The government's advisory feed is a useful second source and a poor only source: by one count, only about a fifth of the industrial vulnerabilities published in 2025 came with a CISA advisory.

The devices in scope

NERC sorts grid computer systems by how much harm their loss could do to the Bulk Electric System (BES).4 High and Medium Impact BES Cyber Systems are the ones R2 covers, together with three kinds of associated device: Electronic Access Control or Monitoring Systems (EACMS), such as the firewalls and logging servers at a substation's network edge; Physical Access Control Systems (PACS), such as badge readers on a control-room door; and Protected Cyber Assets (PCA), other devices on the same protected network.4

In practice the list holds RTUs, relays, gateways, switches, firewalls, servers, workstations, historians, DCS controllers and operator stations. From July 1, 2028, under CIP-007-7.1, the hypervisors and shared hardware that support them join the list.13

A device needs a source only if it can be updated and a source exists. The standard's guidance names the exceptions: devices with "no user accessible way to update the internal software or firmware", and devices whose vendors "no longer exist". It also says the source list is "intended to be performed once unless software is changed or added to the Cyber Asset's baseline".4 That last sentence is where gaps start. When a time-sync upgrade adds six GPS clocks with updatable firmware, they need a source on the day they join the inventory.

Where suppliers publish

Texas RE, the regional entity for most of Texas, lists the evidence it expects for Part 2.1: a "Patch management process document" and a "List of monitored sources", covering "Vendor notifications", "Security feeds" and "Vulnerability databases". It asks whether the process includes "controls to track applicable Cyber Assets".18 A source list that is checked against the inventory every time the inventory changes answers that question.

How an engineer decides whether a security patch applies: model, hardware revision, firmware branch and the sentence that says so

In shortApplicability turns on whether the flawed software is actually installed on a device. The answer sits in the notice's affected and not-affected sections, read against each device's model, hardware revision and firmware. Record the reason for every device, applicable or not, and record the date the evaluation finished, because the second clock starts there.

The standard's guidance puts it plainly: "Applicability determination is based primarily on whether the patch applies to a specific software or hardware component that the entity does have installed in an applicable Cyber Asset. A patch that applies to a service or component that is not installed in the entity's environment is not applicable."4 For an applicable patch, the evaluation "can include a determination of the risk involved, how the vulnerability can be remediated, the urgency and timeframe of the remediation, and the steps the entity has previously taken or will take".4

The example's 14 RTUs, decided device by device

Fictional example. The firmware comes from each RTU's last install record; a record that is out of date makes the decision wrong.

How urgent is an applicable patch

An applicable patch is not always an urgent one. Dragos, an industrial security firm, sorts the vulnerabilities it analyzes into three groups. For 2025 it put 3% in "Now", needing immediate action; 71% in "Next", which "can be addressed with compensating controls or at next maintenance cycle"; and 27% in "Never", not worth remediation effort. It also found that 25% of advisories "had no patch or mitigation".19

That is the logic of the action clock. For most OT flaws, the sensible answer is the next outage, with compensating controls written into a dated plan until then. For the few that are being exploited, the plan's first action is due in days. Either way the decision, the reason and the date go on record.

Why substation and plant patches wait for planned outages, and what a firmware install has to prove

In shortInstalling firmware on an RTU or a DCS controller usually restarts it, so it waits for a planned outage of the equipment it watches. Before the install, the utility verifies the patch's source and integrity; after it, it records the version and updates the device's baseline within 30 days. When the next outage falls after day 35, a dated plan is owed.

NIST's guide to OT security says it directly: "Deploying patches to OT environments requires additional considerations for organizations, including testing and validation to ensure that the patches do not impact operational capabilities or safety", and "Patching should be deployed during planned OT outages". It adds that "availability concerns may push patching until the next planned operational downtime".5 The standard's own guidance agrees that patches "may reduce the reliability of the system", and that changes may be "curtailed or denied" in "periods of high demand or threatening weather".4

How long the wait can be

The example's outages against the action deadline

What an install has to prove

A patch install on a covered device is also a configuration change under CIP-010-4. The device's baseline lists "Any security patches applied". Before a change to firmware, software or patches, the utility must "Verify the identity of the software source" and "Verify the integrity of the software obtained from the software source", where the method exists. After the change it updates the baseline "within 30 calendar days of completing the change".14 For High Impact systems it also tests changes, in a test environment where it can.14

Texas RE's questions for Part 2.3 follow the same line: "How to verify the installation of patches?" and "What controls are in place to verify the patch was installed?" Its examples of evidence are "Records of the installation of the patch" and "A dated plan showing when and how the vulnerability will be addressed".18 The standard's own example of install evidence is an export from a patch tool "that provide[s] installation date" or a record of the software version.4

What a CIP-007 mitigation plan holds: the vulnerability, the devices, the actions, the dates and the approvals

In shortA dated mitigation plan names the vulnerabilities it addresses and the planned actions with a timeframe to finish them. Good plans also list the devices, the owner and target date of each action, what will be monitored until the fix is in, and the condition that ends the plan. A plan must then be carried out on time; a revision or extension needs the CIP Senior Manager or a delegate.

The standard asks for little: "the Responsible Entity's planned actions to mitigate the vulnerabilities addressed by each security patch and a timeframe to complete these mitigations".4 A ReliabilityFirst adviser, writing for the regional entity's newsletter, suggests a fuller structure with eight parts.20

1. The vulnerability or vulnerabilities addressed, by patch or by vulnerability database identifier.
2. The systems affected, with a control so that no vulnerable device is missed.
3. How the flaw could be exploited, which sets the risk and the priority.
4. The mitigating actions that block those paths, which may differ by device and location.
5. Action items, each a discrete, trackable task.
6. A target date for each action, set by risk: high-risk items "within a couple weeks", very low-risk items as long as three months, in the adviser's view.
7. Monitoring of the configuration items that keep the mitigation in place.
8. The condition that ends the plan, such as the minimum software version that removes the flaw.

Source: ReliabilityFirst, The Lighthouse, January/February 2018. These are the author's views, offered for discussion and not binding.20

The example's mitigation plan, action by action

For the four Corvane RTUs, the plan takes its controls from the supplier's own workaround: turn off the web configuration page from the engineering workstation, which needs no outage and can be undone; block TCP port 443 to the four RTUs at the substation firewall; alert on any connection attempt; and install firmware 4.2.9 in the November 24 maintenance. The timeframe ends on November 28, 46 days after the evaluation.

When a plan has to change

Outages move. If the plan above relied on a generating unit's outage and the outage moved by two weeks, the plan would need a new timeframe. Under Part 2.4 that revision or extension needs approval by "the CIP Senior Manager or delegate", and the approval belongs before the original date.4 The adviser's warning: "multiple extensions or a substantial extension of the timeline may be closely scrutinized by your audit team".20 Texas RE lists, among its internal controls for Part 2.4, a "Workflow that requires CIP senior manager or delegate approval with time constraints".8

How NERC grades a late patch evaluation, a late install or plan, and an overrun plan

In shortEach requirement carries violation severity levels. A late evaluation or a late install-or-plan is graded by how late it is: Lower, then Moderate, then High. A plan not carried out in its timeframe, or extended without the CIP Senior Manager's approval, is Severe whatever the delay. The penalty ceiling is set by statute; the actual penalty depends on risk, history and how the problem was found.

The severity level is one input. The penalty itself is set case by case, within a ceiling the Federal Power Act fixes and FERC adjusts for inflation: $1,584,648 per violation per day since January 2025.7 No 2026 adjustment was made.10 Most noncompliance is found by the utilities themselves: in 2024 about 87% of all reported noncompliance was self-identified by registered entities, which NERC reads as a sign of good detective controls.3

When patching failures add up

A 2019 case shows how. In early 2019 NERC announced a $10 million penalty against an unnamed utility for 127 violations of the CIP standards, 13 of them classed as serious. Among the serious ones, SecurityWeek reported, was "failure to install available software patches for months and even years".21 The settlement covered many failures across one program, and patches left uninstalled were among the serious ones.

Ten ways a CIP-007 patch cycle slips past day 35

In shortPatch cycles slip at the source list, at the evaluation, at the outage and at the plan. Most slips come from the same root: dates held in one person's calendar and spreadsheet, with no alert when a clock nears its end and no record of the day an evaluation actually finished. Regulators now publish the controls that prevent them.

NERC calls CIP-010, CIP-007 and CIP-004 "high volume and high frequency conduct": the same task repeated many times, where small lapses add up.3 WECC, the regional entity for the western interconnection, names CIP-007-6 R2, security patch management, among its most-reported requirements.22

One fleet's violation, in its consultant's words

How many industrial vulnerabilities utilities must track: record advisories, rising severity, and fixes that do not exist

In shortThe flow of notices keeps growing: 2025 set a record for CISA's industrial advisories, their average severity keeps rising, and a quarter of the advisories one firm analyzed came with no patch or mitigation at all. These are security vendors' counts; there is no official annual total.

For a utility, the count that matters is its own: notices released per cycle by its own sources, for its own models. A utility with twenty sources might see none from most of them in a given month and several from an operating system or network supplier. The work is uneven, which is why a single reminder per month misses the source that published on day 3.

CISA's catalog of vulnerabilities known to be exploited held 1,769 entries on November 6, 2026.17 Its deadlines bind federal agencies. For a utility it is a prioritization input: a flaw in that catalog that also affects a substation device is a strong reason to move it from "next outage" to "this week".

What regional entities expect from patch tools, and what automation can and cannot do in a CIP-007 program

In shortNo rule requires software, and none forbids it. The regional entities now publish the controls they look for: deadline alerts, evaluation dates logged automatically, peer review, install verification and an approval workflow with time limits. Software can watch sources, match notices to the inventory, draft decisions and plans, and keep the dates. People still decide applicability, sign, install and approve.

Texas RE's newsletter puts it in three lines: "Maintain detailed records of all patch management activities", "Consider using patch management tools that log evaluation dates and patch installation confirmations", and "Consider automated reminders and alerts to ensure deadlines and specified timeframes are consistently met".24

Work that software can take

• Checking sources every day instead of once a cycle, including portals and PDFs, and recording what was found and when.
• Matching each notice to the inventory by model, hardware revision and firmware, and flagging every updatable model with no source.
• Drafting the applicability decision per device with the sentence of the notice behind it, for an engineer to accept or change.
• Fitting each install to the next outage that beats its deadline, and re-checking when the outage plan moves.
• Drafting the plan from the utility's template and the supplier's workaround, on the day the miss is known.
• Keeping the clocks: every evaluation, install and plan date logged as it happens, with escalation before day 35.

Decisions a CIP-007 program keeps with people

• Whether a patch applies when the notice is unclear, and whether a risk is acceptable until an outage. The standard's guidance expects judgment about "the risk involved" and "the urgency and timeframe of the remediation".4
• When a control-system vendor must approve an operating system patch first, waiting for that approval.4 NIST notes that OT operators "are dependent on vendors to validate the operability of a patch".5
• Installing firmware, changing a firewall rule and booking an outage: physical work under change control, with the source and integrity checks of CIP-010.14
• Approving a plan's revision or extension: the CIP Senior Manager or a delegate, by name.4

Neither NERC nor FERC has issued a rule about AI in CIP-007 evaluations as of November 2026. A utility that uses software to draft decisions is still the one that decides, and its evidence has to show who decided, on what, and when.

How utilities run CIP-007 patch cycles today: who checks, who decides, who installs, and where the hours go

In shortAn OT security engineer checks the sources and evaluates; control-system engineers and technicians install during outages; outage planners own the windows; a compliance analyst keeps the evidence; the CIP Senior Manager or a delegate approves plan changes. Most of the engineer's hours go to checking sources, reading notices and matching them to the inventory. No public study measures those hours, so every figure here is a sample or a target.

From the OT security engineer to the CIP Senior Manager

A patch passes through five hands before it is closed

Where an engineer's 40 hours a cycle go, in one sample utility

Twenty-eight of the forty hours go before a single decision is written. That is the part of the work that grows with the number of sources and devices, and the part where a missed notice starts.

Spreadsheet and calendar, work orders, or a patch platform

The Halvard RTU notice: from day 31 on the evaluation clock to a plan signed on day 0 of the action clock

In shortThis is the example from the top of the page, inside the product. At the 6:00 a.m. sweep the RTU notice reaches day 31 and turns red. Noor Haddad, the OT security engineer, clicks once; six agents read the notice, match 14 RTUs, draft 14 decisions, fit seven installs to outages and fill the mitigation plan template for the four that cannot make it. She checks the decisions and signs the evaluation and the plan together, with all 35 days of the action clock to spare.

1

Every open patch is a bead on a 35-day dial

Noor's home screen is a dial of 35 days. Each of the 47 open patches is a bead: the inner ring counts days since its source was last evaluated, the outer ring days since its evaluation. Days 25 to 30 are amber, 31 to 35 red, and the severity bands beyond day 35 are printed under the dial.

Beside it, the selected patch: HCSA-2026-14, firmware 4.2.9 for the HC-560 RTU, with the 14 RTUs it touches drawn site by site with their firmware. Under it, one tile per source, 23 in all, each with its own cycle.

2

The 6:00 a.m. sweep moves the hand to day 31

The notice was found on the supplier's customer portal on Tuesday, September 22. On Wednesday, October 7, day 25, Noor and Elena Marsh, the compliance analyst, were reminded; there was still no evaluation. At this morning's sweep the hand moves from day 30 to day 31 and the bead turns red: four days left to evaluate, due Saturday, October 17.

3

One click, and the evaluation is drafted

Noor clicks Evaluate now. The Source watcher reads the 4-page notice signed by the supplier's product security team. The Inventory matcher lists 14 HC-560 RTUs at six sites. The Applicability assessor finds 11 affected and 3 not applicable, at 0.96 confidence, citing two sentences of the notice.

The Outage fitter places seven installs before Tuesday, November 17, the action deadline if Noor signs today, and flags that Corvane's next window is the T2 transformer maintenance on November 24, seven days late. The Mitigation plan drafter starts MP-2026-031.

4

Every decision rests on a sentence of the notice

The patch file shows the supplier's notice with the deciding sentences highlighted and numbered. Note 1: "HC-560 Remote Terminal Unit, all hardware revisions, firmware 4.0.0 through 4.2.8" covers the 11 RTUs on 4.2.7 and 4.2.8. Note 2: "The issue is resolved in firmware 4.3.0 and later" covers the two at Holloway and the one at Saltmere, on 4.3.0 since June 9.

Note 3 joins the supplier's warning that the install restarts the RTU to the utility's own operating rule: losing RTU telemetry at a transmission substation needs a planned outage.

5

The plan template opens already filled in

MP-2026-031 comes from the utility's RTU template, MT-RTU-02, with its controls taken from the supplier's own workaround. Callum Reid, the substation technician, turns off the web configuration interface from the Corvane engineering workstation by Thursday, October 15: no outage needed, reversible. Noor blocks TCP 443 to the four RTUs at the substation firewall by the same day. Security operations alerts on any connection attempt from Friday, October 16. Callum installs 4.2.9 in the T2 maintenance by Thursday, November 26.

Timeframe: complete by Saturday, November 28, 2026, 46 days, inside the utility's own 60-day policy, so no delegate approval is needed.

6

Signed on day 0 of the action clock

At 9:41 a.m. Noor signs the evaluation and the plan together. The bead leaves the inner ring and starts again on the outer ring at day 0, with all 35 days left to install or plan, due Tuesday, November 17. The Clock keeper logs the evaluation date and starts the action clock. Every affected RTU is now booked into an outage or covered by a dated plan.

The solution's design targets are an evaluation drafted within one day of a notice's release, and a dated plan in place on day 0 of the action clock. They are targets, to be measured on your own sources.

Nine more screens, from the decision table to the evidence an auditor asks for

In shortOne notice is the story. These screens show the rest: the decision for every RTU, sixty days of outages against every deadline, the plan on record with its approvals, every running plan, the sources against the inventory, the assets, the evaluation cycles and what the auditor will ask, and the utility's own rules.

Select any screen to open it larger. The utility, suppliers, sites, people and figures are fictional. The 60-day plan limit is the sample utility's own policy; CIP-007-6 sets no maximum plan length.

Six agents watch, match, draft and keep the clocks; the OT engineer signs, and only the delegate extends a plan

In shortEach agent has one job and limits it does not cross. None of them closes an evaluation, approves a plan, touches a device or books an outage. The OT security engineer signs every evaluation and plan; the CIP Senior Manager's delegate approves any revision, extension or plan longer than the utility's limit, before its date. Every date is logged when it happens and nothing is backdated.

Source watcher to Clock keeper: the six patch agents

The engineer signs; the delegate approves changes to a plan

An optional setting asks a second engineer to confirm every "not applicable" decision, the peer review a regional entity lists among its practices.8

The engineer, technician, analyst, delegate and plant engineer in the screens

Supplier notices and your inventory in; cited decisions, dated plans and a patch evidence log out

In shortIt reads the sources your team already watches, your asset inventory, your outage plan and your plan templates. It leaves behind a decision per patch per device with its citation, dated mitigation plans, both clocks for every patch, and an evidence log the compliance analyst can export by source and cycle. Your systems of record stay where they are.

Where the sample utility's hours would go, by hand and with the solution

Systems a patch rollout connects to

For each, check whether it has an API, a file feed, or only screens, and who owns it.

Your procedure, inventory and outage plan stay yours

Cited, signed, and dated as it happens

What a late patch evaluation costs you: penalty exposure, engineer hours and audit findings

In shortStart from your own numbers. No regulator or study publishes the hours a patch cycle takes or how often evaluations run late, so the costs that matter are yours. A few published figures frame them: the statutory penalty ceiling, how often CIP-007 issues are reported, and what an engineer hour costs by FERC's own reckoning.

Timing one patch cycle to find your own baseline

Self-reports, rushed plans and engineers who leave

What automated patch evaluation returns when you count engineer hours and plans against the tool's yearly cost

In shortPut in your own numbers. The calculator starts from FERC's loaded engineer wage and asks you for the rest: cycles a year, hours per cycle now and after, plans a year and the hours each saves, and what the tool and your testing cost a year. Engineer time is the part a calculator can count. The clocks kept and the evidence ready count too, and they are listed beside it.

Source checks, decisions, plans and evidence: where patch automation saves

Patch cycles a year, hours per cycle and your hourly cost

A program that runs a monthly cycle across twenty or more sources and saves most of its 40 hours covers its yearly cost on engineer hours alone. A program with five sources and a few hours a cycle does not, and should judge the case on the clocks and the evidence, or say no.

How ready your CIP-007 patch program is: sources, inventory, outages, findings and sign-off

In shortPick the answer closest to your program today. Eight questions score 0 to 2; the last is for reflection. The meter adds up your score as you go, and each question says why it matters and what a strong answer sounds like.

A low score means mapping every model to a source first

What to ask CIP-007 patch management software about sources, applicability, outages, plans and evidence

In shortAsk every vendor the same questions, us included. The answers show how the work is done: what it reads, how it decides applicability, how it handles outages and plans, what evidence you keep, what it may touch on your network, and how you would measure it on your own sources.

We found no published independent test of any CIP-007 patch tool's accuracy, as of November 2026. A parallel run on your own sources is the fairest comparison, and the same run measures your current process.

Test patch automation on your own sources and a recent cycle, then decide on four numbers

In shortMeasure first, then run the tool beside your current process on your own sources and notices, then decide with four numbers. None of these steps commits you to a vendor, and your engineers keep signing every evaluation throughout.

1. Time one full cycle by step and by source. That is your baseline.
2. Pull last year's record: release and evaluation dates, plans and their signing days, extensions, self-reports.
3. Gather your source list, inventory, outage plan and templates, and an approval path to share them under your information protection program.
4. Replay one recent cycle, then run in parallel on live notices for six weeks, with your engineers deciding and signing.
5. Decide with four numbers: decisions agreed, notices missed, days from release to evaluation, and engineer hours per cycle.

Decisions agreed, notices missed, days and hours: what a patch pilot measures

CIP-007 patch management questions answered: the 35-day clocks, mitigation plans, penalties and CIP-007-7

In shortThe questions OT security and compliance teams search for most, each answered on its own.