What each framework actually requires about time
ISO 27001, PCI-DSS, NIST, CIS, ANSSI, DORA, NIS 2, MiFID II
Protocol standards, published recommendations and legal requirements are three different things. Here is the text of each, checked at the source.
1. Three kinds of text, three kinds of obligation
Three families of documents talk about time, and they do not bind in the same way:
- Protocol specifications — the IETF RFCs (RFC 5905 for NTPv4, RFC 8915 for NTS). They say how the protocol works; they oblige no one to use it. See the documents that define NTP.
- Security frameworks and recommendations — ISO/IEC 27001, NIST SP 800-53, CIS Controls, ANSSI guides. They bind only those who adopt them, or whose contract or certification refers to them.
- Regulation — PCI-DSS by contract with the card schemes; DORA, NIS 2 and MiFID II by EU law, each for its own scope.
The short answer to the question we are asked most: none of these texts requires a stratum 1 server, NTS, or even NTP by name. They require synchronised clocks, most of them a reference traceable to UTC, some of them several sources. MiFID II is the one case where the tightest accuracy tiers make a local reference necessary in practice.
2. The texts, clause by clause
| Framework | Clause | What it says | What it does not say |
|---|---|---|---|
| PCI-DSS v4.0 | Req. 10.6.1–10.6.3 | 10.6.1: clocks synchronised “using time-synchronization technology”. 10.6.2: designated time servers; only they receive time from external sources; time “based on International Atomic Time or Coordinated Universal Time (UTC)”; updates only “from specific industry-accepted external sources”; several designated servers peer with one another; internal systems take time only from them. 10.6.3: access to time data restricted; changes to time settings on critical systems “logged, monitored, and reviewed”. | No protocol, stratum, accuracy or authentication method. Checked against the official v4.0 SAQ D (April 2022). Guide |
| NIST SP 800-53 Rev. 5 | AU-8, SC-45, SC-45(1), SC-45(2) | AU-8: time stamps in UTC (or with a fixed or stated offset), at an organisation-defined granularity. SC-45: “Synchronize system clocks within and between systems and system components.” SC-45(1): compare with an organisation-defined authoritative time source and resynchronise beyond an organisation-defined difference. SC-45(2): a secondary authoritative source “in a different geographic region”. | AU-8(1) and AU-8(2) are withdrawn — moved to SC-45(1) and SC-45(2). Granularity and source are left to the organisation. The only reference cited is RFC 5905. |
| CIS Controls v8 | Safeguard 8.4 | “Configure at least two synchronized time sources across enterprise assets, where supported.” Implementation groups 2 and 3. | No stratum, accuracy or authentication. |
| ANSSI (France) | Logging-architecture guide v2.0 (28/01/2022), R5 and R4 | R5: clocks synchronised on several internal time sources consistent with each other, which may themselves follow several reliable external sources, except in physically isolated networks; if NTP is used, the same protocol version across the information system. R4: a synchronisation precision of at least one second is recommended. | The guide explicitly accepts internal servers disciplined by dedicated hardware or by public Internet servers: no on-site stratum 1, no NTS. Guide (FR) |
| DORA | RTS (EU) 2024/1774, Art. 12(2)(f) | Logging safeguards include “the synchronisation of the clocks of each of the financial entity’s ICT systems upon a documented reliable reference time source”. | No protocol, stratum or accuracy; the regulation itself sets no clock threshold. Guide |
| NIS 2 | Implementing Regulation (EU) 2024/2690, Annex, point 3.2.6 | Synchronised time sources on systems, where feasible, to correlate logs. Applies to the digital-infrastructure and digital-service providers listed in that regulation — not to every NIS 2 entity. | The Directive itself (Art. 21) does not name time. No retention period, stratum or authentication. Point 3.2.6 read through a secondary source; check the text on EUR-Lex. Guide |
| ISO/IEC 27001:2022 | Annex A, control 8.17 (A.12.4.4 in 2013) | The clocks of information-processing systems are to be synchronised to approved time sources; ISO/IEC 27002:2022 gives the implementation guidance. | ISO texts are not freely available: this is our paraphrase — check your licensed copy. No protocol or stratum. Guide |
| MiFID II | RTS 25, Reg. (EU) 2017/574 | A maximum divergence from UTC for business clocks, by type of activity (tiers from 100 µs to 1 s), with traceability to UTC. | No stratum or protocol named; but the 100 µs and 1 ms tiers call, in practice, for a local reference (GNSS or PTP). Guide |
3. Stratum 1, NTS, number of sources: who asks for what
| Question | Texts that address it |
|---|---|
| A stratum 1 server | None. MiFID II RTS 25 makes a local reference necessary in practice for its 100 µs and 1 ms tiers. |
| Authenticated time (NTS) | None by name. PCI-DSS 10.6.3 protects time settings and data; DORA asks for integrity and authenticity of data. NTS is a good way to meet those, not a requirement. |
| Several sources | CIS 8.4 (at least two, where supported); NIST SC-45(2) (a secondary source in another region); ANSSI R5 (several internal, several external); PCI-DSS 10.6.2 (designated servers peering with one another). |
| A reference traceable to UTC | PCI-DSS 10.6.2 (TAI or UTC); NIST AU-8 (UTC or stated offset); MiFID II (UTC, with traceability); DORA (“documented reliable reference”). |
| A figure for accuracy | MiFID II (100 µs to 1 s); ANSSI R4 (at least one second, recommended). NIST leaves it to the organisation. The others give none. |
Everything else you will read — “at least four sources”, “13 months of NTP logs”, “stratum 1 on site” — is architecture advice, ours included. It may be good advice; it is not what the texts say, and an auditor who knows them will make the difference.
4. What a remote test can and cannot show
The validator queries a public server from our side: NTP over IPv4 and IPv6, then NTS with authenticated time, and the offset from our reference server with its uncertainty. That shows whether a source you depend on is reachable, serving time and, if NTS is used, authenticated under the right name.
It does not show that your own systems synchronise to that source, that their settings are protected, that synchronisation is monitored over time, or that your organisation complies with any of the texts above. One measurement from one vantage point is a snapshot, not an audit.
Different angle? Use the right tool:
- Measure jitter, offset, latency → ntp-tester.eu
- Diagnose firewall / port 123 / daemon → check-ntp.net
- Enterprise reference architecture → ntp.rdem-systems.com