What Meta says is available
Meta's engineering post of October 6, 2026 says its public time service now supports Network Time Security, or NTS. Packets are authenticated, so a device can check that a reading came from Meta and was not altered in transit. Meta says the protocol, server and client code are open source through its Time library on GitHub, and it asks anyone who maintains an NTP client, particularly on Android or iOS, to add NTS support. Silver Owl analysis: that last line is the operational point. A server feature is only protection once the devices you actually run can use it.
Source: NTS: Authenticated Time at Meta · 2026-10-06 · Primary source context · attributed account
The clock behind every security check
Meta's case for bothering is short. Certificate validity windows are compared against the local clock. Credential expiry, fifteen minutes for example, is measured against a clock too. Replay windows need to know what time it is. When two hosts disagree, Meta notes, their correlated logs show a false order of events. Meta adds a detail that changes the stakes: it says the CA/Browser Forum capped newly issued public TLS certificates at 200 days in March 2026, falling to 47 days in March 2029; at that point, Meta says, renewal moves to roughly monthly, unattended, usually over ACME. On a host with a skewed clock, Meta notes, that loop reissues or fails on a schedule nobody is watching.
Source: NTS: Authenticated Time at Meta · 2026-10-06 · Primary source context · attributed account
Authentication has a boundary
Meta is explicit about the edges. NTS stops an on-path attacker from forging packet contents. It does not stop that attacker delaying or dropping packets, and a held packet can shift a clock by up to half the delay with every byte genuine. In Meta's words, NTS "authenticates the path, not the answer": a server that is correctly configured but simply wrong still sends the wrong time, properly signed. Meta still calls for multiple independent sources, sanity limits, quorum and monitoring. There is also a cold-start problem. The key exchange runs over TLS, TLS wants a working clock, so a device with a dead real-time clock must get roughly right before its first handshake.
Source: NTS: Authenticated Time at Meta · 2026-10-06 · Primary source context · attributed account
Support is a client question
Meta says chrony and ntpsec implement NTS. It says Android's platform time synchronization is plain SNTP with no NTS path, and that it is not aware of NTS support in Apple's time setup; elsewhere Meta says both platforms still set clocks over unauthenticated packets. That is Meta's assessment, not an independent test. Our advice is modest. Ask whoever runs your IT which devices can authenticate their time source, which ones do today, and how a wrong reading would be noticed at startup and during the working day. Keep Meta's own list of limits beside the answers. This is not an incident. It is a check worth adding to the next review.
Source: NTS: Authenticated Time at Meta · 2026-10-06 · Primary source context · attributed account