NTP Slew vs Step: Why Time Correction Method Matters for Logs and Auth

A system clock that is wrong breaks more security than most people expect: Kerberos refuses tickets, certificates appear invalid, multi-factor codes fail, and log correlation across systems becomes guesswork. How the clock is corrected matters almost as much as whether it is correct.

Slew and step

Slewing adjusts the clock gradually by changing the rate at which it advances — running slightly fast or slow until it converges on the correct time. Time never jumps and never moves backwards, so it remains monotonic.

Stepping sets the clock directly to the correct value. Fast, and it can move time backwards or skip an interval entirely.

The default behaviour in most implementations is to slew small offsets and step large ones, on the reasoning that slewing a large offset takes impractically long — correcting an hour at the usual maximum slew rate takes weeks.

Why a backwards step causes trouble

Software generally assumes time moves forward. When it does not, several things break in ways that are hard to diagnose.

Log timestamps go out of order, so entries appear to precede events that caused them, and any analysis based on sequence becomes unreliable. Duration calculations produce negative values, which some code handles as an enormous positive number. Databases and distributed systems that use timestamps for ordering or conflict resolution can behave incorrectly. Scheduled jobs may run twice or be skipped entirely. Certificate and token validity checks can transiently fail or, worse, transiently succeed for something expired.

That is why critical systems — databases, authentication servers, anything doing transaction ordering — are frequently configured to slew only and to alert rather than step if the offset grows too large. A clock drifting out of range is a fault to investigate, not something to silently correct in a way that corrupts ordering.

Leap seconds are handled the same way: rather than repeating a second, large operators smear the adjustment across many hours so time stays monotonic.

What depends on accurate time

Kerberos is the strictest. It uses timestamps to prevent replay and rejects authentication when client and server clocks differ by more than a tolerance, typically five minutes. A workstation with a badly wrong clock simply cannot authenticate, and the error messages rarely say so — a classic troubleshooting scenario, and one worth recognizing alongside the protocol behaviour described under Kerberos.

Certificates have validity periods. A clock set before the not-before date or after the not-after date makes valid certificates appear invalid, which presents to users as browser warnings across every site at once — a strong hint that the problem is local rather than remote.

Time-based one-time passwords derive from the current interval, so codes fail when the clock drifts — the mechanism described under TOTP and HOTP.

Log correlation depends on every source agreeing on the time. Reconstructing an incident across a firewall, a domain controller and an endpoint is only possible if their timestamps are comparable, which is why recording each system's clock offset at collection time is part of forensic practice.

Designing the time service

Use a hierarchy rather than letting every host query the internet: a small number of internal servers synchronized to reliable external sources or to a local reference clock, with everything else synchronized to those. This gives consistency across the estate, which matters more for correlation than absolute accuracy does.

Configure at least three or four upstream sources so a single bad source can be outvoted — the algorithm is designed to reject an outlier only if it has enough peers to identify one.

Treat NTP as a security-relevant service. It is unauthenticated by default, so an attacker able to manipulate time can expire or un-expire certificates, break authentication, or shift log timestamps to frustrate an investigation. Restrict which servers clients may use, block outbound NTP to anything else, and use authenticated time synchronization where the environment supports it.

Block inbound NTP queries to servers that do not need to answer them, since an open NTP server is a reflection amplifier — the abuse described under NTP amplification. Monitor offset on every host and alert when it exceeds a threshold; a machine drifting steadily is usually a failing clock or a lost synchronization source, and you want to know before Kerberos starts failing.

Exam angles

Distinguish slewing (gradual rate adjustment, monotonic, used for small offsets) from stepping (direct set, can move backwards, used for large offsets). Know that backwards time breaks log ordering, scheduling and distributed consistency, which is why critical systems slew only. Recognize Kerberos clock skew tolerance, certificate validity and TOTP as the authentication dependencies on accurate time, and know that NTP needs authentication and access restriction to be trustworthy.