A Protection Relay Is Not Another Endpoint

Why field-level vulnerabilities require an operations-led approach to cyber risk

A new cybersecurity advisory lands in the inbox. The vulnerability receives a critical severity rating. The remediation guidance recommends updating the affected product.

In a traditional IT environment, the next steps may be reasonably clear: confirm the affected systems, test the update, schedule deployment, and track completion.

Now consider that the affected product is a protection relay controlling part of an electrical network.

The decision is no longer simply about patching software. The relay may protect a transformer, feeder, generator, or other critical equipment. Updating it could require engineering review, configuration validation, an operating window, protection testing, and a reliable rollback plan. An unsuccessful change could affect the availability or integrity of the physical process the organization is trying to protect.

This is the distinction leaders must understand: a protection relay is not another endpoint.

Recent cybersecurity advisories involving protection relays, remote terminal units, programmable logic controllers, and industrial software reinforce an important reality. Cyber risk is increasingly intertwined with physical processes, yet many organizations still manage it through workflows designed for corporate IT.

The answer is not to slow down remediation or accept unnecessary exposure. It is to make better decisions by bringing operational context into vulnerability management.

Severity is important, but it is not the entire risk

Cybersecurity teams often begin with a vulnerability’s technical severity. That is useful, but it cannot determine OT priorities on its own.

A critical vulnerability affecting an isolated device with no realistic attack path may be less urgent than a moderate vulnerability affecting an engineering interface connected through poorly governed remote access.

The real priority depends on several questions:

• Is the affected product actually deployed?
• What operational function does it perform?
• Can it be reached from an untrusted or less-trusted network?
• What privileges would an attacker require?
• Could exploitation affect safety, reliability, product quality, or environmental compliance?
• What compensating controls already exist?
• What operational risk would the remediation introduce?

These questions cannot be answered by a scanner alone. They require cybersecurity, controls engineering, operations, maintenance, and, sometimes, the equipment manufacturer to share the same understanding of the system.

That shared understanding is where many OT vulnerability-management programs struggle.

The remediation itself can carry operational risk

A field-level device may remain in service for 15 or 20 years. Its firmware may be tied to a particular engineering tool, communication module, configuration file, or supporting application. A newer version may address a vulnerability while introducing compatibility questions elsewhere in the system.

This does not mean the device should remain vulnerable. It means remediation needs to be engineered.

Before modifying a protection relay, for example, the organization may need to:

• Back up and verify its configuration.
• Confirm firmware and hardware compatibility.
• Review protection settings and coordination requirements.
• Determine whether the device can be safely isolated.
• Schedule an approved operating or maintenance window.
• Test the change under controlled conditions.
• Prepare a documented rollback procedure.
• Confirm that the device returns to its required operating state.

These are not excuses for delaying action. They are necessary controls for changing technology that performs a physical function.

Applying an IT patching mandate without this context can create an unintended conflict. The cybersecurity team is measured by remediation speed, while operations is measured by safe and reliable production. A mature OT program does not force one objective to defeat the other. It creates a risk-based process that serves both.

Start with the attack path, not the vulnerability count

Many organizations measure progress by the number of vulnerabilities they identify and close. That may be useful for internal tracking, but it does not necessarily show whether operational risk is decreasing.

An organization could close hundreds of low-impact findings while leaving one exposed engineering workstation, uncontrolled vendor connection, or poorly segmented control network unresolved.

The more meaningful question is: which credible paths could allow an attacker to reach or influence the physical process?

That shifts the program toward a more operationally relevant sequence:

First, determine what assets are present and which functions they perform. Then identify how those assets communicate, who can access them, and which pathways cross trust boundaries. Evaluate the vulnerabilities within that architecture and prioritize the combinations that create credible operational consequences.

This approach frequently brings attention back to the fundamentals:

• Eliminate unnecessary internet exposure.
• Remove default and shared credentials.
• Govern third-party and vendor access.
• Segment critical control functions.
• Restrict engineering access.
• Maintain tested configuration and system backups.
• Monitor the pathways that matter.
• Prepare an OT-specific incident response plan.

A high severity score may accelerate the discussion, but architecture and operational consequences should determine the response.

Temporary controls must be real controls

Some vulnerabilities cannot be remediated immediately. The device may require an outage, the vendor may not yet have issued an update, or the affected product may be approaching the end of its supported lifecycle.

In these situations, “we will patch it later” is not, by itself, an acceptable risk treatment.

The organization should establish specific compensating controls. These may include isolating the affected asset, restricting communication to required protocols and hosts, disabling unused services, strengthening remote-access controls, increasing monitoring, validating backups, or accelerating replacement planning.

The control should have an owner, a verification method, and an expiration or review date. Otherwise, a temporary exception can quietly become a permanent part of the architecture.

Executives also need visibility into these decisions. They do not need a list of every CVE, but they should understand where material risk remains, what is being done to reduce it, and what operational or financial decision is required.

Vulnerability management is an enterprise OT capability

Field-level vulnerability management should not operate in isolation as a security activity. It connects directly to asset inventory, network architecture, remote access, engineering change management, vendor governance, backup and recovery, incident response, business continuity, and capital planning.

This is why organizations need an enterprise OT cybersecurity program rather than a collection of disconnected technical projects.

The program should define accountability across IT and OT. Cybersecurity can provide threat intelligence, exposure analysis, and security guidance. Engineering can determine process function and technical feasibility. Operations can define safe implementation windows and operating constraints. Business leadership can accept, fund, or escalate material risks.

No single function can manage field-level cyber risk on its own.

This becomes even more important as industrial environments adopt software-defined control, remote operations, cloud-connected services, and Industrial AI. Innovation expands what industrial organizations can accomplish, but it also expands the governance boundary. Technology moving from a laboratory or pilot environment into production must receive the same operational and cybersecurity scrutiny as traditional control-system components.

Measure resilience, not activity

The objective of OT vulnerability management is not to produce the largest possible remediation count. It is to reduce the probability that a cyber event can disrupt safe and reliable operations.

Leaders should therefore measure outcomes such as:

• Reduction in exposed or uncontrolled access paths.
• Coverage and accuracy of the critical-asset inventory.
• Time required to assess material advisories.
• Percentage of critical assets with validated backups.
• Effectiveness of segmentation and compensating controls.
• Readiness to isolate, recover, and operate safely during an incident.
• Closure of long-standing risks requiring capital investment.

These measures connect cybersecurity activity to operational resilience.

Recent advisories affecting protection and control equipment should not create panic, but they should create attention. They are reminders that cyber risk has moved beyond the data center and into the systems responsible for physical operations.

Responding effectively requires more than faster patching. It requires engineering judgment, operational ownership, cybersecurity expertise, and executive accountability working together.

Because when the affected asset can trip a substation, stop a production line, or interrupt essential services, vulnerability management is no longer an IT maintenance process.

It is an operational resilience decision.