Windows Security Log · Event 4616
Event 4616: The system clock was changed
The machine's clock moved. Most of these come from the Windows Time service nudging things by a fraction of a second and are pure noise. A large jump, made by a user account, is a different matter — it is one of the simplest ways to make a timeline unreadable.
Also written as Event ID 4616The system time was changed4616 time change eventsystem time changed windows log
- How oftenFires often
- Vendor calls itAudit Success
- LogSecurity
- SourceMicrosoft-Windows-Security-Auditing
What it means for you
On a personal computer
Your PC adjusted its clock. Windows does this automatically against a time server, and it also happens whenever you change the time zone or come back from sleep. It is not something to worry about on a personal machine.
For an analyst
Filter on magnitude, not on occurrence — computing the delta between the previous and new times is the only way to make this event usable, and most SIEM content skips that step and then gets abandoned for noise. Two operational notes: virtual machines produce these constantly from host time synchronisation, and on domain-joined machines a clock more than five minutes out of step with the domain controller breaks Kerberos entirely, so a large 4616 is often the explanation for a sudden burst of authentication failures elsewhere.
The fields that decide it
Everything else in the log line is context.
- Previous Time and New Time
- The clock before and after. The difference between them is the field that matters, and you have to compute it yourself.
- Subject Account Name
- Who or what changed it.
-
LOCAL SERVICEThe Windows Time service doing its job. The overwhelming majority of these events, and the ones to filter out. -
SYSTEMUsually a hypervisor integration service or a driver. Common and normally benign on virtual machines. -
A named user accountA person changed the clock. Rare, and worth an explanation, especially if the jump is large. - Process Name
- What performed the change. VBoxService, vmtoolsd and similar names are host time synchronisation; cmd.exe or powershell.exe are a person or a script.
- Magnitude of the change
- Not a field but the actual signal. Sub-second is time synchronisation; minutes or hours is either a serious clock problem or a deliberate act.
Common questions
Why does Event 4616 appear so often?
Because the Windows Time service adjusts the clock regularly to keep it in step with a time source, and each adjustment is recorded. Those changes are typically a fraction of a second and carry no information. Virtual machines produce even more, because the host synchronises the guest clock as well. Filtering on the size of the change is the only way to make this event useful.
Can changing the system time hide an attacker's activity?
It can complicate a timeline, which is the usual motivation. Events are stamped with the clock at the time they are written, so moving the clock back means new events interleave with old ones and the ordering stops meaning anything. It does not delete evidence, and centrally collected logs usually carry the collector's own receipt time, which is one good reason to forward events off the host.
Should I alert on Event 4616?
Only with a filter, or it becomes noise immediately. Two rules work well in practice: alert when the difference between previous and new time exceeds a few minutes, and alert whenever the subject is a named user account rather than LOCAL SERVICE or SYSTEM. Either alone is manageable; the raw event is not.
My clock changed and now nobody can log in. Are they related?
Almost certainly. Kerberos rejects tickets when the clock is more than five minutes away from the domain controller's, by default, so a large time change breaks domain authentication for everyone on that machine. Look for Event 4771 or 4625 starting at the same moment as the 4616. Fixing the clock resolves it immediately.
Read next
- Usually comes after Event 4771: Kerberos pre-authentication failed Kerberos pre-authentication failures, which a clock more than five minutes out of step causes across the board.
- Usually comes after Event 4625: An account failed to log on Failed logons, the visible symptom when time skew breaks authentication.
- The equivalent of Event 1102: The audit log was cleared Clearing the Security log — the direct approach to the same goal of making a timeline unusable.
- Related Event 4719: The audit policy itself was changed Audit policy changes, the other way to interfere with what the logs can tell you.
- Usually comes after Event 1058: Group Policy could not read a policy file Group Policy failures, which follow when time skew breaks the machine's authentication to a domain controller.
Mentioned by
Vendor documentation
Last reviewed 6 September 2026