The Unsynced Estate: Why UK Automation Needs a Clock-Integrity Ledger

A timestamp looks like a fact. In practice it is a claim: this event happened at this moment, according to this clock, traceable to this source, within this tolerance. UK digital infrastructure is increasingly built on that claim. Substations correlate protection events with telemetry. Traffic systems join sensor detections to signal phases. Building controls sequence plant and log alarms. Outdoor robots stamp observations before they fuse them into a map. Yet few estates can prove that the clocks behind those records agree, or that they still agree after a GNSS outage, a network change or a long period of holdover.

The problem is not that clocks drift. All clocks drift. The problem is that drift is rarely treated as an engineering property with an owner, a budget and an evidence trail. A time-drift register would change that. It would sit alongside the asset register and the configuration ledger as a first-class artefact, recording not merely that a device is synchronised, but how, to what, within what tolerance and with what fallback. The aim is not perfect time. It is accountable time.

A timestamp is an engineering claim

Most operational technology estates inherit time from a mixture of sources: global navigation satellite system receivers, network time protocol servers, precision time protocol grandmasters, mobile networks, building management front ends and, in some corners, the internal clocks of equipment that was never designed to be audited. These sources have different failure modes. GNSS can be lost, spoofed or jammed. NTP can be misconfigured or asymmetrically delayed. PTP can be undermined by a switch that is not transparent to time. A device in holdover can remain plausible for hours while its offset grows quietly beyond the tolerance its control logic assumes.

When those differences stay invisible, the estate produces records that look consistent but are not comparable. A protection engineer may see a relay operation and a substation telemetry event separated by a few hundred milliseconds that never existed. A traffic analyst may reject a detection because it appears to precede the signal phase that triggered it. A building controls team may chase a fault sequence that is an artefact of two controllers disagreeing about when a plant item started. An outdoor robot may fuse a lidar return and a camera frame as if they were simultaneous when they were not. None of these failures announces itself as a clock problem. They arrive as data-quality issues, intermittent faults or disputes about evidence.

Where the estate loses time

The risk is unevenly distributed, which is why a register must be asset-specific rather than estate-wide in principle only. Substations and control rooms sit at the sharp end: protection settings, disturbance records and operational logs depend on ordered sequences, and regulatory evidence may depend on those sequences being defensible. Traffic systems bring a different profile: roadside units, UTC and local-time conventions, signal controllers and analytics platforms that may each apply daylight-saving rules at different moments. Building controls add long-tail equipment, much of it with weak network security and limited observability. Outdoor robots add mobility: a machine that moves between sites may change time sources without changing its assumptions.

The common mistake is to audit only the servers. The register must follow the timestamp to the point of origin. That means recording the source hierarchy for each class of asset, the sync protocol in use, the nominal accuracy, the holdover behaviour, the last verified offset, the method of verification and the owner of remediation. It should distinguish between a device that is traceable to a national time scale and a device that is merely receiving a plausible signal. It should record known exceptions, such as isolated equipment with manual time entry, rather than leaving them out of scope because they are inconvenient.

What the ledger should hold

A useful clock-integrity ledger is not a spreadsheet of hostnames. It is a structured record with a schema stable enough to be queried and granular enough to support engineering decisions. At minimum it should capture the asset or system identifier, its location, its criticality, its time source, its upstream reference, its sync mechanism, its drift budget, its measured offset at last check, its holdover capability, its last verification date, the verification method, the evidence location and the accountable owner. For mobile or outdoor systems it should also capture the time-source history as the asset moves between environments.

The register should be linked to change control. A firmware update, a network reconfiguration or a new virtualised service can alter time behaviour without touching the asset record. If the ledger is not part of the change process, it will age into fiction. It should also be linked to incident management: when a sequence-of-events dispute arises, the first question should be whether the relevant clocks were within tolerance at the time. That question is answerable only if the estate has been recording the answer before the dispute.

Contracting for accountable seconds

Procurement is where many time problems become permanent. Contracts often require synchronisation without defining accuracy, verification, holdover or evidence. A stronger approach is to specify the time-service outcome: the required accuracy at the point of use, the permitted holdover period, the behaviour on loss of reference, the alarms that must be raised, the logs that must be retained and the right to audit the source chain. Acceptance testing should include a deliberate loss of GNSS or reference time, not merely a check that the device displays the correct hour.

Suppliers should be asked to declare their time architecture rather than merely assert compliance. Where a system depends on a cloud service or a mobile network for time, the contract should say what happens when that dependency degrades. Where a vendor provides an appliance, the estate should know whether it can be monitored independently and whether its holdover performance is evidenced or estimated. These are not exotic requirements. They are the time-domain equivalent of asking for a failover test rather than a failover diagram.

Proving that a second is a second

Verification is the hardest part. A device that reports its own offset may be reporting against the same faulty reference that caused the drift. Independent checks matter: a trusted reference traceable to the national time scale, a measurement path that does not share the estate's normal sync chain, and retained evidence that can be produced after an incident. The National Physical Laboratory's time scale provides a UK anchor for traceability, but traceability is a chain, not a sticker. The estate must be able to show the chain from the reference to the timestamp in dispute.

For compliance evidence, the register should support a simple statement: at the time of the event, this asset was synchronised to this source, within this tolerance, verified by this method, with this holdover status. That statement is far more useful than a dashboard showing green ticks. It also gives auditors and regulators something concrete to test, and gives engineers a basis for deciding which assets need better clocks and which need better procedures.

Starting in 2026

No estate needs to instrument everything at once. A sensible start is to prioritise assets where time affects safety, control or regulatory evidence, then extend to systems where timestamp correlation supports commercial or operational decisions. The first pass can be deliberately modest: identify time sources, map dependencies, record known exceptions and run a small number of verification tests. The value comes from making the ledger a living control, reviewed when systems change and consulted when sequences are disputed.

The unsynced estate is not a hypothetical risk. It is the normal condition of any organisation that has added digital systems faster than it has added time governance. The remedy is not a single grand clock. It is a register that tells the truth about which clocks are trusted, how far they may drift and what evidence exists when someone asks whether a second really was a second.