Engineering cybersecurity into the smart grid

Digital substations, utility-scale solar, wind, battery storage, distributed energy resources and grid-connected data centres are changing how electrical infrastructure is designed and operated. The communications environment underneath them has changed with it. Protection relays, RTUs, plant controllers, inverters, BESS controllers, engineering workstations, SCADA platforms and historians now sit in one interconnected operational estate, increasingly reaching enterprise systems and third-party platforms as well.

That connectivity creates real operational and commercial value. It also multiplies the pathways through which a system can be reached, influenced or disrupted. For a power-system engineer this means cybersecurity can no longer sit downstream of the design as an assurance activity. It has to be part of the engineering.

The premise of secure-by-design is not complicated: only the communications, users, devices and services that are explicitly required should be able to interact with critical systems, and everything else should be constrained by the architecture rather than by anyone's vigilance. That principle is common to IEC 62443 and NIST SP 800-82, and the themes it produces are the same across substations, renewable plants, BESS facilities and grid connections: segmentation, controlled communication, secure configuration, restricted access, resilience, monitoring and lifecycle management.

The hard part was never understanding those principles individually. The hard part is applying them consistently across a real project, at engineering pace, with the evidence still intact at handover. Security cannot depend on every engineer remembering every control at every stage. It has to be embedded in the workflow that produces the design.

It starts with the architecture

Defence in depth is the oldest useful idea here: independent layers of control, arranged so that the failure or compromise of any one of them does not expose the operational environment. In practice that means grouping systems of similar function, criticality and trust into security zones, then engineering the communication permitted between them.

In a smart-grid estate those zones typically include enterprise IT, the industrial DMZ, SCADA, substation automation, protection and control, engineering workstations, plant control, inverter and turbine networks, BESS control, the grid-connection interface and remote-access infrastructure. The point is not segmentation for its own sake. The point is to remove trust that nothing in the design ever asked for.

A flat network at a substation, solar farm or battery site lets any compromised asset reach systems that have no operational reason to accept traffic from it. A segmented one makes those relationships explicit and bounds what a single compromise can become. That is the defining property of a secure power-system network: a foothold in one part of it should not automatically become a foothold in the grid-connected environment around it.

Zones are only as good as their conduits

Drawing zones is the easy half. The engineering is in what crosses between them. IEC 62443 groups the communication between two zones into conduits: a conduit exists because a defined operational requirement needs it, not because two devices happen to share a switch.

On a smart-grid project those requirements are concrete. SCADA polls an RTU. A protection relay reports to a station gateway. A plant controller issues setpoints to inverters. A BESS controller exchanges state of charge and availability with a power-conversion system. A renewable plant controller answers a dispatch instruction from a control centre. Each of those is a communication relationship that an engineer should be able to describe completely.

conduit          SCADA  ↔  Substation automation
source           SCADA front-end, control centre
destination      Station gateway, 110 kV substation
purpose          Telemetry and supervisory control
protocol         IEC 60870-5-104 / TCP 2404
initiator        SCADA front-end, outbound only
pattern          Continuous, polled
enforced at      Substation edge firewall, rule FW-04
target SL        SL-T 3
exception        none

Source, destination, justification, protocol, initiator, pattern, point of enforcement, target security level, and any exception taken against it. Once those are answerable for every path, cybersecurity stops being a posture and becomes something that can be reviewed, tested and handed on like any other engineering record.

Note the order of the questions. Default-deny is the starting posture, not the reward for finishing the analysis. The reason the analysis matters is that a deny-by-default network is only survivable in operation if the traffic the power system genuinely needs has been enumerated first. The useful question is never “what should we block?” It is “what does this plant actually need in order to run safely and correctly?” Everything outside that answer is already denied.

The digital point of connection

Grid connections are the sharpest example, because they are where organisations meet. A solar farm, wind farm, BESS installation or large data centre connects to a transmission or distribution network through a defined point of connection, and the electrical design of that interface is specified to the last decimal: voltage, fault contribution, metering, protection, reactive capability, control requirements.

The digital interface deserves the same discipline. Which systems cross the boundary, who owns each asset, which side administers the firewall, which protocols are permitted, which end may initiate, what data is exchanged, which remote-access routes exist, and how changes to any of it are governed. These are not peripheral security questions. They are interface questions, and they belong in the connection agreement beside the protection settings.

The same logic applies inside the organisation, at the IT/OT boundary. Operational data is genuinely wanted outside the control environment: a plant sends production data to analytics, a BESS operator needs state of charge and availability for commercial optimisation, an asset-management team wants condition monitoring from transformers and inverters, a data centre exchanges demand-response signals with a utility. None of those needs justify direct connectivity. An industrial DMZ exists precisely so the exchange can happen through brokered services in an intermediate zone, leaving no path on which an enterprise system talks straight to a controller.

Data centres make the point vividly, because enterprise IT, facility OT and grid-facing electrical infrastructure can all live inside one fence under one owner. Common ownership is not a trust relationship. A UPS, BESS, microgrid controller and utility metering interface do not become safe to reach from the corporate network because the same company runs both. The boundary still has to be explicit, controlled and observable, and that applies with equal force to internet exposure: controllers, relays, RTUs and inverters should not be reachable from outside without a justified requirement and an architecture built to carry it.

Remote access, engineered

Remote engineering and maintenance are now routine. Utilities need access to unmanned substations, solar operators diagnose inverter faults from a desk, turbine OEMs hold maintenance obligations they cannot meet on site, BESS integrators support battery management and power-conversion systems remotely. These are legitimate requirements, and they fail when access is treated as trusted by virtue of being authenticated.

A VPN provides encrypted connectivity. Encryption is not authorisation. The design still has to say who may connect, which systems they may reach once connected, what they may do there, how long the access stays live, how the session is recorded and how the permission is removed. That implies strong and multi-factor authentication, least privilege, a controlled path through a jump host, session logging, time-bounded vendor access and an explicit revocation step tied to project handover.

The architectural rule underneath all of it is simple. Remote access terminates at a controlled boundary. It does not become a convenient tunnel into the protection, control or inverter networks, and the moment it does, every zone downstream of it has quietly been redrawn.

Secure architecture needs secure devices

A well-drawn architecture can still be undone by what sits inside the zones. Relays, RTUs, PLCs, station gateways, switches, firewalls, revenue and power-quality meters, inverters, battery management systems, plant controllers, turbine controllers, industrial servers and engineering workstations all ship with security features that have to be deliberately turned on and configured.

The weaknesses that show up in practice are rarely exotic:

• Credentials: default passwords still in place, administrator accounts shared across a commissioning team, temporary vendor accounts still live long after handover.
• Management planes: insecure protocols left enabled, management interfaces reachable from far more of the network than they need to be.
• Configuration: backups held in plaintext, no record of which revision is actually running on the device in the field.
• Visibility: logging incomplete or pointed nowhere, so the device cannot tell anyone when its own controls change.
• Firmware: versions frozen at whatever shipped, with no owner for the decision to update or the risk of not updating.

None of that is usually the result of poor intent. It is the residue of schedule pressure, commissioning convenience and legacy practice, which is exactly why it recurs on project after project. A requirement that lives only in a specification will lose to a commissioning window every time. A requirement attached to the device in the model, and checked when the design changes, will not.

The problem is not one inverter

Inverter-based resources change the shape of the risk, and this is the part that is most often understated. The security question at a solar or battery site is not really how many devices are on it. It is how far a single control path reaches.

A compromised inverter is a contained event. A compromised plant controller with authority over every inverter on the site is a different class of event entirely, and a compromised aggregation platform with dispatch authority over a portfolio of sites is different again. The countable population that matters for security is the one with an address and an instruction path: inverters, trackers, string monitors, the plant controller, and whatever sits above it. Panels and cells do not take commands.

Battery sites raise the same question with more layers. A BESS facility combines battery management, power conversion, fire detection, HVAC, protection, metering, SCADA and remote vendor support, and it is easy to end up with all of them on one network because they arrived in one container. They do not require the same connectivity, and they certainly do not require the same trust. As DER becomes more numerous, more remotely managed and more dependent on third-party platforms, the aggregate control path matters more than any individual device on the end of it.

Security a protection engineer will sign

Industrial cybersecurity has a constraint that most enterprise security does not: the control cannot be evaluated independently of the process it sits in. Availability, determinism and safety are not competing priorities to be traded against security. They are the reason the system exists.

The timing budgets make this concrete. The fastest IEC 61850 trip messages are specified in low single-digit milliseconds, and sampled-value streams publish thousands of frames a second on the process bus. A control that would be unremarkable on an enterprise network, deep packet inspection in the path, a stateful firewall between a relay and its peer, is simply the wrong instrument there. That is an architectural conclusion, not a compromise: protection traffic stays inside its zone, and the security boundary goes where the timing budget can carry it.

The same reasoning applies more broadly. A poorly planned update window can interrupt SCADA visibility. An undersized security appliance can add latency to a control loop. An access process with no break-glass path can block the engineer who is needed during a restoration. Secure design is not the maximisation of restriction. The best architecture is not the one with the most controls; it is the one where the required controls are correctly placed, justified, operationally compatible and demonstrably effective.

Every design starts drifting

Commissioning is not the end of the security design, and most estates are not greenfield anyway. Relays get replaced. Inverter firmware is updated. BESS operating strategies change. Firewall rules are modified under pressure. Plant controllers are added, SCADA points are appended, vendor access is enabled for a fortnight, another battery block or inverter station is energised, grid-code obligations change. Every one of those can invalidate an assumption the original design rested on.

This is why monitoring belongs in the architecture rather than in operations' backlog. Failed and successful administrative logins, firewall rule violations, remote-access sessions, device configuration changes, unexpected communications, security-control failures and loss of connectivity to critical assets are all design inputs, because each one answers a question the design has to ask of itself.

The question is uncomfortable and short: for every significant control, how will the organisation know if it stops working? A firewall rule may be right today, but who sees it when it is widened in six months? A vendor account may be justified during commissioning, but what closes it at handover? A relay may be securely configured today, but what tells the team when a firmware update quietly resets its management configuration? Those are lifecycle questions, and they are the ones that separate a design that was secure from an estate that still is.

From requirements to evidence

The principles above are well understood. Applying them consistently at project scale is the part that fails. A grid-connection project can carry dozens of zones, thousands of addressable devices, several industrial protocols, multiple vendors, remote-access paths and a long tail of project-specific exceptions. At that scale the design stops fitting in disconnected drawings, spreadsheets and narrative documents, and the rigour leaks out between them.

Structured authoring is what closes that gap. When the security requirements live alongside the network design as engineering data rather than as prose about it, the design becomes something you can interrogate. Which zones communicate? Which conduits cross a boundary? Can an enterprise system reach protection or control? Are the inverter networks isolated in the way the drawing implies? Can vendor access reach outside its scope? Is a firewall rule broader than the requirement that justified it? Is a critical asset reachable by a path nobody drew? Which required controls are missing, and which exceptions were accepted and by whom?

Those are the questions that decide whether a design is documented or actually engineered. And answering them repeatably is what makes the last step possible, which is the one that matters at handover: a secure design should not merely assert that the system is secure, it should show how that conclusion was reached.

That chain is worth more on a power-system project than on almost any other, because the design is never reviewed by a single discipline. Protection, control, cybersecurity, the utility, the OEM, the integrator, the grid-connection team, the asset owner and the operations team all have to understand and challenge the same architecture. A structured model gives them one basis to argue from, and it improves the final documentation as a by-product, because the rationale is captured while the decision is being made rather than reconstructed months later for an audit.

This is the principle Synapse Studio is built around, and the reason we started at design time rather than at runtime, a choice we set out in what design-time cyber engineering means. The intention is not to replace cybersecurity expertise, power-system engineering or operational judgement. It is to make the judgement easier to apply consistently and far easier to prove.

Across substations, grid connections, solar, wind, BESS and distributed energy resources, the underlying point does not change. Cybersecurity should not be applied to the network after the fact. It should be engineered into the power system.