Operating reality
The estate is the problem, not any single site.
A single substation is a tractable cybersecurity problem. Two hundred of them, built across four decades, commissioned by different integrators and connected over a mixture of owned fiber, leased circuits and cellular backhaul, is a different discipline entirely.
Utility programs fail on consistency rather than on capability. A control designed once and deployed differently at every site produces an estate nobody can evidence. The same is true of remote access: a route that was appropriate for one integrator becomes an unmanaged standing path once it has been replicated fifty times.
Compliance adds a second dimension. A registered entity can clear audit and still be unable to say what an attacker reaching the substation network could do to the operation — because the obligation was written as a floor, not as a program.
So the work is as much about repeatable standards and governance as it is about technology — a substation design pattern a field crew can execute, an auditor can verify, and whoever holds the contract in five years can maintain.
Two hundred substations are not a harder version of one substation. They are a different problem, and consistency is almost all of it.
Operational priorities
Four things utility programs have to get right.
These are the priorities we see decide whether a utility program delivers or stalls — ahead of any question about tooling.
01 · Availability is the constraint
Nothing may be recommended that assumes an unplanned outage is acceptable. Cyber work competes with primary plant maintenance for the same scarce windows, so sequencing against the outage plan is part of the design, not a scheduling afterthought.
02 · One executable design pattern
Controls have to be specified so a field crew can apply them identically at every site. Per-site bespoke engineering does not scale across an estate and cannot be evidenced consistently at audit.
03 · Remote access under control
Vendor, integrator and maintenance access is structural in this sector and cannot be removed. It has to be routed, brokered, privileged-managed and revoked on a defined lifecycle — consistently the highest-consequence exposure we find in dispersed estates.
04 · Evidence that survives audit
Every control produces an artifact or it will be re-litigated at the next audit cycle. NERC CIP obligations are treated as a floor to clear cleanly and evidence repeatedly — not as the definition of an adequate program.
In scope
Five environments we work in.
Protection and control is assessed on paper and by configuration. Relays are never interrogated live, and safety-related functions are not a cybersecurity testbed.
Control center
EMS, SCADA and ADMS with their operator consoles, the outage management and work management interfaces, historians, and the ICCP links to neighboring control areas. What we most often find is a boundary to corporate IT carrying considerably more than reporting traffic, and engineering credentials shared across the front end because that is how the system was commissioned.
We work from configuration, existing firewall rule sets and traffic collected with OT-native tools built for control-center networks, and we reason about consequence in terms of dispatch and switching rather than asset counts. Every connection and every action follows your control-center change process.
Substation automation
Station gateways, RTUs, station HMI, the substation LAN, time synchronization, and the serial and Ethernet paths back to the control center. Protection and control relays live in this environment and are reviewed through settings files, drawings and configuration exports only. They are never interrogated live and never used to demonstrate a finding.
The recurring problem is drift — one design applied forty different ways by different integrators across twenty years. The work is to establish a single executable pattern, evidenced from configuration, that a field crew can apply identically and an auditor can verify without a site visit.
Field and telecom
Owned fiber, leased circuits, cellular and licensed radio backhaul, distribution automation devices, reclosers and capacitor bank controllers, and the routing that carries all of it back to the control center.
This is where reachability is most often misunderstood. A circuit believed to be private transits a shared carrier network, or a distribution automation device holds a management path nobody has reviewed since commissioning. We prove reachability from routing tables, circuit records and firewall configuration rather than by probing live equipment, and findings are written so they can be raised with the carrier under the agreement you already hold.
Engineering and vendor access
Engineering workstations, relay settings and configuration management, project archives, jump hosts, and every remote path held by your own staff, by integrators and by OEMs.
In a dispersed estate this is consistently the highest-consequence exposure we find, because a route that was reasonable for one integrator at one site was later replicated across fifty and never revoked. We inventory each path against the agreement that created it, then design brokered, privileged-managed access with a defined review and revocation point. Existing vendor agreements are respected rather than worked around, so tightening usually lands at renewal or retender.
Grid edge
Distributed generation, storage, electric vehicle infrastructure, advanced metering, and the aggregator or DERMS interfaces through which assets the utility influences but does not own can affect the network.
The difficulty here is rarely a device. It is that the interface was agreed commercially before it was designed technically, so nobody has stated what an aggregator may command, under what authentication, and how the network behaves if those signals are wrong. We treat it as an interface and governance question first — decision rights, protocol, authentication and fallback behavior — and as a control problem second.
Related solutions
Where utility engagements usually start.
Each stands alone. Most utilities begin at one of the first two, and prove the method on a single representative site before committing across the estate.
Questions from this sector
What utility teams ask us before anything is signed.
We cleared our last CIP audit. What does an assessment add?
Clearing an audit proves that the controls in scope were implemented and evidenced. It does not answer what an attacker reaching a substation network could actually do to switching, restoration or the control center, because that question is not what the standard was written to ask.
So the work runs alongside your compliance position rather than duplicating it. CIP obligations are treated as a floor to clear cleanly and evidence repeatedly. The assessment adds consequence — which paths reach which functions, and what the operational outcome would be — and the remediation sequence that follows from it.
Most of our estate is low impact. Are you going to tell us to treat it as medium?
No. Impact rating is a regulatory classification and we do not reopen it. What we do examine is whether low-impact sites share routes, credentials, jump hosts or management paths with higher-impact ones, because that is where the classification and the actual exposure diverge.
Where they are genuinely isolated, the recommendation is usually a small set of consistent, cheap controls applied identically everywhere. Where they are not, the finding is about the shared path, not about reclassifying a hundred substations.
We cannot take a substation out of service for this.
You will not need to for the assessment. Collection uses OT-native tools built for live substation and control-center networks, and analysis is built from configuration exports, drawings, firewall rule sets, routing records and settings files, gathered without taking anything out of service.
Implementation is different and we are direct about it. Physical change needs a window, so remediation is written as costed, durationed jobs that can be sequenced into your existing outage and switching plans rather than requesting new ones.
Our protection engineers will not let anyone near the relays.
They are right, and the boundary is ours as well as theirs. Protection and control is reviewed through settings files, drawings and configuration exports. No relay is interrogated live, no protection function is exercised, and nothing in the scope requires a test that could affect a trip decision.
What we can say from configuration is who can reach a relay, over which path, with which credential, and whether the engineering access around it is controlled. That is usually the finding that matters, and it does not require touching the device.
We have a large site portfolio. How is this affordable?
It is not affordable site by site, and we do not propose it that way. The estate is sampled by design vintage and site type — a representative example of each pattern rather than every instance — because sites built to the same design carry the same exposures.
The output is a design pattern per vintage and a rollout your field crews execute. If the sampling is wrong, the pattern is wrong, so we agree the sample with your engineering team before scope is fixed rather than presenting it afterwards.
Next step
Prove the method on one substation first.
A single representative site establishes effort, disruption and value before anything is committed across the estate — and produces the design pattern the rest of the program reuses.
- OT-native data collection — solutions built for production networks, alongside configuration review
- Outage windows respected — scheduling agreed before scope is fixed
- Protection and control out of scope — relays are reviewed, never interrogated live
- Designs your field crews can execute — one pattern, not per-site engineering
- Vendor-independent — specifications written to be tendered competitively
Questions from this sector
What operators in this industry ask first.
What are the main OT cybersecurity risks for electric utilities?
Exposure concentrates where control reaches the field: substation automation and protection, the SCADA network and its wide-area links, distribution automation and the growing population of connected distributed energy resources, and the vendor and engineering access paths into all of them. The consequence is not data loss; it is load, protection behaviour and restoration time.
How does InnovAKT help utilities with NERC CIP or equivalent obligations?
By building the operational capability first and evidencing it second. Compliance artifacts that describe controls nobody operates fail on the next audit and protect nothing in between. InnovAKT designs the control, makes it real in the substation and the control centre, and then produces the evidence the standard requires.
Can substation work be done without taking circuits out of service?
Most of it, yes. OT-native discovery, configuration review, access governance, remote access redesign and monitoring deployment can generally be done without interrupting supply. Work that touches protection or control behaviour is planned into existing outage schedules with the protection engineers, not around them.