Must NTS be proven end to end?

Published 12 August 2026 — measurements from the sealed campaign of 7 August 2026, direct checks of 12 August.

NTS (RFC 8915, the RFC text) authenticates the exchange between a client and its time server. The question this page asks is not whether it works — it does — but how far it reaches. A server that hands you signed time gets its own time from someone. What do you know about that link?

We looked for the answer in our own measurements and did not find it. What follows describes what measurement establishes, what it cannot, and why the gap between the two is the real subject.

Ten servers announce a security they do not deliver

A starting point with no inference: in the campaign of 7 August, ten endpoints present a valid NTS-KE from all six of our observation networks and never deliver authenticated time. The handshake succeeds, the certificate is good, and the time does not come.

No institution is among them. They are two servers of a single operator, a hosting provider, and six pool members spread across the United States, Germany, the United Kingdom and the Netherlands. The interesting fact is not who they are, it is that announcing NTS and delivering it are two distinct things, and that only a measurement of the time itself separates them. A check that stops at NTS-KE validates all ten.

You can verify this on any server with an NTS validator, which tests whether time is actually obtained and not merely whether the handshake completes.

The queried name is part of the service

Before climbing higher up the chain, an obstacle that cannot be worked around.

$ chronyd -Q "server ptbtime1.ptb.de iburst nts"
System clock wrong by 0.002035 seconds (ignored)

$ chronyd -Q "server ntp1.de-cix.net iburst nts"
TLS handshake with [2001:638:610:be01::108]:4460 (ntp1.de-cix.net) failed :
  The certificate is NOT trusted. The name in the certificate does not match the expected.
No suitable source for synchronisation

What measurement establishes, and where it stops

The campaign of 7 August — published in the measured European registry — retains 265 servers delivering authenticated time. Their upstream breaks down as follows:

Among those 86 chains, eleven — 12.8% have an upstream from which we ourselves obtain authenticated time.

The refid cannot designate an IPv6 address

That first figure covers a sub-sample, and the sub-sample must be named. The refid field of RFC 5905 is four bytes: an IPv6 address does not fit. A server following its upstream over IPv6 therefore puts a four-byte digest there, which looks like an IPv4 address without being one. Resolving refids by plain address matching amounts to seeing only the IPv4 chains.

Part of it can be recovered: the digest can be recomputed for any IPv6 address we already know. With the 3,108 IPv6 addresses in our inventory, 70 further chains become nameable, 48 of which have an upstream that serves NTS.

This dehashing is reproducible without us: the refid is MD5(IPv6 address)[0:4], written as a dotted quad. It requires neither our database nor our resolution table — only the address. Here are the upstreams to which the most NTS chains attach, with theirs. The column counts chains recovered by dehashing, not the machine's total number of followers — which is far higher, and which the sealed file gives directly.

Of the 70 recovered chains, 68 point to an upstream we can name. The other 2 target a machine covered by our anonymity policy: they are counted, not named, and their address is not published.

The gap between the two rows is the result: it does not measure the ecosystem, it measures our own blind spot. A naive refid resolution underestimates by a factor of three the chains whose upstream is authenticable, and that underestimate falls entirely on IPv6. It shrinks as our address inventory grows — one can only dehash what one already knows the address of.

In both cases the figure remains an upper bound, and the point bears repeating: we measure that the upstream offers NTS publicly, never that the link uses it. None of these chains is proven authenticated end to end; they are merely the only ones that could be.

The complement is not "in the clear". For the remaining 62.2%, the upstream's NTS is not established — which covers three situations no external measurement can separate: an upstream that does not offer NTS, one that offers it to a closed list we are not on, and one that offers it under a name we did not query.

The right question is not encryption, it is the exposed segment

Since the transport of the upstream link is undecidable, let us measure what is decidable: where that link runs. Across the 86 nameable chains:

IPv6 chains are slightly less exposed — 87.1% against 94.2% — and the gap has an explanation: they attach more followers to dual-stack institutional roots, some of which sit with the same operator. The order of magnitude does not move: nine chains out of ten have their upstream link on the public internet, however they are resolved.

Domain and prefix are public facts: this split requires no inference. And it completely changes how one reads a case we know well.

The French root, and its forty followers

ntp-p1.obspm.fr is a stratum 1 synchronised to UTC(OP), the national reference. Its official page announces NTS on the secondary server since 4 August 2026, and says nothing about the primary — an informative silence, in a document that documents NTS wherever it exists. It also states its intended use, on its official page (in French): that this primary "must only be used to synchronise secondary servers serving important sites".

We measure forty servers following it, across five countries, six of which deliver authenticated time to the world: the Observatory's own secondary, the Dutch NTS pool, a French operator, and three of ours.

That architecture is not at fault: a primary serving its own operator's secondaries is exactly in its role, and the Observatory documents it as such. What the figure shows lies elsewhere — only one of those six is on its network. The link ntp.obspm.fr → ntp-p1.obspm.fr crosses nothing: the architecture is perfectly defensible. The link ntp9.rdem-systems.com → ntp-p1.obspm.fr crosses the public internet. The same absence of authentication, two unrelated risks — and that is precisely why "doing NTS" is not an answer by itself.

A stratum 1 without NTS is not a defect

This needs saying, because the easy reading is the opposite. A primary server is a reference appliance: a clock disciplined by a physical signal, designed to serve a handful of secondaries. That sizing dates from a time when links would not allow such a machine to be exposed to all comers, and the constraint has not gone away: NTS adds a TLS endpoint, a certificate chain to renew, key management. It is an operational object foreign to a clock. Its absence on a primary may come down to hardware, to a schedule, to a security policy — we do not know, and we do not guess.

The Observatory's usage rule is therefore not bureaucratic restriction: it describes what the machine exists for. The defect is not at the root. It is with the 94% that lean on it across the public internet, often outside the stated use.

The mirror figure: a root that does serve NTS

The same survey holds the opposite case. ptbtime1 through ptbtime4.ptb.de, operated by the German metrology institute, do serve NTS and are followed by ninety-four servers we measure, nine of which serve authenticated time themselves.

Both columns count the same population on both rows: every server whose refid designates that root, then those among them that serve authenticated time themselves. For ptbtime1, both families are combined — its IPv4 address and the digest of its IPv6. This is not a methodological asymmetry: ntp-p1.obspm.fr has no AAAA record, it is IPv4-only, so a single refid counts it completely; ptbtime1 is dual-stack and needs two.

Same structure, opposite answer. This settles the previous section's question without imputing motives: a national metrology institute has done it, so it is possible — and those who have not may face constraints we do not know about. We measure what is served, not what explains it. Authenticating a root is a property of the actors and their means, not of the protocol.

Eight questions these measurements raise

1. Who benefits from the signature?

A client obtains signed time from a server whose upstream is unverifiable. Who is reassured: the client, or the operator who can now write "NTS" on their page?

2. What does an audit verify when it ticks "NTS"?

The auditor observes the last hop. They cannot see beyond — we have just shown that nobody can. The tick therefore attests the existence of encryption, not the provenance of a time. That is a distinction UTC traceability auditing must carry explicitly.

3. Is sovereignty measured at the last link?

A French server, authenticated, whose source is out of sight. If sovereignty means controlling the chain, what does a sovereign last hop mean?

4. What is traceability worth when one link is unverifiable?

Traceability to UTC requires a documented, unbroken chain. Ours stops at the first hop. Regulatory frameworks ask for traceability to UTC, not to "a server that says it comes from UTC".

5. Why are those who hold UTC the last to serve NTS?

The question is uncomfortable and the answer is technical, not moral: see the previous section. It is worth asking so that nobody answers it with an accusation of bad faith.

6. And us?

Three of our servers follow ntp-p1.obspm.fr across the public internet — hence beyond the use its page describes, and that is our choice, not theirs. The figure shows one instant only: our twelve secondaries mix NTP and NTS sources, and at the time of the survey nine of them had selected an upstream that does serve NTS. The refid shows only the peer selected at that second, not the configuration — and that caveat applies to every server on this page, not only ours. They are secondary servers, and they serve authenticated time while leaning on an upstream we cannot audit. We do no better than what we measure in others, and that is what makes the other seven questions publishable.

7. What is the advice "use the pool with NTS" worth?

That configuration does not exist for pool.ntp.org, and precision matters here: one of its zones returns a different machine on each resolution, run by a different operator, and no certificate can cover that without giving every volunteer the power to impersonate the others. How many guides recommend it anyway?

NTS pools do exist, however — ntppool1 and ntppool2.time.nl are among the most followed upstreams in our survey. They solve the problem differently: a central NTS-KE endpoint, which then redirects the client to a time server. The difference is therefore not "pool or not", it is who holds the key.

8. If the last hop is enough, why demand a sovereign stratum 1?

And if it is not enough, then serving NTS at stratum 2 is a half-measure — ours included. We have no settled answer. We have an observation: of the 265 NTS servers measured, 75 are stratum 1 with no network upstream at all. The only fully auditable chains are the ones that have no chain.

9. And what does a GNSS stratum 1 authenticate?

We have just written that the only fully auditable chains are those with no chain. That is wrong, and it must be said on the same page. A GNSS-disciplined stratum 1 also has an upstream: a radio signal, received without authentication by almost every receiver in service. A forged signal can be built with commodity hardware, and the server then serves it over NTS, signed, to all its clients.

Galileo answers this with OSNMA, which authenticates the navigation message. But a receiver that does not implement it — the vast majority of the installed base — gains nothing from it, and nothing in the NTP packet tells you whether the stratum 1 answering you has it enabled. The question of this page therefore moves one notch further: authenticating the last hop says nothing about the upstream, and authenticating the network upstream says nothing about the physical source. We do not measure OSNMA today, and we know of no public dataset that does.

The two positions, and what will settle them

The last hop is enough. The realistic attacker sits on the path between client and server, not inside a metrology institute's network. And plurality of sources protects better than a signature: chrony discards a lying source by cross-checking, whatever the protocol. A single-source configuration remains the wrong configuration, NTS or not.

End to end is required. Otherwise an authentic signature certifies a time whose provenance is unverifiable, and auditability stops at the first hop — which is precisely what a compliance framework asks you to demonstrate.

We lean towards a third formulation: the question is neither "NTS or not" nor "end to end or not", but which segment is exposed, and to whom. It is the only one that measures without inference.

Method, limits, data

• A refid shows only one source, at the instant of the probe. A server configured with four sources exposes only one: our follower counts are lower bounds, never inventories.
• An IPv6 upstream has no address in the refid, but a four-byte digest that looks like an IPv4 address. We resolve those against a dictionary of known addresses, and collisions remain possible.
• Unreachable does not mean broken. An ACL and an absence of service are indistinguishable from outside.
• The perimeter is "publicly observable NTP servers", not "all NTP servers".
• Measured from six distinct autonomous networks. Sealed, signed and timestamped campaign: measured European registry, world map. Data in CSV and JSON under CC BY 4.0.

Check for yourself

What you can verify stops where our measurement stops — at the last hop. Here are the tools; beyond that, nobody sees.

• check whether authenticated time is actually delivered — or whether only the NTS-KE handshake completes.
• diagnose a named NTP server — refid included.
• measure from your own network — our path is not yours, and the latencies we publish are ours.