---
title: "NTS: Authenticated Time at Meta"
description: "Meta launched NTS (RFC 8915) authentication for its public time service at nts.meta.com, enabling clients to verify the origin and integrity of time packets. The service separates key establishment over TLS 1.3 from authenticated NTP, with cookie keys derived daily from a shared secret so servers hold no per-client state. Shortening TLS certificate lifetimes to 100 days in 2027 and 47 days in 2029 makes automated certificate renewal increasingly essential, creating a dangerous circular dependency on an authenticated clock. Meta open-sourced its NTS implementation and encourages mobile OS vendors to add client support, as Android and iOS currently sync time over unauthenticated UDP. The protocol does not prevent delay attacks, and device bootstrapping remains circular since NTS-KE requires TLS validation that itself demands a correct clock."
---

# NTS: Authenticated Time at Meta

[Meta](https://yomu.fyi/company/meta) · By Oleg Obleukhov · Oct 6, 2026

**Type:** Announcement

## Summary

Meta launched NTS (RFC 8915) authentication for its public time service at nts.meta.com, enabling clients to verify the origin and integrity of time packets. The service separates key establishment over TLS 1.3 from authenticated NTP, with cookie keys derived daily from a shared secret so servers hold no per-client state. Shortening TLS certificate lifetimes to 100 days in 2027 and 47 days in 2029 makes automated certificate renewal increasingly essential, creating a dangerous circular dependency on an authenticated clock. Meta open-sourced its NTS implementation and encourages mobile OS vendors to add client support, as Android and iOS currently sync time over unauthenticated UDP. The protocol does not prevent delay attacks, and device bootstrapping remains circular since NTS-KE requires TLS validation that itself demands a correct clock.

## Context

Meta’s public time service nts.meta.com adds NTS authentication to its existing precise time service, making time verifiable in addition to precise. The work addresses the fact that NTP has been unauthenticated since 1985, which is problematic because certificate validation, token expiry, and replay windows all depend on an accurate clock. Shortening TLS certificate lifetimes (down to 47 days by 2029) makes automated renewal essential and a skewed clock dangerous.

## Approach / What changed

Meta deployed NTS (RFC 8915) with a two-phase design: an NTS-KE phase over TLS 1.3 to derive session keys and issue cookies, and an authenticated NTP phase where cookies are used for per-packet authentication without server state. Cookie sealing keys are derived from a shared master secret and the current day using HKDF-SHA256, avoiding key replication or shared state between servers.

## Takeaways

- NTS authenticates NTP packets but does not protect against delay attacks; an attacker can shift the clock by up to half the delay introduced despite valid cryptography.
- Meta’s server avoids per-client state by deriving cookie sealing keys daily from a shared master secret using HKDF-HMAC-SHA256, accepting keys up to two days old to cover rotation skew.
- Shortening TLS certificate lifetimes to 47 days by 2029 makes automated renewal over ACME essential, creating a circular dependency: certificate validation requires an accurate clock, but NTS-KE itself needs TLS.

## FAQ

### How does Meta avoid storing per-client state for NTS?

Each NTS cookie holds the session keys sealed with AES-SIV so only the server can open it. The server derives the sealing key from a shared master secret and the current day using HKDF-HMAC-SHA256, so no per-client state, key ring, or replication is needed. Servers accept cookies sealed up to two days in the past and one day in the future to handle clock skew.

### What security limitations does NTS have?

NTS authenticates the sender of a packet but does not protect against delay attacks; an attacker who holds packets can shift the client's clock by up to half the introduced delay. Mitigations include using multiple independent time sources, setting sanity limits, and applying bounded clock steps.

### What is the NTS bootstrapping problem?

NTS-KE requires a TLS handshake, which itself needs a roughly correct clock to validate the server certificate. Devices with a dead RTC must obtain an approximate time before their first NTS-KE handshake, creating a circular bootstrapping problem.

**Tags:** [Meta](https://yomu.fyi/topic/meta), [NTP](https://yomu.fyi/topic/ntp), [NTS](https://yomu.fyi/topic/nts), [Security](https://yomu.fyi/topic/security)

- Source: [Meta](https://engineering.fb.com/2026/10/06/production-engineering/nts-authenticated-time-at-meta)
- Source URL: https://engineering.fb.com/2026/10/06/production-engineering/nts-authenticated-time-at-meta
- Ingested by Yomu: 2026-10-06T18:00:09.398Z

[Read original post](https://engineering.fb.com/2026/10/06/production-engineering/nts-authenticated-time-at-meta)