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.

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.

How NTS works: two phases, two different responsibilities

NTS separates initial key establishment from the ongoing exchange of time packets.

Phase 1: Establish keys over TLS

NTS-KE uses TLS 1.3 over TCP port 4460 and negotiates the ntske/1 application protocol identifier. The client and server negotiate an authenticated encryption with associated data (AEAD) algorithm and derive directional session keys from the TLS session.

The server also provides the client with cookies and a record identifying the NTP server to contact. Meta says its service issues eight cookies during key establishment, then closes the connection.

The important operational property is that the TLS handshake does not need to be repeated for every time query. Once the client has the necessary keys and cookies, it can use the second phase for ordinary time synchronization.

Phase 2: Exchange authenticated NTP packets

The client sends standard NTPv4 packets over UDP port 123, with NTS extension fields added. A request includes a unique identifier, a cookie, and an authenticator. The server uses the cookie to recover the session keys, verifies the authenticator, and returns an authenticated response with fresh cookies.

The authenticator protects packet integrity and authenticity; it does not encrypt the entire NTP packet. The encrypted cookie material lets the client receive replacement cookies without exposing their contents to network observers.

The unique identifier also helps the client distinguish the expected response from a replayed packet. These mechanisms make it harder for an on-path attacker to forge a plausible time response without the relevant cryptographic material.

For the protocol’s precise requirements and security properties, consult RFC 8915 alongside Meta’s implementation notes.

The key design: stateless cookies with daily key derivation

A conventional server-side design might keep session state or maintain a replicated key ring so any node can validate a client’s cookie. That creates an operational dependency: all relevant servers must have consistent state, and key rotation has to be coordinated across the fleet.

Meta takes a different approach. The cookie carries encrypted session information, and the server derives the key used to seal or open that cookie from a shared master secret and a day identifier.

The derivation described by Meta is:

key = HKDF-SHA256(
    master,
    salt = BE32(day),
    info = "fbnts-cookie-seal-v1"
)

Here, day is the number of complete 24-hour periods since the Unix epoch, encoded as a 32-bit big-endian value. It is not a local calendar date, so time zones and daylight-saving transitions do not change the value for the same instant.

The cookie’s key identifier indicates which day-derived key should be used. A server receiving a cookie does not need to ask another node which key sealed it: it can derive the appropriate key itself, using the shared master secret and the encoded day identifier.

This removes the need for a replicated per-client session table or a synchronized ring of daily cookie-sealing keys. The design still depends on secure management of the shared master secret; statelessness does not mean the servers have no shared secret material.

What daily rotation actually means

The day-derived key changes at each 24-hour epoch boundary. Meta says the service accepts cookies associated with two days in the past and one day in the future to accommodate clock skew around rotation boundaries.

That window is expressed in whole days, not hours, and it is the implementation detail Meta documents; it should not be interpreted as a universal guarantee that every clock offset within that window will be safe for every client operation.

The wider lesson is that key rotation and clock discipline must be designed together. A service can eliminate synchronization of cookie state between nodes while still needing a clear policy for which key generations remain acceptable.

Why statelessness matters at scale

A distributed service is easier to scale when any eligible node can process a request without first retrieving session state from another machine.

Meta’s design provides several operational advantages:

• Simpler horizontal scaling: A newly added responder can validate eligible cookies without receiving a per-client session table.
• Less state replication: The service avoids synchronizing cookie-sealing key rings across all responders.
• Independent key establishment and response serving: The NTS-KE endpoint can direct clients to responders that do not need to exchange individual session state with it.
• Cleaner rotation logic: A time-derived key identifier makes the relevant key generation explicit and reproducible across servers.

These benefits are architectural rather than a promise of unlimited capacity. The implementation still needs secure master-secret distribution, service monitoring, network capacity, and reliable time sources. And while the service can authenticate the origin and integrity of a response, it cannot cryptographically prove that the time supplied by a misconfigured server is correct.

How to try it with chrony

Meta documents a concise chrony configuration for its service:

pool nts.meta.com nts iburst maxsources 5

The nts option enables NTS for the pool. iburst requests a burst of initial measurements to help the client establish synchronization, while maxsources 5 asks chrony to maintain up to five sources for that pool.

Meta explains that the configured endpoint performs key establishment and advertises the actual NTP responders. The pool configuration allows chrony to establish multiple independent associations rather than relying on a single responder.

This matters because authenticated time from one source is still time from one source. Multiple independent sources can help a client identify an outlier or a source that disagrees with the others.

Before using this configuration in production, verify the chrony version, NTS support, network policy, and operational requirements of your operating system. Do not blindly replace an existing time configuration on a critical host without understanding how the change will affect synchronization and recovery.

Official starting points:

• Meta Engineering: NTS at Meta
• Meta Time libraries
• RFC 8915: Network Time Security

What data and AI engineers should do

Authenticated time is a foundational control. It is not a replacement for good timestamp semantics or a complete solution to ordering problems in distributed systems.

1. Separate wall-clock time from elapsed-time measurement

Use wall-clock timestamps when you need a time associated with an event. Use a monotonic clock to measure elapsed duration, timeouts, and latency within a process.

Wall clocks can move forward or backward when corrected. NTS authenticates time synchronization; it does not make wall-clock time monotonic. A query-duration measurement or retry timer should not assume that a wall-clock timestamp always increases.

2. Audit systems that rely on expiration

Review certificate validation, token expiry, signed-request windows, and other controls that compare timestamps. Ensure hosts have a reliable synchronization path and that monitoring detects clock offsets and synchronization failures.

For certificate renewal, short validity periods make reliable time more operationally important, but NTS alone does not guarantee successful renewal. DNS validation, ACME workflows, network reachability, permissions, and issuer availability still matter.

3. Do not confuse event ordering with clock synchronization

In streaming systems, event time, ingestion time, and processing time represent different things. Authenticated NTP helps protect the wall clock against forged network responses, but it does not solve late-arriving events, duplicate delivery, clock differences between independent producers, or causality across distributed processes.

Continue to use the right event-time windows, idempotency strategies, watermarks, and ordering guarantees for the pipeline. Our guide to real-time, agentic workloads on the Databricks Lakehouse covers how those pieces fit into a streaming platform.

4. Evaluate NTS support across the fleet

Support depends on the client and operating system, not just on the existence of a public NTS server. Meta specifically highlights the absence of native NTS support in stock Android and iOS time-sync clients in its article.

For managed Linux fleets, check whether your installed time daemon supports NTS and whether your deployment can reach the key-establishment and NTP endpoints. For mobile or embedded environments, verify the actual platform time-sync implementation rather than assuming the operating system automatically uses NTS.

5. Monitor accuracy and authentication separately

A healthy NTS association is evidence that the exchange is authenticated; it is not proof that the measured time is correct. Monitor synchronization status, offsets, source diversity, and unexpected changes. Configure sane bounds for clock correction and have a recovery plan for devices that boot with badly incorrect clocks.

Limitations and open questions

NTS materially improves the security of time synchronization, but it does not remove every failure mode.

• Network delay attacks remain possible. An attacker may delay or drop packets. Authentication does not reveal how long a genuine packet spent in transit.
• Bootstrapping still matters. NTS-KE relies on TLS, which in turn needs a sufficiently plausible clock for certificate validation. Devices starting with severely incorrect time may need a separate bootstrap strategy.
• A trusted server can still be wrong. Authentication protects the path and packet contents, not the correctness of the time source itself. Source diversity and sanity checks remain important.
• Wall clocks are not monotonic. Corrections and leap-second handling can affect wall-clock readings; elapsed-time logic should use monotonic clocks.
• Client adoption is uneven. A public service and open-source implementation cannot make a platform use NTS if its native time client does not support it.
• The master secret remains security-critical. Stateless cookie validation reduces replicated state, but compromise of shared key material can undermine the cookie-sealing design.

The implementation’s statelessness is therefore best understood as a reduction in coordination overhead, not the elimination of operational complexity. Time infrastructure still requires key management, reliable sources, client support, and monitoring.

Key takeaways

1. Meta has open-sourced an NTS implementation and launched a public NTS-KE endpoint. The work builds on RFC 8915 and the company’s existing Time libraries.
2. Stateless cookies simplify horizontal scaling. Servers derive cookie-sealing keys from a shared master secret and an epoch-day identifier instead of synchronizing per-client state.
3. Daily rotation is paired with an explicit acceptance window. Meta documents acceptance of key identifiers from two days back and one day forward around each rotation boundary.
4. Authentication is not the same as accuracy. NTS makes forged or modified responses harder, but source correctness, packet delay, and clock bootstrap remain concerns.
5. Data platforms should treat time as infrastructure. Audit clock synchronization alongside certificate renewal, token validation, event processing, and distributed-system observability.

Time is one of the quiet dependencies behind almost every distributed system. Meta’s design demonstrates how cryptographic authentication and stateless server architecture can work together to make that dependency easier to operate at scale. For data and AI infrastructure teams, the broader lesson is simple: secure time synchronization is worth evaluating, but it must sit inside a larger strategy for clock discipline, event semantics, and operational recovery.

Sources

1. Meta Engineering, NTS: Authenticated Time at Meta, October 6, 2026.
2. Meta, facebook/time: Meta’s Time libraries.
3. IETF RFC Editor, RFC 8915: Network Time Security for the Network Time Protocol, September 2020.
4. Meta Engineering, Building a More Accurate Time Service at Facebook Scale, March 18, 2020.