D3-OMM Operating Mode Monitoring: What It Detects, Which ATT&CK Techniques It Counters and How to Verify It

A programmable logic controller in Program mode will accept new logic from whoever can reach it, so an unexpected change of operating mode is one of the clearest early signs that someone is about to alter a physical process. MITRE D3FEND names the detection Operating Mode Monitoring (D3-OMM) and defines it as "Detects operating modes such as Program, Run, Remote, or Stop." It is a Detect technique under Platform Monitoring, and its digital artefact is the OT Controller Operating Mode, which D3FEND also calls the keyswitch position. This card explains how mode monitoring works, which ATT&CK for ICS techniques D3FEND's data relates to it, how to implement it in controller logic, HMIs and network monitoring, how to verify it, and its limits. It is written for OT security engineers, control engineers and SOC teams that cover industrial sites, and builds on the PLC Security Guide.

Key takeaways

• Mode is a security state. D3FEND notes that many controllers have key switches that select modes such as Program, Run, Remote or Stop, and that the key switch position is often available as a system diagnostic function block in the controller logic.
• Alarm on Program mode. D3FEND's consideration is to configure a key switch alarm so operators are alerted when a controller enters a programming mode, since that may indicate unintended or malicious changes to operational code. The FBI's TRITON advisory recommends the same for safety controllers.
• The ATT&CK link is through the artefact. D3FEND's ontology records that ATT&CK for ICS T0858 Change Operating Mode and T0800 Activate Firmware Update Mode modify the OT Controller Operating Mode, which is the artefact D3-OMM monitors. The D3FEND web page showed no offensive mapping for D3-OMM when checked in November 2026.
• Detect in the controller, not only the HMI. Dragos recommends building the detection into PLC logic, in a protected routine, because HMI scripts are easier to change without notice.
• Remote mode deserves attention too. On some controller families Remote mode lets engineering software change mode or edit online while the process runs, so it is a higher-risk state than Run.

D3-OMM at a glance

How it works

Controllers expose their current mode in at least three places, and D3-OMM can read any of them.

• Inside the controller: controller status data reflects the key position. Dragos describes reading these status bits in Rockwell controllers with a Get System Value (GSV) instruction into a function block that sends alarms to the HMI. Other families expose equivalent diagnostic data; check the vendor manual for the exact object or block.
• At the HMI or historian: predefined mode attributes can be read through the vendor's data server (Dragos cites the @Mode attribute through RSLinx or FactoryTalk Linx), or through DDE or OPC DA for other HMIs.
• On the network: OT network security monitoring tools that decode industrial protocols can record mode change commands and controller status responses. Several OT monitoring products document detection of key state changes; check the product documentation.

Dragos explains what the modes mean in practice. In Run, the controller executes its program; Triconex controllers reject external writes and Rockwell ControlLogix projects cannot be edited online. In Program, execution stops and editing is possible; on Triconex this allows full program downloads and external writes. In Remote, the controller can run while accepting online edits or mode changes from engineering software, which Dragos calls the most vulnerable state on Rockwell controllers. Mode semantics vary by vendor and model, so map each family before writing alarms.

ATT&CK techniques D3FEND relates to D3-OMM

Relationship type: inferred only, through a shared artefact. D3FEND lists no direct ATT&CK mapping for D3-OMM, and its web page showed no inferred offensive techniques when checked (D3FEND 1.6.0, November 2026). The D3FEND ontology does record two ATT&CK for ICS techniques that modify the OT Controller Operating Mode artefact D3-OMM monitors, so they are the techniques mode monitoring can observe. Both IDs were checked against ATT&CK v20.

Defensive detail for both techniques is in ICS T0858 Change Operating Mode and MITRE ATT&CK for ICS T0800 Activate Firmware Update Mode. Mode monitoring is often the first visible step before logic or program changes, which are separate ATT&CK for ICS techniques that need their own detection.

The TRITON lesson

The FBI advisory cited by D3FEND describes TRITON, malware deployed in 2017 against Schneider Electric Triconex safety instrumented systems at a Middle East petrochemical facility. It modified in-memory firmware to add attacker programming. Dragos, which calls the malware TRISIS, states the attack was possible because the controller key was in Program mode, allowing project uploads and downloads from a compromised engineering workstation, and that Run mode would have blocked it. The FBI's mitigations include change management for key positions, regular audits of physical keys, and configuring operator stations to alarm when the safety controller key switch is in PROGRAM. The wider safety context is covered in the Safety Instrumented Systems Security Guide and the ICS Malware History Guide.

Where it is implemented

Network visibility options are covered in the OT Network Security Monitoring Guide. The related parent page, D3FEND Platform Monitoring, groups D3-OMM with firmware and uptime monitoring techniques. Preventing mode changes, rather than detecting them, is D3-OPR Operating Mode Restriction.

Implementation steps

1. Inventory controllers and modes. For each controller family, record the available modes, whether a physical key exists, how mode is exposed (status data, data server attribute, protocol) and the normal mode. The OT Asset Visibility Guide covers building the asset list.
2. Agree the alarm policy with operations. Decide which transitions alarm (for example any move to Program, Remote, Stop or Test), who receives them, and whether alarms are self-clearing or retentive. Dragos stresses involving operations to avoid alarm fatigue during maintenance.
3. Build controller-side detection. Add a mode monitoring routine in a protected, password-protected function block separate from control code, as Dragos recommends, and test it on a simulator or test controller before production.
4. Forward to the SOC. Send mode alarms from the HMI or historian, and mode change events from OT network monitoring, to the SOC with the controller name, old and new mode and time.
5. Link to change control. Match each mode change to an approved work order. A change with no work order is an incident to investigate, not just an alarm to acknowledge.
6. Manage the keys. Keep a register of physical keys, return controllers to Run after maintenance, and audit key positions on a schedule, as the FBI advisory recommends for safety controllers.
7. Roll back safely. Any controller logic change follows plant change management with a tested backup of the previous program. If the monitoring routine causes problems, revert to the backed-up program and keep network or HMI monitoring in place meanwhile.

How to verify it works

• Planned mode change test: during scheduled maintenance, switch a controller to Program and back, and confirm the alarm reached the HMI, the historian and the SOC with the right controller and times.
• Tamper test: Dragos describes using the monitoring block's EnableIn parameter to alarm if the routine is disabled. Test that this alarm fires in a lab.
• Daily mode report: compare the current mode of every controller with its expected mode and list exceptions; a controller left in Program or Remote after maintenance is a finding.
• Key audit: check physical keys against the register and confirm no keys are left in controllers.

Limits, bypasses and failure patterns

• Keys left in Program or Remote: the alarm fired once during maintenance, was acknowledged, and the controller stayed writable. TRITON depended on exactly this state.
• Monitoring removed by a download: a new program that omits the monitoring routine silently ends detection, and Dragos notes the key state may need initialising after a download before detection resumes.
• HMI-only detection: an attacker with access to the engineering workstation or HMI can alter scripts and suppress alarms.
• Alarm fatigue: every maintenance change alarms with no work order context, so operators learn to ignore mode alarms.
• Software mode changes without a key: in Remote mode, or on controllers without a physical key, mode can change through engineering software. Network monitoring and access control on engineering protocols are needed alongside the key.
• Detecting the mode but not the change: mode monitoring says a controller became writable, not what was written. Pair it with program and firmware integrity checks.

Where identity fits

Mode changes in Remote mode come from engineering software running under a user or service account on an engineering workstation. Knowing which accounts can reach controllers, and tying each mode change to a named person through the work order, turns a mode alarm into an attributable event. See the Identity for OT Environments Guide.

Framework mapping

For OT-specific guidance, NIST SP 800-82 applies these controls to industrial systems; see the NIST SP 800-82 OT Security Guide.

Practitioner checklist

• Inventory controller families, available modes, key switches and how mode is exposed.
• Alarm on transitions to Program, Remote, Stop and Test for critical and safety controllers.
• Put the detection in controller logic, in a protected routine, with a tamper alarm.
• Forward mode alarms and network-observed mode changes to the SOC.
• Match every mode change to an approved work order.
• Run a daily expected-mode report and return controllers to Run after maintenance.
• Keep a physical key register and audit it.
• Re-test mode monitoring after every program download.

Standards and references

• MITRE D3FEND: Operating Mode Monitoring (D3-OMM)
• FBI: TRITON Malware Remains Threat to Global Critical Infrastructure Industrial Control Systems (ICS)
• MITRE ATT&CK for ICS: T0858 Change Operating Mode
• MITRE ATT&CK for ICS: T0800 Activate Firmware Update Mode
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• Dragos: Value of PLC Key Switch Monitoring to Keep Critical Systems More Secure

Related NHI Mgmt Group resources: PLC Security Guide · D3-OPR Operating Mode Restriction · OT Network Security Monitoring Guide · MITRE D3FEND Guide