PTP (IEEE 1588) Explained: Clocks, Profiles and How to Secure It

PTP, the Precision Time Protocol, is the IEEE 1588 standard for synchronising clocks across a packet network to well under a microsecond, which is one hundred to one thousand times tighter than NTP usually manages on the same LAN. It gets there by timestamping packets in network hardware and by letting switches measure and report their own queueing delay. Out of the box it has no authentication, so anyone who can send packets on the timing network can try to become the clock everyone else follows.

This post goes one level deeper than our NTP protocol explainer, which compares NTP, NTS and PTP in a single table. Here we stay on PTP: the four message exchange with real numbers, the clock types and the Best Master Clock Algorithm, the main profiles (default, telecom, power, gPTP for time sensitive networking, White Rabbit), why hardware timestamping is the whole point, the attack classes the IETF has catalogued, what the 2019 edition and its amendments added for security, and a working linuxptp configuration with monitoring. For the satellite side of the timing chain, read GPS timing, the hidden dependency in your stack; for authenticated NTP, read Network Time Security (NTS) for NTP explained.

Key takeaways

• IEEE 1588-2019 is the current base edition of PTP. The IEEE board approved it on 7 November 2019 and published it on 16 June 2020; it superseded 1588-2008 (PTP version 2), which itself replaced the original 1588-2002. Seven amendments have since been approved, and a full revision was authorised in September 2024.
• The IEEE abstract says PTP supports synchronisation "in the sub-microsecond range", and that sub-nanosecond time transfer is possible "in a properly designed network". RFC 5905 puts typical NTP clients on fast LANs within a few hundred microseconds.
• PTP computes offset and path delay from four timestamps. Offset is half of the forward difference minus the reverse difference; delay is half of their sum. The maths assumes the path is symmetric, which is exactly the assumption a delay attacker exploits.
• A grandmaster is the root time source, boundary clocks relay time hop by hop, and transparent clocks add their own residence time to a correction field. The Best Master Clock Algorithm (BMCA) elects the grandmaster from values every clock announces about itself.
• Profiles tailor PTP to an industry: the default profiles in 1588, the ITU-T telecom profiles G.8275.1 and G.8275.2, the IEEE C37.238 power profile, IEEE 802.1AS (gPTP) for time sensitive networking, and White Rabbit for sub-nanosecond science and industry networks.
• The IETF's RFC 7384 lists the threat classes: packet manipulation, spoofing, replay, rogue master, interception and removal, delay manipulation, denial of service, attacks on the grandmaster's own time source, implementation bugs and reconnaissance.
• IEEE 1588-2019 added an optional AUTHENTICATION TLV mechanism and security guidance in Annex P; the 1588d-2023 amendment added Group Domain of Interpretation (GDOI) key management guidance. linuxptp implements the TLV, but it needs PTP version 2.1 on every participating port and two step operation, so many networks still rely on isolation and monitoring.
• On Linux, ethtool -T tells you whether a NIC can timestamp in hardware, ptp4l runs the protocol, phc2sys moves time from the NIC clock to the system clock, and pmc lets you watch who the grandmaster is.

What PTP is and which standard defines it

PTP is defined by IEEE Std 1588, "Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems". The standard is maintained by the Precise Networked Clock Synchronization (PNCS) working group, also known as the P1588 working group, under the IEEE Instrumentation and Measurement Society. The IEEE abstract for the 2019 edition describes a protocol for "packet-based networked systems" that can synchronise clocks of different precision, resolution and stability, customised through profiles, with default profiles that let simple systems run "without the need for user management".

That last point matters for security. A PTP network with default settings is designed to organise itself: clocks announce their quality, the best one wins, and everyone follows it. Self organisation is convenient, and it is also why an unauthenticated device that announces itself as better than the real grandmaster can take over the timing of a whole domain.

Timeline of IEEE 1588 and related standards

Two of those rows explain vocabulary you will meet in newer documents. The 1588g-2022 amendment introduced optional alternative terms for the master and slave roles, and IEEE 802.1AS-2025 already uses them: its abstract speaks of selecting the "best timeTransmitter". linuxptp has followed the same path, deprecating its masterOnly and slaveOnly options in favour of serverOnly and clientOnly. This post uses grandmaster, server (time transmitter) and client (time receiver), and keeps the older words only where a configuration option still uses them.

What the next revision says it will cover

The project authorisation request (PAR) for the next revision of 1588, approved on 26 September 2024, is a useful summary of what PTP is supposed to do. It says the protocol supports synchronisation in the sub-microsecond range, "enhances support for synchronization to better than 1 nanosecond", specifies corrections for path asymmetry when the asymmetry is known, provides information for computing UTC, defines timing domains, and allows multicast, unicast or both. Importantly for this post, the PAR also lists "optional specifications for protocol security" and mappings to UDP over IPv4 and IPv6 and to layer 2 Ethernet. Security remains optional in the standard's own words.

Why PTP exists when NTP does, and what accuracy each reaches

NTP was designed to synchronise computers across the internet, through routers and over paths whose delay you do not control. It polls a server every few seconds to every few hours, filters samples from several sources, and disciplines the clock gently. RFC 5905, the NTPv4 specification, says typical primary servers are precise "within a few tens of microseconds", typical secondary servers and clients on fast LANs "within a few hundred microseconds", and clients polling at long intervals within "a few tens of milliseconds". That is plenty for logs, certificates and Kerberos.

Some systems need far more. Mobile radio networks need neighbouring base stations aligned in phase, power grids timestamp measurements from substations hundreds of kilometres apart, financial venues timestamp orders, audio and video networks need every endpoint to sample on the same edge, industrial controllers coordinate motion, and particle accelerators trigger equipment across a site. These applications need time in the hundreds of nanoseconds or better, and they usually control their own network.

PTP closes the gap with three design choices:

1. Timestamps as close to the wire as possible. A PTP capable network card or switch records the instant a timing packet crosses the physical layer, so the operating system's scheduling delays never enter the measurement.
2. The network helps. Transparent clocks in switches measure how long each timing packet waited inside them and add that to a correction field. Boundary clocks terminate PTP on every port and regenerate it, so queueing on one hop does not accumulate across many.
3. Frequent exchanges in a known domain. linuxptp's defaults are one Sync message per second and one Announce message every two seconds, and profiles commonly run much faster. Every clock in a domain follows one elected grandmaster.

The IEEE 1588-2019 abstract states the result: accuracy and precision "in the sub-microsecond range", and "sub-nanosecond time transfer accuracy can be achieved in a properly designed network". White Rabbit, which we cover below, reports sub-nanosecond accuracy across links of around 10 km.

The practical rule: if you need milliseconds, use NTP, ideally with NTS. If you need microseconds or better and you control the network, use PTP. Many hosts run both, with PTP on a dedicated interface and NTP as a sanity check.

How the Sync, Follow_Up, Delay_Req and Delay_Resp exchange works

PTP has two classes of message. Event messages need precise timestamps and travel on UDP port 319: Sync, Delay_Req, Pdelay_Req and Pdelay_Resp. General messages carry information and travel on UDP port 320: Announce, Follow_Up, Delay_Resp, Pdelay_Resp_Follow_Up, Management and Signaling. With the layer 2 Ethernet mapping, linuxptp sends ordinary PTP messages to the multicast address 01:1B:19:00:00:00 and peer delay messages to 01:80:C2:00:00:0E, an address that bridges do not forward.

The end to end delay request and response mechanism, which linuxptp uses by default, works between a server and a client like this:

1. Sync. The server sends a Sync message and records the moment it left, t1, in server time.
2. Follow_Up. In two step mode, the server sends a Follow_Up carrying the precise t1. Hardware often cannot insert a timestamp into a packet that is already leaving, so two step mode sends it afterwards. One step hardware writes t1 into the Sync itself.
3. The client records when the Sync arrived, t2, in client time.
4. Delay_Req. The client sends a Delay_Req and records when it left, t3, in client time.
5. Delay_Resp. The server records when the Delay_Req arrived, t4, in server time, and sends it back in a Delay_Resp.

The client now has four timestamps. If the one way delay is the same in both directions, two equations fall out:

offset = ((t2 - t1) - (t4 - t3)) / 2      # how far the client is ahead of the server
delay  = ((t2 - t1) + (t4 - t3)) / 2      # mean one way path delay

The client subtracts offset from its clock (in practice, it steers its frequency so that the offset trends to zero) and repeats the cycle every Sync interval.

Worked example 1: a symmetric path

Suppose the client clock is 1,500 ns ahead of the server, and the path delay is 400 ns in each direction. All values are in nanoseconds.

Now plug them in:

• t2 - t1 = 1,900 - 0 = 1,900
• t4 - t3 = 8,900 - 10,000 = -1,100
• offset = (1,900 - (-1,100)) / 2 = 3,000 / 2 = 1,500 ns
• delay = (1,900 + (-1,100)) / 2 = 800 / 2 = 400 ns

The client correctly learns that it is 1,500 ns ahead and that the path delay is 400 ns.

Worked example 2: an asymmetric path

Keep the same 1,500 ns true offset, but make the forward path (server to client) 500 ns and the reverse path 300 ns. The average is still 400 ns.

• t2 - t1 = 2,000
• t4 - t3 = -1,200
• offset = (2,000 + 1,200) / 2 = 1,600 ns
• delay = (2,000 - 1,200) / 2 = 400 ns

The computed delay looks perfect, but the computed offset is wrong by 100 ns, which is half the asymmetry: (500 - 300) / 2. The client will steer itself 100 ns away from true time and has no way of noticing from these four timestamps alone. This is why the next 1588 revision's PAR talks about corrections for asymmetry "if the asymmetry values are known", why fibre lengths and transceivers matter in telecom networks, and why a delay attack is so effective: an attacker who can hold packets in one direction for 2 microseconds shifts the victim by 1 microsecond while every message stays perfectly valid.

Worked example 3: a transparent clock in the path

Now put a switch between server and client that acts as an end to end transparent clock. The Sync spends 1,250 ns queued inside the switch on its way out and the Delay_Req spends 50 ns. The switch adds each residence time to the message's correctionField, and the client subtracts it:

offset = ((t2 - t1 - cf_sync) - (t4 - t3 - cf_delayreq)) / 2
delay  = ((t2 - t1 - cf_sync) + (t4 - t3 - cf_delayreq)) / 2

With 400 ns of wire delay each way, the client sees t2 - t1 = 400 + 1,250 + 1,500 = 3,150 and t4 - t3 = 400 + 50 - 1,500 = -1,050. Without the corrections it would compute an offset of 2,100 ns, a 600 ns error caused purely by queueing. With them it computes ((3,150 - 1,250) - (-1,050 - 50)) / 2 = (1,900 + 1,100) / 2 = 1,500 ns, the right answer. This is the single biggest reason PTP beats NTP on a busy network, and it is also why the correction field is so sensitive: change it and you change the time.

The peer delay mechanism

The alternative peer to peer mechanism measures each link separately. Every port sends a Pdelay_Req to its neighbour, which answers with Pdelay_Resp and, in two step mode, Pdelay_Resp_Follow_Up. Four timestamps give the link delay:

link_delay = ((t4 - t1) - (t3 - t2)) / 2

Here t1 and t4 are the requester's send and receive times and t2 and t3 are the responder's receive and send times. If t1 = 0, t2 = 5,320, t3 = 5,900 and t4 = 1,180 (each side on its own clock), the link delay is ((1,180 - 0) - (5,900 - 5,320)) / 2 = (1,180 - 580) / 2 = 300 ns. The two clocks' offset cancels out because each pair of timestamps is taken on one clock. Peer to peer transparent clocks then add both their residence time and the measured upstream link delay to the Sync correction field, so a client never needs to send Delay_Req upstream at all. 802.1AS networks work this way, and the linuxptp man page notes that every clock on a path must use the same mechanism; ptp4l warns when it receives the wrong kind.

Frequency, not just offset

Offset is only half the job. A quartz oscillator that is 10 parts per million fast gains 10 microseconds every second, so a client that corrected its offset once a second and did nothing else would swing by up to 10 microseconds between Syncs. The servo in ptp4l (a PI controller by default, with linreg as an adaptive alternative) adjusts the clock's frequency in parts per billion so that the offset stays near zero between messages. linuxptp's first_step_threshold default is 20 microseconds: on start, larger offsets are stepped and smaller ones are slewed. Its step_threshold default is 0, which means that after start the clock is never stepped, only steered. That default is a quiet safety feature: an attacker who manages to present a wildly wrong time cannot make a running client jump in one go.

Grandmaster, boundary and transparent clocks, and how BMCA picks a leader

IEEE 1588 defines a small set of clock types. linuxptp implements the three you will meet most often: ordinary clocks, boundary clocks and transparent clocks.

RFC 8575, the PTP YANG model, mirrors this structure: it has data sets for the ordinary and boundary clock (default, current, parent, time properties and port data sets) and separate ones for the transparent clock. If your switches expose PTP over NETCONF or RESTCONF, those are the nodes you will read.

How the Best Master Clock Algorithm works

Every clock that could become a grandmaster sends Announce messages describing itself. Every port compares the Announce messages it hears with its own data and decides whether to be a server, a client or passive. The comparison uses attributes you can see in the linuxptp configuration:

In the default BMCA these are compared in roughly that order: the administrator's priority1 first, then the quality of the clock, then priority2, and finally the identity to break ties. Topology also counts: the stepsRemoved field in each Announce message says how many boundary clocks the time has passed through. The 1588a-2023 amendment clarified BMCA operation and added an annex on the default BMCA, which tells you that implementations had not always read the original text the same way.

The telecom profiles use an alternate BMCA. linuxptp exposes it through dataset_comparison G.8275.x and two localPriority settings that break ties when clockClass, clockAccuracy, offsetScaledLogVariance and priority2 are equal. The linuxptp documentation carries a warning worth repeating: the BMCA is only guaranteed to produce a loop free timing tree with the default local priorities, so "careful network engineering is needed" if you change them.

Why the BMCA is the soft spot

The BMCA trusts what clocks say about themselves. A device that announces priority1 0 and the best possible clock class will normally beat a real grandmaster configured with a higher priority1, because nothing in an unauthenticated Announce message proves the claim. RFC 7384 calls this the rogue master attack and notes that the attacker "does not fake its identity" at all; it simply manipulates the election. It also describes a rogue boundary or transparent clock variant, where a device in the path pretends to be timing infrastructure and alters the time it forwards.

You have three structural answers, all covered in the hardening section below: stop clients from ever becoming servers (clientOnly), stop server ports from listening to Announce messages (serverOnly), and, where you know the roles in advance, skip the election entirely. linuxptp's BMCA noop option does this, and the 1588h-2026 amendment standardises an option to disable Announce messages on a port.

The main PTP profiles

A profile picks options from the 1588 menu for one industry: which transport, which delay mechanism, which message rates, which BMCA, which domain numbers and which ranges of values are allowed. The table compares the profiles this post covers.

Telecom profiles: G.8275.1 and G.8275.2

The ITU-T titles say it plainly. G.8275.1 is the PTP telecom profile "with full timing support from the network", which means every node on the path is a PTP aware boundary or transparent clock and no ordinary router sits in the timing path. G.8275.2 is the profile "with partial timing support from the network", where timing runs over IP and some nodes in between do not support PTP. Both received new editions in early 2026 and an amendment in August 2026, so check the ITU-T page before you rely on any clause number from an older copy.

The difference matters for security as well as accuracy. With full timing support, every hop regenerates time and can be locked down. With partial support, PTP packets cross ordinary routers whose queues the client cannot see, which widens the window for both innocent asymmetry and deliberate delay. linuxptp supports both profiles: dataset_comparison G.8275.x, the G.8275.defaultDS.localPriority and G.8275.portDS.localPriority options, and serverOnly on ports that should only ever distribute time, an option its documentation says exists to support "the Telecom Profiles according to ITU-T G.8265.1, G.8275.1, and G.8275.2".

Power profile: IEEE C37.238

Utilities use PTP to timestamp measurements and protection events across substations. IEEE C37.238 defines the power profile. In linuxptp it is selected with power_profile.version, which accepts 2011 or 2017. The 2011 version carries separate grandmaster and network time inaccuracy values, and the 2017 version carries a single total time inaccuracy that adds the grandmaster, network and local node contributions together. Both are reported in nanoseconds and default to -1, meaning unknown. A grandmaster ID field lets operators identify which grandmaster a device is following, which is useful for monitoring even outside the power industry.

gPTP: IEEE 802.1AS

IEEE 802.1AS defines generalised PTP for time sensitive networking. The current edition, 802.1AS-2025, was approved on 10 December 2025 and published on 17 December 2025, superseding 802.1AS-2020, which superseded 802.1AS-2011. The IEEE abstract says it covers "the transport of synchronized time, the selection of the timing source" and "the indication of the occurrence and magnitude of timing impairments". gPTP runs at layer 2, measures every link with the peer delay mechanism and expects every bridge in the path to take part. linuxptp has options that only apply to 802.1AS, such as gmCapable, and a workaround, assume_two_step, whose description says it exists for "buggy 802.1AS switches". Automotive networks often go further and fix the roles in advance, which is what linuxptp's inhibit_announce option (described as used by the Automotive profile) and the 1588h-2026 amendment support.

White Rabbit

White Rabbit began as an effort to renew CERN's control and timing system. CERN describes it as a bridged Ethernet network that uses PTP and reports "sub-nanosecond accuracy and picoseconds precision of synchronization", thousands of nodes, typical distances of 10 km between elements, gigabit data rates and fully open hardware, firmware and software. Its extensions to PTP were incorporated into the 2019 revision of IEEE 1588, and a White Rabbit Collaboration was launched in 2024 to support industrial uptake. White Rabbit is an example of what a "properly designed network" looks like in the IEEE abstract: dedicated fibre, calibrated links and hardware designed for timing.

Why hardware timestamping matters, and how to check your NIC

The worked examples assume timestamps are exact. In software, they are not. A packet that arrives at a NIC waits for an interrupt, a driver, a softirq and a socket before the kernel records a software timestamp, and that wait varies by microseconds with load. Hardware timestamping latches the time in the NIC as the packet crosses the physical layer, against a dedicated PTP hardware clock (PHC) on the card.

The Linux kernel documentation describes the PHC infrastructure as a class driver that, "together with the SO_TIMESTAMPING socket options", gives user space a standard way to build PTP programs. Each PHC appears as a character device such as /dev/ptp0, which programs can use as a POSIX clock with clock_gettime, clock_settime and clock_adjtime. Basic operations are set time, get time, shift by an offset and adjust frequency; ancillary features include timestamping external events, periodic output signals and synchronising system time through the PPS subsystem.

The kernel timestamping documentation defines the flags. SOF_TIMESTAMPING_TX_HARDWARE and SOF_TIMESTAMPING_RX_HARDWARE request hardware timestamps on transmit and receive, and SOF_TIMESTAMPING_RAW_HARDWARE asks the kernel to report them. Hardware filters such as HWTSTAMP_FILTER_PTP_V2_EVENT decide which received packets get stamped.

Checking NIC support with ethtool -T

ethtool -T (long form --show-time-stamping) shows a device's timestamping capabilities and its associated PTP hardware clock. Run it on the interface you plan to use:

# Replace eth0 with your timing interface
ethtool -T eth0

Output varies by ethtool and driver version. A card with full support looks roughly like this (trimmed):

Time stamping parameters for eth0:
Capabilities:
        hardware-transmit
        software-transmit
        hardware-receive
        software-receive
        software-system-clock
        hardware-raw-clock
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
        off
        on
Hardware Receive Filter Modes:
        none
        all

What to look for:

Newer kernels and ethtool releases can list several timestamp providers per interface; the man page documents index N qualifier precise|approx for choosing among them, and --get-hwtimestamp-cfg and --set-hwtimestamp-cfg for reading and setting the active configuration. Two more checks are useful:

# List PTP hardware clocks the kernel knows about
ls -l /dev/ptp*
# Show which network device owns each PHC (sysfs layout can vary by driver)
ls -l /sys/class/ptp/

Virtual machines are a common trap. Many virtual NICs offer only software timestamping, and some hypervisors expose a paravirtual PHC that tracks the host's clock rather than a real NIC. Containers share the host kernel and its PHCs, so PTP is normally run on the host, not inside each container.

Attack classes on PTP, described conceptually

RFC 7384 (October 2014) is the IETF's requirements document for securing time protocols, and it focuses on PTP and NTP. It classifies attackers along two axes. Internal attackers have access to a trusted segment or hold the keys; external attackers do not. Man in the middle attackers sit on the path and can intercept and change packets; injectors can only send packets, though they may record multicast traffic and replay it later. The RFC notes that without any security mechanism "all attackers are internal in practice", which is the normal state of an unauthenticated PTP network.

Two lessons stand out. First, delay manipulation is not solved by cryptography. RFC 7384 makes protection against delay and interception a MUST but notes that common practice is redundant servers or redundant paths, so a source that disagrees with the others can be discarded. Second, the grandmaster's own reference is out of scope for PTP. If your grandmaster follows GNSS, the GPS timing post covers the controls that sit before PTP ever sends a packet.

The implementation row is not theoretical. On 9 July 2021, NVD published CVE-2021-3570 and CVE-2021-3571 for the ptp4l program in linuxptp. According to NVD, the first was a missing length check when forwarding a PTP message between ports, which could allow "an information leak, crash, or potentially remote code execution", and affected versions before 3.1.1 and before several older point releases. The second affected ptp4l running as a transparent clock on little endian systems, where a crafted one step Sync message could cause an information leak or crash. Both were fixed in linuxptp 3.1.1 and corresponding backports. Timing daemons are network facing parsers like any other, and they need the same patch discipline as a web server.

What IEEE 1588-2019 added for security, and how deployed it is

Before 2019, PTP had no usable built in security. RFC 7384 records that IEEE 1588-2008 "includes an experimental security protocol, defined in Annex K", which "was never formalized into a fully defined security protocol", and argues that the absence of a standard PTP security solution "undoubtedly contributed" to the wide deployment of unsecured time synchronisation.

IEEE 1588-2019 changed that in three ways, and the amendments since have filled in details:

• An integrated security mechanism. The 2019 edition defines an optional AUTHENTICATION TLV that a sender appends to PTP messages, carrying a security parameters pointer, a key identifier and an integrity check value (ICV). Receivers that share the security association verify the ICV before acting on the message. linuxptp's documentation describes its sa_file option as supporting "the optional security mechanism defined in ieee1588-2019".
• Security guidance in Annex P. The 2019 edition includes security guidance in its Annex P. The 1588d-2023 amendment, approved on 6 December 2023 and published on 20 June 2024, "adds guidelines on the application and operation of GDOI (Group Domain of Interpretation) key management to Annex P" and corrects and clarifies parts of that annex.
• Management modules. The 1588e-2024 amendment adds MIB and YANG modules to the standard itself, building on the IETF's earlier RFC 8173 (PTPv2 MIB, June 2017) and RFC 8575 (PTP YANG model, May 2019). Standard management models make it easier to monitor the parameters an attacker would try to change.

How the TLV works in practice is easiest to see in linuxptp, which documents it in detail:

The constraints explain why deployment is still limited:

1. Version 2.1 everywhere. linuxptp says spp is "not compatible with one step ports or advertised versions less then PTPv2.1". Every node in an authenticated domain needs a stack that speaks the 2019 edition and runs in two step mode. Older devices advertise version 2.0.
2. Transparent clocks change the message. A transparent clock must write into the correction field. If the transparent clock cannot verify and re-sign the message, the only way to keep end to end authentication working is to leave the correction field unprotected, which is exactly what allow_mutable does and why linuxptp warns against it.
3. Key distribution. A shared key across a multicast domain is a group key. The standard's answer, GDOI guidance, only arrived in Annex P with the 1588d amendment in 2023 and 2024, and products need time to implement it. Manually distributed keys work but need a rotation process.
4. It does not stop delay attacks. Authentication proves who sent a message, not how long it took. RFC 7384 is explicit that delay protection depends on redundancy and topology.

We could not find a public, primary source measurement of how widely the AUTHENTICATION TLV is deployed, so we will not put a number on it. What the standards and implementation documents do show is that the mechanism is optional, needs a 2019 era stack on every participating port, and depends on key management guidance that was only completed recently. In practice many operators protect PTP with network isolation, boundary clocks, link layer security where hardware supports it, and monitoring, and add the TLV where every device supports it.

How to configure linuxptp safely: ptp4l, phc2sys and monitoring

linuxptp is the PTP implementation most Linux hosts use. Its man page describes ptp4l as an implementation of PTP "according to IEEE standard 1588 for Linux" that supports boundary, ordinary and transparent clocks. The tools you need are:

The steps below set up a Linux host as a PTP client (a time receiver) that can never become a server, then add monitoring. They assume a NIC with hardware timestamping and a timing network you control. Configuration changes are not destructive, but stepping a production clock can break running applications, so try this on one host first.

Step 1: install and check the version

# Debian and Ubuntu
sudo apt install linuxptp
# Fedora, RHEL and derivatives
sudo dnf install linuxptp

# Check what you actually run (versions before 3.1.1 lack the 2021 ptp4l fixes)
ptp4l -v

Debian testing currently ships linuxptp 4.4. Whatever your distribution ships, record the version: it is the first thing you need when an advisory lands.

Step 2: confirm hardware timestamping

ethtool -T eth0
ls -l /dev/ptp*

You want hardware-transmit, hardware-receive, hardware-raw-clock and a PTP Hardware Clock number. If the NIC lacks them, ptp4l can run with -S (software timestamping), but expect accuracy closer to NTP than to PTP.

Step 3: write a client only configuration

# /etc/linuxptp/ptp4l-client.conf
[global]
# This host only ever receives time
clientOnly              1
# Lowest preference, in case clientOnly is ever removed by mistake
priority1               255
priority2               255
# Must match the domain your grandmaster uses (0 is the default)
domainNumber            0
# Match the network: E2E or P2P on every clock in the path
delay_mechanism         E2E
network_transport       UDPv4
time_stamping           hardware
# Slew only after start; never step a running clock
first_step_threshold    0.00002
step_threshold          0.0
# Optional: maximum clockClass accepted before leaving the locked state
# (default 248). Set it to the class your grandmaster advertises when locked.
# clock_class_threshold <class>
# Summary statistics every 2^4 = 16 seconds
summary_interval        4
logging_level           6
# Local management sockets: read-write for root and group, read-only for monitoring
uds_address             /var/run/ptp4l
uds_file_mode           0660
uds_ro_address          /var/run/ptp4lro
uds_ro_file_mode        0666

[eth0]

Notes on the choices:

• clientOnly 1 means the clock never takes the server role, so a compromised or misconfigured network cannot turn this host into someone else's grandmaster. On the command line, -s does the same.
• domainNumber separates timing domains on the same network. A non default domain is not security, but it stops accidental cross talk with other PTP traffic. Use the value your grandmaster is configured with, and check your profile, since some profiles fix a range.
• clock_class_threshold is the maximum clock class a client will accept from its server before leaving the locked state; linuxptp's default is 248. Setting it to the class your grandmaster advertises when locked means the client notices when the grandmaster loses its reference. Read the advertised class with pmc (Step 5) before you tighten this.
• step_threshold 0.0 keeps the default: after the first update, the servo only adjusts frequency, and max_frequency limits how hard it can pull.
• The read only socket at /var/run/ptp4lro is restricted to GET actions and does not forward messages to other ports, so the linuxptp documentation says it can be given to untrusted applications for monitoring. Keep the read-write socket at 0660 and limit the group.

Run it in the foreground first:

sudo ptp4l -f /etc/linuxptp/ptp4l-client.conf -m

On a healthy client, the log shows the port moving through its startup states into the client state, and then prints periodic lines with the offset from the server in nanoseconds, the servo state, the frequency adjustment in parts per billion and the path delay. With summary_interval set, ptp4l prints RMS and maximum offset and the mean and standard deviation of frequency and path delay instead of each sample.

Step 4: discipline the system clock with phc2sys

ptp4l disciplines the NIC's PHC, not the system clock. phc2sys closes the gap:

# Follow ptp4l automatically and also discipline CLOCK_REALTIME
sudo phc2sys -a -r -m

The man page explains why this matters beyond accuracy. With hardware timestamping, ptp4l uses the PTP timescale, which "does not apply leap seconds" and so runs a few tens of seconds ahead of UTC. phc2sys keeps the offset between the PHC and the UTC based system clock using the currentUtcOffset that ptp4l learns from the grandmaster. If you use the manual form instead (-s eth0 -c CLOCK_REALTIME), add -w so phc2sys waits for ptp4l to synchronise and reads the offset; getting it wrong leaves the system clock off by a whole number of seconds.

Do not run phc2sys and an NTP daemon against the same system clock at the same time. If you want NTP as a fallback, configure ptp4l or phc2sys to feed the NTP daemon as a reference clock instead; linuxptp's ntpshm and refclock_sock servos exist for that.

Step 5: watch the grandmaster with pmc

pmc is the management client. Over the Unix domain socket it reads the local ptp4l without touching the network:

# Who is my grandmaster and how far away is it?
sudo pmc -u -b 0 'GET PARENT_DATA_SET'
sudo pmc -u -b 0 'GET CURRENT_DATA_SET'
# PTP to UTC offset, master offset and grandmaster identity as ptp4l sees it
sudo pmc -u -b 0 'GET TIME_STATUS_NP'
# Port states
sudo pmc -u -b 0 'GET PORT_DATA_SET'

Monitoring that catches most attacks and faults is simple:

1. Alert when the grandmaster identity changes. Record the expected grandmasterIdentity from PARENT_DATA_SET and alarm on any other value. A rogue master shows up here first.
2. Alert when stepsRemoved changes. A new hop in the timing path is either a topology change or a device inserting itself.
3. Alert on offset and path delay. Track the offset and meanPathDelay from CURRENT_DATA_SET. A sudden change in path delay without a network change is a classic sign of delay manipulation or a rerouted path.
4. Compare against an independent reference. Run an NTP client in monitor only mode, or compare with a second grandmaster on a separate path. RFC 7384's guidance on delay attacks rests on exactly this kind of redundancy.
5. Alert on port state. A client that falls out of the client state, or a port that becomes a server unexpectedly, needs a human.

Step 6: harden the grandmaster and boundary clock side

On devices that distribute time, the controls are the mirror image:

# Grandmaster or boundary clock: ports facing clients
[eth1]
# Never accept time from this direction, and ignore Announce messages here
serverOnly              1

• Set serverOnly 1 on every port that faces clients. The man page says such a port cannot enter the client state and "will ignore Announce messages received on this port", which removes the rogue master path from that side.
• Give your real grandmaster priority1 lower than anything else, and document the value. Do not rely on it alone; priorities are announced, not proven.
• Where roles are fixed, consider BMCA noop with clientOnly and serverOnly, which skips the election. Profiles that standardise this, such as automotive gPTP, pair it with disabled Announce messages.
• For telecom profiles, keep the localPriority values at their defaults unless you have engineered the topology, as linuxptp warns.

Step 7: add authentication where every device supports it

If every node in the domain runs a 2019 edition stack in two step mode, enable the AUTHENTICATION TLV. A minimal linuxptp security association file looks like this (example key IDs; generate your own random key values and keep the file readable only by root):

# Generate a random 16 byte key, Base64 encoded, for AES128
openssl rand -base64 16

# /etc/linuxptp/sa.conf  (chmod 600)
[security_association]
spp 1
seqid_window 3
1 AES128 B64:REPLACE_WITH_OUTPUT_OF_OPENSSL_RAND

# In ptp4l.conf
[global]
sa_file                 /etc/linuxptp/sa.conf

[eth0]
spp                     1
active_key_id           1

Check the security association section of the man page for the version you run, since the file format belongs to linuxptp, not to the standard. Leave allow_mutable off unless you have a transparent clock that cannot support on path authentication, and if you must turn it on, remember the correction field is now unprotected and compensate with boundary clocks or stricter monitoring.

Step 8: isolate the timing network

• Put PTP on its own VLAN or physical network, and drop UDP 319 and 320 and the PTP multicast addresses everywhere they are not needed.
• On access switches, do not let end hosts send Announce messages into the timing domain. Many switches can filter PTP by port or role; use it.
• Use link layer encryption (MACsec) or IPsec between sites where hardware timestamping still works with it, but remember that encryption does not stop an on path device from delaying packets.
• Keep management protocols (SNMP with the PTP MIB, NETCONF with the PTP YANG model) on a management network with authentication. Management access to a clock is the ability to change time.

Common mistakes

• Running PTP with software timestamps and expecting PTP accuracy. Without hardware-transmit, hardware-receive and a PHC, results look more like a busy NTP client. Check ethtool -T before you design around nanoseconds.
• Leaving clients able to become servers. The default is that any port can take any role. Set clientOnly on time receivers and serverOnly on client facing ports of grandmasters and boundary clocks.
• Treating priority1 as access control. It is an announced number. A rogue device can announce a lower one.
• Mixing delay mechanisms. End to end and peer to peer cannot be mixed on one path; ptp4l warns, but the warning is easy to miss in a log.
• Forgetting the UTC offset. PTP time ignores leap seconds. Starting phc2sys in manual mode without -w or -O can leave the system clock off by whole seconds.
• Running phc2sys and an NTP daemon against the same clock. Two servos fighting over CLOCK_REALTIME produce noisy time and confusing logs.
• Assuming authentication stops delay attacks. It does not. Only redundancy, independent references and monitoring catch a valid packet that arrives late.
• Turning on allow_mutable and forgetting it. It leaves the correction field, the value transparent clocks use to change your time, outside the integrity check.
• Ignoring the daemon itself. linuxptp, switch firmware and grandmaster software all parse untrusted packets. The 2021 ptp4l fixes are a reminder to track versions like any other network service.
• Monitoring only the offset. Offset can look perfect while you follow the wrong grandmaster. Watch grandmaster identity, steps removed and path delay too.

FAQ

What is the difference between PTP and NTP?

Both synchronise clocks over a network. NTP is built for the internet and reaches a few hundred microseconds on fast LANs according to RFC 5905. PTP, defined by IEEE 1588, uses hardware timestamps and network devices that correct for their own delay to reach sub-microsecond accuracy, and sub-nanosecond in specialised networks, but it expects you to control the network.

Which ports does PTP use?

Over UDP, PTP event messages use port 319 and general messages use port 320; IANA registers both for UDP and TCP. Over Ethernet, linuxptp sends PTP messages to multicast 01:1B:19:00:00:00 and peer delay messages to 01:80:C2:00:00:0E.

What is a PTP grandmaster clock?

The grandmaster is the root time source of a PTP domain, the clock every other clock ultimately follows. It is usually a dedicated appliance locked to GNSS or an atomic reference, and it is chosen by the Best Master Clock Algorithm from the attributes clocks announce about themselves.

What is the difference between a boundary clock and a transparent clock?

A boundary clock terminates PTP: it is a client on one port and a server on others, so it regenerates time at each hop. A transparent clock forwards PTP messages but measures how long each one waited inside it and adds that to the correction field. Both stop switch queueing from turning into time error.

How do I check if my network card supports PTP hardware timestamping?

Run ethtool -T <interface>. Look for hardware-transmit, hardware-receive and hardware-raw-clock in the capabilities, and a PTP Hardware Clock number, which corresponds to /dev/ptpN. If the PHC is "none", only software timestamping is available.

Is PTP secure?

Not by default. IEEE 1588-2019 added an optional AUTHENTICATION TLV and security guidance in Annex P, and linuxptp supports the TLV, but it needs PTP version 2.1 and two step operation on every participating port. Most networks combine isolation, clientOnly and serverOnly settings, redundancy and monitoring, and add authentication where all devices support it.

What is a rogue grandmaster attack?

A device announces better clock attributes than the real grandmaster, wins the Best Master Clock Algorithm and becomes the source everyone follows. RFC 7384 calls it a rogue master attack. Client only ports, server only ports that ignore Announce messages, static roles, authentication and alerts on grandmaster identity changes are the defences.

What is the difference between G.8275.1 and G.8275.2?

Both are ITU-T telecom profiles for phase and time. G.8275.1 assumes full timing support, with every node in the path acting as a PTP clock. G.8275.2 assumes partial timing support, running over IP through nodes that may not support PTP, which makes it more sensitive to path asymmetry.

What is gPTP and how does it relate to IEEE 1588?

gPTP is the generalised PTP profile defined by IEEE 802.1AS for time sensitive networking. It runs at layer 2, uses peer delay measurement on every link and has its own source selection rules. The current edition is 802.1AS-2025, published in December 2025.

Can PTP run in a virtual machine or a container?

It can run with software timestamps, but accuracy drops sharply. Containers share the host's kernel and PTP hardware clocks, so the usual design runs ptp4l and phc2sys on the host and lets containers read the host clock.

Where Safeguard fits

Safeguard does not configure, monitor or filter PTP traffic, it does not scan NIC, switch or grandmaster firmware, and it cannot tell you whether your clocks are correct. Nothing in the hardening steps above depends on it. The honest connection is the software that implements PTP: linuxptp and similar stacks ship as OS packages, inside container images for network functions, and inside appliances, and they parse untrusted packets.

For the images and applications you build yourself, Safeguard's container scanning shows which images carry which package versions, including a time daemon, and software composition analysis builds a dependency inventory of your own applications. SBOM generation and analysis records that inventory in SPDX or CycloneDX, and the platform shows which projects contain a given component and version, so a question like "where do we still ship linuxptp older than 3.1.1" has a quick answer. Vulnerability matching, reachability analysis, and policies and gates help you decide what to fix first and stop a build that pulls in a known vulnerable version. See using SBOMs to find affected products fast.

Most PTP security problems are configuration and network design, but the daemons and libraries that speak PTP are ordinary open source components that arrive through your distribution, your base images and your vendors. The parts you build and ship yourself, such as network function images that bundle linuxptp or management services that talk to clocks, are where you can act today.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, SBOM and remediation workflows, not time synchronisation or network monitoring. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Pointed at a network function image that bundles linuxptp, the same scan lists the packages and versions inside it and their known vulnerabilities, so you know which images to rebuild after a timing daemon advisory.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: ask it to fix the lodash CVE in a repository and watch it read the finding and the advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with your approval, and push nothing. The same approve each step flow applies when you bump a library in a management service that talks to your clocks.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects ship a given package version and get the answer from your own scan data rather than from memory.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• IEEE SA: IEEE 1588-2019, Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems
• IEEE SA: IEEE 1588-2008
• IEEE SA: IEEE 1588-2002
• IEEE SA: P1588 revision project authorisation request (approved 26 September 2024)
• IEEE SA: IEEE 1588a-2023, BMCA enhancements
• IEEE SA: IEEE 1588b-2022, PTP over the Optical Transport Network
• IEEE SA: IEEE 1588c-2024, clarification of terminology
• IEEE SA: IEEE 1588d-2023, GDOI key management
• IEEE SA: IEEE 1588e-2024, MIB and YANG modules
• IEEE SA: IEEE 1588g-2022, master-slave optional alternative terminology
• IEEE SA: IEEE 1588h-2026, option to disable Announce messages
• IEEE 1588 (PNCS) Working Group home page
• IEEE SA: IEEE 802.1AS-2025, Timing and Synchronization for Time-Sensitive Applications
• IEEE SA: IEEE 802.1AS-2020
• ITU-T G.8275: Common aspects of PTP profiles for phase/time synchronization
• ITU-T G.8275.1: PTP telecom profile with full timing support from the network
• ITU-T G.8275.2: PTP telecom profile with partial timing support from the network
• RFC 7384: Security Requirements of Time Protocols in Packet Switched Networks, October 2014
• RFC 8173: Precision Time Protocol Version 2 (PTPv2) Management Information Base, June 2017
• RFC 8575: YANG Data Model for the Precision Time Protocol (PTP), May 2019
• RFC 5905: Network Time Protocol Version 4, June 2010
• IANA: Service Name and Transport Protocol Port Number Registry
• Linux kernel documentation: PTP hardware clock infrastructure for Linux
• Linux kernel documentation: Timestamping
• ethtool(8), Linux manual page
• ptp4l(8), linuxptp 4.4 (Debian manpages)
• phc2sys(8), linuxptp 4.4 (Debian manpages)
• pmc(8), linuxptp 4.4 (Debian manpages)
• ts2phc(8), linuxptp 4.4 (Debian manpages)
• CERN: The White Rabbit Project
• NVD: CVE-2021-3570 (linuxptp ptp4l)
• NVD: CVE-2021-3571 (linuxptp ptp4l)

Last reviewed: 23 October 2026. PTP standards, ITU-T profiles and linuxptp options change between editions and releases; check the pages above for the version you actually run.