Time is a silent prerequisite of every IT infrastructure. Every log, every certificate, every replication, every authentication relies on a rarely questioned assumption: all machines share the same time.
When this assumption stops being true, everything breaks -- often without an immediate alert. Logs become inconsistent, certificates are rejected, authentication fails, backups lose their integrity. In virtualized environments, the risk is amplified by the very nature of virtual machines. And the most insidious aspect: time drift is gradual, invisible, and triggers no native alert on most systems.
Timestamping: The Invisible Foundation of IT
We only think about time when it malfunctions. Yet timestamping is the invisible glue of virtually every subsystem in an IT infrastructure.
Logging
Syslog, journald, application logs, firewalls: every event is timestamped. Correlation between different sources relies entirely on temporal consistency.
Certificates and encryption
TLS/SSL certificates, TOTP tokens, Kerberos tickets -- all integrate a temporal dimension into their validation mechanism.
Replication and consensus
Distributed databases, replicated file systems, and HA clusters use timestamps to order operations and resolve conflicts.
Scheduling
Cron jobs, schedulers, CI/CD pipelines, orchestrators: all depend on a reliable clock to trigger tasks at the right time.
The problem is not the outright failure -- a stopped clock is detectable. The real danger is gradual, invisible drift: a few milliseconds per hour that accumulate into minutes, then tens of minutes, without any system raising an alert.
Why Virtualization Amplifies the Risk
On a physical server, the hardware clock (RTC, TSC) provides a stable time base. In a virtualized environment, this stability disappears -- and with it, the temporal guarantees taken for granted.
A VM has no physical clock of its own
A virtual machine borrows its notion of time from the hypervisor via an emulated software clock. This abstraction introduces a layer of structural imprecision: the time perceived by the VM depends on the host's load, the number of allocated vCPUs, and contention with other VMs.
Clock drift amplified by vCPU scheduling
When the hypervisor preempts a vCPU (scheduling), the VM "loses" time without knowing it. Steal time -- the time during which the vCPU waits for the hypervisor to return control -- creates gaps in the VM's temporal perception. Under load, these micro-pauses accumulate and amplify drift.
Three scenarios where time jumps
Live migration
The VM is moved to another physical host. The memory transfer time creates a micro-pause -- and if the two hosts do not share the same time, the VM experiences a time jump.
High availability (HA)
During an HA failover, the VM restarts on a different node. The clock restarts from the new host's hardware state, with a potential offset.
Snapshot / Restore
Restoring a snapshot puts the VM back into a past state -- including its internal clock. The VM literally finds itself "in the past" until NTP resynchronizes it.
We detail the operational aspects of NTP synchronization in Proxmox environments -- chrony configuration, VM vs LXC choice, sysadmin checklist -- in our dedicated guide: Hosting a public NTP server on Proxmox.
Security Impact
Time desynchronization is not just an operational problem. It is a silent security vulnerability that compromises the protection mechanisms on which every infrastructure relies.
Kerberos and Active Directory broken
Kerberos incorporates an anti-replay mechanism based on timestamps: the default tolerance is 5 minutes between the client and the KDC (Key Distribution Center). Beyond that, tickets are rejected. In a virtualized environment, a clock drift of just a few minutes is enough to block authentication for all users in a domain -- without an explicit error message.
Forensic investigation impossible
In incident response, temporal correlation between logs from different systems is fundamental. If timestamps diverge between the firewall, authentication server, and application, reconstructing the timeline of an attack becomes guesswork. Evidence loses its value -- including in legal proceedings.
TOTP and 2FA compromised
OTP tokens (Google Authenticator, FreeOTP) rely on a shared secret and the current time, divided into 30-second windows. A one-minute offset between the validation server and the reference clock is enough to systematically invalidate codes -- rendering two-factor authentication unusable.
We analyze the TOTP/NTP dependency in detail on ntp.rdem-systems.com -- TOTP and NTP. To strengthen your synchronization security, discover how to secure NTP with NTS.
Data Impact
Beyond security, time desynchronization directly compromises the integrity and reliability of data that the infrastructure is supposed to protect.
Database replication
Replication systems (Galera, MySQL Group Replication, PostgreSQL logical replication) use timestamps to order transactions and resolve conflicts. An offset between nodes causes sequence conflicts, silently corrupted data, and in the worst case, split-brain scenarios where each node believes it holds the correct version.
Backups and retention
Inconsistent timestamps corrupt retention policies: a "future" backup may be kept indefinitely or deleted prematurely. Incremental snapshots lose their consistency if the time delta between two captures is wrong. And the correlation between a backup and the actual system state at the time of capture becomes unverifiable.
The integrity of timestamped backups relies on reliable time -- a prerequisite we systematically integrate into our NimbusBackup offerings. We detail the full approach in our Proxmox 3-2-1 backup strategy.
Orchestration and automation
Cron jobs that trigger twice or not at all. CI/CD pipelines whose steps execute out of order. Kubernetes schedulers that miscalculate timeouts. All these scenarios become possible as soon as a node's clock drifts -- and diagnosis is rarely intuitive.
Business Impact by Sector
Time desynchronization is not a purely technical problem. In certain sectors, it has direct regulatory, legal, and financial consequences.
Finance
MiFID II requires precise timestamping of financial transactions. Algorithmic trading systems demand microsecond synchronization. Even a minimal offset can cause sequencing errors, non-compliant audits, and regulatory sanctions.
Healthcare
Patient records, medication administration traceability, medical act timestamping: inconsistent time compromises regulatory traceability and can have direct consequences on patient safety.
Industry
SCADA/OT systems rely on real-time event correlation for industrial process supervision. Desynchronization between PLCs and the monitoring system can mask critical anomalies.
What a CTO Should Demand from Their Managed Service Provider
NTP synchronization is not an implementation detail. It is an infrastructure prerequisite that should be part of your managed service provider's contractual commitments -- on the same level as network availability or backup policy.
Local Stratum 1 time source
Do not rely solely on public NTP servers over the Internet. Demand a Stratum 1 source (GNSS/GPS) operated locally by your provider. Network latency and third-party dependency are not acceptable for such a critical service. To learn more, discover how to understand the NTP protocol and its reliability mechanisms.
NTP monitoring integrated into supervision
Clock drift triggers no native alert on most operating systems. Your provider must actively monitor the NTP offset of every machine (physical and virtual) and alert beyond a defined threshold -- typically 100 ms.
Verifiable compliance evidence
Ask your provider to prove the quality of their synchronization. Tools like check-ntp.net allow public verification of an NTP server's status -- stratum, offset, reference. If your provider cannot offer this transparency, question why. Also see our NTP firewall configuration guide to ensure your network rules do not interfere with synchronization.
Time source redundancy
A single NTP server is a SPOF (Single Point of Failure). Demand a redundant architecture with multiple Stratum 2 servers, ideally distributed across different geographic sites and autonomous systems (ASes) to withstand site failures.
For a complete view of our managed services offerings including NTP supervision: managed-services.rdem-systems.com.
The RDEM Systems NTP Infrastructure
RDEM Systems does not just recommend NTP synchronization -- we operate our own time infrastructure, open to the public, since 2005.
Stratum 1 GNSS
GPS/Galileo receivers with PPS (Pulse Per Second) signal for microsecond accuracy. Time source independent of the Internet.
Distributed multi-AS, multi-DC pool
~10 redundant Stratum 2 servers distributed across Equinix Paris and OVH Frankfurt, on different Proxmox clusters.
French NTP pool contribution
~10 servers out of the 366 in the French NTP pool (pool.ntp.org). An active contribution to public time infrastructure since 2005.
24/7 monitoring and on-call
Integrated NTP offset supervision, automatic drift alerts, 24/7 on-call. Publicly verifiable on ntp.rdem-systems.com and check-ntp.net.
Our autonomous network AS206014 and our multi-datacenter infrastructure ensure that NTP synchronization does not depend on a single network path or a single site.
Frequently Asked Questions
Why is Kerberos particularly sensitive to time drift?▼
How does virtualization amplify the risk of clock drift?▼
What are the risks of NTP desynchronization on backups?▼
What should a CTO demand from their managed service provider regarding NTP?▼
Why do desynchronized logs compromise security?▼
Can NTP desynchronization have a regulatory impact?▼
Need a reliable NTP infrastructure?
RDEM Systems operates its own Stratum 1 time infrastructure, integrated into 24/7 supervision for all our clients. Discover our NTP audit service to prevent these risks (fr).