Trusted time is a security control: why logs need reliable clocks

Poland’s National Institute of Telecommunications has highlighted an infrastructure component that rarely leads the security agenda: trusted time synchronisation. At the 10th IT Security in Public Administration Forum, its experts showed that reliable clocks underpin log analysis, incident reconstruction and the correct operation of some retention and backup processes.

Systems can agree with one another while all showing the wrong time relative to the outside world. If an upstream source has been disconnected or is supplying incorrect data, internal logs may look consistent yet fail to align with records held by a telecommunications operator, cloud provider, partner or law-enforcement body.

Breachroad’s conclusion: time synchronisation is not merely an administrator’s task. It is a security control with an owner, monitoring, failure scenario and test. Without it, even an expensive SIEM can create a precise picture of events in the wrong order.

Why time determines evidence quality

Incident analysis brings together events from many sources: a user login, privilege change, process launch, data access, network traffic, an EDR alert and a cloud operation. Each system records a timestamp that allows the team to build a common timeline.

When one clock differs by several minutes, analysts may mistake an effect for its cause. With a larger offset, they may search the wrong interval and conclude that a provider does not hold the relevant logs. The problem becomes harder when an application records local time, infrastructure uses UTC and the report omits the time zone and offset.

The institute also highlights the risk of silently losing an external source. A system may continue on its own clock and drift gradually. If nobody notices before logs rotate, accurate reconstruction may become impossible precisely when it is needed most.

Agreement between devices does not guarantee correct time

The common check that “all servers show the same time” demonstrates consistency, not trustworthiness. Hundreds of devices can use the same faulty source. Two GNSS receivers likewise do not provide true independence if both share the same weakness or physical location.

Real redundancy requires an understanding of common dependencies. An organisation should know:

• where domain controllers, hypervisors, network devices, cloud systems and applications obtain time;
• which sources are primary and which are backups;
• how long a device maintains acceptable accuracy after source loss;
• how it reports failover, degradation or excessive offset;
• who receives the alert and owns the response decision.

The dependency map must extend beyond servers. Cameras, physical access control, industrial devices, telephony, transaction platforms and security tools also produce evidence whose value depends on time.

The effect on backup and retention

The institute notes that backup-retention mechanisms may depend on timestamps. In certain configurations, an incorrect or manipulated clock may alter how a system assesses backup age and when data qualifies for deletion.

This does not mean every clock change automatically deletes backups. The result depends on the product, policy and implementation. Organisations should test the behaviour instead of assuming that a system always relies on an independent, trustworthy time source.

A test scenario should establish what happens after source loss, a large offset, device restart and resynchronisation. Review backup scheduling, object age, deletion policy, immutability and alerts separately. A good backup is not merely an object visible in a console; it is data that can be located and restored during a failure.

A time-synchronisation assurance plan

1. Assign ownership and scope

Identify the owner of the time service and the consumers that depend on it. Infrastructure, networking, cloud, SOC, application owners and backup teams usually need to collaborate. Without shared scope, it is easy to secure the data centre while overlooking boundary appliances or SaaS systems.

2. Map sources and dependencies

For each system class, record the time source, network path, backup source, logging time zone and maximum acceptable offset. Include managed services where the provider controls time and note how historical status can be obtained during an incident.

3. Monitor state, not just availability

A response from a time service does not prove correctness. Monitoring should detect loss of the upstream source, a change in the selected source, growing offset and prolonged holdover. Thresholds should reflect system importance: a transactional environment may require tighter tolerance than an office appliance.

4. Test source loss and recovery

A controlled test reveals whether devices fail over, how quickly they drift and whether an alert reaches someone able to act. Test recovery as well. A sudden time correction may affect sessions, jobs and log ordering, so the return to normal operation also needs observation.

5. Standardise incident handling

Analysts should record the timestamp source, time zone, known offset and evidence-collection time. They should not correct timestamps by intuition without retaining the original value. A combined incident timeline must state which events were adjusted and on what evidence.

A rehearsed incident response plan and mature detection engineering and SIEM correlation process make this discipline easier.

Questions for service providers

For cloud, data-centre, backup or SOC services, ask:

• what the authoritative time source is and whether an independent backup path exists;
• how the provider detects source loss and excessive offset;
• which time zone is used for stored and exported logs;
• whether exports preserve sufficient precision and unambiguous zone information;
• how time affects retention, schedules and backup immutability;
• how historical offset information can be obtained during an incident.

“We use NTP” is the beginning of the discussion, not its conclusion. Organisations need evidence about sources, dependencies, observability and failure behaviour.

A low-risk exercise for organisations

Not every test needs to begin by disconnecting a production time server. A team can run a tabletop exercise using logs from four systems: one is seven minutes fast, another records local time without a zone, and a third lost synchronisation the day before. Participants must build the incident timeline, identify missing information and decide whether to escalate.

The exercise quickly reveals whether the SOC knows where to find synchronisation state, whether infrastructure retains offset history and whether the application owner understands timestamp format. Its output should be a short list of fixes, owners and deadlines—not merely a slide deck.

Source facts and Breachroad’s analysis

Poland’s National Institute of Telecommunications describes the importance of trusted time for correlating logins, privilege changes, data access and network traffic. It highlights unnoticed source loss, common weaknesses in apparently redundant receivers, and the dependency of some backup and retention mechanisms on time. It recommends knowing the source and path, holdover duration, loss detection and behaviour after disconnection.

The environment-wide map, monitoring thresholds, evidence standard, supplier questions and tabletop scenario are Breachroad recommendations. Organisations can rehearse the responsibilities through cybersecurity training for businesses and public bodies and assess logging, backup and monitoring assurance through an IT security audit.

Primary source: Poland’s National Institute of Telecommunications — Cybersecurity starts with the right time.