Time Risk Overview

System time is a root-of-trust dependency. Any system that depends on the ordering, validity, or non-repudiation of events depends on accurate time — and most organisations have left this dependency entirely unmanaged.

Adversarial time drift exploits this quietly. An attacker does not need to break TLS or compromise a host. Shifting the system clock silently invalidates TLS certificates, expires DNSSEC signatures, breaks distributed database consistency, and corrupts audit trails — without triggering a single IDS alert. The failure mode is indistinguishable from hardware fault or network jitter.

Who depends on accurate time

The scope is broader than most security reviews reach:

• Distributed databases — Cassandra, CockroachDB, and similar systems use timestamps for conflict resolution and causal ordering. Clock drift between nodes corrupts consistency under concurrent writes.
• DR and failover — when a primary site fails, the DR site must determine which data is most recent. Disagreeing clocks between primary and replica make this determination unreliable.
• Hypervisor clusters — clock stutter under CPU load causes hypervisors across an estate to drift relative to each other, producing split-brain scenarios during failover.
• TLS certificates — validity windows depend on the server knowing what time it is. A clock shifted by days causes valid certificates to appear expired, or allows expired certificates to pass validation.
• Kerberos authentication — Kerberos enforces a 5-minute clock skew tolerance. Beyond that, authentication fails across the domain without any credential compromise.
• Log correlation — when debugging incidents across distributed systems, logs from different hosts must be ordered by time. A 30-second offset between servers makes the sequence of events in an incident unrecoverable.
• API replay prevention — timestamp-based request validation rejects queries outside a defined window. A drifted clock causes valid requests to be rejected or allows replayed requests to pass.
• Regulatory audit trails — in any sector where timestamped logs are evidence — finance, healthcare, government, telecoms — the provenance of those timestamps is a legal question, not just a technical one.

The attack surface

The risk has two dimensions. The first is jurisdictional and forensic: public NTP is anonymous foreign infrastructure with no contract, no chain of custody, and no legal accountability to Cambodian regulators. The second is technical: attack vectors against unauthenticated NTP are documented, unpatched by design, and accessible to any motivated adversary with an internet connection.

Each section below covers one dimension — and how CNX Precision Time addresses it.

A third dimension — record attestation — is covered separately. Clock synchronisation proves your servers know the correct time. It does not prove to a third party when a specific event occurred. When internal systems control both records and their timestamps, manipulation leaves no external trace. The Timestamp Authority addresses this.