Time Synchronization for Reliable Security Evidence

When video shows a person at 9:03, an access event says 9:07 and an alarm record says 8:04, the customer has more than a clock problem. Investigators may search the wrong period, misread the order of events and spend avoidable time explaining which record is trustworthy.

The practical choice is to give cameras, access control, alarms and their servers an approved time hierarchy, define an acceptable offset, alert when a clock exceeds it, and test one event across every system. Many organizations can keep their existing infrastructure if it already provides reachable, resilient and monitored time. Others need an internal relay for a segmented security network or dedicated redundant sources where continuity and timing accuracy justify the added cost. The goal is a timeline the customer can reconstruct without guesswork.

What does a mismatched timestamp cost the customer?

The immediate cost is investigation effort. A reviewer may need to search wider time ranges, compare several clocks manually and explain discrepancies before deciding what happened. A larger offset can hide the relationship among a forced-door alarm, a card transaction, a camera view, a monitoring-centre record and an IT event.

Public end-user discussions about surveillance systems repeatedly ask whether incorrect time weakens evidence and why a camera, recorder and viewing application show different times. Those discussions are useful demand signals, not proof of legal consequences or prevalence. The customer-facing lesson is clear: people expect the displayed time to help them find and correlate an incident, and uncertainty becomes visible at the worst possible moment.

The United Kingdom government’s video-evidence recovery guidance gives a useful investigation practice: compare the CCTV system time with a reliable source, record any discrepancy in the audit trail and account for it when retrieving footage, especially when records from multiple systems must be compared. This is UK policing guidance rather than Canadian legal advice. Its practical method helps avoid changing a system clock before the original offset has been recorded.

If a discrepancy is discovered during an event:

1. preserve the original recordings and logs under the organization’s approved process;
2. record the displayed clock, reliable reference time, observed offset, time zone and daylight-saving setting;
3. identify whether the camera, recorder, access controller, application and export apply separate clocks;
4. avoid resetting devices until the current condition and relevant records are documented; and
5. involve the organization’s investigation, privacy, legal and technical roles according to the matter.

Time synchronization supports reliable interpretation. It does not, by itself, establish authenticity, continuity, identity or legal admissibility.

Which time-source option fits the security environment?

Choose the smallest architecture that meets the customer’s investigation, cybersecurity and availability needs. A new appliance is unnecessary when an existing approved service can provide the required outcome.

Option	Best fit	Customer advantages	Questions and trade-offs
Existing enterprise or domain time hierarchy	Security servers and devices can safely reach approved internal services	Reuses supported infrastructure and existing IT ownership	Can every device and isolated segment reach it? Are security devices permitted clients? Who monitors failures?
Internal security-network relay	Cameras and controllers sit on a restricted VLAN or separate operational network	Limits direct external access and creates one controlled distribution point	What feeds the relay, what happens if it fails, and can legacy devices use primary and secondary sources?
Dedicated resilient time service	Multi-site or high-consequence environments need stronger independence, availability or traceability	Can provide controlled redundancy, holdover and specialized monitoring	Adds hardware, support, power, network, security and lifecycle responsibilities that must be justified

The Canadian Centre for Cyber Security’s March 2025 SIEM implementation guidance recommends synchronizing network devices to a central time server so audit logs use the same source. For maintenance and troubleshooting, it recommends a minimum of three time servers. The publication addresses large enterprise cybersecurity and SIEM programs. It does not set a legal or universal physical-security architecture for every commercial property.

For a typical connected security environment, IT can maintain upstream authoritative sources and approved internal distribution. The security integrator configures the actual cameras, controllers and servers to use that hierarchy. The customer should avoid a design where each device independently selects an undocumented public server or where an isolated device silently free-runs because network policy blocks its configured source.

The network work should be included in the commercial networking and data-wiring scope when switches, firewalls, VLANs, DNS or resilient paths must change. A time-source address entered into a device has limited value if routing, name resolution or firewall policy prevents the device from reaching it.

What should the customer specify instead of “enable NTP”?

“Enable NTP” leaves the important decisions unresolved. A useful requirement defines the source hierarchy, client population, trust controls, representation, acceptable offset, monitoring and failure response.

NIST Special Publication 800-213A’s IoT cybersecurity requirement catalogue provides a strong decision model. It describes device capabilities for synchronization with a verified time source, timestamps that can be translated to Coordinated Universal Time, and logging when timing strays beyond an organization-set threshold. The publication is written for United States federal IoT acquisition, so a Canadian commercial organization must tailor it to its own environment.

Specify these items:

• Authoritative hierarchy: primary and fallback upstream sources, internal relays and which clients use each tier.
• Time representation: UTC mapping, local display rules, explicit offset and daylight-saving behaviour.
• Tolerance: maximum permitted difference for each evidence use case, with tighter requirements only where they change a decision.
• Measurement: which platform calculates offset, how often it checks and whether device status can be exported.
• Alerting: threshold, persistence, severity, recipients, acknowledgement and escalation.
• Failure behaviour: how long a device can free-run, what operators see, which compensating action applies and how recovery is verified.
• Change control: who may alter source addresses, time zones, daylight-saving rules and manual clock settings.
• Audit evidence: configuration baseline, source status, offset history, change record and test results.

Use addresses or names consistently. If a device receives its time source through DHCP, confirm what it receives on every relevant network. If static server names are used, include DNS as a dependency. If IP addresses are fixed, define how source replacement will be managed. Where the platform supports authenticated time, assess compatibility and trust management with the IT security team rather than assuming that all security devices implement the same mechanism.

How accurate is accurate enough?

The customer should set accuracy from the sequence they need to reconstruct. There is no useful universal threshold for every property, camera and investigation.

Start with representative questions:

• Could the offset reverse the apparent order of a card read and a door opening?
• Could it associate an alarm with the wrong person or vehicle on video?
• Could it cause an investigator to miss footage during a narrow search?
• Could different sites or monitoring records be compared without a manual correction?
• Can the organization explain the time zone and offset in an export months later?

Then define a maximum offset and a warning threshold with the customer, IT team and system specialists. Include measurement uncertainty and network delay where they matter. A product default can be a starting point, but it is not the customer’s requirement.

Official vendor documentation illustrates why the installed platform must be checked. The current AXIS Camera Station Pro manual exposes the device’s NTP source, UTC time, server-time offset and synchronization status. It can generate an alarm when the difference between a device and server exceeds two seconds. That two-second value is a product capability, not a universal evidence standard.

Genetec’s February 2026 Security Center time-synchronization guidance says synchronization is required for the platform to process timestamps for events and video archives and assigns management of time synchronization to IT or the Windows domain. The guidance applies to listed Security Center versions. Other products can assign timestamps at the camera, controller, server, cloud service or receipt point differently.

During procurement, ask the vendor to identify every clock that can affect:

• live video and burned-in overlays;
• recorded video and edge-storage retrieval;
• camera analytics and metadata;
• door-controller transactions and access-server events;
• alarm-panel, receiver and monitoring-centre records;
• workstation display and exported files; and
• API, integration, ticket and SIEM records.

The answer should show which timestamp is authoritative for each record and which clocks are merely presentation layers.

Who owns the service after installation?

Time synchronization crosses organizational boundaries. Assign responsibility before handover so a quiet clock failure does not remain invisible.

Responsibility	Typical accountable role	Evidence to retain
Upstream source and internal relay	IT infrastructure	Approved architecture, source status and maintenance record
Network reachability and trust controls	Network or cybersecurity team	Firewall rules, route, DNS dependency and security review
Device and platform configuration	Security system owner or qualified service provider	Asset-level source, zone, time-setting and software baseline
Offset and failure monitoring	Security operations or IT monitoring	Threshold, alert route, acknowledgement and trend history
Investigation procedure	Investigations, privacy and legal roles	Export procedure, time-check form and evidence-handling record
Acceptance and periodic testing	Named customer project or service owner	Cross-system test results, exceptions and corrective actions

Recurring cost can include relay or appliance support, monitoring licences, log storage, certificate or key management, replacement hardware and labour to test multiple sites. One-time effort can include inventory, legacy-device remediation, firewall changes, switch configuration, travel, commissioning and documentation. Ask bidders to separate these items so a low installation price does not hide ongoing ownership.

Vendor lock-in becomes relevant when offset monitoring, source configuration or audit history exists only inside a proprietary platform. Ask whether the customer can export the device inventory, time-source settings, offset status, alarms and change records in a usable format. The security system health-monitoring plan should treat loss of time service and stale synchronization status as operational conditions with named owners.

How should the complete timeline be tested?

Use one controlled physical event that creates records in several systems. A card presentation at a test door can generate an access event, associated camera view, door-position event, video bookmark or integration record. Where approved, a test alarm can add a monitoring record. Never disrupt egress or life-safety functions.

Before the event, record the approved reference time and the current synchronization status of every participating component. Perform the action once, then collect the records without manually changing clocks.

The test passes when:

1. each expected record exists and identifies the correct asset;
2. timestamps map unambiguously to the approved time reference;
3. measured offsets remain within the customer’s documented tolerance;
4. the sequence is consistent with the observed action;
5. local display, UTC mapping and exported evidence can be explained;
6. the source and offset status can be retrieved for the test period; and
7. failures create an actionable alert and owned response.

Repeat with the primary time source unavailable. Confirm that the fallback or holdover behaviour matches the design, that the outage becomes visible and that clients recover without an unexplained jump or missing record. Repeat affected tests after firmware, platform, network, domain, time-source or daylight-saving configuration changes.

For a commercial security camera system, also compare the video overlay, recorder timeline, export player and file metadata. They may represent time differently. The deliverable should state which representation investigators use and how they record a discrepancy.

What should appear in the quote and handover package?

Give every bidder the same customer-centred requirements and request evidence instead of a general assurance that the system “uses NTP.”

Ask:

1. Which existing customer time services can this design safely reuse?
2. Which devices cannot use the proposed primary and fallback sources?
3. Does any device require direct internet access, DNS or a proprietary cloud time service?
4. Which component timestamps each type of event and export?
5. What offset is acceptable, who approved it and how is it measured?
6. How are source loss, excessive drift and manual clock changes reported?
7. What happens to timestamps during restart, network loss, battery depletion or failover?
8. How are time-zone and daylight-saving changes controlled across sites?
9. Which licences, services and recurring costs enable synchronization monitoring?
10. Can the customer export configuration, offset history, alerts and test records?
11. Which cross-system and source-failure tests are included at acceptance?
12. Who owns each fault after warranty and how is restoration verified?

Require a time-source diagram, asset configuration schedule, dependency and firewall record, tolerance decision, alert matrix, investigation time-check procedure, acceptance results and exception register. A clear handover lets the customer maintain an adequate existing design, target a limited remediation or justify a more resilient service based on evidence.

Securitron Canada can help GTA organizations inventory security-system clocks, align the design with approved IT services and test whether video, access-control and alarm records form a reliable timeline.