Key takeaways
- CCTV evidence and SCADA forensics both depend on timestamps being accurate, consistent and traceable to a known source. When a clock is wrong, the recording or the event log loses much of its evidential weight.
- Remote sites are particularly exposed. Devices that sit behind intermittent connections drift, sync to whatever NTP pool server they can reach, and quietly disagree with each other by seconds or minutes.
- The fix is architectural. A clean time hierarchy on site, with a single trusted local source that itself syncs to a known reference, removes most of the common failure modes and gives you something defensible if the timestamps are ever questioned.
Time synchronization is one of those topics that almost nobody thinks about until something goes wrong, and then it suddenly matters very much. The CCTV footage is needed for a prosecution, and defence counsel asks how the camera’s clock was set. A SCADA incident has to be reconstructed across three sites, and the event logs do not line up. An alarm signal arrives at the ARC with a timestamp twenty seconds before the system that triggered it. Each of these is preventable, and each of them comes back to the same root cause.
This piece walks through why time sync matters more than it gets credit for, what goes wrong on remote sites in particular, and what a defensible architecture looks like.
Why CCTV Evidence Depends on the Clock
UK and Irish courts have admitted CCTV evidence routinely for decades, but the bar on its provenance has risen steadily. Defence teams now regularly question the chain of custody, the integrity of the footage and, increasingly, the accuracy of the timestamps overlaid on it. The standards bodies behind evidential video, including BS EN 62676 and the related guidance from the Surveillance Camera Commissioner, all assume that timestamps are accurate and that the source of that accuracy can be demonstrated.
The practical problem is that most cameras and NVRs ship with a default NTP configuration that points at a public pool server somewhere on the internet. When the site has a steady, reliable connection, this works well enough. When the connection is intermittent, or when the camera cannot reach the pool server for any reason, the device falls back on its internal clock. Internal clocks drift. A camera that has not synced for a week can be seconds out, and across a multi camera installation the disagreement between devices compounds.
Two cameras, three seconds apart on a 60 frames per second video, are 180 frames apart on the recording. That is more than enough to change what a court considers as showing one event versus two, or to disagree about who was where in a crowd at a given moment.
Why SCADA and OT Forensics Depend on It Just as Much
If anything, OT environments depend on accurate time even more than CCTV does. Modern incident response and root cause analysis is built around event correlation. When a PLC trips, an HMI raises an alarm, a controller logs a status change and a SCADA server records an operator action, the order in which these things happened is often the entire story.
If the clocks on those devices disagree, the order can be wrong, the correlation can be misleading, and the conclusions drawn from the data can point at the wrong cause. In a regulated environment, particularly under IEC 62443 or NIS2 expectations, the integrity of event logs is no longer a nice to have. It is part of what auditors and incident investigators will look at.
The same logic applies across sites. An operator running fifty solar farms or two hundred remote treatment plants needs the events from all of them to share a consistent time reference, otherwise cross site correlation is impossible.
What Goes Wrong on Remote Sites
Remote sites concentrate every time synchronization weakness in one place. The connection is often slower and less reliable than a head office. The devices on site may be from multiple vendors, each with their own default NTP configuration pointing at different servers. Engineering teams rarely include time sync in their handover checklist. The site might be behind a CGNAT or a restrictive firewall that occasionally blocks NTP traffic without anyone noticing.
When the site goes offline, devices fall back on their internal clocks and start drifting. When the connection returns, devices catch up suddenly, and that jump itself can break event correlation, because a log that recorded a steady stream of events now contains a gap or an overlap depending on direction.
The deeper problem is that none of this is usually visible until you need the logs to be right. By then it is too late to fix the underlying configuration on the data you have already collected.
What a Clean Time Architecture Looks Like
The reliable pattern is straightforward, and it works the same way on a CCTV site, an OT site or a mixed estate.
A single device on each site acts as the local time source. Every other device on the site, cameras, NVRs, PLCs, HMIs, switches, points its NTP configuration at that one source rather than at a public pool. That local source itself syncs to a known, traceable reference, ideally over an authenticated path that does not depend on whichever public NTP server happens to respond fastest.
The advantages stack up. Every device on site agrees with every other device on site. The drift when the site loses its internet connection is bounded by the accuracy of the one local source, not by the worst clock in the building. The chain of custody is short, documented and defensible. And when an auditor or a court asks how the timestamps were set, the answer is one sentence, not a guess.
How Netcelero Fits
The i-ctrl is well placed to act as that single local time source on a site. It is always on, it is always connected to our core network via the management VPN, and it runs on Ubuntu 24 LTS with a properly maintained NTP implementation. Configured to serve as a local NTP source for the rest of the site, it gives you a clean time hierarchy without additional hardware.
The path that hierarchy takes is also documentable. Every device on site syncs to the i-ctrl. The i-ctrl syncs through the management VPN to time references in our core network in Dublin and Amsterdam. Those references in turn sync to authoritative sources upstream. If you ever need to demonstrate to a court, an auditor or an insurer how the time on a given device was set, the path is short and verifiable.
For sites where this matters most, particularly evidential CCTV and regulated OT, this small architectural addition removes an entire class of problem.
What to Do This Week
Three quick checks will tell you whether your remote estate has a time sync problem hiding in plain sight.
First, log in to a sample of your sites and check what NTP server each camera, NVR, PLC or HMI is configured to use. If the answer is “the default” or “different ones”, that is your first finding.
Second, compare the current time reported by two or three devices on the same site against a trusted external source. Any disagreement of more than a second is worth investigating, and a disagreement of minutes points to a device that has been drifting for some time.
Third, look at how you would document the chain of custody for time on a piece of footage or an event log if it was asked of you tomorrow. If the answer is uncomfortable, the architecture is the place to start, not the documentation.
Time synchronization is the kind of unglamorous detail that rarely makes the front page until it does. A small amount of attention now removes a problem that, when it arrives, has no good last minute fix.
Contact us today if you would like help building a clean time architecture across your remote sites, or to talk through how the i-ctrl can serve as a local NTP source on your estate.
