Compliance Risk: System Time Changes on Windows 11 Affecting Chromeleon Audit Logs

Repeated time or time zone changes on Windows 11 can be caused by Windows Time service behavior, including Secure Time Seeding (STS), and by any configured NTP/domain time sources. For regulated environments, time must be tightly controlled and traceable.

To investigate and then restrict time changes, proceed in three parts: root-cause analysis, correction of time source behavior, and hardening against further changes.

1. Investigate where time changes come from

a. Check Windows Time (W32Time) activity

• Open Event Viewer → Applications and Services Logs → Microsoft → Windows → Time-Service.
• Review:
  • Event 259 (NTP Client Provider Periodic Status) to see which NTP servers or sources are being used and which one is chosen as reference.
  • Event 261 (System Time is set) to see every instance where system time was changed via SetSystemTime API.
• Alternatively, run in an elevated Command Prompt:
  • w32tm /query /peers to list configured time sources.
  • w32tm /query /configuration /verbose to see full W32Time configuration.

b. Correlate with Chromeleon audit trail

• Match timestamps from Event 261 with the Chromeleon audit trail entries that show time/time-zone changes. This will confirm whether Windows itself (W32Time/STS/NTP) is changing the time versus another application or user action.

c. Check for Secure Time Seeding (STS)

• STS uses SSL metadata to seed time and can reset the clock when no proper NTP/AD time is available. This is known to cause time reverting or jumps if SSL metadata is stale.
• If the environment sometimes has limited or no internet/SSL traffic (for example, isolated lab networks), STS can cause unexpected time changes based on old SSL timestamps.

2. Correct Windows time behavior

a. Reset W32Time state and force sync to the intended time source If the device should follow a specific NTP server or domain hierarchy, clear the W32Time state and resync:

1. Open an elevated Command Prompt and run:

net stop w32time
w32tm.exe /unregister
w32tm.exe /register
net start w32time
w32tm.exe /resync /force

2. Verify with:

w32tm.exe /query /status /verbose
w32tm.exe /query /peers

Ensure the peers list and chosen time source match the approved lab time source.

b. Consider disabling Secure Time Seeding (STS) if not needed In tightly controlled, regulated environments where time must come only from an approved NTP/AD source, STS can be a risk because it may adjust time based on SSL metadata.

To disable STS on the affected systems:

1. In an elevated Command Prompt:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config /v UtilizeSslTimeData /t REG_DWORD /d 0 /f

2. Restart the computer.
3. After restart, force a resync:

net start w32time
w32tm.exe /resync /force

With STS disabled, Windows Time will use NTP/AD time only. This reduces the chance of unexpected time jumps due to SSL-based seeding.

Note: To re-enable STS later, set UtilizeSslTimeData back to 1 and restart.

c. Ensure a single, approved time hierarchy For compliance and forensic integrity:

• Configure all lab PCs to use the same, approved NTP source (for example, a validated internal NTP server or domain controller) and document it.
• Avoid mixing multiple independent time sources (internet NTP, domain NTP, device-specific time sync tools) on the same machine.
• Monitor time drift and log time source changes centrally, as recommended in LT-7 (Use approved time synchronization sources).

3. Hardening and operational controls

a. Restrict who can change time and time zone

• Use local or domain Group Policy to restrict “Change the system time” and “Change the time zone” rights to a limited, audited admin group.
• Ensure standard lab users and Chromeleon operators do not have these rights.

b. Monitor and document time changes for audits

• Regularly export and archive:
  • Time-Service logs (including events 259 and 261).
  • System event logs related to time changes.
• Implement monitoring/alerts for:
  • Any Event 261 (System Time is set) outside of planned maintenance windows.
  • Significant time drift (for example, >5 seconds) compared to the approved NTP source.

c. Validate BIOS/RTC and hardware

• Confirm the BIOS/UEFI clock is correct and stable.
• Ensure no hardware issues (for example, RTC battery failure) are causing time resets.

4. Summary for compliance

• Use one approved time source (NTP/AD) for all lab systems.
• Disable Secure Time Seeding if the environment is isolated or if SSL-based seeding is not desired.
• Reset W32Time state and force resync to clear stale time metadata.
• Lock down time-change privileges and continuously monitor time changes via event logs.
• Maintain documentation and evidence of time configuration and monitoring for regulatory audits.

These steps will help identify the root cause of the time changes, prevent unintended system time adjustments, and provide the traceability required for Health Canada and similar regulatory inspections.

References:

• Windows computer clock resets to a previous date and time
• Secure Time Seeding recommendations for Windows Server
• Windows Time for Traceability
• Logging and Threat Detection
• Set time, date, and time zone settings in Windows
• Daylight saving time help and support