DET0755: Detection of Change Operating Mode
MITRE ATT&CK DET0755: Detection of Change Operating Mode Detection Strategy details, with detection guidance, relationships and mapped CVEs.
Security context for executives and security teams
DET0755 is a detection strategy for identifying changes to the operating mode of ICS controllers. This matters because controller mode changes can enable sensitive engineering actions such as program download, turning what may look like a routine maintenance action into a potential control-system integrity and operational resilience concern.
Executive priority
Security and operations leaders should treat controller mode changes as high-value audit and incident-decision events. The key business question is whether the organization can prove when a controller was placed into a mode that permits engineering changes, who or what initiated it, whether it matched approved maintenance, and whether physical or API-based mode changes are covered by monitoring.
Technical view
ATT&CK provides no official detection text, platforms, or tactics for DET0755, but the relationship states that it detects ICS technique T0858, Change Operating Mode. SOC, OT, and IR teams should validate whether controller operating-mode transitions are observable, whether API-driven changes can be distinguished from physical key-switch changes, and whether mode changes are correlated with engineering functions such as program download and approved work orders.
Likely telemetry
- Controller operating-mode change events, where supported by the asset
- Engineering workstation or controller API communications associated with mode changes
- Physical key-switch or mode-selector state, if instrumented or logged
- Controller or engineering-function logs related to program download activity
- OT asset configuration and change-management records
Detection direction
- Baseline expected controller mode states and alert on transitions outside approved maintenance windows.
- Correlate operating-mode changes with authenticated engineering activity, work orders, and program download events.
- Tune for legitimate maintenance to reduce false positives, but require evidence of authorization and expected asset scope.
- Check for blind spots where physical key-switch changes, controller-local actions, or vendor/API-specific events are not centrally logged.
- Ensure incident responders can quickly determine whether a mode change was physical, API-driven, or otherwise unverified.
Mitigation priorities
- Prioritize governance around authorized controller mode changes, including maintenance approval and evidence retention.
- Restrict and monitor access to engineering functions that become available after a mode change.
- Apply physical access controls and key-management practices where controller modes can be changed locally.
- Ensure OT monitoring and IR playbooks include controller mode transitions as triage triggers.
- Use periodic control validation to confirm that mode-change telemetry is actually collected and reviewable.
Additional notes and limits
The material decision point is not merely whether a mode changed, but whether the organization can tie that change to an authorized operational reason. This detection strategy is especially relevant for OT environments where engineering access, physical access, and controller state changes may be monitored by different teams or tools.
The supplied ATT&CK object has no official description, detection guidance, platforms, or tactics. This take is derived from the official external reference and the stated relationship to T0858 Change Operating Mode. Local controller models, logging capability, network architecture, and maintenance processes are required to determine actual detection feasibility.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Detection of Change Operating Mode
No official description is available in the imported ATT&CK source object.
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 | T0858 | Change Operating Mode | This object detects Change Operating Mode. |
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 | 899bdf9d8bd0… |
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]mitre-attackDET0755Open 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.