Network Time in 2026: Why Your Servers Quietly Disagree About the Clock, What NTP, NTS and PTP Actually Do, and What Breaks When Drift Wins

Nobody puts time synchronisation on a roadmap. It gets attention only after something else has failed: a login that refuses valid credentials, a gateway that rejects a certificate, an incident timeline where the firewall and the application server tell two different stories about the same minute. Underneath all of it sits an assumption that is quietly false in most networks — that every machine agrees what time it is.

Why Clocks Drift in the First Place

Every server, switch and laptop keeps time with a quartz oscillator, and quartz is temperature sensitive. A typical computer crystal is accurate to somewhere between 10 and 50 parts per million. That sounds impressive until you convert it: 10 ppm is roughly 0.86 seconds of error every day, or about four minutes a year. A hot rack, a cold morning or a busy CPU changes the rate, so the error is not even consistent.

Virtualisation makes it worse. A guest operating system measures time by counting ticks it may not receive on schedule, because the hypervisor was busy running something else. Live migration moves a running machine onto a different oscillator, and a restored snapshot or a resumed instance can wake up minutes or hours behind. Drift is not a fault. It is the default state of an unmanaged network.

What Actually Breaks

The failures are rarely reported as time problems, which is exactly why they take so long to diagnose.

The last row is the expensive one. Security tooling reconstructs an attack from timestamps produced by a dozen different devices. If those devices disagree by thirty seconds, the sequence of events is a guess, and so is the conclusion about how far an intruder got.

An incident timeline is only as trustworthy as the worst clock that contributed to it.

NTP: The Protocol That Still Runs the Internet

The Network Time Protocol dates to the mid-1980s and remains, in its fourth version, the way almost everything on the internet learns the time. It works on a hierarchy of strata. A stratum 0 device is a reference clock — an atomic clock or a GNSS receiver. A server directly attached to one is stratum 1, a server synchronising from that is stratum 2, and so on down the chain.

What makes NTP clever is that it does not simply ask for the time. Each exchange records four timestamps, letting the client calculate the round-trip delay as well as the offset between the two clocks and correct for both. It polls several servers, discards outliers using an algorithm that deliberately distrusts any single source, and steers its own oscillator gradually rather than jumping. Over the public internet that yields accuracy in the low milliseconds; on a local network it is comfortably below one.

The common mistake is architectural rather than technical: letting every machine reach the public NTP pool independently. That produces inconsistent results across the estate and means nobody notices when one host silently stops synchronising. The better pattern is two or three internal time servers upstreamed to reputable sources, with everything else pointing at them.

NTS: Time That Can Finally Be Authenticated

Classic NTP has an uncomfortable property. The packets are unauthenticated UDP, so anyone able to intercept or spoof them can tell your servers whatever time they like. Moving a client backwards makes an expired certificate look valid again; moving it forwards can kill sessions and break signed requests.

Network Time Security, standardised as RFC 8915, closes that gap. It uses a TLS 1.3 handshake on a separate key-establishment port to obtain cookies, then protects the ordinary NTP exchanges with authenticated encryption. Crucially, the time packets themselves stay small, stateless and UDP-based, so the protocol scales the way NTP always did. Public NTS servers are now offered by Cloudflare, Netnod and several national metrology institutes, and chrony has supported it since version 4.0.

The other half of the story runs in the opposite direction. NTP servers have long been abused for reflection attacks, where a spoofed query returns a much larger response to the victim. Modern software disables the worst offenders by default, but plenty of forgotten appliances still answer monitoring queries from the open internet. If a device does not need to serve time to strangers, it should not be reachable on UDP port 123 from outside.

PTP: When Milliseconds Are Not Good Enough

Some workloads need far better than NTP can deliver. The Precision Time Protocol, defined in IEEE 1588 and revised in the 2019 edition, reaches sub-microsecond and often nanosecond accuracy on a local network. It gets there by moving timestamping out of the operating system and into the network interface hardware, which removes the unpredictable delay of a packet waiting in a software queue.

• A grandmaster clock is the authoritative source, usually a rack appliance disciplined by GNSS with an internal oscillator that holds accuracy if the satellite signal is lost.
• Boundary clocks are switches that terminate PTP on one side and regenerate it on the other, so error does not accumulate hop after hop.
• Transparent clocks measure how long a packet spent inside the switch and write that residence time into the message for the receiver to subtract. Industry profiles then tune the protocol for telecom, substations, broadcast or the data centre.

PTP used to mean specialist hardware and a specialist to run it. That changed when the major cloud providers began exposing precision time to ordinary instances, delivering microsecond-level accuracy to virtual machines that previously made do with best-effort NTP. Trading platforms, media production, industrial control and databases that order transactions by timestamp are the obvious beneficiaries.

The Compliance Angle Most Teams Miss

For regulated businesses, clock accuracy is a written obligation, and the tolerances are tighter than most infrastructure delivers by accident.

• European financial markets. The MiFID II standard on clock synchronisation requires timestamps traceable to UTC, within one millisecond for many venue activities and 100 microseconds for high-frequency trading.
• United States market participants. Consolidated audit trail rules require business clocks to stay within 50 milliseconds of the national time standard, with documented evidence.
• Everyone else. Security frameworks and cyber insurance questionnaires now ask whether log sources share a common, authenticated time source. Answering yes without evidence is a finding waiting to happen.

The word that recurs is traceable. It is not enough for the clocks to agree with each other; they must demonstrably agree with a recognised standard, and that demonstration has to be recorded.

Leap seconds are being retired by 2035, but until then the rule is simple: never mix a time source that smears the extra second across the day with one that does not, or the two will disagree by up to a full second.

A Practical Checklist

• Designate internal time servers. Two or three, upstreamed to at least four diverse external sources, with everything else pointed at them and nothing else.
• Use NTS where the client supports it, and prefer chrony on anything other systems depend on.
• Monitor offset, not reachability. A server can answer on port 123 while being badly wrong.
• Do not forget the appliances, log in UTC, and block inbound NTP for devices with no reason to serve time to the internet.

En resumen

Time synchronisation is cheap to get right and quietly expensive to get wrong. Most organisations need nothing more exotic than a pair of properly configured internal NTP servers, authenticated upstream sources, and monitoring that measures how far each clock has actually wandered. A smaller set of workloads — trading, broadcast, industrial control, precision databases — need PTP and the hardware behind it. What nobody can afford is the current default: a hundred devices guessing independently, and an incident report built on timestamps nobody can defend.