Generating Risk: When Cyber Issues Reach Plant Operations

­A power plant is a study in boundaries. Efficient and safe operation depends on knowing where equipment limits are, seeing when conditions begin to move, and having confidence that the right system will act at the right time. That has always been an engineering problem, but it is now also a cybersecurity problem.

The systems that help operators see, control and recover a plant are more connected than they used to be. Historians feed enterprise platforms, maintenance tools exchange files across business and plant environments, and OEMs support turbines, inverters, protection relays and battery systems from outside the site. Assets are spread far and wide, and often operate unattended outside of a digital link.

None of this is inherently dangerous. On the contrary, remote expertise is invaluable, and better data is essential to reducing avoidable downtime. But risk can creep in when those connections become trusted parts of plant operation. If visibility, control, configuration or communications are degraded, can the site still operate safely? If there is any uncertainty in the answer, that means cyber risk has moved beyond the screen and into the operating envelope.

Compliance does not define the whole plant

For North American generators, NERC CIP provides essential structure. It gives owners and operators a common framework covering electronic access, personnel risk, configuration change, recovery planning and supply-chain controls across Bulk Electric System environments.

That structure gives teams a defensible baseline and a shared language. Yet plant risk does not always stop neatly at the compliance boundary. A system may fall outside a formal BES Cyber System category and still influence the way a plant is restored, monitored or understood during an event.

An engineering workstation is an obvious example. It may not run the process, yet it can be used to change the logic that does. A historian may not control a breaker or valve, yet its reporting shapes the operator’s view of what just happened. A backup server is disconnected from the control process, yet it becomes critical when the site needs to rebuild trusted systems after compromise.

A consequence-led view helps. Instead of starting only with the regulatory category of a device, begin a design review with the function the plant needs to preserve. This is an exercise that often crosses organisational lines. The plant, however, does not operate with respect to those divisions. It experiences all of them as one connected operating environment. While a plant may be a study in boundaries, it is run through its functions.

Functions first, assets second

A useful cyber assessment follows function. It asks what would happen if a signal was lost, a display was reading wrong, a setpoint was altered, or trust in equipment was otherwise lost. Those questions bring cybersecurity closer to the plant reality: the concern is not just whether a device exists, but what its failure or misuse could do to operation.

This approach also changes the tone of risk discussions. The conversation becomes less about ownership of a server or checkbox status, and more about whether the site can keep equipment inside design assumptions when digital confidence is under pressure.

Functional safety depends on trust. A trip system is expected to respond when demanded. A control display is expected to reflect field conditions. A configuration baseline is expected to describe the equipment in front of the operator.

Cyber events can erode those assumptions quietly. Perhaps a temporary firewall exception remains in place after an outage, or a shared account hides who made a change. A patch exception might stay in place, leaving software vulnerable, or a firmware update could change device behaviour before policies and training have caught up with it.

This is where IEC 62443 and functional safety thinking should meet. IEC 62443 gives engineering and cybersecurity teams a practical way to discuss zones, conduits, lifecycle controls and responsibilities. Functional safety analysis brings the consequence view. Used together, they help teams decide which digital pathways deserve engineering control because of what they can affect in the plant.

Click image to enlarge

Remote access needs engineering discipline

Remote access is often treated as an IT service, but power generators should consider it a control path. The design issue is one of rights and privileges: whether each connection is specific to the task, approved by the owner, visible during use and removed when no longer needed.

Standing access creates problems because it survives long after the original reason has disappeared. Broad VPN routes do the same, as do vendor-controlled gateways, shared credentials and unmanaged remote desktop tools. They are often introduced to solve a practical support problem and then remain as permanent trust relationships.

A better pattern puts the generator back in control of the route. Interactive access should pass through an owner-managed jump host or secure gateway. Strong authentication, approval, session logging and role-based limits should be built into the process. The person connecting should reach only the systems needed for the job, for the period in which the job is being performed.

Machine-to-machine traffic also requires discipline. It should be separated from human remote access, authenticated where possible and restricted to known communications. Where legacy accounts or vendor requirements make perfect control unrealistic, the compensating measure should be visibility. The plant owner needs to know when the path is used and what changed as a result.

Renewables alter the trust model

Wind, solar and battery storage can change the shape of cyber risk. Many sites are lightly staffed, geographically dispersed, and their operation can depend heavily on links which are not often well-policed.

A cyber issue here may not announce itself as a classic security incident. It may appear as unexplained trips, inconsistent telemetry, failed updates, unexpected setpoint behaviour or loss of remote visibility – the kind of tiny glitch that is easy to hand-wave away.

The shared-platform problem is also different. One portal, support process or firmware pipeline may touch many sites. Efficient, but a structure which means a weak access model can become a fleet issue. Procurement and design should account for this from the start.

Click image to enlarge

Figure 2: Renewable and storage portfolios often depend on shared support platforms, remote diagnostics and firmware processes, making access control and update integrity fleet-level concerns

Operating with reduced confidence

Cybersecurity work often concentrates on keeping an attacker out. Power generation is not different, but it also has to plan for the point where the plant is still running, but confidence in the digital picture has been damaged.

That is an uncomfortable state for operators. At a moment of lost confidence, the site needs to fall back on pre-agreed operating choices. Procedures should define when to continue, hold, isolate, transfer to local control, reduce output or shut down. Operators should know which signals are authoritative in a degraded state and which manual checks remain available. Someone must also have clear authority to declare a cyber-related loss of confidence.

Exercises should reflect this uncertainty. Many plants rehearse equipment failure, weather disruption and trip events. Fewer rehearse working in a confusing digital environment in which systems appear to be functioning, but the basis for trusting them is unclear. That is exactly the scenario where operations, engineering, safety, cybersecurity and compliance need one playbook.

Click image to enlarge

Figure 3: A degraded-confidence model gives operators pre-agreed choices when systems appear to be running but the basis for trusting them has been weakened

Evidence from the real plant

The best evidence is drawn from the working environment. Network diagrams should be checked against observed traffic, and firewall rules should be reviewed with engineers who understand why a communication exists. Asset inventories should be reconciled with discovery, maintenance records and field walkdowns.

Configuration baselines should record the details people need during trouble: software version, firmware version, services, ports, accounts, approved exceptions and accountable owners. Without that level of detail, recovery becomes slower and less certain.

Change management needs the same practical grounding. Emergency changes may be unavoidable during outages, commissioning or restoration, but they should still leave a trace. The record should show what changed, why it changed, who approved it and whether the change was later reversed or accepted into the baseline. Treating change as an operational event brings cybersecurity into the same design culture that already governs plant safety and reliability.

Keeping the plant inside its assumptions

Power generation will continue to rely on remote expertise, digital maintenance and software-driven control. The answer is not to pretend those connections can disappear, but to design them with the same seriousness given to other systems that influence safe operation.

Regulation gives the floor, and engineering consequence should guide the design. NERC CIP, IEC 62443, functional safety practice and cyber-informed engineering all help in different ways, but the plant-level task is clear enough: know which functions must be preserved, understand the digital paths that can affect them, limit unnecessary trust and prove that recovery can return the site to a known state.

A generator stays safe because people can trust what they see, govern what can change and recover when something goes wrong. Cybersecurity now belongs in that chain. Once digital systems support the limits of the plant, protecting those systems becomes part of keeping the plant inside them.

Arista Cyber