Whether a controller is in run or program mode tells an adversary whether it can be reprogrammed right now, and that question is often answerable by anyone who can reach the controller on the network. MITRE ATT&CK for ICS tracks this as T0868 Detect Operating Mode, a Collection technique for embedded assets such as PLCs and safety controllers. ATT&CK notes that operating modes are often controlled by a key switch and that modes and how they are selected vary by vendor and product line. This guide is for control engineers, OT security analysts and safety system owners. It explains the modes, why reading them matters, the public Triton case, MITRE's mitigations and detection, and how to manage key switches as a security control. Defensive framing only.
Key takeaways
- Mode reconnaissance comes before change. ATT&CK describes mode knowledge as valuable for deciding whether a PLC can be reprogrammed, which precedes techniques such as T0858 Change Operating Mode and T0843 Program Download.
- The key switch is a security control. Mandiant's Triton analysis advises that Triconex keys should not be left in PROGRAM mode outside scheduled programming, with change management and regular audits of key state.
- Who asks matters more than what is asked. SCADA servers and HMIs poll status legitimately; MITRE's analytic alerts on mode reads from sources outside the approved list.
- Authenticate and allowlist access to controllers. Most of the eight mitigations MITRE maps to T0868 control who can talk to the device.
- Triton shows the pattern. ATT&CK records that Triton contained definitions for program state and key state, used by its tooling.
Operating modes in ATT&CK
ATT&CK for ICS lists commonly implemented modes, while stressing that names and behaviour differ between vendors. Check your own product documentation for the exact behaviour.
| Mode | ATT&CK description | Why an adversary cares |
|---|---|---|
| Program | Must be enabled before changes to a device's program; allows program uploads and downloads with an engineering workstation; logic is often halted and outputs may be forced off | Indicates logic can be changed now |
| Run | The program executes and I/O is used according to the logic; Program Upload and Program Download are disabled | Indicates a mode change is needed first |
| Remote | Allows remote changes to the operating mode | Indicates the mode can be changed over the network without touching the key |
| Stop | The PLC and program are stopped and outputs are forced off | Indicates the process is not under that controller's logic |
| Reset | Conditions are reset to original states; warm reset may retain some memory, cold reset resets all I/O and data registers | Context for timing and recovery state |
| Test or Monitor | Like run with I/O processed, but allowing monitoring, forcing and tuning or debugging | Indicates engineering activity is under way |
For the controller hardening context, see the PLC Security Guide.
The Triton case
| Source | What it records | Lesson |
|---|---|---|
| ATT&CK for ICS, Triton (S1009) | A file in the Triton framework contains default definitions for program state and key state, referenced by its tooling | The attackers built mode and key awareness into their toolkit |
| ATT&CK for ICS, Triton campaign (C0030), 2017 | TEMP.Veles targeted Triconex safety controllers at a petrochemical organisation; the incident was discovered after a safety trip caused by an issue in the malware | Safety controllers are targets; mode and logic monitoring could have surfaced the activity earlier than a trip |
| Mandiant analysis of Triton | Advises physical key switches for programming control, keys not left in PROGRAM outside scheduled programming, change management for key position, regular key state audits, and segregated SIS networks without dual-homed engineering workstations | Key position and network isolation are practical controls |
See the Safety Instrumented Systems Security Guide.
Mitigations MITRE maps to T0868
| Mitigation | MITRE's guidance |
|---|---|
| M0801 Access Management | Authenticate all access to field controllers before authorising access to or modification of state, logic or programs; centralised authentication helps manage controller accounts |
| M0800 Authorization Enforcement | Restrict program modification to certain users, such as engineers and field technicians, preferably with role-based access |
| M0804 Human User Authentication | Field controllers should require authentication for all remote and local management sessions |
| M0813 Software Process and Device Authentication | Authenticate connections from software and devices to stop unauthorised systems reaching management functions |
| M0802 Communication Authenticity | Control protocols should provide authenticity through MAC functions or signatures, or use bump-in-the-wire devices or VPNs for legacy controllers and RTUs |
| M0807 Network Allowlists | Host-based allowlists so devices accept connections only from master stations or known engineering workstations |
| M0930 Network Segmentation | Restrict access to critical system functions to predetermined management systems |
| M0937 Filter Network Traffic | Inline allowlisting of automation protocol commands, designed accurately enough not to block valid messages |
Decision guidance
- Controllers with a physical key switch: keep the key out of program and remote positions in normal operation, store keys under control, and log every change against a work order. This is the most effective step for most sites.
- Controllers with software-selected modes only: rely on controller authentication, network allowlists and protocol filtering, and monitor mode changes from the engineering software and network.
- Safety controllers: apply the strictest key and network controls, and agree any change with the safety owner. See the OT Cyber Physical Risk and Safety Guide.
- Small sites: a key register and a weekly walk-down of key positions is achievable without new tools. Large sites can add automated mode monitoring through OT network monitoring.
Detection and measurement
ATT&CK for ICS v20 detection strategy DET0768 gives one embedded analytic. MITRE tells defenders not to alert on novelty, read volume or enumeration alone; alert when the source is not authorised to poll and the scope, protocol or rate departs from the operational baseline, and suppress normal SCADA, HMI and historian polling, asset inventory, backup and approved engineering activity.
| Signal (from MITRE's analytic) | Log source | Tuning list |
|---|---|---|
| S7comm SZL CPU-state reads, or CIP Identity Object state attribute reads, from a source that is not an approved SCADA server or engineering workstation, where requests focus on mode or state rather than broad process polling | Network security monitoring with OT protocol decoding | Approved SCADA servers and engineering workstations (IP allowlist) |
MITRE notes the analytic is directly informed by the "Get Control Program Status" request in the Triton attack chain. Pair it with alerts on actual mode changes and program transfers, and with a periodic comparison of reported mode against the expected mode for each controller. See the OT Network Security Monitoring Guide.
Metrics:
- Percentage of controllers with a key switch whose key is in the expected position at the last audit.
- Number of mode-state reads from unapproved sources per month.
- Percentage of controllers that accept management connections only from listed engineering workstations.
- Percentage of mode changes matched to an approved work order.
- Number of safety controllers reachable from outside the safety zone (target: zero).
Implementing the controls
- Inventory modes: record for each controller how mode is selected (key, software, both), the expected normal mode and who holds keys. See the OT Asset Visibility Guide.
- Set key procedures: key register, storage, issue against work orders and return after programming.
- Baseline polling: use passive monitoring to learn which hosts read status from which controllers.
- Write the allowlist: approved SCADA servers and engineering workstations per controller, then alert on others.
- Restrict access: apply controller authentication and network allowlists where the product supports them, testing in a maintenance window with the vendor. Keep the prior configuration so a change can be reverted if communications fail.
- Audit: walk down key positions and compare reported modes to expected modes on a set schedule.
Where identity fits
Controller access is often protected by a single shared password or none, and the engineering software on a workstation is the identity the controller trusts. Map which accounts and hosts can reach controller management functions, remove shared engineering logins where the product allows named accounts, and treat the physical key as a credential with its own register. See the OT and ICS Identity and Access Guide.
Responding to suspicious mode queries
- Identify the source: find the host and account behind the request; an unexpected engineering tool on an unusual host is a strong signal.
- Check for follow-on activity: look for mode changes, program uploads or downloads to the same controllers.
- Verify the controllers: confirm mode and key position on site and compare logic with the approved version, with operations and the safety owner involved.
- Contain carefully: isolate the source host through agreed procedures without disrupting legitimate SCADA polling.
Follow the OT Incident Response Guide.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK for ICS v20 | T0868; M0801, M0800, M0804, M0813, M0802, M0807, M0930, M0937; DET0768 | Technique, mitigations and detection strategy |
| MITRE ATT&CK for ICS v20 | T0858 Change Operating Mode; T0843 Program Download; T0845 Program Upload | Techniques that commonly follow mode discovery |
| NIST SP 800-53 Rev. 5 | AC-3 Access Enforcement; IA-3 Device Identification and Authentication; CM-5 Access Restrictions for Change; SI-4 System Monitoring | Controller access, change restriction and monitoring |
| NIST CSF 2.0 | PR.AA-03; DE.CM-01 | Authentication and network monitoring |
For zone design see the IEC 62443 Guide.
Common failure patterns
- Keys left in program or remote. The physical control exists but is not used, often since commissioning.
- No key register. Nobody knows who holds keys or when the position last changed.
- Any host can query any controller. Without allowlists, mode reconnaissance looks like normal traffic.
- Alerting on every status read. Normal SCADA polling floods the queue and real reconnaissance is missed.
- Dual-homed engineering workstations for safety systems. Mandiant's Triton guidance warns against it.
Practitioner checklist
- Record how each controller's mode is selected and its expected normal mode.
- Keep keys out of program and remote positions outside scheduled work.
- Maintain a key register and audit key positions regularly.
- Allowlist the hosts that may query and manage each controller.
- Alert on mode-state reads from unapproved sources.
- Alert on mode changes not matched to a work order.
- Isolate safety controllers and their engineering workstations.
- Enable controller authentication where the product supports it.
Standards and references
- MITRE ATT&CK: Detect Operating Mode (ICS)
- MITRE ATT&CK: Triton
- MITRE ATT&CK: Triton Safety Instrumented System Attack
- Mandiant: Attackers Deploy New ICS Attack Framework TRITON
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: PLC Security Guide · Safety Instrumented Systems Security Guide · MITRE ATT&CK for ICS Guide · Engineering Workstation Security Guide