DEV Community

Cover image for Meta Open-Sources Stateless NTS: Authenticated Time Without Server-Side Cookie State
AI Data Legends
AI Data Legends

Posted on Originally published at aidatalegends.com

Meta Open-Sources Stateless NTS: Authenticated Time Without Server-Side Cookie State

Time synchronization is easy to overlook in a distributed system, until a clock is wrong.

A data pipeline may process events correctly but order them incorrectly. A distributed database may struggle to reconstruct the sequence of writes. A certificate can appear expired or not yet valid, while a short-lived token can be accepted or rejected at the wrong moment. In AI infrastructure, these problems can affect job coordination, logs, credentials, and the reproducibility of operational workflows.

The Network Time Protocol (NTP) has long provided the mechanism for synchronizing clocks across networks. The security problem is that traditional NTP does not, by itself, authenticate the source of a time response. An attacker positioned on the network path may be able to forge responses and influence a client's clock.

Meta's latest contribution addresses that problem. In an October 6, 2026 engineering post, the company announced that its public time service supports Network Time Security (NTS), specified in RFC 8915, and that its protocol, server, and client implementations are available through the Meta Time libraries on GitHub. The public NTS key-establishment endpoint is nts.meta.com. Source: Meta Engineering

The most interesting engineering detail is not simply that Meta supports authenticated time. It is how the service scales: the servers can validate cookies without maintaining a per-client session table or replicating a cookie-sealing key ring across the fleet.

Infographic: how Meta's stateless NTS works. Clients run NTS-KE over TLS 1.3 on TCP 4460 to get 8 cookies, then send authenticated NTP over UDP 123; servers derive cookie keys with HKDF-SHA256 instead of storing per-client state

Why authenticated time matters

A machine clock is an input to much more than timestamps.

  • TLS certificate validation: Clients compare certificate validity windows with their local clocks.
  • Credential expiry: Short-lived tokens and credentials rely on time-based validity checks.
  • Replay protection: Security controls often reject requests that fall outside an allowed time window.
  • Distributed event processing: Timestamps help systems correlate records and reconstruct timelines.
  • Observability: Logs from machines with inconsistent clocks can make the order of events difficult to establish.

Traditional NTP provides time synchronization, but an unauthenticated response does not cryptographically prove which server supplied it or whether an intermediary modified it. A malicious response can therefore be more than a logging nuisance: shifting a clock can interfere with controls that depend on expiration or validity windows.

NTS adds cryptographic authentication to the NTP client-server exchange. It helps a client verify that a response belongs to an authenticated exchange and has not been modified in transit. It does not magically guarantee that the authenticated server has the correct time, nor can it prevent every network-based timing attack. Those distinctions matter when designing a time service for production infrastructure. Source: RFC 8915

What Meta released

Meta's announcement brings together three components:

  1. NTS protocol support for authenticated NTP exchanges.
  2. Server implementation to provide the service.
  3. Client implementation in the company's open-source Time libraries.

The repository contains more than NTS. It includes NTP and Precision Time Protocol (PTP) code, hardware-clock-related components, timestamping libraries, and utilities for working with leap-second information. The repository identifies its license as Apache 2.0. Teams should still review the repository's current license and any dependencies before incorporating it into their own products. Source: Meta Time repository

The public service is available at nts.meta.com, but the endpoint has a specific role: it performs NTS Key Establishment (NTS-KE). During that handshake, it advertises the NTP responder the client should use for authenticated time packets. The advertised responder is separate from the key-establishment endpoint.

That separation is important because it allows the handshake service and the time-serving infrastructure to scale independently.


This is an excerpt. The full article continues with:

  • How NTS works: two phases, two different responsibilities
  • The key design: stateless cookies with daily key derivation
  • Why statelessness matters at scale
  • How to try it with chrony
  • What data and AI engineers should do
  • Limitations and open questions

Read the full article on AI Data Legends, with diagrams, code and sources.

Top comments (0)