Security glossary

What is NTP (network time protocol)?

Abstract isometric UI showing network ranges, usage bars, region names (EMEA/APAC), and a purple "Deploy" button
Key takeawaysKey takeaways are generated with AI assistance. Because automated summaries can occasionally contain errors or miss important context, always refer to the full blog post for complete information.

Network Time Protocol (NTP) is a network protocol that synchronizes computer system clocks across networked devices using hierarchical time sources and timestamped message exchanges, as specified in RFC 5905. Accurate time is critical for incident investigation, security functions like TLS certificate validation and Kerberos authentication, and operational reliability, as clock drift can cause authentication failures and audit evidence corruption. Organizations should implement NTP security best practices including multiple trusted internal time sources, firewall restrictions on UDP port 123, authentication mechanisms, and monitoring to prevent drift and protect against reflection attacks and clock spoofing.

  • NTP clients calculate round-trip delay and clock offset from four exchanged timestamps, then gradually slew the clock to correct the offset while stepping only when errors are large.
  • Clock skew exceeding configured tolerances—typically five minutes in Kerberos implementations—causes authentication and name resolution failures that may appear unrelated to time synchronization issues.
  • Misconfigured NTP servers responding to unauthenticated UDP queries on port 123 can be abused for reflection and amplification attacks, requiring access restrictions, management query disabling, and continuous offset monitoring.

NTP at a glance

AttributeValue
Full nameNetwork time protocol
CategoryNetwork protocol
Defined inRFC 5905 (NTP version 4)
Protocol and portUDP port 123
OSI layerApplication layer (layer 7)
Primary useSynchronizing system clocks across networked devices
Related termsDNS, DHCP, DNSSEC, Syslog, Network observability

How NTP works

NTP clients estimate how far their local clock differs from one or more reference servers, then gradually adjust the clock. Servers are organized into levels called strata, where stratum 1 servers connect directly to a reference clock such as GPS.

  1. Client sends request: The client sends a UDP packet to an NTP server on port 123, recording its own transmit timestamp in the packet.
  2. Server replies: The server records when it received the request and when it sent the reply, and returns both timestamps along with the client's original timestamp.
  3. Client records arrival: The client notes the time the reply arrived, giving it four timestamps for the exchange.
  4. Offset and delay calculation: From the four timestamps the client calculates the round-trip delay and its clock offset from the server.
  5. Selection and filtering: When several servers are configured, the client compares samples, discards unreliable sources and picks the best candidates.
  6. Clock discipline: The client slews its clock gradually to remove the offset. It steps the clock only when the error is large.

The exchange repeats continuously, and the polling interval lengthens as the clock stabilizes. NTP does not authenticate servers by default, so optional mechanisms such as symmetric keys or network time security are used where source trust matters.

Why NTP matters in enterprise networks

Accurate time underpins many functions that are not obviously about time. Log correlation across firewalls, DNS servers, DHCP servers and applications depends on timestamps that agree, so incident responders can reconstruct event sequences. When clocks drift, investigations slow down and audit evidence becomes unreliable.

Time errors also break security controls. TLS certificate validation, Kerberos authentication and DNSSEC signature validity all depend on clocks being close to real time. Kerberos, for example, rejects requests when clock skew exceeds a configured tolerance, which is five minutes by default in many implementations. A drifting server can therefore cause sudden authentication or name resolution failures that look unrelated to time.

NTP itself is a target. Because it runs over UDP and responds to unauthenticated queries, misconfigured servers have been abused for reflection and amplification attacks, and spoofed responses can shift a client's clock. Good practice is to use several trusted internal sources, restrict which hosts may query servers, disable unneeded management queries, and monitor offset so drift is caught before it causes outages.

Common NTP issues

An NTP daemon may refuse to correct a clock that is off by more than its panic threshold, which is 1000 seconds by default in the reference implementation. A device with a dead battery or wrong date then stays wrong until an administrator sets the time manually or starts the daemon with a step option.

Configuring only one server leaves clients with no way to detect a faulty source. If that server drifts or is wrong, every client follows it. Using several independent sources lets the selection algorithm discard an outlier.

Firewall rules that allow DNS and web traffic but drop UDP port 123 leave clients unsynchronized with no obvious error. Symptoms include a growing offset, a stratum 16 status or a peer that never becomes reachable. Check both outbound requests and return traffic through stateful devices.

A server that answers monitoring or control queries from any address can be used in reflection attacks against third parties. Restrict query and control access to trusted networks and keep the software patched.

Guests can drift or jump after a pause, snapshot restore or host migration. Running a guest NTP client alongside a hypervisor time sync feature can cause the two to fight over the clock, so choose one method deliberately.

See how unified DDI simplifies network operations

Manage DNS, DHCP and IP addresses from one platform with automation, visibility and control built in.

NTP FAQ

Related terms

Article

User Datagram Protocol (UDP)

An alternative protocol to TCP used primarily for establishing low-latency and loss-tolerating connections between applications on the internet.

Learn more
Article

Transport layer security (TLS)

A cryptographic protocol to provide communications security over a computer network.

Learn more
Article

DNSSEC (Domain Name Service Security Extension)

A mechanism that uses cryptography to provide authentication and integrity for DNS queries.

Learn more
Article

Simple Network Management Protocol (SNMP)

A protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior.

Learn more
Article

DNS server

Also called a DNS nameserver, it stores DNS records and responds to and resolves DNS queries from devices. Learn More

Learn more
Article

DNS – Domain Name System

A hierarchical naming system that enables communication across devices in a network.

Learn more
Article

ACL (Access Control List)

Limits which entities are allowed to perform certain functions against a DNS server, such as sending queries or performing dynamic updates.

Learn more
Article

DMZ (Demilitarized zone)

A subnetwork that contains and exposes an organization’s external-facing services to an untrusted, usually larger, network such as the internet.

Learn more