T0858: Change Operating Mode

Changing a controller’s operating mode is a high-consequence ICS behavior because it can move a PLC, PAC, DCS controller, or safety controller from normal execution into states that allow program changes, downloads, resets, testing, or stopping logic. For business leaders, the practical issue is not just cyber access; it is whether unauthorized or poorly controlled mode changes could interrupt production, affect safety functions, or create uncertainty during an incident about whether control logic remains trustworthy.

Executive priority

Treat this as an operational resilience and safety-governance control point. Leaders should ask whether controller mode changes require approved authorization, whether remote mode changes are restricted, whether engineering actions are attributable to authenticated users or systems, and whether evidence exists for audits and incident reviews. Priority is highest where mode changes could halt outputs, enable program download, reset controller state, or affect safety controller behavior.

Technical view

SOC, OT security, and IR teams should validate visibility and control around controller operating mode transitions, especially Program, Run, Remote, Stop, Reset, and Test/Monitor states described by ATT&CK. Because the ATT&CK object provides no official detection text and no platform field, detection engineering should be driven by local controller models, vendor protocols, engineering workstation workflows, and the related DET0755 detection strategy. Relationship context shows the technique targets PLCs, safety controllers, DCS controllers, and PACs, and is used by PLC-Blaster, Triton, and INCONTROLLER, so investigations should correlate mode changes with engineering workstation activity, controller API access, remote access paths, and any subsequent program upload/download or logic-change activity.

Likely telemetry

Controller event logs or diagnostics showing operating mode transitions
Engineering workstation activity and project/logic transfer records
Network traffic between engineering systems, gateways, and controllers, including protocol/API commands where available
Authentication and authorization logs for users, devices, software processes, and remote access paths
Configuration management or change-management records for approved controller mode changes

Detection direction

Validate whether DET0755-style monitoring exists for controller operating mode changes rather than relying only on IT endpoint alerts.
Baseline expected mode-change behavior by asset, maintenance window, engineering workstation, and authorized operator to reduce false positives from legitimate commissioning, debugging, or maintenance.
Alert on mode changes that occur outside approved windows, from unexpected network segments, from unauthenticated or weakly attributable sources, or immediately before program download/upload activity.
Correlate remote mode changes with access-management, segmentation, and authentication logs to determine whether the command path was authorized.
Account for blind spots where controllers expose limited logging, where mode selection is physical via key switch, or where vendor/product-line differences change how mode state is represented.

Mitigation priorities

Start with authorization enforcement so only approved users can read, manipulate, or execute controller functions related to operating mode.
Use access management controls or gateways where field devices cannot provide sufficient user identification and authentication themselves.
Require human user authentication and, where appropriate, software process and device authentication before accepting controller commands or API access.
Apply communication authenticity controls on untrusted networks to reduce spoofed or tampered command risk.
Use network allowlists and network segmentation to restrict which systems can reach controller management interfaces and engineering functions.

Analyst notes and limits

This technique is materially important in ICS because mode selection can determine whether a controller is executing process logic or accepting engineering changes. The relationship set provides strong defensive direction: relevant mitigations include authorization enforcement, access management, communication authenticity, human authentication, network allowlists, software/device authentication, and segmentation. Related assets are embedded ICS controllers, including PLCs, safety controllers, DCS controllers, and PACs. Related software examples are PLC-Blaster, Triton, and INCONTROLLER, but this does not by itself establish current activity in any environment.

The supplied ATT&CK object has no official detection text, no listed tactics, and no primary platform field. Mode names, APIs, logging, and enforcement mechanisms vary by vendor and product line, so local asset inventory, controller documentation, and observed engineering workflows are required before finalizing detections or control requirements.

Official MITRE ATT&CK definition

Change Operating Mode

Adversaries may change the operating mode of a controller to gain additional access to engineering functions such as Program Download. Programmable controllers typically have several modes of operation that control the state of the user program and control access to the controllers API. Operating modes can be physically selected using a key switch on the face of the controller but may also be selected with calls to the controllers API. Operating modes and the mechanisms by which they are selected often vary by vendor and product line. Some commonly implemented operating modes are described below:

* Program - This mode must be enabled before changes can be made to a devices program. This allows program uploads and downloads between the device and an engineering workstation. Often the PLCs logic Is halted, and all outputs may be forced off. [1] * Run - Execution of the devices program occurs in this mode. Input and output (values, points, tags, elements, etc.) are monitored and used according to the programs logic. Program Upload and Program Download are disabled while in this mode. [2] [3] [1] [4] * Remote - Allows for remote changes to a PLCs operation mode. [4] * Stop - The PLC and program is stopped, while in this mode, outputs are forced off. [3] * Reset - Conditions on the PLC are reset to their original states. Warm resets may retain some memory while cold resets will reset all I/O and data registers. [3] * Test / Monitor mode - Similar to run mode, I/O is processed, although this mode allows for monitoring, force set, resets, and more generally tuning or debugging of the system. Often monitor mode may be used as a trial for initialization. [2]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Associated objects

Groups, software, and campaigns

S1045: INCONTROLLER

INCONTROLLER is custom malware that includes multiple modules tailored towards ICS devices and technologies, including Schneider Electric and Omron PLCs as well as OPC UA, Modbus, and CODESYS protocols. INCONTROLLER has the ability to discover specific devices, download logic on the devices, and exploit platform-specific vulnerabilities. As of September 2022, some security researchers assessed INCONTROLLER was developed by CHERNOVITE.[1][2][3][4][5]

Engineering WorkstationField Controller/RTU/PLC/IEDSafety Instrumented System/Protection Relay

S1009: Triton

Triton is an attack framework built to interact with Triconex Safety Instrumented System (SIS) controllers.[1][2][3][4][5][6][7]

S1006: PLC-Blaster

PLC-Blaster is a piece of proof-of-concept malware that runs on Siemens S7 PLCs. This worm locates other Siemens S7 PLCs on the network and attempts to infect them. Once this worm has infected its target and attempted to infect other devices on the network, the worm can then run one of many modules. [1] [2]

Relationship explorer

All related ATT&CK context

mitigates · Mitigation M0802: Communication Authenticity ICS mitigates · Mitigation M0804: Human User Authentication ICS uses · Malware S1045: INCONTROLLER ICS uses · Malware S1009: Triton ICS mitigates · Mitigation M0813: Software Process and Device Authentication ICS targets · ICS Asset A0017: Distributed Control System (DCS) Controller ICS detects · Detection Strategy DET0755: Detection of Change Operating Mode ICS uses · Malware S1006: PLC-Blaster ICS mitigates · Mitigation M0801: Access Management ICS mitigates · Mitigation M0807: Network Allowlists ICS mitigates · Mitigation M0930: Network Segmentation ICS targets · ICS Asset A0010: Safety Controller ICS targets · ICS Asset A0003: Programmable Logic Controller (PLC) ICS mitigates · Mitigation M0800: Authorization Enforcement ICS targets · ICS Asset A0018: Programmable Automation Controller (PAC) ICS

Mitigations

Mitigation direction

M0802: Communication Authenticity

When communicating over an untrusted network, utilize secure network protocols that both authenticate the message sender and can verify its integrity. This can be done either through message authentication codes (MACs) or digital signatures, to detect spoofed network messages and unauthorized connections.

M0804: Human User Authentication

Require user authentication before allowing access to data or accepting commands to a device. While strong multi-factor authentication is preferable, it is not always feasible within ICS environments. Performing strong user authentication also requires additional security controls and processes which are often the target of related adversarial techniques (e.g., Valid Accounts, Default Credentials). Therefore, associated ATT&CK mitigations should be considered in addition to this, including Multi-factor Authentication, Account Use Policies, Password Policies, User Account Management, Privileged Account Management, and User Account Control.

M0813: Software Process and Device Authentication

Require the authentication of devices and software processes where appropriate. Devices that connect remotely to other systems should require strong authentication to prevent spoofing of communications. Furthermore, software processes should also require authentication when accessing APIs.

M0801: Access Management

Access Management technologies can be used to enforce authorization polices and decisions, especially when existing field devices do not provide sufficient capabilities to support user identification and authentication. [1] These technologies typically utilize an in-line network device or gateway system to prevent access to unauthenticated users, while also integrating with an authentication service to first verify user credentials. [2]

M0807: Network Allowlists

Network allowlists can be implemented through either host-based files or system hosts files to specify what connections (e.g., IP address, MAC address, port, protocol) can be made from a device. Allowlist techniques that operate at the application layer (e.g., DNP3, Modbus, HTTP) are addressed in Filter Network Traffic mitigation.

M0930: Network Segmentation

Architect sections of the network to isolate critical systems, functions, or resources. Use physical and logical segmentation to prevent access to potentially sensitive systems and information. Use a DMZ to contain any internet-facing services that should not be exposed from the internal network. Restrict network access to only required systems and services. In addition, prevent systems from other networks or business functions (e.g., enterprise) from accessing critical process control systems. For example, in IEC 62443, systems within the same secure level should be grouped into a zone, and access to that zone is restricted by a conduit, or mechanism to restrict data flows between zones by segmenting the network. [1] [2]

M0800: Authorization Enforcement

The device or system should restrict read, manipulate, or execute privileges to only authenticated users who require access based on approved security policies. Role-based Access Control (RBAC) schemes can help reduce the overhead of assigning permissions to the large number of devices within an ICS. For example, IEC 62351 provides examples of roles used to support common system operations within the electric power sector [1], while IEEE 1686 defines standard permissions for users of IEDs. [2]

Change history

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 .

ATT&CK release: 19.1
Object version: 1.0
Created: May 21, 2020, 17:43 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: 18305da65faa2d5f...

Imported snapshots across ATT&CK releases (1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	May 18, 2026, 07:08 UTC (UTC+00:00)	1.0	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`18305da65faa…`

Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
N.A. October 2017

N.A. 2017, October What are the different operating modes in PLC? Retrieved. 2021/01/28
Open source URL
[2]
Omron

Omron Machine Information Systems 2007 How PLCs Work Retrieved. 2021/01/28 PLC Different Operating Modes Retrieved. 2021/01/28
Open source URL
[3]
Machine Information Systems 2007

Machine Information Systems 2007 How PLCs Work Retrieved. 2021/01/28
Open source URL
[4]
PLCgurus 2021

PLCgurus 2021 PLC Basics Modes Of Operation Retrieved. 2021/01/28
Open source URL
[5]
mitre-attack T0858
Open source URL

Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use

Analyst context for executives and security teams