This is a small experiment.
Alongside the longer Software in the Grid deep dives, I want to regularly look at what is changing around the software that runs modern power infrastructure.
Not everything happening in energy belongs here. The filter is narrower:
Does this development tell us something interesting about how software inside the power system is built, connected, secured or operated?
This week, one theme kept appearing: systems that look like ordinary software suddenly become much more interesting when the other side of the interface is physical infrastructure.
Main signal: engineering tools are part of the substation attack surface
PCM600 is ABB’s engineering software for protection and control devices used in electrical substations. Many of those devices are IEDs — intelligent electronic devices — small computers such as protection relays that monitor electrical conditions and perform protection or control functions.
An engineer can run PCM600 on a Windows workstation, connect to supported devices over the network, work with their settings and configuration, and exchange engineering data with them.
So PCM600 may look like ordinary desktop software, but its context is very different.
The machine running it can sit close to devices that participate directly in protecting and operating the electrical system.
That is what makes two security advisories published by ABB on 28 September interesting.
The first vulnerability, CVE-2026-15952, is about privileges on the Windows workstation running PCM600.
One of PCM600’s background services can run with elevated permissions. At the same time, a local PCM600 user may be able to change how that service is configured.
In practice, that creates a dangerous combination: an authenticated local user who belongs to the PCM600 user group may be able to modify a Windows service running with SYSTEM privileges. If exploited successfully, that could allow commands to run with elevated privileges on the workstation.
The second issue, CVE-2026-15953, is easier to picture.
PCM600 can import project archives. A specially crafted archive could contain file paths that point outside the directory where the project is supposed to be extracted.
Instead of writing files only into the project folder, the archive could potentially overwrite files somewhere else on the workstation, using the permissions of the engineer importing it.
Both issues are described in ABB’s security notifications.
The individual CVEs matter, but I find the larger architectural point more interesting.
When we think about substation cybersecurity, it is natural to focus on the equipment that is visibly part of the operational network:
protection relays, gateways, station computers, SCADA servers, switches and remote connections.
But the engineering environment is part of the system too.
An engineering workstation may hold project files, device credentials and configuration information. It may communicate directly with IEDs and may be trusted to make changes that an ordinary office computer cannot.
That makes the workstation a meaningful trust boundary.
This does not mean that a vulnerability in PCM600 automatically gives an attacker control of an IED or a substation. That would be an unjustified jump.
But it does mean that protecting the operational network while treating engineering workstations as ordinary desktop systems is an incomplete security model.
The interesting question for me is therefore not only:
How serious are these two vulnerabilities?
It is also:
What should the security architecture around a modern substation engineering workstation actually look like?
Isolation, imported project files, provenance, privileges, update mechanisms, credentials, engineering access and communication with field devices all meet at that point.
That feels more interesting than another CVE headline.
Around the grid
EV charging software meets a very physical security boundary
Another vulnerability this week came from a very different part of the energy system: EV charging.
Monta provides software for managing charging stations. A charging station can connect to Monta’s backend using OCPP — the Open Charge Point Protocol — over a WebSocket connection.
That connection is important. It is how the charger and the backend exchange information and commands: the charger can report its state and meter values, while the backend can send commands such as starting or stopping a charging session.
A simplified view looks like this:
charging station → OCPP over WebSocket → Monta backend → operator / application
Now the vulnerability becomes easier to understand.
CVE-2026-95102 concerns insufficient authentication on WebSocket endpoints. According to the vulnerability report, an attacker could use this weakness to impersonate a charging station.
In other words, the backend may receive a connection that claims to be a real charger without having sufficiently verified that identity.
This looks like a very familiar software problem: authentication at the boundary between a client and a backend.
But the “client” here is not a browser or another SaaS service.
It is a physical charging station.
That changes the consequences.
The same connection can represent a device that reports measurements, receives commands and controls the delivery of electrical energy to a vehicle. A weakness in authentication therefore crosses the boundary between ordinary backend security and a physical system.
This is the part I find interesting.
WebSockets, authentication, backend services and APIs are normal software-engineering territory. But increasingly, the system on the other side of those interfaces is something physical.
And that raises a broader question:
Which assumptions from conventional software stop being safe once the software is connected to the physical world?
Europe wants more grid-data exchange — but the architecture matters
On 28 September, ENTSO-E published its position on the European Commission’s Future-proof Electricity Bills proposal.
Among other things, the proposal touches accelerated grid connections, smart-meter deployment and enhanced grid-data exchange.
One recommendation caught my attention. ENTSO-E argues that an EU grid-data exchange framework should remain voluntary, secure, focused and supported by adequate financing.
This is policy language.
But behind it sits a very concrete software problem.
“Exchange more grid data” eventually turns into questions such as:
Which systems expose the data?
Which information models describe it?
Which organizations are allowed to consume it?
How is identity established?
How is authorization managed across organizational boundaries?
Which interfaces and protocols are used?
What are the latency and availability requirements?
Who owns compatibility when the model changes?
How do you secure all of this without making interoperability impossible?
These are distributed-systems questions as much as energy-policy questions.
The proposal may be written in Brussels, but somebody eventually has to implement the interfaces.
Worth watching: IEC 61850 meets WebSockets and JSON
This one is not strictly from this week, but it is too relevant to Software in the Grid to ignore.
On 4 September, IEC published Committee Draft 57/2980/CD for IEC 61850-8-3, with comments from the IEC national committees due by 30 October. Karlheinz Schwarz documented the Committee Draft publication, while the BSI project description gives a useful public summary of what is being proposed.
To understand why it is interesting, it helps to separate two things inside IEC 61850.
IEC 61850 defines a rich information model for the power system and a set of abstract communication services called ACSI — things like reading data, receiving reports or operating controllable objects.
Those services describe what applications want to do.
They do not by themselves define exactly how the messages should travel over the network.
That is the job of a communication mapping.
The familiar IEC 61850 client/server stack uses IEC 61850-8-1, which maps ACSI services onto MMS — Manufacturing Message Specification — and then transports them over the usual network stack.
IEC 61850-8-3 proposes another mapping.
The important part is that the IEC 61850 information model and ACSI services stay in place. What changes is the way those services are represented and transported.
Instead of mapping them through MMS, the new approach defines messages more directly. They can be encoded using ASN.1 JSON Encoding Rules for a human-readable, JSON-like representation, or using binary Distinguished Encoding Rules where a more compact representation is useful. The messages are then carried over WebSockets.
A simplified view looks like this:
IEC 61850 information model → ACSI services → direct message representation → JSON-like JER or binary DER → WebSocket
That makes the proposal much easier to place.
It is not “IEC 61850 is replacing MMS with JSON”.
It is another communication option alongside the existing mappings.
And the intended use case is especially interesting.
The draft targets communication between DSO control centres and potentially large populations of modern devices associated with distributed energy resources — solar installations, batteries, controllable loads and other DER systems.
That is a very different environment from a small number of protection devices inside one substation.
You may have thousands of geographically distributed devices, software-heavy controllers and systems that already live much closer to conventional IP and web technologies.
In that context, WebSockets and a JSON-like representation start to make much more sense.
What I like about this development is the broader engineering idea behind it.
IEC 61850 is a mature system with years of domain knowledge embedded in its information models and services. Instead of throwing that away and designing another completely new protocol, the standard can keep those mature abstractions while adapting the communication layer to newer software requirements.
I find that a much more interesting story than “IEC 61850 now supports JSON”.
It is a good example of how mature infrastructure can evolve: preserve the domain model that already works, but modernize the parts that need to interact with a changing software world.
And it raises several questions I want to investigate properly:
How does this compare with the traditional MMS mapping?
Why was WebSocket chosen?
What does the security architecture look like?
Where exactly does this communication sit between DER systems and DSO control centres?
And what becomes easier — or harder — for software engineers when IEC 61850 services can be represented this way?
This deserves a proper technical deep dive.
The thread I see this week
These stories look unrelated:
a Windows service inside an IED engineering tool,
WebSocket authentication for EV chargers,
European grid-data exchange,
and a new IEC 61850 mapping using WebSockets and modern encoding mechanisms.
But there is a common pattern.
Power infrastructure is accumulating more of the problems software engineers already recognize:
authentication, trust boundaries, distributed communication, interoperability and compatibility.
The difference is what sits on the other side of the software.
Not another SaaS application.
Protection systems. Charging infrastructure. Control centres. Distributed energy resources. Physical power flows.
That boundary between software systems and physical infrastructure is exactly what I want to keep exploring with Software in the Grid.
See you next week.
— Dmytro
Software in the Grid explores how software actually works inside modern power infrastructure — from protocols and networking to SCADA, cybersecurity, distributed systems and software architecture.
Software in the Grid is an independent publication. The views expressed here are my own.