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.
\r\nThe 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.
\r\nCreate 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.
\r\nThen 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.
\r\nSet 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.
\r\nDuring 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.
\r\nRepeat 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.
\r\nIf 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.
\r\nTime 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.
\r\n