M0815: Watchdog Timers
Utilize watchdog timers to ensure devices can quickly detect whether a system is unresponsive.
Analyst context for executives and security teams
Watchdog timers matter because they help industrial devices recognize when they have become unresponsive and recover more quickly. In practical terms, this mitigation is about operational resilience: if a denial-of-service condition or malformed request causes an ICS device to stop responding, a properly implemented watchdog can reduce the time the process is left without expected device behavior.
Executive priority
Treat this as a cyber-physical resilience control rather than a pure security monitoring control. Leaders should ask which critical controllers, field devices, or supporting systems have watchdog functionality enabled, tested, and documented; whether recovery behavior is safe for the process; and whether this evidence supports IEC 62443-4-2:2019 CR 7.2 compliance expectations. Priority should be based on operational consequence: devices whose unresponsiveness could affect safety, production continuity, or incident recovery should be reviewed first.
Technical view
For SOC, IR, engineering, and OT security teams, the key validation is whether watchdog timers are present, configured appropriately, and tested against device unresponsiveness scenarios. This mitigation is related to ATT&CK for ICS technique T0814, Denial of Service, where devices may become unable to send or receive requests or perform expected functions until recovery occurs. Because ATT&CK provides no detection guidance for this mitigation, teams should not assume watchdog activity is visible in standard SOC telemetry; they should confirm what engineering systems, device logs, alarms, or maintenance records show when a watchdog triggers or a device reboots.
Likely telemetry
- Device health/status indicators showing unresponsive or recovered states
- Controller, PLC, RTU, or embedded device event logs where available
- Engineering workstation or asset management records showing watchdog configuration
- Process historian or SCADA alarms indicating communication loss, device fault, restart, or recovery
- Network monitoring showing loss and restoration of device communications
Detection direction
- Validate whether watchdog-triggered resets or recoveries generate observable alarms or logs in the local OT environment.
- Correlate device unresponsiveness, communication loss, and restart/recovery events with possible Denial of Service conditions rather than treating them only as reliability incidents.
- Tune triage to distinguish planned maintenance, power events, firmware updates, and normal device restarts from unexpected watchdog activations.
- Identify blind spots where field devices do not export logs, where SCADA alarms only show communication loss, or where SOC tools lack OT context.
- Use relationship context to prioritize monitoring around assets where unresponsiveness would materially affect operations.
Mitigation priorities
- Inventory critical ICS devices and determine whether watchdog timer capability exists and is enabled.
- Review configuration against vendor and engineering requirements, with attention to safe recovery behavior for the physical process.
- Test watchdog behavior in controlled conditions before relying on it for production resilience.
- Document configuration and test evidence for operational governance and IEC 62443-4-2:2019 CR 7.2 alignment.
- Integrate watchdog-related alarms or recovery events into incident response runbooks so OT, SOC, and engineering teams know when to investigate potential DoS-related disruption.
Analyst notes and limits
This is a mitigation object, not an adversary behavior. Its value is in reducing dwell time of unresponsive device states and improving recoverability when DoS-like disruption occurs. The most important local question is not whether the control exists on paper, but whether it is configured, observable, and safe for the process it protects.
The supplied ATT&CK object does not specify platforms, tactics, or detection guidance. It provides a brief mitigation description and one relationship to ICS Denial of Service. Local architecture, device capabilities, vendor documentation, and engineering safety analysis are required before making coverage or effectiveness claims.
Watchdog Timers
Utilize watchdog timers to ensure devices can quickly detect whether a system is unresponsive.
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 | T0814 | Denial of Service | System and process restarts should be performed when a timeout condition occurs. |
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 | 551b78043fac… |
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 M0815Open 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.