NTP and Clock Drift in CCTV Systems

Every camera and recorder keeps time on an inexpensive internal oscillator that gains or loses seconds per day as a matter of physics - faster with temperature swings, which security hardware in cabinets and outdoor housings experiences constantly. Without correction, a device typically drifts minutes per year; poor units drift minutes per month.

Correction means NTP - the device periodically synchronizing against a time server. Drift problems are therefore almost always NTP problems: no server configured, a server that is unreachable from the camera VLAN, a firewall rule that silently blocks UDP 123, a recorder configured against a decommissioned server, or devices syncing to different sources that themselves disagree. DST handling adds its own class of failures, with devices applying offsets twice or not at all.

• Evidential weakness

  A timestamp is a claim. When the recorded clock is provably minutes off, every timestamp from that system becomes arguable - a gift to opposing counsel.

• Broken cross-system correlation

  Investigations align video with access-control events, alarm logs and transaction records. Three minutes of drift can place a person at a door before the badge event that opened it.

• Failed multi-camera reconstruction

  Tracking movement across cameras requires their clocks to agree. Drift between cameras turns a clean sequence into contradictory fragments.

• Misleading searches

  Operators search the archive by time. If the recorder is five minutes behind, footage of a 14:00 event lives at 13:55 - and a hurried search concludes the event was not captured.

The stable pattern for security networks:

• One authoritative internal time source for the security VLAN, itself synced upstream (or GPS where isolation demands)
• Every camera AND every recorder synced to that same source - not a mix of vendor defaults and public pools
• Firewall rules that explicitly permit NTP from all device subnets to the source
• Identical timezone and DST settings across devices, verified after every firmware update
• A written check of actual displayed time versus reference at commissioning - configuration does not prove synchronization

Configuration decays: servers get decommissioned, rules change, updates reset settings. The only durable answer is treating clock accuracy as a monitored health property - reading each device's time on schedule, comparing it to reference, and alarming past a threshold measured in seconds, not minutes.

IOSentra runs clock-drift checks as part of its standard verification cycle across cameras and recorders. A drifting device opens an incident before its offset reaches evidence-threatening territory, and the fix is re-verified like any other fault. Combined with recording verification, this closes both halves of the evidential question: the footage exists, and its timestamps can be trusted.