Before the Token Expires: Why Trustworthy Time Deserves a Place in UK Zero-Trust Assurance

A zero-trust programme is usually described through identity, device posture, segmentation and policy enforcement. Time is seldom on the slide. Yet every short-lived token, certificate validity window, session timeout, log entry and forensic timeline depends on a shared belief in what time it is. When that belief is wrong, access controls do not always fail loudly. They fail quietly, and the evidence used to prove that they worked becomes contestable.

For UK organisations, the problem is not theoretical. Time distribution depends on global navigation satellite systems, telecommunications links, national time services and an estate of servers, switches and virtualisation platforms that may have been configured years ago and rarely examined since. In a zero-trust model, where trust is meant to be continuously evaluated, an unmonitored clock is an unmonitored control.

The quiet dependency behind every access decision

The modern access decision is full of time assumptions. A JSON Web Token is accepted only between its not-before and expiry claims. A mutual TLS session depends on certificate validity dates and revocation data that must be fresh enough to matter. Kerberos has long relied on bounded clock skew. Conditional access policies may allow a session for a fixed period before re-evaluation. Audit logs are correlated by timestamp, and incident responders reconstruct an attack from the order in which events appeared to happen.

Zero trust increases the sensitivity to drift because it deliberately shortens the life of credentials and sessions. That is a sound design choice. It reduces the window in which stolen material can be used. But it also means that a clock error of minutes rather than hours can cause authentication failures, premature token rejection or, worse, acceptance of a credential outside its intended validity period. The control has not been defeated by an attacker in the conventional sense. The environment has simply stopped agreeing on the time.

How time sources fail

Most organisations inherit a time architecture rather than design one. A router points to an internal server; that server points to a public pool; a virtualisation cluster takes time from a host; a GPS receiver sits in a rack because it was installed for something else. Each step is reasonable. Together they can create a single path with no authentication, no diversity and no monitoring.

Unauthenticated NTP is vulnerable to spoofing and interference. GPS signals are weak by the time they reach a receiver and can be jammed or spoofed. A grandmaster clock in a PTP deployment may be well engineered but still represents a concentrated dependency. Cloud workloads inherit the provider's time service, which is usually robust but not automatically aligned with the assumptions made by on-premises applications or by regulators asking for evidence. Virtual machines can drift when hosts are overloaded. Leap-second handling and smearing policies can create their own discontinuities if applications are not designed for them.

The UK context adds a further reason for care. Critical services, communications networks and data centres increasingly rely on satellite-derived timing, while awareness of interference and resilience gaps has grown. Treating time as a utility that simply arrives is no longer defensible for organisations that claim to operate a zero-trust model.

Make time a governed control

The first step is not to buy a caesium clock. It is to establish ownership. A named function should be accountable for time as a security and resilience dependency, with representation from network operations, platform engineering, security assurance and service owners. The inventory should record where time comes from for each class of service, how it is distributed, which applications depend on it, and what skew is tolerable.

That tolerance should be explicit. A collaboration platform may tolerate a minute of drift without material harm. A certificate authority, a financial trading system, a security information and event management platform or a regulated audit trail may not. Once tolerances are defined, monitoring can be designed around them rather than around the availability of a server.

Governance should also decide how the organisation behaves when time is degraded. Some services should fail closed. Others should enter a restricted mode. None should continue silently while pretending that access decisions remain fully assured. A time incident should be exercisable in the same way as a identity provider outage or a network segmentation failure.

A resilient architecture in practice

A defensible design uses layered sources and authenticated distribution. Where public NTP is used, Network Time Security provides authentication and should be preferred over legacy unauthenticated configurations. PTP deployments should be designed with security and monitoring in mind, not only precision. GPS-derived references should be treated as one input among several, with holdover capability sized to the organisation's tolerance for loss. Internal distribution should be hierarchical, documented and monitored at the endpoint as well as at the source.

Diversity matters, but so does independence. Two sources that share the same upstream path are not true diversity. Holdover matters, but so does knowing how long a local oscillator can maintain acceptable accuracy under load and temperature variation. Monitoring matters most of all: drift against an external reference, source changes, authentication failures, satellite signal anomalies and the percentage of endpoints outside tolerance should all be visible to operations and to assurance teams.

Cloud estates need the same discipline. Provider time services should be used deliberately, with application assumptions documented and cross-checked against on-premises systems. Where workloads span environments, the organisation needs a single narrative for how time is compared and how discrepancies are investigated.

Evidence that survives scrutiny

For audit and assurance teams, the question is not simply whether time synchronisation exists. It is whether the organisation can demonstrate that access decisions and audit records were produced under trustworthy time conditions. That means retaining configuration baselines, drift measurements, alert histories, test results and change records. It means being able to show what happened during a degraded period and why the chosen response was appropriate.

This evidence should be tied to the controls it supports: certificate validation, token issuance, session management, logging integrity and incident reconstruction. A control narrative that says identity is continuously verified, while leaving the time source undocumented, has a gap that a competent reviewer will find.

A practical next quarter

In 2026, few UK organisations need a wholesale timing programme. Most need a bounded one. Assign an owner. Inventory the sources and distribution paths for the ten most security-sensitive services. Define tolerable skew for each. Enable authenticated time where it is missing. Add drift telemetry at endpoints and at the source. Run a tabletop exercise in which GPS is lost and an internal source is suspected of spoofing. Record what breaks, what alarms and what evidence survives.

Zero trust is often framed as the discipline of not assuming trust. Time is one of the assumptions most easily overlooked and most deeply embedded. The clock is not a background utility. It is part of the control plane, and it deserves to be assured accordingly.