Why A Single Grandmaster Is Now A DORA Article 11 Problem

What Article 11 actually asks for

The Digital Operational Resilience Act came into force across the European Union on 17 January 2025. It applies to banks, investment firms, trading venues, payment institutions, insurers, and a long list of other financial entities — including, importantly, their ICT third-party service providers. Article 11 is the one that addresses ICT business continuity, and its language is very specific about what a financial entity must demonstrate.

Article 11(1) requires financial entities to implement a comprehensive ICT business continuity policy that enables them 'to continue the delivery of critical or important functions' through ICT-related incidents. Article 11(2) requires that this policy 'shall ensure the continuity of the financial entity's critical or important functions' and 'shall be implemented through appropriate arrangements, plans, procedures and mechanisms' — those arrangements being tested, reviewed, and documented. Article 11(6) adds the obligation to test the business continuity plans at least annually.

Clock synchronisation is not explicitly named in Article 11. It does not need to be — the Article applies to 'ICT systems', and timing infrastructure plainly is an ICT system that underlies trade execution, transaction reporting, surveillance and settlement. If timing fails, critical functions fail. A financial entity whose timing fabric cannot meet the Article 11 standard has a gap at the ICT level that a regulator can examine and cite.

Three structural gaps in a single-unit grandmaster

A single grandmaster clock, regardless of how good the individual unit is, has three structural gaps against DORA Article 11. None of them are fixable with firmware.

• ●Single point of failure. One grandmaster means one GNSS antenna, one oscillator, one chassis, one power feed. If any of those fails, every downstream device that was taking PTP from that grandmaster loses its reference simultaneously. BMCA fallback is typically to an OCXO-grade slave in a nearby switch — minutes of holdover, not hours. Article 11(2) requires documented arrangements for business continuity; a single unit with BMCA fallback is not a documented arrangement for continuity, it is an implicit hope.
• ●Unknown holdover under realistic denial scenarios. An incumbent OCXO grandmaster datasheet typically specifies ±1.5 µs of drift over 24 hours under ideal conditions. In practice, with aging and thermal cycling, a seven-year-old OCXO routinely drifts 3–5× the datasheet. A firm that cannot answer the question 'what is our documented holdover spec for a 24-hour GNSS denial event?' has an Article 11(6) testing gap — because testing requires knowing what the expected behaviour is in order to verify it.
• ●Non-auditable monitoring output. Most incumbent vendor platforms emit log files. Log files are generated by the firm's own systems and stored by the firm; a regulator cannot independently verify they were not modified after the fact. DORA Article 9 requires 'accurate, complete and consistent' ICT records — an auditable record is one a third party can verify. Log files are, at best, a record the regulator can be asked to trust.

Why adding a second unit is not the answer

The instinctive reaction to 'single point of failure' is 'add a second unit'. A/B redundancy with two incumbent grandmasters is better than a single unit, but it does not in itself close the Article 11 gap. The right questions to ask a two-unit incumbent topology are uncomfortable to answer honestly.

Are the two GNSS antennas on physically separate roof mounts, with independent cable runs, or are they co-located on the same mast with a splitter? A shared mast, a shared cable run, a shared RF environment — a localised interferer takes both units out at once. Article 11 does not care that the units are individually redundant if the shared failure mode is undocumented.

Is the failover active-active with sub-second detection, or hot-standby with a manual cutover procedure? If the on-call engineer has to SSH into the secondary and flip a failover flag, the procedure has a manual step — and Article 11(2) requires arrangements that ensure continuity, not arrangements that require human intervention to ensure continuity at 3 a.m.

Is the failover event itself monitored, logged and evidenced? If the incumbent's vendor platform emits a log line that says 'FAILOVER to SECONDARY' but does not evidence that the failover was clean, that downstream clients transitioned without phase step, that the secondary's GNSS was healthy at the moment of cutover — then the evidence trail for the failover is incomplete. An Article 11(6) annual test is hard to pass cleanly if the monitoring platform does not produce the evidence the test requires.

What a compliant topology looks like in 1RU

The Open Time Appliance Shelf is a 1RU rack kit containing three independent grandmaster units. Each unit has its own Rubidium Black+ oscillator, its own u-blox LEA-F9T multi-band GNSS receiver, its own IEEE 1588 Transparent Clock output, and its own Timebeat Agent streaming 167 telemetry fields per cycle to Sync Insight. Three independent cable runs to three independent antenna mounts, three independent power feeds, three independent failure domains.

PTP² Mesh runs across the three units in active-active configuration. Downstream PTP slaves connect to whichever unit is currently the best master under the Mesh's cost model; if one unit's GNSS degrades, Mesh detects the capability downgrade in under a second and re-weights downstream traffic towards the remaining two units. The transition is smooth because the remaining units were already serving time — they simply take on additional load. No manual failover. No downstream client reconfiguration.

Clock Ensemble on each unit fuses its own GNSS with PTP feeds from the other two units and any configured upstream references. A unit that loses GNSS continues to be disciplined by the ensemble of the remaining inputs, with no phase step visible to downstream applications. This is the topology that satisfies Article 11's documented-arrangements standard, because each layer is documented, testable and evidenced continuously through Sync Insight.

The evidence chain — Article 9 as well as Article 11

Article 11 is about the topology; Article 9 is about the records. DORA Article 9 requires 'accurate, complete and consistent' ICT system records, and that requirement extends to any ICT system that supports critical or important functions. Timing infrastructure qualifies. The regulator, presented with a request to verify UTC traceability for a specific trade on a specific date, must be able to see — and ideally verify independently — that the clock that timestamped the trade was within tolerance.

UTC Verification, which ships with Sync Insight Enterprise and above, signs the clock state of each host every second. Each attestation contains measured offset, path delay, GNSS quality, holdover status, and the UTC reference value — chained cryptographically to the previous attestation. Any modification to the chain is detectable by anyone holding it. The chain is verifiable offline, without contacting TimeBeat or the firm, using a standalone command-line tool and a public key.

That is what Article 9 'auditable records' looks like in practice. Not a log file stored on the firm's systems, but a cryptographic chain that a regulator can verify with a public key. The difference is the difference between 'we have records' and 'we can prove the records are accurate'.

The procurement angle — how firms are actually moving

The hardware conversation in finance is not primarily a cost conversation. It is a risk conversation, and the cost is one input to the risk model. Against a DORA exposure of up to 2% of global annual turnover, the Shelf at £23,385 hardware CapEx plus Sync Insight Enterprise at £29,940 annually is not a significant line item — it is a mitigation cost for a risk that firms were carrying implicitly.

The typical procurement motion starts with Sync Insight deployed alongside the existing incumbent — PAYG at £1.12 per device per day for up to 20 devices, no procurement approval needed at that scale. Within a few days the firm has documented baseline data on its own infrastructure — holdover behaviour, GNSS quality, Allan deviation trending, monitoring gaps. That data funds the hardware conversation when the budget window opens; the procurement decision is made on the firm's own numbers, not on vendor claims.

A 30- to 90-day parallel deployment of a Shelf alongside the incumbent then produces a direct performance comparison — both platforms monitored by Sync Insight in real time, both evidenced against DORA requirements side by side. The cutover happens when the team is satisfied with the comparison. The incumbent is retained for 60 to 90 days as a passive fallback. The migration path has no blast radius.

What to do this quarter

Three practical next steps, in order of increasing commitment.

• ●Run a 30-day Sync Insight trial alongside your existing grandmaster on PAYG. No hardware change, no procurement approval at the 1–20 device scale. Baseline what you have.
• ●Request a 45-minute CCO compliance briefing — we walk through the Article 9 / 10 / 11 requirements and the specific evidence your current platform does and does not produce. Output is a one-page DORA gap assessment on your data.
• ●Commission a parallel Shelf deployment for 30 to 90 days. Full telemetry comparison in Sync Insight. No cutover commitment during the pilot. When the evidence is in hand, the procurement conversation is about numbers rather than claims.