Key takeaways

  • NTPv4 (RFC 5905) is typically precise within a few tens of microseconds on primary servers and sub-millisecond for secondary servers on fast LANs. Over the internet the error is usually larger and varies with network delay.
  • Classic NTP authentication uses a shared key and an MD5 digest. Network Time Security (RFC 8915) replaces that with a TLS 1.3 key exchange on TCP port 4460 and cookies, so authentication scales without per-client state.
  • NTS authenticates time packets, but the RFC states that cryptography does not feasibly mitigate delay attacks. The defence is multiple independent sources and network paths.
  • PTP (IEEE 1588) reaches sub-microsecond accuracy on a LAN with hardware timestamping and boundary or transparent clocks. It is the tool for trading, broadcast, telecom and power systems.
  • U.S. SEC Rule 613 requires business clocks to be synchronized to NIST time, consistent with industry standards, with timestamps at least to the millisecond; FINRA Rule 6820 sets 50 milliseconds for most clocks and one second for manual events.
  • In the EU, the MiFID II clock rules (RTS 25) were repealed and replaced by Delegated Regulation 2025/1155, which applies from 2 March 2026. Its Annex IV keeps a maximum divergence from UTC of 100 microseconds for high-frequency algorithmic trading.

Why time is a security control

Ask where time matters in a company and the first answers are usually clocks on desks. The real answers are quieter. Security logs from firewalls, servers, identity providers and endpoints are merged by timestamp, and an investigation of an incident depends on that ordering being right. Kerberos tickets are rejected if clocks differ by more than a few minutes. TLS certificates and signed tokens have validity windows. Distributed databases, certificate transparency checks and many fraud controls compare times between machines. When a regulated firm records a trade, a clock error can turn a compliant record into a violation. Time is a dependency, and like DNS it is often unmonitored until an outage teaches the lesson.

Time is also an attack surface. A machine that can be made to believe it is a different time can accept expired certificates, replay old tokens, or write logs that obscure what happened. The protocols described below differ mainly in how accurate they are and how well they resist tampering.

NTP: the general-purpose workhorse

The Network Time Protocol, version 4, is specified in RFC 5905. Time comes from a hierarchy of strata: stratum 1 servers are connected to a primary reference such as a GPS receiver or atomic clock, stratum 2 servers synchronize to stratum 1, and so on to 15. Stratum 16 means unsynchronized. Accuracy degrades as the stratum rises. The RFC states that typical primary servers using modern machines are precise within a few tens of microseconds, that secondary servers on fast LANs reach sub-millisecond accuracy, and that wide-area use can show tens of milliseconds.

The on-wire exchange uses four timestamps. The client records when it sent a request, the server records when it received it and when it replied, and the client records when the reply arrived. From these the client computes offset, which is the difference between its clock and the server's, as half the sum of the two one-way differences, and round-trip delay, which is the total elapsed time minus the server's processing time. The offset estimate assumes the path is symmetric: the same delay in each direction. When it is not, the error is half the asymmetry, and the protocol cannot detect that on its own. This is why NTP over a congested or asymmetric link, such as a consumer broadband line, is less accurate than the headline numbers suggest.

Timestamps in packet headers are 64 bits: 32 bits of seconds and 32 bits of fraction. The seconds field counts from 1900, so era 0 ends in 2036 and implementations must handle the rollover. This is a known, documented property rather than a surprise, but old embedded devices have been caught by similar boundaries.

RFC 5905 supports optional authentication with a message authentication code: a key identifier followed by an MD5 digest over the header, using a shared 128‑bit key. MD5 must be supported if authentication is implemented, and the RFC does not make authentication mandatory. Shared keys do not scale to a population of clients you do not control, and MD5 is old. That is why most NTP in practice runs unauthenticated, and why NTS exists.

NTS: authenticating time

Network Time Security, RFC 8915, adds cryptographic protection to NTP's client-server mode. Its abstract describes two loosely coupled sub-protocols. NTS Key Establishment runs over TLS 1.3 on TCP port 4460 with the ALPN identifier ntske/1. The client authenticates the server with its X.509 certificate, and both sides derive keys from the TLS session. The server returns cookies, which are opaque blobs containing the session keys encrypted so that only the server can read them, so the server needs no per-client state. Then ordinary NTP packets carry extension fields: a Unique Identifier of at least 32 random bytes to bind each response to its request, a cookie, and an authenticator that holds an AEAD tag. AEAD_AES_SIV_CMAC_256 is mandatory to implement. The server hands back fresh cookies in each response so that a client's cookie is not reused, which limits tracking.

What does NTS protect? The packets are authentic and unmodified, replays and mismatched responses are detected, responses are no larger than requests so the server cannot be used for amplification, and extension fields can be encrypted. The RFC is plain about the limits. Delay attacks, where an on-path attacker holds a genuine packet before forwarding it, are not mitigated by cryptography, in the RFC's words; the error they cause is bounded, and using multiple sources and network paths helps. NTS stripping, where an attacker blocks the key exchange to force a fallback to plain NTP, is another risk; clients should not downgrade silently. An on-path attacker can also send forged Kiss-o'-Death packets, though NTS-KE servers see extra load as a result.

For most companies the right move is to run a small number of internal NTP servers that take time from several upstream sources, ideally including NTS-capable ones and a local GPS or GNSS receiver with a stated antenna and holdover plan, and to point every internal system at those servers. Four sources is the usual minimum so that the algorithms can outvote one bad source. Block outbound NTP from everything else so that stray devices cannot silently use another time.

PTP: when microseconds matter

The Precision Time Protocol, IEEE 1588, was designed for measurement and control systems where NTP is not accurate enough and a GPS receiver at every node is impractical. Three versions exist: 1588-2002, 1588-2008, which is not backward compatible and added profiles, IPv6, unicast negotiation and transparent clocks, and 1588-2019, which adds optional features including a security TLV for integrity checking. We read the IEEE standard's description in a Wikipedia summary because the standard itself is paywalled.

A PTP domain has a grandmaster clock, usually disciplined by GNSS, at the root. Other clocks are ordinary clocks with one connection, boundary clocks that terminate PTP on each port and re-originate it, or transparent clocks that measure the time a message spends crossing a switch and correct for it. The Best Master Clock Algorithm elects the grandmaster by comparing priority, class, accuracy and variance, using each clock's self-declared quality, not any measurement of the network. Followers compute offset from four timestamps in the same way as NTP. The difference in accuracy comes from hardware timestamping in network cards and switches, which removes the unpredictable delay of operating-system software, and from on-path correction in boundary and transparent clocks. With that support, sub-microsecond accuracy on a local network is achievable. PTP runs over UDP on ports 319 for event messages and 320 for general messages.

Industry profiles fix the options for specific uses. gPTP, IEEE 802.1AS, adapts PTP for audio-video bridging and time-sensitive networking. SMPTE ST 2059-2 is the broadcast profile, and AES67 audio-over-IP includes a compatible profile. IEC/IEEE 61850-9-3 covers power substations and IEC 62439-3 covers industrial automation. Telecom and power-utility profiles also exist; our source did not describe them, so check the standards before specifying. Our broadcast and manufacturing work uses these profiles with PTP-aware switches.

PTP is less forgiving than NTP. A single switch without PTP support in the path degrades accuracy, asymmetric fiber lengths bias the result, and a rogue device claiming to be a better clock can win the election unless ports are restricted. Secure PTP deployments pin the allowed grandmasters, limit PTP to the ports that need it, and monitor for changes of grandmaster and for large offsets.

What the regulators require

In the United States, Rule 613 under the Securities Exchange Act established the consolidated audit trail. Paragraph (d) requires exchanges, associations and their members to synchronize the business clocks used to record reportable events to the time maintained by the National Institute of Standards and Technology, consistent with industry standards. Timestamps must be at least to the millisecond, and finer where systems already use finer increments. Exchanges and associations must evaluate the clock synchronization standard annually and consider shortening it. The rule text itself sets no number of milliseconds for the clock tolerance.

The number comes from FINRA Rule 6820. Business clocks must be within 50 milliseconds of the NIST atomic clock, which includes the difference to NIST, transmission delay from the time source and clock drift. Clocks used solely for manual order events or allocation report times must be within one second. Clocks must be synchronized each business day before market open, then checked and resynchronized as needed. Firms must document the procedures, keep a log of synchronization times and results, including every instance of drift beyond the tolerance, retain the logs for at least five years, certify to FINRA, and report violations to the plan processor and FINRA.

In the European Union, the old MiFID II technical standard, Delegated Regulation 2017/574 (RTS 25), required clocks traceable to UTC. For trading systems with gateway-to-gateway latency of one millisecond or less, venues had to stay within 100 microseconds of UTC with granularity of 1 microsecond or better, and members engaged in high-frequency algorithmic trading had the same 100‑microsecond limit. That regulation was repealed by Delegated Regulation (EU) 2025/1155, and its clock provisions, Articles 11 to 16, apply from 2 March 2026. Annex IV Table 2 keeps 100 microseconds as the maximum divergence for high-frequency algorithmic trading, now with granularity of 0.1 microseconds or better, and 1 second for voice and certain request-for-quote systems. Approved publication arrangements and consolidated tape providers must record to 1 millisecond or better and stay within 1 millisecond of UTC. Article 16 requires traceability to UTC, documentation, identification of where timestamps are applied and an annual review.

Building a defensible time service

  • Define the requirement per system. A file server needs seconds, a log pipeline needs milliseconds, a trading gateway may need microseconds. Different tiers can use different protocols.
  • Use more than one source. Combine GNSS with at least a few independent network sources. A single GPS receiver is vulnerable to jamming and spoofing, which are real for antennas on rooftops, and a holdover oscillator buys time to react.
  • Authenticate where you can. NTS for the upstream links, restricted PTP ports and pinned grandmasters internally, and no NTP from untrusted clients to your servers.
  • Monitor offset, not just uptime. Alert on offset, stratum changes, loss of the reference and unexpected grandmaster changes. Keep the data; regulated firms must be able to show it.
  • Document traceability. Regulations ask you to show a chain from the business clock to a recognized reference such as NIST or UTC, and to say where the timestamp is applied in the system.
  • Test the failure. Disconnect the antenna and confirm what the clients do, how soon alerts fire and how long holdover lasts.

None of this is exotic engineering. It is a short list of controls, usually missing because time is nobody's job. Clayton Cybernetics designs time distribution as part of network and datacenter work, from GNSS-disciplined NTP and NTS to PTP for trading and media networks, and writes the monitoring and evidence that regulated clients are asked for.

Sources

This article is general technical information, not legal advice or a compliance opinion. We read the RFCs and regulations through a summarizing fetch tool; RFC 5905 was read only to about section 9, so its security section was not read, and RFC 8915 was read in summary. IEEE 1588 is paywalled, so we used a Wikipedia summary for it. The Rule 613 text was read through an eCFR fetch, and the 2025/1155 Annex IV tables were read in a second part of the fetched text; confirm the exact thresholds and categories in the regulation and in ESMA guidance. The statement that the SEC rule itself sets no millisecond figure and that FINRA 6820 supplies 50 milliseconds follows the fetched texts; the CAT NMS Plan may set other detail. The advice on GNSS, holdover, monitoring and design is general engineering knowledge, not quoted from the sources listed. Last reviewed .

Keep reading

Need help with this?

Cloud cost review and management, without compromising on quality or security.

Cloud Management