What you need to know
Camera, recorder, access-control, identity, alarm, and network records become difficult to correlate when clocks disagree. Build a governed time hierarchy, measure offset, alert on drift, and prove behavior through outage and reboot tests.
Potentially affected
Organizations correlating camera video, access events, alarms, intercoms, identity records, servers, switches, firewalls, and investigation logs.
DSE recommendation
Inventory every clock and time source, define an approved hierarchy and tolerance by use case, monitor drift, and run documented commissioning, failover, restart, and daylight-saving tests.
Source fact: timestamps need a trustworthy reference
NIST’s IoT cybersecurity guidance says devices should be able to timestamp audit events, synchronize with a verified time source, translate timestamps to UTC or GMT, and report when time strays beyond a defined threshold. See NIST’s Cybersecurity Event Awareness capability. NISTIR 8161 Revision 1 likewise treats precise time and clock-offset information as important to useful surveillance-video exchange.
The Internet Engineering Task Force’s RFC 8633 recommends keeping Network Time Protocol software current, using enough time sources, considering diversity, restricting control messages, and monitoring for out-of-sync servers and suspicious behavior. It also warns that authentication cannot prevent every delay-manipulation attack. Synchronization is therefore an operated service, not a promise that every timestamp is exact.
DSE recommendation: define the timeline before configuring devices
Create an inventory of every system that originates, changes, displays, or exports time: cameras, encoders, recorders, video clients, access panels, readers, intrusion panels, intercoms, visitor systems, domain controllers, identity platforms, hypervisors, switches, firewalls, log collectors, and cloud services. For each, record the supported protocol, configured source, time zone, daylight-saving behavior, UTC handling, sync status, expected accuracy, authentication option, and what happens when its source disappears.
Then define an approved hierarchy. A common design uses authoritative external or enterprise sources feeding controlled internal time servers, with security devices acting only as clients. That is a DSE architecture recommendation, not a universal NIST topology. Some embedded devices support only SNTP, one server, an IP address instead of a hostname, or no authenticated mode. Document those limitations rather than assuming identical behavior.
Make offset visible
Set an organization-approved tolerance for each workflow. Door-event correlation may tolerate a different offset than frame-level analysis, distributed authentication, or industrial control. NIST SP 800-171 Revision 3 leaves timestamp granularity and synchronization to the organization and permits UTC, a fixed offset from UTC, or a local timestamp that includes its UTC offset. The defensible choice is the one the organization defines, verifies, and can explain.
- Monitor client state, selected source, stratum or equivalent quality indicator, last successful synchronization, and measured offset where the product exposes them.
- Alert when a device loses its source, changes source unexpectedly, steps its clock, crosses the approved threshold, or repeatedly restarts its time service.
- Keep configuration and change logs for the time servers themselves. Restrict who can change time, time zones, and source settings.
- Prefer UTC in centralized logs when supported, while preserving the offset needed to explain local wall-clock displays.
Test the whole evidence path
During commissioning, generate one authorized, harmless event that appears in several systems—for example, a test credential at a controlled door while a camera records and the access server logs. Compare the original device records, server records, video overlay, exported-file metadata, and centralized logs. Record the observed differences; do not adjust evidence after the fact to make it align.
Repeat the test after a camera or panel restart, time-server outage, network interruption, recorder failover, firmware update, and daylight-saving transition where local displays are used. Check a device that has been disconnected long enough for its clock to drift. Confirm what operators see when synchronization is unavailable and whether alerts reach an accountable owner.
Handle an incident without rewriting history
If an investigation reveals a wrong clock, preserve the original records and document how the offset was measured, by whom, against which reference, and when. Do not rename files or edit overlays to create corrected evidence. A derived timeline may apply a documented correction, but it should remain traceable to the source timestamps and their uncertainty.
Time synchronization cannot prove that an event occurred, that a camera saw the correct scene, or that a log remained unaltered. It makes cross-system comparison more reliable. Pair it with protected logs, controlled administration, tested exports, and custody records.
Official sources
Review the official source
RFC 8633 — Network Time Protocol Best Current Practices · Verified August 4, 2026
Need help applying this guidance safely?
DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.
Talk with DSE