What safety standards require watchdog timers, and what do they mandate?

Several international safety standards explicitly require independent monitoring of program execution, and the watchdog timer is the most common mechanism to satisfy this requirement:

IEC 61508 (Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems) is the umbrella standard for industrial systems. It requires monitoring of the program sequence (execution flow) and detection of timing faults. A watchdog satisfies this by verifying that software progresses through its expected sequence within expected time bounds. For SIL 2 and above, the monitoring mechanism must be independent of the monitored software — meaning the watchdog must use an independent clock source. The IWDG's LSI oscillator satisfies this requirement because it is separate from the main system clock; the WWDG (clocked from APB1) does not fully satisfy it because a main clock failure takes down both the application and the watchdog.

ISO 26262 (Road Vehicles — Functional Safety) requires software execution monitoring for ASIL B and above. The watchdog mechanism must be independent of the monitored software, and the monitoring must cover both temporal (too slow or too fast) and logical (correct sequence) aspects of execution. For ASIL C and ASIL D applications, the standard often requires an external watchdog IC in addition to the internal MCU watchdog, providing a second independent fault detection path that can reset or power-cycle the MCU even if the MCU itself is completely non-responsive.

IEC 62304 (Medical Device Software — Software Life Cycle Processes) requires risk mitigation mechanisms for software failures in Class B and Class C medical devices. A watchdog reset is a standard risk control measure. The standard also requires that watchdog reset events are logged (to non-volatile memory if possible), that the system verifies correct startup after a watchdog reset (not just blind restart), and that repeated resets trigger an escalated fault response rather than entering an infinite reset loop that could mask a persistent hazard.

All three standards share common requirements: the watchdog must be started early in the boot process (before the application reaches its main loop), it must not be disableable by application software (once started), and the feeding strategy must verify meaningful application progress — not just CPU activity.