NTS Enabled Across Our Entire Pool Secured

That is not the norm, and that is precisely the point: of the 2598 European time servers we measure from 6 networks, only 7.4% serve NTS — 192 authentication endpoints for an entire continent. The rest hand out time nobody can authenticate. The detail lives on the world map and in the European study, with the dependency tree for what it all rests on.

Time synchronization is a critical component of any IT infrastructure. Until now, the NTP protocol transmitted time in plaintext and without authentication, exposing systems to potential attacks. With the activation of NTS on our infrastructure, your systems can now cryptographically verify that the time received actually comes from our servers.

Why Enable NTS Now?

NTS (Network Time Security), standardized by RFC 8915 in September 2020, represents a major evolution of the NTP protocol. Here is why now is the time to adopt this technology.

Adoption Is Accelerating

Technical and Operational Benefits

Security Risks Without NTS

The NTP protocol, designed in the 1980s, includes no native security mechanism. NTP packets travel over UDP without encryption or authentication, exposing systems to several well-documented attack types:

How Does NTS Work?

NTS (Network Time Security) is defined by RFC 8915. The protocol operates in two phases:

1. Establishment Phase (NTS-KE): The client establishes a TLS 1.3 connection with the server on port 4460. They exchange encrypted cookies that will be used to authenticate subsequent NTP exchanges.
2. Synchronization Phase: Standard NTP requests (port 123) now include cryptographic extensions. Each response is authenticated using the cookies negotiated previously.

Our Available NTS Servers

Our entire NTP pool now supports NTS. You can use any of these servers for secure synchronization. All TLDs are valid: .com, .fr, .eu, .net, .org, .be, .biz, .info.

Individual Servers (Stratum 2)

Pool Entries (Load-Balanced)

These three site sub-pools cover nine of the twelve servers. The other three sit outside the Paris rooms — one of them in Frankfurt: geographic diversity is part of what makes a pool resilient, and ntp-pool.rdem-systems.com serves them exactly like the rest. They have no sub-pool of their own, because we only publish one from three addresses upwards: below that, the word “pool” would name a single machine.

Per-Transit-Operator Pools

To target a specific transit network (path diversity, compliance testing), we expose one pool per transit provider, grouping the servers reachable through that AS:

Configure Your NTS Client

Chrony is the recommended NTP client for using NTS. It is available on most modern Linux distributions and natively supports NTS since version 4.0.

Chrony Configuration with NTS

Edit your /etc/chrony/chrony.conf (or /etc/chrony.conf) file:

# /etc/chrony/chrony.conf - NTS RDEM Systems Configuration

# NTS RDEM Systems servers (secured)
# You can mix TLDs: .com, .fr, .eu, .net, .org, .be, .biz, .info
server ntp-pool.rdem-systems.com iburst nts
server ntp-1.rdem-systems.fr iburst nts
server ntp-2.rdem-systems.eu iburst nts
server ntp-3.rdem-systems.net iburst nts

# Drift file
driftfile /var/lib/chrony/drift

# Allow significant updates at startup
makestep 1.0 3

# Enable real-time clock sync
rtcsync

# Logging
logdir /var/log/chronyCopier

Installation and Restart

# Install Chrony (Debian/Ubuntu)
sudo apt update && sudo apt install chrony

# Or on RHEL/CentOS/Fedora
sudo dnf install chrony

# Restart the service
sudo systemctl restart chronyd

# Check the status
sudo systemctl status chronydCopier

Verify That NTS Is Working

After configuring Chrony with NTS, verify that authentication is working correctly:

chronyc sources Command

sudo chronyc -N sourcesCopier

You should see your sources with the N flag indicating that NTS is active:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp-pool.rdem-systems.c>     2   6   377    23   -145us[ -201us] +/-   12ms
^+ ntp-1.rdem-systems.com       2   6   377    24   +234us[ +178us] +/-   15ms
^+ ntp-2.rdem-systems.com       2   6   377    25   -89us[ -145us] +/-   14ms

Check NTS Status

sudo chronyc -N authdataCopier

This command displays the NTS authentication details for each source:

Name/IP address         Mode KeyID Type KLen Last Atmp  NAK Cook CLen
=========================================================================
ntp-pool.rdem-systems.c> NTS     1   15  256  23m    0    0    8  100
ntp-1.rdem-systems.com   NTS     1   15  256  24m    0    0    8  100
ntp-2.rdem-systems.com   NTS     1   15  256  25m    0    0    8  100

Frequently Asked Questions

Does NTS work with ntpd?

No, the standard ntpd daemon does not support NTS. You must use Chrony (recommended), NTPsec, or ntpd-rs (Rust) to benefit from NTS. Windows W32Time does not support NTS either.

What is the performance impact?

The impact is negligible. The TLS negotiation only occurs at startup and during cookie renewal (approximately every hour). Regular NTP exchanges add only ~100 bytes for authentication.

Can I mix NTS and standard NTP?

Yes, Chrony can simultaneously use NTS sources and standard NTP sources. However, for optimal security, prefer NTS sources.

What happens if NTS fails?

By default, if NTS cannot be established, Chrony will not use the affected source. This is secure behavior: it is better not to synchronize than to synchronize without authentication.

How many NTS servers exist worldwide?

Two figures circulate, and they do not measure the same thing — hence the importance of saying which is which:

• The declarative worldwide count — jauderho/nts-servers lists servers whose operator advertises NTS, across all regions. It is the reference the community recognises, and RDEM Systems appears there with 11 servers.
• Our measured European count — 192 machines serving NTS, confirmed by a time that is really authenticated rather than by an open port, across 2598 European machines probed from 6 networks (campaign of 7 August 2026). It runs higher than the declarative one because it finds undocumented NTS — and stricter, because it removes what is advertised but not served.

The two do not contradict each other: one counts worldwide claims, the other European facts. According to our measured registry, the leading European operators are Netnod (Sweden, 12 machines, all stratum 1), RDEM Systems (France, Germany, 12 machines), SIDN Labs (Netherlands, 6 machines, 5 of them stratum 1), PTB (Germany, 4 machines, all stratum 1), Nothing to hide (Netherlands, 4 machines) and Tharyrok (France, Belgium, Germany, 4 machines). On an equal machine count, the stratum breaks the tie: a stratum 1 server holds its own time reference, a stratum 2 one receives it from elsewhere. A further 98 European NTS machines are run by operators we cannot name — pool volunteers with no organisation name, or machines discovered by deduction and published under a pseudonym. They count in the totals, not in this ranking.

That ranking deserves one point of honesty: we are its source, and we sit second in it. It is reproducible — the CSV filtered on counted=yes and nts_measured=yes gives back exactly these figures. That is the only guarantee we can offer against our own bias: making the calculation redoable without us.

Is there an NTS pool like pool.ntp.org?

Two things are usually conflated here. What is incompatible with NTS is the pool.ntp.org model: a DNS round-robin behind which roughly 2,400 volunteer operators answer under a single name. NTS requires the client to validate the certificate for the name it queried — and you cannot have 2,400 independent organisations each hold a valid certificate for that name. This is not an oversight by the project: it follows directly from its founding property, anyone can contribute without being audited. NTS rests on the opposite.

An NTS pool remains possible, though, in three forms — one of which is already running.

1. The single-operator pool — one operator, one certificate deployed across all its machines behind a single name. Simple, working today, and what we run as ntp-pool.rdem-systems.com. The limit is plain: it is a pool in the load-balancing sense, not in the trust-diversity sense — one operator, one jurisdiction.

2. The small consortium, three or four operators, with two variants that do not carry the same cost:

• Shared private key — a single certificate for the pool name, deployed at each operator. Easiest to implement. But a compromise at one operator compromises the whole pool, and not just the name: also the NTS cookie encryption key, hence the ability to forge valid cookies on behalf of all the others.
• One certificate per operator, for the same name — this requires a certificate authority willing to issue the same hostname to several distinct organisations. Constraining and unusual, but not a protocol obstacle.

3. The pool with a central NTS-KE — and this one is no longer theoretical. sectime.org, run by the Trifecta Tech Foundation with ICANN funding (2025-2027), is running today. The principle avoids the certificate problem rather than solving it: the client talks to a central NTS-KE (ke.sectime.org) that presents a certificate valid for its own name, hands out the cookies, then redirects the client to a member server through the NTPv4 Server negotiation (RFC 8915 §4.1.7). The member keeps its own name and its own certificate; the pool authenticates to it with a token. Measured on 31 July 2026: eight distinct member servers seen across 72 handshakes, seven of them located in five countries (NL, FR, BE, DE, CH).

The cost of this third model is a software one, and it is the pool's own join page that spells it out: joining requires ntpd-rs 1.9.0 or newer — the only implementation with upstream pool-mode support — or a modified build of chrony (ntsauthtokenfile) or NTPsec (nts poolauth), two directives absent from those projects' upstream documentation. The 1.9.0 threshold is not arbitrary: the ntpd-rs release notes (12 June 2026) record the switch to the IANA early-allocated codepoints for the KELB-style pool — earlier versions therefore speak a different dialect — and label that mode experimental. Our production stack is upstream chrony: we are not joining that pool, because we refuse to make a time infrastructure depend on an out-of-tree patch. The project remains worthwhile, and recommendable to anyone running the right stack.

In other words: what a European NTS pool lacks is not a technical solution — one exists, and it runs — but an ecosystem of operators able to join without changing stack, or willing to agree on key governance for the consortium variant.

One practical lock remains on that second variant — and it is being lifted at the IETF. ACME DNS-01 validation relies on a single name, _acme-challenge.<name>, which a CNAME can only delegate to one target: only one operator can renew. This is not specific to time — it is the classic problem of high-availability deployments where several independent stacks each need a valid certificate for the same name.

The draft draft-ietf-acme-dns-account-challenge (ACME DNS Labeled With ACME Account ID Challenge) solves exactly this: the validation name carries a label derived from the ACME account — _ujmmovf2vn55tgye._acme-challenge.pool-nts.eu — so that each operator has its own validation name, its own account and its own private key, for the same pool name. No shared key, no human coordination at every renewal. A second draft, draft-ietf-acme-dns-persist, goes the same way with reusable records. Both are IETF working group documents, at revision 01 as of 31 July 2026 — an open effort, not something deployable today.

Which operating systems support NTS by default?

Ubuntu 25.10+ will enable Chrony with NTS by default — a major turning point. RHEL/Fedora and SUSE document NTS configuration. Most modern Linux distributions allow easy NTS activation with Chrony.

Can NTP/NTS management be outsourced?

Yes. RDEM Systems provides 24/7 managed services and on-call support for servers — including NTP/NTS time synchronization, drift monitoring, and Chrony configuration maintenance. Ideal for IT departments that need reliable timestamping without dedicating an internal team.

How to ensure NTP compliance for MiFID II or PCI-DSS?

MiFID II (RTS 25) requires UTC traceability with a threshold that depends on the activity: 100 μs for high-frequency algorithmic trading, 1 ms for other forms of algorithmic trading, 1 s for manual order entry. PCI-DSS (requirement 10.6) requires time-synchronization technology and designated time sources, without mandating NTP by name. RDEM Systems offers a 1-day NTP/NTS audit: technical interview with your sysadmins, architecture analysis (sources, strata, redundancy, SPOF), and delivery of a compliance report with a remediation plan. Contact us →

Check the NTS compatibility of your server with the tester ntp-tester.eu/nts

And beyond the last hop?

NTS authenticates the exchange between you and your server. Your server gets its own time from someone else, and that part of the chain is not observable from outside. We measured it: must NTS be proven end to end?