Meta's public time service now cryptographically signs the clock
Network Time Security is live at nts.meta.com, letting devices check that the time they receive really came from Meta and was not altered in transit.

Meta has switched on Network Time Security across its public time service, so devices that ask the company what time it is can now verify the answer instead of taking it on trust. The service answers at nts.meta.com and the company has open-sourced the protocol, server and client code that make it work.
Why an unauthenticated clock is a security problem
NTP has gone without authentication since 1985. A client sends 48 bytes, something sends 48 bytes back, and the client believes it. There is no signature and no identity behind the reply, yet that reply is the input that every certificate, token and signature is measured against.
Certificate validation compares notBefore and notAfter with the local clock, token expiry is a claim about a clock, and replay windows depend on knowing the time. Meta argues the check is circular: you cannot validate a certificate without already knowing the current time, so devices either skip validation until the clock is set or quietly widen their tolerance windows.
The tolerance trick was survivable when a publicly trusted TLS certificate lasted 398 days. The CA/Browser Forum's SC-081v3 ballot cuts that to 200 days from March 2026, 100 days from March 2027 and 47 days from March 2029. Meta points out that at 47 days renewal becomes an unattended, roughly monthly loop, so a host with a skewed clock reissues or fails on a schedule nobody is watching.
How NTS splits key exchange from time
NTS runs in two phases. Key establishment is TLS 1.3 over TCP port 4460, where client and server agree on an authenticated encryption algorithm and derive two session keys, after which the server hands over eight cookies and points the client at the NTP server it should actually use. Standard NTPv4 then runs over UDP port 123 with NTS extension fields, and the replacement cookies ride inside the response authenticator rather than in the clear.
Meta says its servers hold no per-client state. Rather than replicating a cookie key ring, each server derives its sealing key from a shared master secret and the current epoch day number, accepts two days back and one forward, and can therefore open a cookie it has never seen. A forged packet fails verification and is dropped without an NTS NAK, so a failure looks exactly like packet loss and cannot be used to push a client into a fresh key exchange.
The company is candid about the limit. An attacker who can hold your packets can still delay your clock by up to half the introduced delay, and RFC 8915 says as much: authentication tells you who wrote a packet, not how long it spent in flight. What an on-path attacker can no longer do is lie about the contents.
Our opinion
Time is the quiet dependency underneath everything else, and it has been running unauthenticated for four decades because it usually only meant a clock that was a few seconds out. Short-lived certificates turn that tolerance into a liability, because the safety of a 47-day credential rests entirely on the issuer and the checking host agreeing on the date.
Meta's decision to publish the protocol, server and client is the part that matters most here. A single vendor running an authenticated time service makes one company's clock more trustworthy; dragging NTP clients on Android and iOS into supporting NTS is what would make the internet's baseline clock verifiable. The honest admission that delay attacks remain out of scope is also a welcome change from the usual security-launch framing.