RDEM Systems / Operator Notes Stratum 1 · GNSS · NTS EN FR
NTP test & audit toolkit · No signup · No telemetry

Online NTP Validator — Test your NTP servers: what the measurement shows for your controls.

Enter a server name: we query it from our side — NTP over IPv4 and IPv6, then NTS with authenticated time — and tell you what the measurement shows for ISO 27001, PCI-DSS, MiFID II, NIS 2 and DORA, and what it does not.

Built and operated by Richard Demongeot — running NTP infrastructure since 2005, Pontoise, France.

Validate an NTP or NTS server

A hostname or a public IP address. The measurement runs on our server, with the same code as our production probe, and compares the target with our reference server in the same instant. If you operate the server, prove it with a one-time curl challenge from it, and we also run a reflection (amplification) self-check on that address.

Try:

What this does not do: test your clock (ntp-tester.eu), diagnose your daemon (check-ntp.net), follow a server over time, or certify anything. One measurement, from one vantage point.

Test the security of your NTP server

The validator above is an NTP/NTS security check. From our side, it reports three things on any public server, and a fourth on yours:

  • Unauthenticated NTP — whether the server hands out time in cleartext, with the stratum, leap indicator and round-trip that come with it.
  • NTS (RFC 8915) — whether the authenticated channel works: the key-establishment handshake, whether the TLS identity is attested for the name you asked, and how many days its certificate has left.
  • Traceability — the reference ID (refid) the server announces, its stratum, and its offset from our reference, each with its uncertainty.
  • Hardening / reflection — whether the server returns an amplified reply to a legacy control query, the pattern abused in NTP amplification attacks. This one runs only after you prove you operate the address.

Why we ask you to prove ownership

The reflection check is the only intrusive one, so we run it only against an address whose operator has proven control of it — a one-time curl challenge from the server itself, like a Let's Encrypt HTTP challenge. We never run it against an address on someone else's request. That is what separates this tool from a scanner, and it is why the result comes straight back to you, in your own terminal.

What the terminal report looks like

$ curl -4 --interface 203.0.113.10 https://ntp.rdem-systems.com/verify/<token>
NTP validation for 203.0.113.10  (2026-09-21 10:20 UTC)
--------------------------------------------------------
ownership: proven for this address (source of your request matched)
NTS-KE: present (identity attested) - cert 56 d left
stratum 2 (refid 192.53.103.108) - offset vs our server +0.619 ms - leap 0
hardening: closed - no amplifying reply to a legacy control query (good)
--------------------------------------------------------
NTP works iff unauthenticated time is obtained; NTS iff authenticated time is.
The two verdicts are independent. Refid is the raw value the server announces.
One measurement from one vantage point - not an audit, not a certification.

Validate a server above, then choose Prove IP ownership to get the exact command for your server.

Going deeper: NTP server security — threats, hardening and how to test it, and what each field of the test means, and its limits.

Other test modes

For what the validator above cannot reach: your own system clock, internal servers on private networks, or a script to run on the server itself.

Basic Time Test

Browser-side check of your system clock against our reference server, over HTTPS (±10–30 ms).

NTP Bridge Test (RFC 1918)

Test internal NTP servers on private networks (10/8, 172.16/12, 192.168/16).

CLI Testing Script

Bash script for server-side checks and evidence collection.

Basic Time Test

Test your system clock against our reference server, over HTTPS: enough to tell whether your machine is on time, not to characterise a server — the validator above does that. (We also operate a GNSS/PPS-disciplined Stratum 1, which this browser test does not reach.)

04 — REFERENCE CHECKLIST

15 recommended checks.

What we recommend reviewing in your NTP stack ahead of an ISO 27001 or NIS 2 audit. The PDF is printable, dated, and produced from this same operator log.

Infrastructure
  • Multiple NTP sources configured (≥4, our recommendation)
  • Stratum 1 or 2 servers used (our recommendation)
  • Geographic diversity of sources
  • Internal NTP hierarchy defined
  • Failover mechanisms in place
Security
  • UDP 123 firewall rules documented
  • NTP amplification protection
  • Access control lists configured
  • Monitoring and alerting active
  • Logs retained per policy
Validation
  • Offset within acceptable range
  • No false tickers detected
  • Reach value at 377
  • Regular sync verification
  • Documentation up to date
Download the PDF checklist

Printable format, ideal for audit evidence files

By downloading, you agree to receive information about our NTP services. Unsubscribe anytime.

05 — DIFFERENT ANGLE?

Pick the right tool for the job.

This site tests NTP servers with an audit and compliance angle. For other angles, our sister sites do better:

Measure jitter, offset, latency ntp-tester.eu →
Diagnose firewall / port 123 / daemon issues check-ntp.net →
Enterprise reference architecture ntp.rdem-systems.com →

Frequently asked questions

What are the NTP requirements under NIS 2?

NIS 2 (Directive (EU) 2022/2555, Art. 21) requires cybersecurity risk-management measures (including incident handling), but does not name NTP. Its Implementing Regulation (EU) 2024/2690, which covers the digital providers and trust service providers listed in its Article 1, asks for synchronised time sources on systems (Annex, point 3.2.6). Neither text sets an accuracy, a stratum, an authentication method or a retention period: several diverse sources, NTS authentication and offset monitoring are good practice, not requirements. Our audit checklist covers what auditors usually ask for.

How does NTP compliance map to ISO 27001 control 8.17?

ISO/IEC 27001:2022 control 8.17 (Clock synchronization — A.12.4.4 in the 2013 edition) requires the clocks of information-processing systems to be synchronised to approved time sources. Auditors commonly ask for a documented NTP hierarchy, offset monitoring and alerting on stratum-16 or false-ticker events; source authentication is good practice rather than a requirement of the control. The validator shows, for each source, what a remote measurement establishes for that control — and what it does not.

Can I audit internal RFC 1918 NTP servers without public exposure?

Yes — this is what the RFC 1918 Bridge mode is designed for. A lightweight Node.js relay running on your audit workstation proxies NTPv4 packets to private-range servers (10/8, 172.16/12, 192.168/16). No data leaves your network. Results include stratum, offset, RTD, reference ID and leap indicator — the measurements an auditor will typically ask to see for ISO 27001 8.17 or NIS 2.

Does DORA impose specific NTP requirements for financial entities?

DORA (Regulation EU 2022/2554) does not name NTP and sets no clock threshold. Its RTS (EU) 2024/1774, Art. 12(2)(f), requires the synchronisation of the clocks of each of the financial entity’s ICT systems upon a documented reliable reference time source. Authenticated, redundant, monitored synchronisation is our recommendation to make those timestamps defensible.

What evidence do auditors expect from an NTP compliance review?

Auditors typically ask for: (1) list of configured NTP sources with stratum levels, (2) offset and jitter measurements over a representative window, (3) authentication configuration (NTS / symmetric-key), (4) monitoring/alerting rules for stratum-16 and false-ticker conditions, (5) change-management records for NTP configuration. Our NTP audit checklist goes through these points.