Join our Newsletter — 33% off our NHI Course
Home› Guides› T0837 Loss of Protection: Keeping Protective Relays and…
Guide OT & IoT Security

T0837 Loss of Protection: Keeping Protective Relays and Safety Functions Working

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 12 November 2026 9 min read
On this page

Loss of Protection (T0837) is the outcome where protective functions, such as protective relays and other systems that act on faults faster than any operator, stop working because of an attack. ATT&CK for ICS lists it under the Impact tactic and is frank about the defence: it lists no mitigations for the technique, and its detection strategy states that no standard detection method currently exists. That makes it an engineering and resilience problem as much as a security one. This guide is for protection engineers, OT security engineers and site leaders: what ATT&CK means by loss of protection, what Industroyer did to protective relays, and how to make loss of protection hard to cause, quick to notice and safe to live with. For the related outcome on safety instrumented systems, see Loss of Safety (T0880), and for safety system controls see the Safety Instrumented Systems Security Guide.

Key takeaways

  • Protection acts faster than people. ATT&CK notes many faults and abnormal conditions happen too quickly for an operator to react; protective functions exist to limit outcomes such as Loss of Control and Damage to Property.
  • Loss of protection can be a set-up step. ATT&CK describes adversaries disabling protection as a prerequisite to a later attack, or so future faults go unchecked.
  • Industroyer is the recorded case. ATT&CK records a module that caused a denial of service against Siemens SIPROTEC protective relays in the 2016 Ukraine Electric Power Attack.
  • Even detection has a cost. ATT&CK notes operators who detect a loss of protection may have to shut the process down under protection policies, which can itself meet an adversary's goal.
  • Health monitoring is your detection. With no standard method, the practical signal is protection devices that stop communicating, report self-test faults or change settings unexpectedly.

What T0837 covers

ATT&CK for ICS describes T0837 as adversaries compromising protective system functions designed to prevent the effects of faults and abnormal conditions, which can result in equipment damage, prolonged process disruption and hazards to personnel. It lists no platform, because it describes an outcome rather than a specific action on a host. The techniques that typically produce it are separate entries:

How protection is lostRelated ATT&CK for ICS techniqueExample in ATT&CK
Protective device made unresponsiveDenial of Service (T0814)Industroyer's SIPROTEC module rendered relays unresponsive until manually rebooted
Device needs a restart to recoverDevice Restart/Shutdown (T0816)ATT&CK notes the Industroyer DoS did not restart the relay; it had to be restarted manually
Alarms that would reveal the fault are changed or silencedModify Alarm Settings (T0838), Alarm Suppression (T0878)See the ATT&CK for ICS Inhibit Response Function Tactic Guide
Safety instrumented functions disabledLoss of Safety (T0880)Triton targeted safety controllers

Protection here is broader than a safety instrumented system. In power systems it means protective relays and the schemes built on them; in process plants it can include equipment protection functions, interlocks and machine protection systems that are not part of the safety instrumented system.

The Industroyer case

ATT&CK records that Industroyer (S0604), used by Sandworm Team (G0034) in the 2016 Ukraine Electric Power Attack (C0025), contained a module that exploited a vulnerability in Siemens SIPROTEC relays (CVE-2015-5374) to create a denial of service against automated protective relays. ATT&CK's Denial of Service (T0814) procedure for Industroyer adds that the device then stopped responding to commands until it was rebooted manually. The lessons are defensive and vendor-neutral:

  • Protection devices are network endpoints. Once relays have Ethernet interfaces, anything that can reach them can try to disrupt them. Restrict which hosts can reach relay services.
  • Apply protection device updates as an engineering change. Track vendor security advisories for every protective device model and plan updates through protection testing.
  • Know what failure looks like. A relay that stops responding but shows no alarm is the worst case; make loss of communication with protection devices an alarm in its own right.

The substation context is covered in the IEC 61850 Substation Communications Security Guide.

Detection: building your own signals

ATT&CK's detection strategy for T0837 (DET0775) states that no standard detection method currently exists. In practice you detect the conditions that lead to loss of protection and the health of the protective layer itself:

SignalSourceWhy it matters
Protection device stops communicating or reportingSCADA communications alarms, polling status, protocol monitoringEarliest sign a device is unresponsive
Device self-test or health status changesRelay and controller diagnostics, where exposed to SCADADistinguishes a failed device from a failed link
Settings or logic changes on protective devicesConfiguration management tools, engineering software logs, settings comparisonProtection can be disabled by settings as well as by denial of service
Traffic to protection device management services from unapproved sourcesOT network monitoring with protocol decodingMost disruption needs network access first
Bypasses or overrides active on protective functionsBypass registers, controller statusA legitimate bypass left in place leaves the same gap as an attack

See the OT Network Security Monitoring Guide for the monitoring architecture.

Prevention and resilience

With no ATT&CK mitigation listed for the outcome itself, apply controls to the paths that lead to it:

  • Restrict network reach: place protection devices in their own zone and allow management services only from named engineering hosts. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
  • Control settings changes: settings files under version control, changes approved by protection engineering and verified against the approved copy afterwards.
  • Design for fail-safe and redundancy: backup protection and fail-safe behaviour on communication loss mean a single disrupted device does not remove protection. These are engineering decisions; involve protection and process safety engineers. See the OT Cyber Physical Risk and Safety Guide.
  • Manage vulnerabilities on protection devices: include relays and protective controllers in advisory triage. See the ICS Advisory Triage and OT Vulnerability Management Guide.
  • Plan the response before you need it: agree in advance what operations do when protection is lost, so the decision to shut down or run with compensating measures is not made under pressure.

Where identity fits

Protection settings are often changed with vendor tools that use device passwords shared across a fleet, or through integrator remote access. A shared relay password known to many contractors is a protection risk. Use per-device or per-role credentials where devices support them, broker integrator access through a controlled path with session recording, and remove access after the work. See the OT and ICS Identity and Access Guide.

How to implement

  1. Inventory protective functions: relays, protective controllers, interlocks and safety functions, with their network exposure and owner.
  2. Alarm on loss of communication and health for every protective device, tested by simulating a lost link during maintenance.
  3. Restrict access to protection device services at the conduit, logging denies before enforcing.
  4. Baseline settings and compare them after every maintenance visit and on a schedule.
  5. Review redundancy and fail-safe behaviour with protection engineers, using the scenario of a deliberately disrupted device.
  6. Write and exercise the response: who decides to shut down, what compensating measures allow continued operation, how devices are safely restored.

Decision guidance

  • Continue or shut down: follow the site's protection policy; ATT&CK's point that shutdown can meet an adversary's goal is a reason to plan compensating measures in advance, not to ignore the policy.
  • Networked versus hardwired protection: networked protection brings monitoring and flexibility but adds an attack surface; keep critical trip paths independent of shared networks where the engineering allows.
  • Small sites: loss of communication alarms, restricted access and settings backups cover most of the risk.
  • Large utilities and plants: add protocol-aware monitoring of protection traffic, central settings management and exercises with the grid or process operator.

Responding to loss of protection

Treat suspected loss of protection as a safety event. Operations decide immediately whether to shut down or apply compensating measures. Before restarting or replacing a device, preserve what you can: device event records and settings, protocol captures and the logs of hosts that reached it. Restore from approved settings, and test protection before returning to service. Assume the loss may be preparation for a further attack and raise monitoring across the site. See the OT Incident Response Guide.

Detection and measurement

  • Health alarm coverage: percentage of protective devices with loss of communication and health alarms.
  • Settings assurance: percentage of protective devices whose settings matched the approved copy at the last check.
  • Exposure: number of hosts able to reach protection device services, against the approved list.
  • Advisory latency: median time from a protection device advisory to an engineering decision.
  • Bypass hygiene: number of protective bypasses active beyond their approved duration.

Framework mapping

FrameworkReferenceHow it applies
MITRE ATT&CK for ICS v20T0837; DET0775; S0604; C0025; related T0814, T0816, T0838, T0878, T0880Outcome, detection note, case, related techniques
NIST SP 800-53 Rev. 5SC-7, SC-5, CM-3, CM-5, SI-4, CP-2, IR-4Boundary protection, denial of service protection, change control, monitoring, contingency and incident handling
NIST CSF 2.0PR.IR-01, DE.CM-01, RS.MA-01Network protection, monitoring, incident management

Common failure patterns

  • Silent failure: loss of communication with a relay is not alarmed, so a disrupted device looks healthy.
  • Protection reachable from the wider OT network: any compromised host can reach relay services.
  • Settings without a baseline: a changed setting cannot be spotted.
  • Bypasses left in place: a maintenance bypass removes protection as effectively as an attack.
  • No pre-agreed response: operations face a shutdown decision without compensating measures prepared.

Practitioner checklist

  • Inventory protective devices and functions with owners and network exposure.
  • Alarm on loss of communication and health for each protective device.
  • Restrict protection device services to named engineering hosts.
  • Keep approved settings copies and compare after every change.
  • Track vendor advisories for every protective device model.
  • Review redundancy and fail-safe behaviour against a deliberate disruption scenario.
  • Use per-device or per-role credentials and controlled integrator access.
  • Exercise the loss of protection response with operations.

Standards and references

Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · Safety Instrumented Systems Security Guide · IEC 61850 Substation Communications Security Guide · ATT&CK for ICS Inhibit Response Function Tactic Guide

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 12 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org