T0837: Loss of Protection
Adversaries may compromise protective system functions designed to prevent the effects of faults and abnormal conditions. This can result in equipment damage, prolonged process disruptions and hazards to personnel.
Many faults and abnormal conditions in process control happen too quickly for a human operator to react to. Speed is critical in correcting these conditions to limit serious impacts such as Loss of Control and Property Damage.
Adversaries may target and disable protective system functions as a prerequisite to subsequent attack execution or to allow for future faults and abnormal conditions to go unchecked. Detection of a Loss of Protection by operators can result in the shutdown of a process due to strict policies regarding protection systems. This can cause a Loss of Productivity and Revenue and may meet the technical goals of adversaries seeking to cause process disruptions.
Analyst context for executives and security teams
Loss of Protection is an ICS impact behavior where an adversary compromises safety or protective functions that are meant to stop faults, abnormal process conditions, equipment damage, or hazards to personnel. For leaders, the key issue is not only cyber intrusion; it is whether the organization can prove that protective systems remain trustworthy during an incident. If operators detect loss of protection, policy may require shutting down the process, creating direct productivity and revenue impact even before physical damage occurs.
Executive priority
Treat this as a cyber-physical resilience and governance issue. Executives should ask whether protective functions are independently monitored, whether shutdown criteria are documented, and whether incident responders can quickly distinguish a true loss of protection from incomplete visibility. Budget and audit priority should focus on evidence that safety/protection functions cannot be silently disabled or degraded without operational awareness. The supplied ATT&CK relationship to Industroyer reinforces that this behavior is relevant to ICS disruption scenarios, especially where industrial processes depend on fast automated protection rather than human response.
Technical view
ATT&CK does not provide platform, tactic, or detection text for T0837, so SOC and IR teams should validate coverage around the protective-function boundary rather than assume endpoint-centric detection is sufficient. Confirm whether the environment can observe changes in protective system state, disabled or bypassed protection logic, unexpected trips, protection alarms, controller or engineering workstation activity affecting safety/protection functions, and operator actions taken in response. Use the related DET0775 detection strategy as a reference point for building or assessing local detection logic, but require site-specific process context and engineering validation.
Likely telemetry
- Protective system status, trip, bypass, inhibit, and alarm records
- ICS controller and engineering workstation change logs where available
- Process historian data showing abnormal conditions, trips, or loss of protective response
- Operator console events and alarm acknowledgements
- Maintenance, testing, and management-of-change records for protective functions
Detection direction
- Validate that monitoring can identify protective functions being disabled, bypassed, inhibited, or otherwise unavailable.
- Correlate protection-system events with process conditions to distinguish legitimate maintenance/testing from suspicious or unsafe loss of protection.
- Tune alerts with operations and engineering input; false positives may occur during authorized testing, maintenance windows, or planned shutdowns.
- Do not rely solely on generic IT telemetry, because the ATT&CK object describes fast process conditions where operator reaction may be too slow and where process-aware evidence is decisive.
- Use the relationship to DET0775 as an ATT&CK-supported detection reference, while recognizing that the official technique entry provides no detailed detection procedure.
Mitigation priorities
- Prioritize governance for protective-system changes: authorization, maintenance windows, documentation, and independent review.
- Ensure operators and incident responders have clear shutdown and escalation procedures when protection integrity is uncertain.
- Validate independent monitoring of protection availability and alarms, not just monitoring of production control functions.
- Test incident response playbooks for scenarios where protection loss may require process shutdown to prevent equipment damage or personnel hazards.
- Maintain compliance and audit evidence showing protective functions are controlled, monitored, and recoverable after abnormal cyber or process events.
Analyst notes and limits
This technique is material because it connects cyber activity to safety, equipment protection, production continuity, and revenue loss. The official ATT&CK entry also notes that disabling protection may be a prerequisite for later attack execution or may allow future faults to go unchecked. Relationship context includes detection strategy DET0775 and software S0604 Industroyer, which is described as an ICS malware framework associated with electrical substation disruption; however, that relationship should be used as context, not as proof of current activity in any environment.
The supplied ATT&CK object has no official detection text, no platforms, and no tactics specified. Any concrete detection logic, asset scope, or control assurance must be derived from local ICS architecture, protective-system design, available historian/controller/operator telemetry, and approved engineering procedures.
Loss of Protection
Adversaries may compromise protective system functions designed to prevent the effects of faults and abnormal conditions. This can result in equipment damage, prolonged process disruptions and hazards to personnel.
Many faults and abnormal conditions in process control happen too quickly for a human operator to react to. Speed is critical in correcting these conditions to limit serious impacts such as Loss of Control and Property Damage.
Adversaries may target and disable protective system functions as a prerequisite to subsequent attack execution or to allow for future faults and abnormal conditions to go unchecked. Detection of a Loss of Protection by operators can result in the shutdown of a process due to strict policies regarding protection systems. This can cause a Loss of Productivity and Revenue and may meet the technical goals of adversaries seeking to cause process disruptions.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Groups, software, and campaigns
S0604: Industroyer
Industroyer is a sophisticated malware framework designed to cause an impact to the working processes of Industrial Control Systems (ICS), specifically components used in electrical substations.[1] Industroyer was used in the attacks on the Ukrainian power grid in December 2016.[2] This is the first publicly known malware specifically designed to target and impact operations in the electric grid.[3]
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 31221cdb1b58… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack T0837Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.