OT patch management that runs both 35-day clocks on every patch, so each evaluation is signed in time and a dated mitigation plan is in place before an install has to wait
Every OT patch evaluated inside the 35-day window, with a dated plan if it must wait.
See one case, screen by screen ↓CIP-007-6 R2 asks for two clocks on every patch. Each source that publishes patches for your Cyber Assets must be evaluated at least once every 35 calendar days, and within 35 days of finishing the evaluation each applicable patch must be installed, or a dated mitigation plan written. Across substations, a power station and control centres, the notices come from many suppliers — by customer portal, email list, release page and PDF — and each source's cycle started on a different day. The control is often a reminder in one engineer's calendar.
The answer to "does this apply to us?" is usually one sentence in a release note behind a supplier login, and it depends on model, hardware revision and firmware branch. RTUs and plant DCS can only be patched in planned outages, so when the next outage falls after the deadline a mitigation plan is owed — and it is usually written in the last two days. A model added to the inventory without a tracked source is never evaluated at all, and nobody finds out until the audit. Lateness is a violation whatever the reason, from day 36.
Estimated split of one cycle across 23 sources, in engineer-hours, by hand (about 40 hours, Lumina's own baseline) and with the solution (the 6-hour target).
Six specialist agents watch the sources, match the inventory, draft each decision and plan; the OT engineer signs.
Lumina Utilities runs 312 Cyber Assets at 9 sites — five substations, the Saltmere power station, two control centres and the Wrenfield water works. On Tue 22 Sep, Halvard Controls posted security notice HCSA-2026-14 on its customer portal. Lumina last evaluated that source on Sat 12 Sep. Here is Tue 13 Oct, screen by screen, in the working solution.
Noor owns the patch evaluations for the substations and the power station. Her home is a dial of 35 days with a bead for each of the 47 open patches: the inner ring counts the days to evaluate, the outer ring the days to install or plan. Days 25–30 are amber, 31–35 red, and the severity bands past day 35 are printed under the dial. Below it, a tile for each of the 23 sources shows where its cycle stands.
“47 patches open on 312 Cyber Assets at 9 sites · 19 to evaluate · 28 to install or plan · 12 plans running · 0 late this year”
The Source watcher found the notice the day it was posted and the Inventory matcher matched 14 HC-560 RTUs. On Wed 7 Oct, day 25, the Clock keeper reminded Noor and Elena Marsh; there was still no evaluation. At this morning's sweep the hand moves from day 30 to 31, and the bead for HC-560 firmware 4.2.9 — an authentication bypass in the RTU's web configuration interface, CVSS 8.8 — turns red. Four days are left to evaluate, by Sat 17 Oct.
“06:00 · HCSA-2026-14 reached day 31 with no evaluation — escalated to Noor Haddad and Elena Marsh”
Noor clicks Evaluate now. The Source watcher reads the 4-page notice signed by Halvard PSIRT. The Inventory matcher lists 14 HC-560 RTUs at 6 sites. The Applicability assessor finds 11 affected and 3 not applicable, at 0.96 confidence. The Outage fitter places 7 installs before Tue 17 Nov — Pennick on 27 Oct, Brackwater on 3 Nov, Ashgrove on 4 Nov — and flags that Corvane's next window is 7 days too late.
“Outage fitter · Corvane misses the deadline — next window: T2 maintenance Tue 24 Nov, 7 days late”
The patch file shows Halvard's notice with the sentences that decide applicability marked and numbered, and margin notes beside them. Firmware 4.2.7 and 4.2.8 fall inside the affected range; Holloway's two RTUs and Saltmere's one run 4.3.0, installed 9 Jun. The note on remediation adds Lumina's own operating rule: losing RTU telemetry at a 400 kV or 132 kV substation needs a planned outage.
Affected: “HC-560 Remote Terminal Unit, all hardware revisions, firmware 4.0.0 through 4.2.8.” Not affected: “The issue is resolved in firmware 4.3.0 and later.”
The decision table lists every RTU by tag, bay and firmware: applicable or not applicable, the reason with its citation, the action and the date. COR-RTU-401 to 404 go into mitigation plan MP-2026-031 with the install on 24 Nov. The Pennick RTUs are installed in the bay outage on Tue 27 Oct, Brackwater in feeder maintenance on Tue 3 Nov, Ashgrove in planned maintenance on Wed 4 Nov. Noor can change any decision before she signs.
“14 HC-560 RTUs · 11 applicable · 3 not applicable · drafted · you sign”
Outage fit lays the next 60 days of planned outages at all nine sites against each patch's deadline. 13 of 15 install groups fit: 141 assets across 8 sites are booked into outages before their deadlines. Two miss. The four Corvane RTUs need Bays 1, 2, 5 and 6 out, and that is the T2 transformer maintenance on Tue 24 Nov. At Saltmere, VPA-2026-19 misses too, because the Unit 2 outage moved from 2 Nov to 16 Nov.
“Install or plan by Tue 17 Nov; the next window covering Bays 1, 2, 5 and 6 is T2 maintenance on Tue 24 Nov.”
MP-2026-031 is drafted from template MT-RTU-02, with controls taken from the supplier's own workarounds. Disable the RTU web configuration interface from the Corvane engineering workstation — no outage needed, reversible — by Thu 15 Oct (Callum Reid). Block TCP 443 to the four RTUs at the substation firewall (Noor Haddad). Alert on any connection attempt (Security operations). Install 4.2.9 in the T2 maintenance, by Thu 26 Nov.
“Complete by Sat 28 Nov 2026 · 46 days · inside the 60-day limit, so no delegate approval needed”
Noor signs the evaluation and the plan together. The red bead leaves the inner ring and starts again on the outer ring at day 0, with 35 days left to install or plan, due Tue 17 Nov. 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.
“Signed on day 0 of the action clock · all 35 days to spare · plan MP-2026-031 complete by Sat 28 Nov”
The full plan shows the security patch, why it cannot be installed in time, the four assets, the timeframe, the four actions with owners and dates, and the evidence to collect: a configuration export showing the HTTPS server off, the firewall rule export, the monitoring rule ID and an install record with the firmware version for each RTU. Elena reviews it at 10:05. Victor Anand, the CIP Senior Manager's delegate, is needed only for a revision or an extension.
“The Clock keeper asks for each on its date.”
The sweep also compares the inventory's 41 models with the source list. Six Bexley Time BT-90 GPS clocks at Pennick, added on Mon 21 Sep by the time-sync upgrade WO-26-40118, run updateable firmware 1.4.2 but have no tracked source. Noor adds Bexley Time as a source; its clock starts, with the first evaluation due by Tue 17 Nov.
“They are updateable (firmware 1.4.2), so CIP-007-6 R2.1 needs a source. Without one, no evaluation clock ever starts.”
The same patch, seen by the five people who own it — what their cycle looked like, and what it looks like now.
Six specialist agents watch the sources, match the inventory, draft each decision and plan; the OT engineer signs.
Checks the 23 patch sources every morning — supplier portals, email lists, release pages and the national ICS advisory feed — and downloads each notice and its release notes, recording when and where it was published.
Matches each release to asset models, hardware revisions and firmware branches in the inventory, and each morning flags any updateable model with no patch source.
Reads the notice's affected and not-affected sections, fixed versions and workarounds, and drafts applicable or not applicable for every matched asset, citing the sentence and the inventory record behind it.
Places each install in the next planned outage or maintenance window that covers its bay and beats the action deadline, says which cannot make it, and re-checks when the outage plan changes.
Fills the plan template for the asset type with controls from the supplier's workarounds first, owners, dates, a timeframe that ends after the planned install, and the evidence to collect.
Runs both 35-day clocks for every patch and every plan's timeframe, reminds the owner and the compliance analyst at day 25, escalates at day 31 and logs every evaluation, install and plan date as evidence.
Signs evaluations and plans. The agents propose; a named person decides.
Ask in plain words, or say what to draft. Every answer points to the notice, the inventory or the outage plan behind it.
Which patches could miss day 35 this week?
One is in the red sector: HCSA-2026-14, the Halvard HC-560 RTU firmware, at day 31 with no evaluation — due Sat 17 Oct. Three Orrin rollups are at day 28 (due Tue 20 Oct), drafted and waiting for Priya Sethi. On the action side, CRSN-26-04 is at day 30 and its last 7 relays go in Thursday's Unit 1 outage, before the Sun 18 Oct deadline.
Why are the Holloway RTUs not applicable?
The notice says “the issue is resolved in firmware 4.3.0 and later”, and the inventory shows both Holloway RTUs and the Saltmere RTU on 4.3.0, installed 9 Jun. The other 11 are on 4.2.7 or 4.2.8, inside “4.0.0 through 4.2.8”.
Which asset models have no patch source?
One: Bexley Time BT-90 GPS clocks — 6 at Pennick, added on Mon 21 Sep with the time-sync upgrade. They are updateable, so CIP-007-6 R2.1 needs a source for them. The other 40 models are covered by 23 sources.
Draft the plan for the Corvane RTUs
Drafted from template MT-RTU-02: disable the web interface and block TCP 443 at the Corvane firewall — both the supplier's own workarounds — alert on any attempt, and install 4.2.9 in the T2 maintenance on Tue 24 Nov. Timeframe: complete by Sat 28 Nov, 46 days, inside the 60-day limit. It's open for you to sign.
13 screens from the working solution, on its sample data. Pick one to see it large.
The 35-day clocks are fixed by the standard. Everything around them is set by the utility, and every change is saved as a new rule version with its author.
| Setting | Default | Choose from |
|---|---|---|
| Evaluation clock and action clock | 35 days each | Fixed by the standard — from a source's last evaluation (R2.2), and from evaluation to install or dated plan (R2.3) |
| Amber from day | 25 | Adjustable by day — the owner and the compliance analyst are reminded |
| Red from day | 31 | Adjustable by day — escalated to the OT security lead; agents draft the evaluation and the plan |
| Morning sweep | 06:00 | 05:00 · 06:00 · 07:00 — sources checked and clocks moved |
| A person decides below confidence | 0.80 | 0.75 · 0.80 · 0.85 · 0.90 — the Applicability assessor asks the engineer |
| Longest plan without the delegate | 60 days | 45 days · 60 days · 90 days — longer plans, revisions and extensions need the CIP Senior Manager's delegate |
| Draft a plan when the next outage misses the deadline | On | On · Off — from the matching template: MT-RTU-02 RTU, MT-NET-01 switch and firewall, MT-DCS-03 plant DCS, MT-WS-01 workstation |
| Require a second engineer on “not applicable” | Off | On · Off — peer review, as the regional entity recommends |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample utility data · “target” = the design goal, measured in the live solution · “estimated” = our estimate of how one cycle's hours split, from the sample utility's own baseline of about 40 engineer-hours · “typical” = published figures (FERC civil penalty inflation rule, Federal Register, 14 Jan 2025 — $1,584,648 per violation per day; SERC settlement NP18-25-000 — $220,000 for three evaluations at 37 days; Forescout, ICS cybersecurity in 2026 — 508 ICS advisories and 2,155 CVEs in 2025). Regulatory context: NERC CIP-007-6 R2 and its Violation Severity Levels. Lumina Utilities and every person, site, supplier, notice and asset named on this page are fictional — characters and sample data in the working solution.
Software that tracks every security patch for your control-system assets — RTUs, relays, switches, firewalls, DCS, EMS and historians — from the supplier's notice to an install or a dated mitigation plan. OT Patch Management adds six agents that watch the sources, match each notice to the inventory, draft the decision and any plan, and run the clocks. The OT engineer signs.
Every patch carries two clocks: 35 days from its source's last evaluation to evaluate it, then 35 days from the evaluation to install it or write a dated mitigation plan. The Clock keeper moves both at the morning sweep, reminds the owner and the compliance analyst at day 25, escalates at day 31 and logs each date as it happens.
The Inventory matcher lists the assets of the named models with their hardware revision and installed firmware. The Applicability assessor reads the notice's affected and not-affected sections and drafts a decision per asset, citing the sentence behind it. In the sample case, 11 HC-560 RTUs on 4.2.7 and 4.2.8 were affected and 3 on 4.3.0 were not.
The Outage fitter places each install in the next planned outage that beats the deadline. When none does, the Mitigation plan drafter fills the template for that asset type with controls from the supplier's workarounds, owners, dates and the evidence to collect, so the engineer can sign a dated plan the day the patch is evaluated.
Yes. Each morning the Inventory matcher compares every model in the inventory with the source list. In the sample case it found six GPS clocks added in a time-sync upgrade with no tracked source; adding the source starts its evaluation clock.
Yes. The agents draft and never sign, never install firmware, change a device or book an outage. Below 0.80 confidence a person decides. A named engineer signs every evaluation and plan, and only the CIP Senior Manager's delegate approves a plan over 60 days, a revision or an extension, before its date.
Yes. The rules covered are settings. In the sample utility, NERC CIP-007-6 R2 covers the 8 sites with High or Medium Impact BES Cyber Systems, and the Wrenfield water works runs on the same clocks under the company's water cyber policy.
The Agentic Solution Engine builds and deploys it from your requirements and documents — your patch management procedure, source list, asset inventory, outage plan and mitigation plan templates — and it goes live once every quality gate has passed. We will walk you through it on your own sources and a recent cycle first.
Audit binders built continuously, not in a 30-day scramble.
1-min demoThird-Party Cyber Risk ManagementEvery supplier answer checked against its evidence before you sign.
1-min demoICS Vulnerability ManagementWhich advisories affect our substations? Answered today.
1-min demoWe'll run OT Patch Management on your own source list, your asset inventory and a recent cycle of supplier notices.