NTP basics: stratum, offset, delay and why clock skew breaks things

NTP synchronizes clocks by exchanging four timestamps with a server, estimating how far your clock is off and how long the round trip took, then choosing among several sources. A wrong clock quietly breaks certificate checks, token expiry and log correlation, which is why time is a security dependency.

Stratum in one paragraph

RFC 5905 defines stratum as distance from a reference clock. Stratum 1 is a primary server, for example one with a GPS receiver. Stratum 2 through 15 are secondary servers, each a level further away. Stratum 16 means unsynchronized, and 0 means unspecified or invalid. Accuracy generally degrades as stratum rises. Clients pull time from servers, and servers do not take time from their clients.

Offset and delay

A client records T1 when it sends, the server records T2 on receipt and T3 when replying, and the client records T4 on receipt. Then:

• Offset is half of the sum of (T2 minus T1) and (T3 minus T4).
• Round trip delay is (T4 minus T1) minus (T3 minus T2).

Offset is how far the local clock is from the server. Delay measures path cost. Asymmetric paths add error, because the formula assumes the outbound and return legs take equal time.

Choosing among servers

With several sources, NTP uses a selection algorithm with Byzantine fault detection to throw out falsetickers and keep truechimers. A cluster algorithm picks the most accurate set, and a combine step averages the survivors. The practical lesson: configure several independent servers, not one. With one source you cannot tell a good clock from a bad one.

Rate limiting and Kiss-o'-Death

Servers can reply with a stratum 0 packet carrying a four character kiss code. Clients must respond to some of them: on DENY or RSTR they stop sending to that server, and on RATE they reduce the poll interval. Codes starting with X are ignored if unrecognized.

Why this is a security issue

• Certificates. A client with a clock far in the past or future sees valid certificates as expired or not yet valid.
• Tokens and signatures. Short lived tokens, signed requests and one time codes depend on loosely agreed time.
• Logs and forensics. Events from different systems can only be ordered if clocks agree.
• Replay windows. Protocols that accept a timestamp within a window widen the replay opportunity as skew grows.

Plain NTP over UDP port 123 is not authenticated by default, which is addressed in Network Time Security for NTP.

A short checklist

1. Use at least three independent time sources.
2. Monitor offset and alert when it drifts beyond a limit you choose.
3. Make sure containers and VMs inherit a synchronized host clock.
4. Treat a sudden large clock step as an incident signal, not just a glitch.
5. Check time first when debugging unexplained certificate or token errors, with openssl s_client and your logs.

Where Safeguard fits

Safeguard does not manage this layer of your infrastructure. It scans the dependencies and SBOMs of the software you ship, uses reachability analysis to show which vulnerable code paths are actually used, and can enforce policies and gates in CI. A free scan is at gold.safeguard.sh/scan.

Quick check

Sources

• RFC 5905, Network Time Protocol Version 4

Last reviewed: 19 October 2026.