AN1887: Analytic 1887
Monitor ICS management protocols for functions that change an asset’s operating mode. Monitor device application logs which may contain information related to operating mode changes, although not all devices produce such logs. Monitor alarms for information about when an operating mode is changed, although not all devices produce such logs.
Analyst context for executives and security teams
This analytic is about watching for changes to an ICS asset’s operating mode. For executives and operations leaders, that matters because mode changes can affect how industrial equipment behaves, who can control it, and whether normal production or safety processes remain reliable. The decision value is not that this object proves malicious activity; it highlights a control point where security and operations teams should know whether they can see, explain, and validate mode changes in their environment.
Executive priority
Treat operating-mode visibility as an operational resilience and incident-readiness question. Leaders should ask: which critical ICS assets can change operating mode, which protocols or systems expose that change, who is authorized to perform it, and whether the SOC or operations team receives usable evidence when it happens. This is also useful for compliance and audit evidence where organizations must demonstrate monitoring of changes to critical operational assets.
Technical view
ATT&CK’s supplied guidance is limited to monitoring ICS management protocols, device application logs, and alarms for functions or events related to operating mode changes. SOC, OT security, and incident response teams should validate whether those three evidence sources exist for relevant assets, whether mode-change events are timestamped and attributable where possible, and whether alarms or logs are normalized into the monitoring workflow. Because no platforms, tactics, relationships, or detailed detection logic are supplied, local asset knowledge and engineering input are required to define normal versus suspicious mode-change behavior.
Likely telemetry
- ICS management protocol traffic showing functions that change an asset’s operating mode
- Device application logs that record operating mode changes, where supported by the device
- Alarm records indicating an operating mode change, where supported by the device or control system
- Asset inventory or engineering documentation needed to identify which devices support operating mode changes and which evidence sources are available
Detection direction
- Confirm which ICS management protocols in the environment can indicate operating mode changes and whether that traffic is monitored at the right network points.
- Validate that device application logs and alarms actually record mode changes; ATT&CK notes that not all devices produce these logs.
- Tune monitoring around expected operational workflows so planned maintenance, commissioning, or operator-driven changes do not create excessive false positives.
- Prioritize critical assets where an unexplained operating-mode change would have production, safety, or incident-response significance.
- Document blind spots where devices do not log mode changes or where protocol monitoring is unavailable.
Mitigation priorities
- Start with asset and process ownership: identify critical ICS assets, their valid operating modes, and who is authorized to change them.
- Ensure monitoring architecture can capture relevant ICS management protocol traffic, device logs, and alarms where available.
- Integrate mode-change evidence into SOC or OT operations triage procedures with clear escalation paths to engineering and incident response.
- Use change management and maintenance records to distinguish approved mode changes from events requiring investigation.
- Track evidence availability as a readiness gap where devices or systems cannot produce the logs or alarms described by ATT&CK.
Analyst notes and limits
This is a detection analytic in the ICS ATT&CK domain with no supplied tactics, platforms, relationships, or official detection logic beyond monitoring guidance. The strongest use is as a validation checklist for OT monitoring coverage around operating-mode changes rather than as a ready-to-deploy detection rule.
The supplied ATT&CK fields do not identify specific platforms, protocols, devices, adversaries, or related techniques, and they do not provide a formal detection query. Any assessment of coverage, severity, or suspiciousness depends on local ICS architecture, device capabilities, operational procedures, and available telemetry.
Analytic 1887
Monitor ICS management protocols for functions that change an asset’s operating mode. Monitor device application logs which may contain information related to operating mode changes, although not all devices produce such logs. Monitor alarms for information about when an operating mode is changed, although not all devices produce such logs.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | eccec40a84f6… |
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-attack AN1887Open 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.