DORA & NTP Time Synchronization
Regulation (EU) 2022/2554

Published 19 June 2026 · By Richard DEMONGEOT, RDEM Systems · Target audience: heads of operational resilience, CISOs and ICT risk managers at banks, insurers, investment firms and their ICT third-party providers in scope of DORA.

1. Scope: who DORA binds — and why there is no clock number

The Digital Operational Resilience Act — Regulation (EU) 2022/2554 applies from 17 January 2025 to a broad set of financial entities (credit institutions, payment and e-money institutions, investment firms, insurers, crypto-asset service providers and more) and, through its oversight framework, to their critical ICT third-party service providers.

Unlike MiFID II RTS 25, DORA contains no numeric clock-accuracy requirement. There is no "±100 µs", no granularity table. That absence is the single most important thing to understand — and the trap. DORA's obligations are outcome-based, and several of those outcomes silently assume that time across your estate is synchronized, traceable and trustworthy.

2. Why time is load-bearing without a threshold

Three DORA outcomes break the moment clocks diverge:

• You cannot correlate what you cannot align. Detecting an anomaly (Art 10) means joining events from firewalls, applications, identity systems and ICT providers. If their clocks differ by seconds, the attack timeline scrambles and the detection logic mis-fires.
• You cannot prove a deadline you cannot timestamp. The reporting clocks (Art 19) run from "awareness" and "classification". Those are timestamps. A disputed or drifting clock turns "we reported within 4 hours" into an argument you cannot win.
• You cannot reconstruct a forensic chain that does not line up. Post-incident analysis and the final report (Art 19) depend on a coherent, cross-system sequence of events — which only exists if the timestamps share one reference.

So the relevant question for DORA is not "how accurate?" but "how trustworthy and consistent?" — one authenticated reference, synchronized across the estate, with the chain documented.

3. Detection of anomalies (Article 10)

Article 10 requires financial entities to have mechanisms to promptly detect anomalous activities, including ICT network performance issues and ICT-related incidents, and to identify potential single points of failure. Detection at scale is correlation, and correlation is only as good as the timestamps it joins on.

The practical consequence: the time layer itself is a potential single point of failure. An unauthenticated, single-homed time source that every log depends on is exactly the kind of dependency Article 10 asks you to find and remove — which is why a resilient, authenticated time service (see §6) is part of satisfying it.

4. The major-incident reporting clocks (Articles 17–20)

Articles 17 and 18 require a documented ICT-related incident management process and a classification of incidents (major incidents and significant cyber threats singled out). Article 19 requires reporting major incidents to the competent authority; Article 20 mandates the harmonised content and the reporting time limits. The precise deadlines below are not in the body of Article 19 itself — they are set by the reporting standards adopted under Article 20 — RTS (EU) 2025/301 (report content and time limits) and ITS (EU) 2025/302 (templates) — but every one is anchored to a timestamp:

Report	Deadline	The clock starts at…
Initial notification	As early as possible — within 4 hours of classifying the incident as major, and no later than 24 hours from becoming aware of it	awareness / classification timestamp
Intermediate report	Within 72 hours of the initial notification	initial-notification timestamp
Final report	Within one month of the latest intermediate report	intermediate-report timestamp

These time limits are laid down by the reporting technical standards adopted under Article 20, not numerically by Article 19. The point for the time layer is unchanged: each is measured between two recorded instants.

5. The RTS that make it concrete (2024/1774 & 2024/1772)

DORA delegates the detail to the European Supervisory Authorities, whose technical standards are where the time dependency becomes operational:

Standard	Regulation	Relevance to time
RTS on ICT risk management framework	(EU) 2024/1774	Logging, event recording and the integrity/authenticity controls that traceable, authenticated time underpins.
RTS on incident classification	(EU) 2024/1772	Criteria and materiality thresholds for "major" incidents — applied to an event timeline that must be internally consistent.

RTS (EU) 2024/1774 in particular ties logging and the protection of data integrity and authenticity into the risk-management framework. Logs whose timestamps are not synchronized — or whose time source can be spoofed — fail both the usefulness test (you can't correlate them) and the integrity test (you can't trust them).

6. A resilient time topology for DORA

Because DORA is about resilience rather than a number, the design goal is no single point of failure and an authenticated, monitored reference:

        ┌───────────────────────────────────────────────┐
        │  Diverse references (no single dependency)     │
        │  ─────────────────────────────────────────────  │
        │  GNSS + PPS  ·  national lab UTC(k)            │
        │  authenticated public NTS sources             │
        └─────────────────┬─────────────────────────────┘
                          │  NTS (RFC 8915) — authenticated
                          ▼
        ┌───────────────────────────────────────────────┐
        │  Redundant internal time servers (peered)      │
        │  ─────────────────────────────────────────────  │
        │  monitored for offset & reachability          │
        │  alerting on drift = a detectable anomaly      │
        └─────────────────┬─────────────────────────────┘
                          │  one consistent reference
                          ▼
        ┌───────────────────────────────────────────────┐
        │  The whole estate logs on the same clock       │
        │  ─────────────────────────────────────────────  │
        │  SIEM · apps · identity · ICT providers        │
        │  correlation & incident timeline hold together │
        └───────────────────────────────────────────────┘

This is the supervised, authenticated Stratum 1 design RDEM Systems operates and documents: a GNSS-disciplined, PPS-supervised reference distributed over NTS, redundant and monitored. The reference architecture and the server role are on the hub — the RDEM time infrastructure, the Stratum 1 server reference, and NTS (RFC 8915) for the authenticated channel.

7. What an examiner looks for

For the time layer, assemble:

1. Architecture & SPOF analysis. The time topology, showing diverse references and no single point of failure — directly answering Article 10.
2. Authentication. Evidence that the time channel is authenticated (NTS), supporting the integrity/authenticity controls of RTS (EU) 2024/1774.
3. Monitoring & alerting. Proof that clock offset and source reachability are monitored and that drift raises an alert — i.e. clock failure is itself a detectable anomaly.
4. Synchronization proof across the estate. Sampled status from representative systems (SIEM, applications, identity, key ICT providers) showing one consistent reference.
5. Source validation. Output of the Online NTP Validator against each external source — stratum, offset, refID, dual-stack reach — for the file.

8. DORA vs MiFID II and the other frameworks

DORA is the resilience layer; the others set the specific controls. The clean mental model:

Framework	Regulation	What it asks of time
DORA	(EU) 2022/2554	Resilience outcomes — detection, incident clocks, forensics (this page). No numeric threshold.
MiFID II RTS 25	(EU) 2017/574	Numeric accuracy of trading business clocks (down to 100 µs). See the RTS 25 guide.
NIS 2	(EU) 2022/2555	Risk-management and incident reporting for essential/important entities. See NIS 2.
ISO 27001	A.8.17	Clock synchronization control. See ISO 27001 8.17.
PCI-DSS v4.0	Req. 10.6	Designated time servers, approved sources, protected settings. See PCI-DSS 10.6.

A financial entity in scope of several of these does not need separate time infrastructures: one resilient, authenticated, traceable service satisfies DORA's outcomes, RTS 25's number, and the control-level requirements of NIS 2, ISO 27001 and PCI-DSS at once. Map them all in the NTP audit checklist. DORA is enforced by your national competent authority under standards set by the European Supervisory Authorities (EBA, EIOPA, ESMA), with critical ICT third-party providers falling under the ESAs' dedicated oversight framework.

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