That's a valid defence, and certainly protecting against the clock being moved too far too fast is a no-brainer, but you also need to threat-model the attack: w

That's a valid defence, and certainly protecting against the clock being moved too far too fast is a no-brainer, but you also need to threat-model the attack: what are the chances of an real attacker (not a theoretical weakness) carrying out an NTP-based attack and what would they gain from it? For example an attacker who has control over your local network and can spoof NTP on it, which means it's probably already game over before you even start, can move the clock on something around and reuse an expired certificate if they've compromised the device and captured its private key... you can probably dream up some sort of scenario where this might be an issue and where all the other things they can do with that level of compromise of the system won't be easier but it's so far down on the list of other things that attackers could do that it doesn't even rate. And for the few places where clock distribution is critical, e.g. when you need to use IEEE 1588 PTP (Precision Time Protocol) you're typically running over tightly-controlled private links/networks or protocols (IEC 61850, 62439) and/or using GPS or rubidium clocks as your time source, not NTP. Or you sync using nonces, not time. Or whatever. It's just really hard to come up with a real-world scenario where this is a significant threat, and moreso one where the answer would be to run NTP over TLS rather than just using some better mechanism for the job.