DC0108: Device Alarm
This includes alarms associated with unexpected device functions, such as shutdowns, restarts, failures, or configuration changes
Analyst context for executives and security teams
Device Alarm is an ICS ATT&CK data component for alarms tied to unexpected device behavior such as shutdowns, restarts, failures, or configuration changes. Its value is operational: these alarms may be one of the earliest pieces of evidence that a cyber or operational event is affecting equipment state, reliability, or configuration integrity.
Executive priority
For security and operations leaders, the priority is to confirm that device alarms are treated as security-relevant evidence, not only maintenance noise. This data component supports incident triage, operational resilience decisions, compliance evidence around monitoring, and cyber-physical risk management where device changes or failures could affect safety, production, or service continuity.
Technical view
SOC, IR, and OT teams should validate whether device alarm records are collected, retained, time-synchronized, and available for investigation. Because ATT&CK provides no specific platform, tactic, detection logic, or relationship context for this object, teams should map local alarm sources to critical assets and determine which alarms represent unexpected shutdowns, restarts, failures, or configuration changes. Detection engineering should focus on correlation with asset criticality, maintenance windows, change records, operator actions, and other telemetry rather than treating every alarm as malicious.
Likely telemetry
- Device alarm/event logs from ICS or OT monitoring systems
- Alarms indicating device shutdown, restart, failure, or unexpected state change
- Configuration change alarms or related change notifications
- Timestamped asset identifiers, device names, zones, or process areas associated with alarms
- Maintenance, operator action, or change-management records used to explain expected alarms
Detection direction
- Validate that device alarms from critical operational assets are actually ingested into the monitoring or investigation workflow.
- Tune alerting around unexpected device functions, especially when alarms occur outside approved maintenance or change windows.
- Correlate alarms with configuration-change evidence, operator activity, asset criticality, and operational context to reduce false positives.
- Watch for blind spots where alarms remain only in engineering workstations, HMIs, controllers, historians, or vendor tools and are not forwarded to security monitoring.
- Ensure time synchronization and retention are sufficient for incident response reconstruction.
Mitigation priorities
- Prioritize reliable collection and preservation of alarms from devices whose shutdown, restart, failure, or configuration change could affect operations.
- Define which device alarms require security review versus routine maintenance handling.
- Integrate alarm review with change-management and incident-response procedures so unexpected configuration or availability events are escalated consistently.
- Use asset criticality to sequence monitoring improvements before expanding to lower-risk devices.
- Periodically test whether alarms are generated, retained, and visible to both OT operations and security responders.
Analyst notes and limits
This object is a data component, not a technique. Its main decision value is helping teams verify whether they have usable evidence for unexpected ICS device behavior. The supplied ATT&CK fields do not identify specific platforms, tactics, related techniques, or detection analytics, so local asset architecture and alarm sources are required to make this operational.
Official detection guidance and relationship context were not supplied. No platform-specific, vendor-specific, attribution, exploitation, or coverage claims can be made from this object alone.
Device Alarm
This includes alarms associated with unexpected device functions, such as shutdowns, restarts, failures, or configuration changes
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 | 2.0 | Current bundle | b9d8e386e0cb… |
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 DC0108Open 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.