Does NIS 2 explicitly require NTP?

Article 21 of the NIS 2 Directive does not name NTP specifically. It requires 'appropriate and proportionate technical, operational and organisational measures' to manage cybersecurity risks. In 2026, regulators and ENISA guidance treat authenticated time-synchronisation as a baseline risk-management measure: without it, audit trails, incident timelines and forensic evidence are not defensible.

Which NIS 2 entities are concerned by NTP compliance?

NIS 2 applies to essential entities (energy, transport, banking, health, digital infrastructure, public administration) and important entities (postal services, waste, chemicals, food, manufacturing, digital providers, research). All of them must document how their time-sync infrastructure supports incident reporting obligations within the 24h/72h/1-month deadlines imposed by Article 23.

Is NTS mandatory under NIS 2?

NTS (Network Time Security, RFC 8915) is not explicitly mandated, but it is the only standardised way to authenticate NTP time-sources at scale. Given documented attacks (KoD spoofing, MITM on public NTP, pool-pollution), an auditor will likely treat unauthenticated NTP as a disproportionate risk for essential entities under Art. 21(2)(e) — supply-chain security.

What evidence does a NIS 2 auditor expect for time synchronisation?

Auditors typically request: (1) architecture diagram of the time-sync hierarchy, (2) list of upstream sources with stratum and authentication method, (3) monitoring dashboard showing offset/jitter/reach over a 90-day window, (4) alerting rules on stratum-16 and false-ticker, (5) incident-response playbook for time-source failure, (6) 13-month retention of NTP logs to match the incident-reporting statute of limitations.

How does NIS 2 interact with ISO 27001 and DORA on time-sync?

ISO 27001:2022 (A.8.17) and DORA (Art. 11) both require reliable, synchronised timestamps. NIS 2 adds a horizontal risk-management obligation (Art. 21) and reinforces incident-reporting deadlines (Art. 23). An organisation that maps NTP evidence once can typically satisfy all three frameworks with a single control set — provided authentication, redundancy and monitoring are documented.

NIS 2 NTP Requirements | Time-Sync Compliance for Essential & Important Entities

Published 20 April 2026 · By Richard DEMONGEOT, RDEM Systems · Target audience: CISOs, DPOs and auditors of essential and important entities under Directive (EU) 2022/2555.

On this page

1. Who is concerned — essential vs important entities
2. Article 21 and time-sync: the implicit obligation
3. Article 23 incident-reporting deadlines depend on reliable time
4. Threats against unauthenticated NTP
5. NIS 2 NTP checklist — 10 controls
6. Why NTS (RFC 8915) is the proportionate answer
7. Evidence pack for the auditor
8. Cross-mapping: NIS 2, ISO 27001, DORA, PCI-DSS

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 applies to two categories of organisations:

Essential entities (Annex I): energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure (DNS, TLD, cloud, data centres, CDN, ICT service providers), public administration, space.
Important entities (Annex II): postal & courier services, waste, manufacturing (chemicals, food, medical devices, computers, electronics, machinery, vehicles), digital providers (online marketplaces, search engines, social networks), research organisations.

In both categories, Article 21 imposes a risk-management obligation that — read in 2026 with ENISA technical guidance — effectively covers time-source authentication and integrity. Unauthenticated NTP cannot credibly support the audit-trail obligations that sit downstream of the directive.

2. Article 21 and time-sync: the implicit obligation

Article 21(2) lists ten categories of measures that essential and important entities must implement. Three of them anchor the NTP obligation:

Art. 21(2)(c) — Business continuity and crisis management. Incident timelines, log correlation across systems, and post-incident analysis all require a common time-reference. An untrusted time-source makes business-continuity evidence non-defensible.

Art. 21(2)(e) — Supply-chain security. Depending on a single public NTP pool without authentication is a supply-chain risk: pool operators can be compromised, BGP-hijacked, or withdrawn. ENISA guidance explicitly calls for diversified, authenticated upstream time sources.

Art. 21(2)(f) — Security in acquisition, development and maintenance of systems. Vulnerability handling and patch windows are timestamped. If time can be manipulated, so can the window of apparent vulnerability exposure.

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 — only admissible if timestamps are authenticated and monotonic.

Practical consequence. Miss any of these deadlines and the entity exposes itself to administrative fines up to EUR 10 million or 2% of global annual turnover (Art. 34). Reliable, authenticated NTP is no longer optional hygiene — it is a direct prerequisite of Article 23 compliance.

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 authenticated upstream sources.
BGP hijack against public NTP — the Quintin Lin 2015 incident and subsequent research show that blackhole/RPKI gaps affect time-critical flows too.
Stratum-16 silent failure — a source that loses sync reports stratum 16; without alerting, the operator believes time is flowing while it is actually frozen.

5. NIS 2 NTP checklist — 10 controls

#	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	13-month log retention	Log-management policy; retention aligned with Art. 23 final-report statute.
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, production-ready authentication layer for NTP:

NTS benefits aligned with NIS 2. Cryptographic authentication of every time-packet (AEAD), no replay, no MITM time-shift, zero-config for clients that already use chrony 4.x or ntpsec. Deployment effort is typically one day for a small infrastructure; the proportionality argument is trivial to make.

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.conf from each stratum level.
90-day export of offset / jitter / reach per client.
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 this Compliance Validator to produce machine-readable evidence on demand.

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)(c)	A.8.17	Art. 11	Req. 10.6
Authenticated source	Art. 21(2)(e)	A.8.17 (implicit)	Art. 9(3)	Req. 10.6.2
Monitoring & alerting	Art. 21(2)(g)	A.8.16	Art. 10	Req. 10.4
Audit-trail retention	Art. 23	A.8.15	Art. 12	Req. 10.7
Supply-chain diversification	Art. 21(2)(d)(e)	A.5.19, A.5.21	Art. 28	Req. 12.8

A single evidence pack that satisfies the NIS 2 checklist above will typically close the time-sync portion of all four frameworks simultaneously.

Ready to produce audit evidence?

Use the compliance validator to generate a NIS 2-aligned NTP report for your infrastructure — public and RFC 1918 servers supported.

Run the Compliance Validator → Full Audit Checklist

NIS 2 NTP Requirements:Time-Sync for Essential & Important Entities