M0812: Safety Instrumented Systems
Utilize Safety Instrumented Systems (SIS) to provide an additional layer of protection to hazard scenarios that may cause property damage. A SIS will typically include sensors, logic solvers, and a final control element that can be used to automatically respond to an hazardous condition [1] . Ensure that all SISs are segmented from operational networks to prevent them from being targeted by additional adversarial behavior.
Analyst context for executives and security teams
Safety Instrumented Systems (SIS) matter because they are the independent safety layer intended to keep hazardous industrial conditions from becoming property damage or loss-of-safety events. For executives and risk owners, this mitigation is less about a single security tool and more about ensuring that cyber incidents in operational technology do not remove the last protective barrier between process disruption and physical harm.
Executive priority
Prioritize SIS governance where operational failure could create property damage, environmental impact, or safety consequences. Leadership should ask whether SIS architecture is truly separated from operational networks, whether safety functions are maintained as independent protection layers, and whether evidence exists for audit, insurance, and incident-response decision-making. This is especially material for business continuity because the related ATT&CK techniques include Damage to Property and Loss of Safety.
Technical view
ATT&CK describes SIS as sensors, logic solvers, and final control elements that automatically respond to hazardous conditions, and specifically advises segmentation from operational networks to reduce exposure to additional adversarial behavior. SOC, OT security, and IR teams should validate network separation, approved communication paths, change-control evidence, and monitoring visibility around any interfaces between SIS and operational environments. Because ATT&CK provides no detection guidance and no platforms or tactics for this mitigation, local engineering diagrams, asset inventories, and safety documentation are required to assess coverage.
Likely telemetry
- OT network architecture and segmentation evidence for SIS and operational network boundaries
- Asset inventory records identifying SIS components such as sensors, logic solvers, and final control elements
- Firewall, routing, access-control, or data-diode policy evidence for allowed SIS communications where present
- Change-management and engineering workstation activity related to SIS configuration or logic changes
- Safety system event, alarm, trip, bypass, maintenance, and diagnostic records where available
Detection direction
- Validate that monitoring can show whether SIS networks remain segmented from operational networks; absence of visibility at the boundary is a key blind spot.
- Tune reviews around unauthorized or unexpected connectivity to SIS environments rather than assuming normal OT traffic patterns are acceptable.
- Correlate SIS alarms, bypasses, maintenance states, or configuration changes with OT network and change-control records to reduce false positives from legitimate engineering work.
- Because MITRE provides no official detection text for M0812, treat detection as an assurance and validation activity, not as a predefined analytic.
- Use the relationship context to prioritize detection engineering around scenarios that could lead to Damage to Property or Loss of Safety.
Mitigation priorities
- Establish or confirm SIS as an additional independent protection layer for hazardous scenarios that could cause property damage.
- Segment SIS from operational networks as the core control priority stated by ATT&CK.
- Maintain accurate documentation of SIS components, communication paths, and dependencies so incident responders can quickly determine whether safety protection remains intact.
- Apply disciplined change control and engineering authorization for SIS-related configuration, logic, and maintenance activity.
- Test incident-response procedures for confirming SIS integrity and safe-state capability during an OT cyber event, using local safety and engineering requirements.
Analyst notes and limits
This is an ICS ATT&CK mitigation, not a technique. Its decision value is in resilience assurance: confirming that cyber activity in operational networks cannot easily affect the independent safety layer intended to respond faster than human operators during hazardous conditions. The most important local questions are whether SIS independence is real, whether exceptions are documented, and whether SOC/IR teams know how to verify SIS status during an incident.
The supplied ATT&CK object does not specify platforms, tactics, or official detection guidance. The assessment therefore cannot claim specific detection coverage, exploitation patterns, or technology applicability. Practical validation depends on local SIS design, engineering documentation, segmentation architecture, and safety-management evidence.
Safety Instrumented Systems
Utilize Safety Instrumented Systems (SIS) to provide an additional layer of protection to hazard scenarios that may cause property damage. A SIS will typically include sensors, logic solvers, and a final control element that can be used to automatically respond to an hazardous condition [1] . Ensure that all SISs are segmented from operational networks to prevent them from being targeted by additional adversarial behavior.
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.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0880 | Loss of Safety | Ensure that all SIS are segmented from operational networks to prevent them from being targeted by additional adversarial behavior. |
| ICS | T0879 | Damage to Property | Ensure that all SIS are segmented from operational networks to prevent them from being targeted by additional adversarial behavior. |
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 | 4bebd4e1fc82… |
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]
A G Foord, W G Gulland, C R Howard, T Kellacher, W H Smith 2004
A G Foord, W G Gulland, C R Howard, T Kellacher, W H Smith 2004 APPLYING THE LATEST STANDARD FOR FUNCTIONAL SAFETY IEC 61511 Retrieved. 2020/09/17
Open source URL -
[2]
mitre-attack M0812Open 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.