Standard: RFC 8915 (Network Time Security for the Network Time Protocol)
Purpose: Adds authentication and integrity protection to NTP packets so clients can trust that the time they're receiving really comes from the intended server and hasn't been altered.
How it works:
• Uses TLS (Transport Layer Security) for key exchange and authentication.
• Provides AEAD (Authenticated Encryption with Associated Data) to encrypt and authenticate time data.
• Prevents attacks like delay, replay, or impersonation that could trick devices into using incorrect time.
While PTP (IEEE 1588) is the primary synchronization protocol in SMPTE ST 2110, some facilities or hybrid setups still use NTP for:
Without security, NTP is vulnerable — an attacker could spoof time, causing:
Lip-sync drift in media
Incorrect timestamps in recordings/logs
Security issues (e.g., certificate expiration, Kerberos ticket problems)
NTS fixes this by making NTP secure, similar to how PTP can use authentication extensions (e.g., IEEE 1588 Annex K or MACsec on the network).
Quick Comparison
| Protocol | Primary Use in 2110 | Security | Typical Accuracy |
|---|---|---|---|
| PTP | Mandatory for frame-accurate sync | Optional extensions (MACsec, 1588 authentication) | Sub-microsecond to nanoseconds |
| NTP | Secondary / IT / non-media timing | NTS (RFC 8915) adds strong security | Milliseconds |
| NTS | Secures NTP | TLS-based authentication + encryption | Same as NTP (milliseconds) |
Bottom Line
When you see NTS in modern timing discussions:
• It almost always means Network Time Security — the secure version of NTP.
• It's relevant if the conversation includes both PTP (for 2110 media) and NTP (for general system time), or if security of time sources is a concern.