NIS 2 NTP Requirements:
Time-Sync for Essential & Important Entities
Mapping Article 21 to authenticated NTP infrastructure
1. Who is concerned — essential vs important entities
Directive (EU) 2022/2555 — the NIS 2 Directive — entered into force on 16 January 2023 and Member States had until 17 October 2024 to transpose it. It distinguishes two categories of entities, essential and important (Art. 3):
- Annex I (sectors of high criticality): energy, transport, banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure (IXPs, DNS, TLD registries, cloud, data centres, CDN, trust services, electronic communications), ICT service management (B2B), public administration, space. Large entities are essential, medium-sized ones important (with the exceptions of Art. 3(1)(b)-(g)).
- Annex II (other critical sectors): postal & courier services, waste management, chemicals, food, manufacturing (medical devices, computers, electronics, electrical equipment, machinery, motor vehicles, other transport equipment), digital providers (online marketplaces, search engines, social networks), research organisations. Important entities.
In both categories, Article 21 imposes a risk-management obligation. The directive does not name time; its implementing regulation asks for synchronised time sources, and ENISA's technical guidance recommends authenticated NTP and several time sources. Unauthenticated NTP is hard to defend as the basis of an audit trail.
2. Article 21 and time-sync: four measures where time matters (our reading)
Article 21(2) lists ten categories of measures that essential and important entities must implement. Four measures where time matters (our reading):
3. Article 23 incident-reporting deadlines depend on reliable time
Article 23 mandates a strict incident-reporting cadence to the competent CSIRT:
| Deadline | Artefact | Time-sync dependency |
|---|---|---|
| 24 hours | Early warning | "Significant incident" detection relies on monitoring thresholds that are time-bucketed. |
| 72 hours | Incident notification with initial assessment | Log correlation across services to establish the perimeter. |
| 1 month | Final report | Forensic timeline — one whose timestamps can be contested weakens the report. |
4. Threats against unauthenticated NTP
NTP is one of the oldest unauthenticated protocols still in active use. Documented attack classes that an essential entity must consider under Art. 21:
- Off-path time shifting — a MITM on UDP/123 injects timestamps that skew the victim by minutes to years, invalidating TLS certificates, MFA tokens and audit trails.
- Kiss-of-Death spoofing — a forged KoD packet forces a client to back off from a legitimate source, steering it toward an attacker-controlled server.
- Pool pollution — injection of a hostile volunteer server in
pool.ntp.org; mitigated by choosing known operators and several independent sources, so selection can outvote a bad one. Authentication proves who answers, not that the time is right. - BGP hijack against public NTP — a hijacked route to a public time server delivers attacker-controlled time; route-origin validation (RPKI) narrows this risk without removing it, and NTS makes the forged answers detectable.
- Stratum-16 silent failure — a source that loses sync signals itself as unsynchronised (LI=3; stratum 16 in ntpq/chronyc, often 0 on the wire); without alerting, the operator believes time is still disciplined while it is actually drifting freely.
5. NIS 2 NTP checklist — 10 controls we recommend
| # | Control | Evidence |
|---|---|---|
| 1 | At least 4 upstream time-sources | NTP configuration file with 4+ server lines; rationale document. |
| 2 | Sources in at least 2 distinct autonomous systems (AS) | Whois / routing-registry extracts linking IPs to operators. |
| 3 | At least one authenticated source (NTS or symmetric key) | Running config + key-management procedure. |
| 4 | Stratum hierarchy documented | Architecture diagram: Stratum 1 → internal Stratum 2 → clients. |
| 5 | Monitoring of offset, jitter, reach | 90-day metrics dashboard (Prometheus/Grafana, Zabbix, Datadog). |
| 6 | Alerting on stratum ≥ 16 and false-ticker | Alert rule export + past alert history. |
| 7 | Incident-response playbook for time-source failure | Documented IR runbook with RACI and escalation path. |
| 8 | Log retention (we recommend 13 months) | Log-management policy. NIS 2 sets no retention period; the Art. 23 final report is due one month after the incident notification. |
| 9 | Change-management record for NTP config | Ticketing trail for every ntp.conf / chrony.conf change. |
| 10 | Periodic audit against this checklist | Annual internal audit report signed by the CISO or DPO. |
6. Why NTS (RFC 8915) is the proportionate answer
Article 21(1) requires measures to be proportionate to the risk. In 2026, NTS (Network Time Security, RFC 8915) is the only standardised mechanism that authenticates NTP without pre-shared keys, hence usable with public servers:
Public NTS-capable sources include Cloudflare, Netnod, NIST, and RDEM's NTS service. For internal hierarchies, chrony 4.x acts as both NTS client and NTS server — a single binary covers both roles.
7. Evidence pack for the auditor
Assemble these artefacts in a single folder before the audit:
- Architecture diagram (PDF or draw.io export).
ntp.conf/chrony.conffrom each stratum level.- 90-day export of offset / jitter / reach per client. For the time servers themselves, a history the auditor can verify without trusting you: the monthly sealed NTP compliance report (Time Evidence) from RDEM Systems, measured from outside and sealed when issued.
- Alerting rule file and past-incident tickets.
- Key-management procedure (who rotates NTS certs, when, how).
- Log-retention policy and actual log sample (13 months back).
- Change-log for NTP configuration files.
- Signed annual review of the 10-control checklist above.
Use our NTP Audit Checklist for CISOs to structure the review, and the validator to check each public time source on demand.
Worked example from the field: how a 4.2-second drift across 12 servers was brought under 50 ms (FR) — a concrete walk-through of the evidence-pack artefacts above.
8. Cross-mapping: NIS 2, ISO 27001, DORA, PCI-DSS
| Requirement | NIS 2 | ISO 27001:2022 | DORA | PCI-DSS v4.0 |
|---|---|---|---|---|
| Synchronised clocks | Art. 21(2)(b) | A.8.17 | RTS (EU) 2024/1774, Art. 12(2)(f) | Req. 10.6 |
| Authenticated source (our reading) | Art. 21(2)(h) | A.8.17 (implicit) | — (not specified) | Req. 10.6.3 (protection of settings; no authentication required) |
| Monitoring & alerting | Art. 21(2)(b) | A.8.16 | Art. 10 | Req. 10.4 |
| Audit-trail retention | — (directive); 2024/2690 point 3.2.5 (period predefined by the entity) | A.8.15 | RTS 2024/1774, Art. 12(2)(a) | Req. 10.5.1 (10.7 in v3.2.1) |
| Supply-chain diversification | Art. 21(2)(d) | A.5.19, A.5.21 | Art. 28 | Req. 12.8 |
A single evidence pack built on our checklist feeds the time-sync portion of all four frameworks; it is not proof of compliance. See the dedicated pages: ISO 27001 Control 8.17 · PCI-DSS Requirement 10.6. For trading venues and investment firms, the comparable time-sync obligation is MiFID II RTS 25 clock synchronization.
If producing and maintaining that evidence pack in-house isn't practical, RDEM Systems delivers it as a managed service — the UTC time traceability audit covers the documented chain to UTC and the periodic review.
Not here for NIS 2 compliance? Use the right tool for your use-case:
- Measure jitter, offset, latency → ntp-tester.eu
- Diagnose firewall / port 123 / daemon → check-ntp.net
- Enterprise reference architecture → ntp.rdem-systems.com