Have you ever experienced unexplainable changes to your Windows Servers system time before? We sure have! And Microsoft has recently changed their recommendation on Secure Time Seeding which seems to be the root cause for these strange behaviors as described here.
Microsoft has identified potential timekeeping issues in Windows Server OS caused by the Secure Time Seeding (STS) feature—a heuristic-based system that uses SSL/TLS metadata to correct large time errors. While STS can improve time reliability in some environments, it has also been linked to erratic system time behavior in others, including severe time jumps.
- What is STS?
STS uses SSL/TLS metadata to detect and correct significant clock drift. It’s enabled by default in Windows Server 2016, 2019, and 2022—but disabled by default in Windows Server 2025 following customer feedback. - What’s the issue?
Some deployments reported unexpected, large time shifts when STS is active—sometimes corrected automatically, sometimes not. These time errors can disrupt critical services, especially in time-sensitive workloads. - Who is affected?
These issues appear sporadically and are environment-specific, making them difficult to reproduce or predict. However, they affect systems where STS is enabled, regardless of whether problems have previously occurred. - Recommended action:
Microsoft strongly recommends disabling STS on all Windows Server machines, especially for:- ADDS domain controllers
- Servers with time-sensitive applications
- VM hosts
- Any workload relying on accurate system time
Even if your environment hasn’t encountered STS-related problems, preemptive mitigation is advised.
Settings to disable STS:
Disabling (or enabling) STS requires administrators to modify settings on the target machines, either in the registry setting or in the group policy and reboot those machines.
| Group Policy setting | Local setting |
|---|---|
| Path: Computer Configuration\Administrative Templates\System\Windows Time Service Group Policy: Global Configuration Settings Setting: UtilizeSslTimeData Values (Reboot required): 0 = STS disabled 1 = STS enabled For more information, see Windows Time service tools and settings. | Back up existing settings before making any registry changes. Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\ConfigValue Name: UtilizeSslTimeDataValue Type: REG_DWORDValues (Reboot required): 0 = STS disabled1 = STS enabledFor more information, see Windows Time service tools and settings. Command to disable the STS local setting in the registry: reg.exe add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config" /v "UtilizeSslTimeData" /t REG_DWORD /d 0 /f |
Ensuring time is kept correctly
Now is also a good time to ensure NTP is in working order and configured accordingly. By default, all computers and devices on a domain synchronize system time using the domain hierarchy. Domain members synchronize time with domain controllers, which in turn synchronize time with the domain controller running the PDC emulator role.
But do you know where the PDC emulator role is getting its time from? It may be simply trying to synchronize to itself, in which case the Windows Time Service should be throwing a warning with event ID 12 in the event log.
Microsoft recommends configuring the PDC emulator to synchronize time directly with an external time source, or alternatively, have it synchronized to another secure internal device, which in turn syncs with an external time service (for example, a gateway router).
There’s loads more information and time synchronization recommendations in Microsoft’s own article which I highly recommend reading.
Be sure to test changes slowly first before applying this to all servers (remember it requires a full reboot), and confirm you have proper NTP configurations in place.
