Change Operating Mode (T0858) is an adversary moving a controller out of Run and into a mode that accepts new logic, or stopping it outright, so that the next step of an attack becomes possible. Most programmable controllers refuse program downloads while running, so a mode change is often the gate an attacker has to pass before tampering with logic. MITRE ATT&CK for ICS lists T0858 under both Execution and Evasion, on the Embedded platform. This guide is for OT security engineers, control engineers and OT SOC analysts: what operating modes are, what Triton, INCONTROLLER and PLC-Blaster did with them, what ATT&CK's v20 analytics look for, and how to make an unauthorised mode change both harder and louder. For the wider matrix see the MITRE ATT&CK for ICS Guide.
Key takeaways
- The mode is a security boundary. In Run mode many controllers disable program upload and download; Program mode reopens them, so every move into Program is an event worth knowing about.
- The physical key switch still matters. Where a controller has one, leaving it in Run (not Remote or Program) means a remote mode change request is refused by the hardware.
- Triton needed Program mode. ICS-CERT's HatMan report notes a Triconex controller cannot be programmed with its key in RUN or REMOTE, and advises switching to PROGRAM only when necessary.
- Who changed it is the detection question. ATT&CK's analytics alert on a mode change from a source outside the approved engineering workstation list or without a matching change ticket, not on mode changes as such.
- Alarm on the position, not only the command. Schneider Electric's guidance, cited by ICS-CERT and the Canadian Centre for Cyber Security, is for operator stations to raise an alarm whenever the Tricon key is in Program.
What T0858 covers
ATT&CK describes the technique as adversaries changing the operating mode of a controller to gain additional access to engineering functions such as Program Download (T0843). Modes can be selected with a physical key switch on the face of the controller or through calls to the controller's API, and both the modes and the way they are selected vary by vendor and product line. ATT&CK lists these commonly implemented modes:
| Mode | What ATT&CK says happens | Why a defender cares |
|---|---|---|
| Program | Must be enabled before the program can be changed; allows uploads and downloads with an engineering workstation; logic is often halted and outputs may be forced off | Opens the door to logic changes and can stop the process |
| Run | The program executes; Program Upload and Program Download are disabled | The safe resting state for production |
| Remote | Allows remote changes to the controller's operating mode | Lets software, including an attacker's, change mode without anyone touching the device |
| Stop | The controller and program are stopped and outputs forced off | A direct loss of control in its own right |
| Reset | Conditions return to original states; warm resets may keep some memory, cold resets clear all I/O and data registers | Can wipe state an operator relies on |
| Test / Monitor | I/O is processed as in Run, but forcing, resets and tuning are allowed | Allows values to be forced while the process keeps running |
Because T0858 sits under Execution and Evasion, a mode change can be both the enabling step for a logic change and a way to stop the controller doing its job. Reading the current mode first is a separate ATT&CK technique, Detect Operating Mode (T0868), which commonly precedes it. For controller hardening in general, see the PLC Security Guide.
The procedure examples and what they teach
ATT&CK v20 lists three software entries for T0858:
- Triton (S1009): ATT&CK records that Triton can halt or run a program through the TriStation protocol. ICS-CERT's malware analysis report MAR-17-352-01 (HatMan, December 2017) notes that a Triconex controller cannot be programmed while its key is in RUN or REMOTE, which implies the PROGRAM position was needed to install the malicious program, and that once installed the implant could be reached over the network regardless of key position. The lesson is twofold: the key switch is a real barrier, and it only helps if it stays in Run. See the ICS Malware History Guide.
- INCONTROLLER (S1045): ATT&CK records that INCONTROLLER can establish a remote HTTP connection to change the operating mode of Omron PLCs. The joint advisory AA22-103A (DOE, CISA, NSA and FBI, April 2022) maps the Omron tooling to Change Operating Mode and Detect Operating Mode, and describes tools that back up and restore files on the PLC. The lesson: modes reachable over a web or management interface are only as protected as that interface. See the Mitsubishi MELSEC and Omron PLC Security Guide.
- PLC-Blaster (S1006): a proof-of-concept worm for Siemens S7 PLCs. ATT&CK records that it stops execution of the user program to transfer its own code, then starts the PLC again. Stop and restart is the pattern to look for: a brief stop followed by a download and a start.
Detection: ATT&CK v20 analytics
MITRE's v20 detection strategy for T0858 looks for a mode-change command to a field device from a source not on the approved engineering workstation list, where the transition is not followed by an operator acknowledgement. It applies ATT&CK's OT operational fidelity gate: alert only when the action is not attributable to an authorised operator or engineering source for that target and function, and falls outside an approved change or maintenance window or lacks change-control context. Suppress activity that matches approved maintenance, commissioning, failover or recovery procedures.
| Data source | What to look for | Practical note |
|---|---|---|
| Network content (OT protocol decoding) | A mode-change service from a source not on the engineering workstation list, outside the change window | Needs a monitoring sensor that decodes the vendor's management protocol and labels mode-change and start/stop functions |
| Operational alarm and event database (HMI, historian, SIS) | A device mode-change alarm with no operator identity recorded within the acknowledgement window | Requires the controller or HMI to raise a mode or key-position alarm in the first place |
| Engineering workstation application log | A mode-change session logged without a change ticket reference | Engineering tools vary in what they log; check what yours records before relying on it |
Two further signals are worth adding where your equipment supports them. First, a physical key position change raised as an alarm, as Schneider Electric advised for the Tricon after Triton. Second, a stop or Program transition followed within minutes by a program download, which ties T0858 to T0843 and is a stronger signal than either on its own. See the OT Network Security Monitoring Guide.
Prevention: ATT&CK mitigations in practice
| ATT&CK mitigation | What ATT&CK says for T0858 | How to apply it |
|---|---|---|
| M0800 Authorization Enforcement | Restrict mode changes to authenticated engineers and technicians, preferably role-based; physical keys can also limit changes | Keep keys in Run, keys removed and held under a sign-out procedure; use controller role settings where they exist |
| M0801 Access Management | Authenticate all access to field controllers before allowing changes to state, logic or programs | Put an authenticating access layer in front of controllers that cannot authenticate users themselves |
| M0804 Human User Authentication | Field controllers should require authentication for all remote or local management sessions | Turn on controller passwords and project protection after testing; replace defaults |
| M0802 Communication Authenticity | Device management protocols should authenticate network messages | Enable authenticated or secure variants of management protocols where the platform supports them |
| M0813 Software Process and Device Authentication | Authenticate connecting software and devices before allowing management functions | Bind engineering software to known workstations; avoid unauthenticated management services |
| M0807 Network Allowlists | Devices accept connections only from master stations or known engineering workstations | Allowlist engineering workstation addresses on controllers or the nearest conduit |
| M0930 Network Segmentation | Restrict access to critical functions to predetermined management systems | Place controllers, and safety systems especially, in zones whose conduits carry management traffic only from engineering zones |
The Canadian Centre for Cyber Security alert AL17-015 on Triton repeated Schneider Electric's guidance: keep controllers in locked cabinets and never leave them in Program mode, alarm when the key is in Program, keep engineering terminals in locked cabinets and connected only to the safety network, and enable the platform's enhanced security features. These translate to most controller families. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
Where identity fits
Mode changes are an engineering privilege, and in many plants that privilege sits with a shared engineering account, a vendor's support login or a remote access credential used by an integrator. If a mode change cannot be tied to a named person, neither the detection analytic nor an investigation can answer the key question. Use named accounts on engineering software, record who holds physical keys, and treat integrator remote access as a privileged path with its own approval. See the OT and ICS Identity and Access Guide and NHIs in OT.
How to implement
- Inventory modes and keys. For each controller, record whether it has a physical key switch, its normal key position, which modes can be changed remotely, and which engineering tools can change them. Start with safety instrumented systems and controllers whose stop would trip the process.
- Agree the normal state with operations. Document that production controllers sit in Run with the key removed, and when Program is allowed. Write it into the change procedure.
- Raise the position as an alarm. Configure the HMI or SIS operator station to alarm on Program or Remote key position and on mode transitions, where the platform exposes them. Test on a non-production controller first.
- Turn on controller protections. Enable passwords, project protection and any setting that blocks remote mode changes, one controller family at a time, after vendor guidance and a bench test. Keep the previous configuration so you can revert.
- Restrict the path. Allowlist engineering workstations at the conduit for management protocols. Run the rule in log-only mode for a full maintenance cycle before enforcing.
- Build the detection. Feed protocol decoding, alarms and engineering logs to the OT SOC, and correlate mode changes with change tickets and with following program downloads.
- Exercise the response. Run a tabletop where an unexplained Program transition appears on a safety controller, with operations leading the process-safety decisions.
Decision guidance
- Key switch versus software controls: where a key exists, it is the stronger control because it does not depend on authentication the controller may not implement. Software role controls matter most on controllers without a key, or where Remote must stay enabled for operational reasons.
- Remote mode left on: some sites keep keys in Remote so engineers can work from the control room. If that is a business need, compensate with tighter network allowlists, named accounts and an alarm on every transition.
- Small sites: a written key procedure, removed keys and a weekly walk-round check of key positions give most of the value without new tooling.
- Large estates: rely on protocol-aware monitoring and change-ticket correlation, since manual checks do not scale across hundreds of controllers.
Responding to an unexplained mode change
- Process safety first. Operations decides whether the process is safe and whether to move to manual control. Security does not force a controller back to Run without that decision.
- Confirm with the people who could have done it. Check the change calendar and ask engineering and any vendor on site or connected remotely.
- Preserve evidence. Keep network captures around the event, engineering workstation logs, controller diagnostic buffers and alarm history before anything is restarted.
- Check the logic. Compare the running program with a known-good offline copy before returning to Run, since a mode change is often followed by a download.
- Close the path. Identify the source host and account, remove access and review other controllers it can reach.
See the OT Incident Response Guide.
Detection and measurement
- Key position compliance: percentage of controllers with a key switch found in Run with the key removed at each check.
- Mode change attribution: percentage of mode changes matched to a named person and a change ticket.
- Monitoring coverage: percentage of controllers whose management protocol traffic is decoded by OT monitoring.
- Allowlist enforcement: percentage of controller zones where only approved engineering workstations can reach management services.
- Logic verification: percentage of unexplained mode changes followed by a completed program comparison.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK for ICS | T0858; related T0868, T0843 | Technique, its usual precursor and its usual follow-on |
| NIST SP 800-53 Rev. 5 | AC-3, CM-5, SC-7, SI-4, PE-3 | Access enforcement, access restrictions for change, boundary protection, monitoring, physical access |
| NIST CSF 2.0 | PR.AA-05, PR.IR-01, DE.CM-01 | Authorisations, protection from unauthorised logical access, network monitoring |
| NIST SP 800-82 Rev. 3 | OT overlay guidance | Applying the controls above in OT |
| IEC 62443 | Zones and conduits; authorisation enforcement | Segmenting controllers and restricting who may change them |
Common failure patterns
- Keys left in Remote or Program. Convenient for engineering, but it removes the hardware barrier that would otherwise refuse a remote mode change.
- No alarm on mode or key position. The controller knows its state, but nobody is told when it changes.
- Monitoring that sees traffic but not functions. Flow data shows a session to a controller; only protocol decoding shows a stop or Program transition.
- Shared engineering accounts. Every change looks authorised, so the analytic has nothing to separate.
- Returning to Run without checking the logic. The mode change is fixed, but whatever was downloaded keeps running.
Practitioner checklist
- Record mode capabilities, key switches and normal positions for every controller, safety systems first.
- Keep production keys in Run, removed and signed out under a written procedure.
- Alarm on key position and mode transitions at the HMI or SIS operator station.
- Enable controller passwords and remote mode-change restrictions after bench testing.
- Allowlist engineering workstations for management protocols at each conduit.
- Decode management protocols in OT monitoring and correlate mode changes with change tickets.
- Hold offline known-good programs and compare after any unexplained mode change.
- Use named accounts for engineering tools and vendor access.
Standards and references
- MITRE ATT&CK for ICS: Change Operating Mode (T0858)
- MITRE ATT&CK: Triton (S1009)
- MITRE ATT&CK: INCONTROLLER (S1045)
- ICS-CERT: MAR-17-352-01 HatMan, Safety System Targeted Malware
- Canadian Centre for Cyber Security: AL17-015 Malcode affecting Triconex Industrial Safety Controllers
- CISA, DOE, NSA and FBI: AA22-103A APT Cyber Tools Targeting ICS/SCADA Devices
- NIST: SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security
Related NHI Mgmt Group resources: MITRE ATT&CK for ICS Guide · PLC Security Guide · MITRE ATT&CK for ICS T0871 Execution through API · OT Network Security Monitoring Guide · Engineering Workstation Security Guide