Clock Synchronisation and DORA Compliance: A Guide to Precision and Resilience

What DORA is and why it matters for timing

The Digital Operational Resilience Act (DORA) is the European Union's framework for ICT operational resilience in the financial sector, formally in force since January 2025. It applies to investment firms, credit institutions, payment institutions, market infrastructure operators and a wide range of other regulated entities, plus their critical ICT third-party providers. The core requirement is that financial entities maintain operational resilience against disruption in their ICT systems — across cybersecurity, business continuity, third-party risk and incident reporting.

DORA does not have a dedicated clock-synchronisation regulation in the way MiFID II's RTS 25 does. But timing infrastructure is squarely within DORA's scope for two reasons. First, the audit trails that financial entities are obligated to maintain depend on accurate timestamps, and an audit trail with unreliable timestamps is not an audit trail. Second, DORA's operational resilience requirements explicitly include the systems and infrastructure that the entity relies on for its critical functions — and timing infrastructure is critical to clearing, settlement, trading, post-trade reporting and most regulated activities.

Where MiFID II RTS 25 focused on the precision of timestamps under nominal conditions, DORA shifts the question to whether the timing infrastructure continues to deliver compliant precision under disruption. A timing fabric that delivers 100-nanosecond accuracy when GNSS is healthy but loses ten microseconds within an hour of GNSS denial is technically compliant with MiFID II under the right reading and emphatically not compliant with DORA's resilience expectations.

What DORA actually demands of timing infrastructure

DORA's resilience requirements translate into four practical demands on a financial entity's timing infrastructure. None of them are surprising if you've ever sat through an MiFID II audit; what changes under DORA is that they all become explicit expectations rather than implicit good practice.

• ●Resilience to single-point failures. No single grandmaster failure, no single GNSS antenna failure, no single boundary clock failure may cause the timing fabric to drift outside the regulatory precision budget. This means redundant grandmasters at minimum, ideally across separate failure domains.
• ●Documented and tested holdover. The entity must be able to demonstrate that holdover behaviour under credible disruption scenarios (multi-hour GNSS denial, antenna damage, primary grandmaster failure) keeps the timing fabric within compliance. "We have an OCXO, it should be fine" is not a documented test.
• ●Third-party risk management for timing vendors. Vendors providing timing hardware, software or cloud services to a DORA-regulated entity are explicitly within scope as ICT third-party providers. The entity must have a documented relationship, an exit strategy, and an understanding of what happens if the vendor is compromised, acquired, or fails.
• ●Incident reporting for timing-related events. Significant ICT incidents affecting critical functions must be reported to the entity's competent authority within defined timescales. A multi-hour timing fabric outage that affects audit-trail accuracy is a reportable incident, and the entity must have the operational capability to detect, classify and report it.

Building a DORA-compliant timing fabric

A timing fabric designed for DORA compliance has the same precision goals as one designed for MiFID II — it has to meet the relevant accuracy budgets continuously — but its architecture is shaped by the additional requirement to survive credible disruption without falling out of compliance. That changes several design decisions.

Grandmaster redundancy and geography. Two grandmasters are the floor; three across separate failure domains (different power, different network paths, ideally different physical locations) is the resilient default for any entity with significant exposure to a regulator's view of operational resilience. The grandmasters should be configured for BMCA failover and the failover behaviour should be tested in production maintenance windows on a defined cadence.

Oscillator class matched to disruption scenarios. OCXO holdover that drifts out of compliance within an hour of GNSS denial is fine for MiFID II in a controlled environment but exposes the entity under DORA, because the regulator can credibly ask "what happens if GNSS is unavailable for four hours?" and the entity has to have an answer that doesn't end in non-compliance. Rubidium holdover, which maintains compliance for 24+ hours, materially shifts the risk position.

Open-standard, multi-vendor hardware. Avoiding concentration risk on a single proprietary timing vendor is a DORA-specific consideration that didn't exist under MiFID II alone. Open Compute Project Time Appliance Project hardware, running linuxptp, supplied by a vendor with auditable firmware and a documented exit plan, is the lowest-risk procurement path for a DORA-regulated entity.

Continuous observability with tamper-evident logging. Every clock on the timing path streaming health metrics into a monitoring stack with alerts on excursions, with the historical metrics stored for the regulatory retention period in a tamper-evident format. The entity must be able to demonstrate, on demand, that the timing fabric has maintained compliance over any specific historical window.

Documented incident response. The operations team must have a runbook for timing-related incidents, with clearly defined detection criteria, escalation paths, classification rules for whether an incident is reportable under DORA, and the procedural steps to make the report within the regulatory timescale.

Where most entities are exposed

Working with financial entities preparing for DORA compliance, we see the same exposure patterns repeatedly. Three of them are common enough that they are worth flagging explicitly.

First: timing infrastructure that was specified for MiFID II compliance years ago and never re-evaluated against DORA's resilience expectations. The hardware works, the precision is fine on a normal day, and nobody has thought about what happens during the kind of multi-hour disruption DORA is now scrutinising.

Second: dependence on a single proprietary timing vendor with closed firmware and no documented exit plan. This is a third-party concentration risk under DORA in a way it was not under MiFID II alone. Entities that bought into a proprietary vendor a decade ago are now finding themselves in the position of explaining to a regulator why they cannot replace the vendor without re-architecting the timing fabric.

Third: lack of operational discipline around failover testing. DORA expects the entity to be able to demonstrate that resilience properties have been tested, not just designed. Quarterly grandmaster failover exercises in production, with documented outcomes, are now the operational floor — and many entities are starting from a baseline of having never deliberately failed over a grandmaster in production.

Where TimeBeat fits

TimeBeat builds the open-standard timing hardware and operations platform that DORA-regulated entities use to address the resilience and concentration-risk requirements that closed-firmware vendors struggle with. Our hardware is OCP TAP-aligned and runs linuxptp, our software stack is auditable end to end, and our customers include financial entities preparing for DORA assessments across European jurisdictions.

If your DORA preparation work has surfaced gaps in timing infrastructure resilience, the engineering team is happy to walk through architecture, observability and audit-trail patterns specific to your activity profile and risk position.