If the MissionUtils portion depends on the due key in the mission table, I'd recommend moving the if Game.time < mission.due portion into FailedWhenOverdue. Additionally, is there any validation to determine the mission status is a non-complete state, i.e. checking for the current state to be ACTIVE?

Separately, I'd recommend a more descriptive name of what's being accomplished inside the FailedWhenOverdue state. A verb would be appropriate here, such as TrackMissionDueState or SetupOverdueTimer. My main concern is that it's very difficult to tell what's actually happening inside the function, as well as whether the function is appropriate to call multiple times (or that it has to be called post-load). Both of the proposed name changes are directive, and the latter indicates that it's registering a timer (which is itself transient state and therefore has to be restored when loading a saved game).

This looks good to me, thanks for reducing the amount of duplicated functionality in the mission modules!

A potential extension to this functionality is for the mission module which registered the timer to receive a callback when one of its missions fails for being overdue (I suspect this would allow the other mission modules to hook their custom logic into the function). I have a prototype which enables that sort of message-passing in a branch I'm working on, but it's unlikely to make this release window.