Your Computer’s Clock Belongs to the US Navy
When you write
time.Now, have you ever wondered where that value actually comes from?
Right now, your phone, laptop, bank servers, and even the satellites overhead are all silently asking the same question: What time is it?
And the answer they receive points to the same institution you’ve probably never heard of — a 19th-century observatory-style building in Washington, D.C. It houses over 100 cesium atomic clocks and hydrogen masers, serving as the single root of trust for the global internet’s time infrastructure.
Pretty fascinating, isn’t it?
Your Computer Doesn’t “Know” Time
Most developers never really think about this: the time displayed in the corner of your screen is not generated by your computer.
Computers have no reliable internal time source. CPU oscillators drift — sometimes by several seconds per day. Without correction, your machine would “drift off” into its own private timeline within weeks.
So every operating system includes NTP (Network Time Protocol) — a protocol that silently pings external servers every few minutes to correct the time. This process is completely transparent, automatic, and happens without your permission. You never configured it, never thought about it, yet it determines:
- Whether your SSL certificates are valid
- Whether financial transactions can settle
- Whether distributed databases remain consistent
- Whether your authentication tokens are accepted or rejected
So here’s the question: Who do these external servers trust?
NTP’s Trust Hierarchy: A Hidden Pyramid
NTP uses the concept of stratum to build a chain of trust that flows down from the most precise clocks on Earth.
Stratum 0 sits at the top: atomic clocks, GPS receivers, radio time signals. These are physical hardware devices that tick with nanosecond precision, but they don’t directly provide network services.
Stratum 1 servers connect directly to these atomic sources and begin distributing time to the internet. Stratum 2 syncs to Stratum 1, and so on, until the signal reaches your laptop, phone, or AWS container.
Every device in the chain completely trusts the one above it — with neither encryption verification nor authentication between levels.
And at the very top of this chain, for a significant portion of global internet infrastructure, sits an institution you may never have heard of: The United States Naval Observatory (USNO).
The US Navy: Guardian of Global Internet Time
The United States Naval Observatory was established in 1830, over a century before the Internet existed.
Its master clock — a cluster of 100+ cesium beam atomic clocks and hydrogen masers stored in an underground vault in Washington D.C. — generates UTC(USNO): the official U.S. reference for Coordinated Universal Time.
This isn’t metaphorical. USNO is the exclusive time reference provider for the GPS satellite system. Every GPS satellite in orbit carries atomic clocks that continuously compare and correct against UTC(USNO). And since GPS has become the most widely used Stratum 0 time source for global internet infrastructure, USNO’s atomic clocks are, in a very real sense, the heartbeat of the global internet.
NIST (National Institute of Standards and Technology) runs a parallel time service, and together they form the two pillars of American timekeeping. But the military dependency runs deeper: GPS time is a Department of Defense asset, originally built for military navigation. Civilian internet just “happened” to hitch a ride.
When Clocks Lie: What Breaks?
If time errors were harmless, this would be a mere academic curiosity. But reality is far different.
SSL/TLS certificates have notBefore and notAfter timestamps defining their validity. When server clocks drift, they may reject perfectly valid certificates (showing “not yet valid”) or accept expired ones. Google’s research found that incorrect system clocks are the #1 root cause of HTTPS certificate errors in production. In 2019, Microsoft Teams went down for three hours due to an expired certificate — ironically, accurate clocks could have flagged this issue days in advance.
Financial trading systems rely on timestamps to establish event ordering. High-frequency trading, payment processing, and clearinghouses all depend on synchronized clocks. Even a few hundred milliseconds of drift can scramble transaction order, trigger reconciliation failures, and in worst cases, create double-spend vulnerabilities.
Kerberos authentication — the protocol that protects nearly every enterprise Active Directory environment worldwide — has a hard-coded 5-minute tolerance window. When the client clocks drift more than 5 minutes from the domain controllers, authentication fails**. No helpful error message, no obvious fix, just locked-out users confused why their passwords suddenly “stopped working.”
Distributed databases such as CockroachDB, Cassandra, and Google Spanner rely on clock synchronization as a fundamental consistency primitive. CockroachDB’s architecture documentation explicitly states that correctness guarantees degrade when clock drift exceeds certain thresholds. And Spanner — Google’s globally distributed database — built its own GPS and atomic clock infrastructure precisely because it cannot trust internet time.
An Attack Surface Nobody Patches
Now things get truly unsettling.
NTP, in its most widely deployed form, has no authentication mechanism. Packets claiming to be from time.cloudflare.com look identical to those from malicious servers — there’s no cryptographic signature to verify.
Researchers at Boston University demonstrated in a peer-reviewed paper that attackers don’t even need to be on the network path between client and server. Using IPv4 packet fragmentation techniques, they can shift a victim’s clock by hours.
The implications cascade:
- Roll clocks backward to replay expired authentication tokens
- Roll them forward to make certificates appear expired before their actual expiration, triggering service outages on demand
- With sufficient offset, break the consistency guarantees of distributed systems — guarantees that those systems’ engineers thought were unshakeable
NTPsec and NTS (Network Time Security) exist as hardened alternatives with cryptographic authentication, but adoption remains low. Most servers, cloud instances, and IoT devices still run unauthenticated NTP, trusting a chain that ultimately leads to GPS satellites controlled by the U.S. Department of Defense.
A Single Point of Failure That Isn’t Redundant Enough
Internet architects designed the network to survive nuclear war: no single point of failure, naturally distributed. Yet the time infrastructure everything else depends on is surprisingly centralized.
GPS jamming and spoofing incidents are increasingly documented in conflict zones — the Eastern Mediterranean, around Moscow, and the South China Sea. When GPS signals are jammed, Stratum 1 servers relying solely on GPS receivers begin to drift. They don’t fail loudly; they fail silently, continuing to serve slowly, with an invisibly incorrect time.
In 2016, a software bug in one GPS satellite caused approximately 12 hours of time error, propagating through the NTP infrastructure across Europe, affecting telecom and network operators. One satellite’s bug, millions of systems affected.
This isn’t theoretical. It has happened, and it will happen again.
What Engineers Should Do
The appropriate response to all this isn’t panic — it’s turning awareness into architecture.
Use multiple time sources from geographically and organizationally diverse providers. Google (time.google.com), Cloudflare (time.cloudflare.com), and NIST (time.nist.gov) all operate public NTP infrastructure with different upstream dependencies. Running NTP with at least three sources lets the protocol’s own clock selection algorithm detect and reject outliers.
Enable NTS (Network Time Security). For any infrastructure that treats time integrity as a security property rather than a convenience, NTS adds authenticated key exchange to NTP, making man-in-the-middle attacks significantly harder. Chrony (the default NTP implementation for most modern Linux distributions) and Cloudflare’s time service both support NTS.
Monitor clock skew as a first-class metric. In distributed systems, clock drift between nodes is a leading indicator of consistency issues. Prometheus, Datadog, and most observability platforms can track this — though most teams only configure alerts after incidents occur.
Most importantly: understand what you’re trusting. Next time you write time.Now() in Go, call Date.now() in JavaScript, or query NOW() in PostgreSQL — that value traveled through a chain of trust: from atomic clocks in military facilities, through GPS satellites, down through server tiers you don’t control, to your screen, with no cryptographic guarantees anywhere along the way.
The Clock Keeps Ticking
The global internet — this distributed, decentralized, supposedly “trustless” system — has a single synchronized heartbeat. And a branch of the U.S. Navy maintains that heartbeat you may never have heard of, using a protocol designed in 1985, never built for 2026’s threat model.
The time on your computer isn’t yours. It never has. You’re just borrowing it from a chain of trust that starts with atomic clocks in Washington, D.C., passes through military satellites in orbit, and then through servers you don’t control, to the corner of your screen.
That chain holds up most of the time. But the question every engineer should ask isn’t whether it will break — it’s whether you’ll notice when it does.
Summary
- Your computer’s clock isn’t self-generated — it syncs from external servers via NTP, ultimately tracing back to GPS satellites and atomic clocks
- The United States Naval Observatory (USNO) is the core root of trust for global internet time infrastructure, its atomic clock cluster providing the reference for GPS
- Time errors can cause serious consequences: SSL certificate failures, financial transaction corruption, authentication failures, distributed database inconsistency
- NTP lacks authentication mechanisms, leaving it vulnerable to clock-shifting attacks by malicious actors
- Mitigations: use multiple time sources, enable NTS cryptographic authentication, monitor clock skew, and understand the nature of the trust chain
Tags: NTP, cybersecurity, distributed-systems, infrastructure, GPS, time-synchronization