What is SNTP?

SNTP (Simple Network Time Protocol) is a simplified form of NTP that lets a device set its clock over an IP network against a single time server, using the same packet format as NTP but without the algorithms that filter, compare and combine multiple sources. SNTPv4 was described in RFC 4330 in 2006 and has been part of the NTPv4 specification, RFC 5905, as a subset since 2010. Because the protocol is small and simple, it is built into many embedded devices such as managed switches, PLCs, HMIs and protection relays.

In OT networks, SNTP is often the time client on devices at the edge of the network: lightweight, compatible with any NTP server and good enough for timestamps at the level of milliseconds to tens of milliseconds.


🎯 Why does time synchronisation matter in OT?

A quartz clock in an embedded device always drifts a little. An error of a few tens of ppm is common and amounts to one to several seconds a day, so without correction devices drift minutes apart within weeks. A shared time is therefore the basis for:

  1. Correct timestamps on alarms, logs, historical data and events in SCADA and the historian
  2. Incident analysis - reconstructing the sequence of events during forensic investigation and incident response
  3. Correlation in the SIEM - linking events from firewalls, switches and controllers by time
  4. Coordination between systems - batch processes, data logging and alarm management with first-out analysis
  5. Compliance - IEC 62443 requires reliable timestamps on audit records in part 3-3 (SR 2.11), ISO 27001 has a dedicated control for clock synchronisation (A.8.17 in the 2022 edition) and GxP also calls for reliable timestamps in audit trails
  6. Time-dependent security - certificate validity, Kerberos in Active Directory (a maximum clock skew of five minutes by default), time-based access rules and log retention

πŸ”§ How does SNTP work?

SNTP uses the same messages as NTP over UDP port 123. A packet has a 48-byte header containing, among other things, the stratum, the poll interval and four 64-bit timestamps.

Step What happens
1. Request The client sends a mode 3 (client) packet and records the transmit time T1
2. Response The server replies in mode 4 (server) with receive time T2 and transmit time T3
3. Calculation The client records arrival time T4 and calculates offset and round-trip delay from T1-T4
4. Set the clock The client sets or corrects its local clock, often in a single step
5. Repeat After the poll interval a new request follows; RFC 4330 forbids intervals shorter than 15 seconds

The simplest SNTP client uses only the server’s transmit timestamp and ignores network delay. Better implementations use all four timestamps, just like NTP. Besides unicast, SNTP also supports broadcast mode (mode 5), in which a server periodically sends the time to a broadcast or multicast address, and manycast, in which a client discovers servers itself via a broadcast or multicast address.

A server that is overloaded or refuses the client can send a Kiss-o’-Death packet: stratum 0 with a code such as RATE, DENY or RSTR. A well-behaved SNTP client stops querying that server on DENY or RSTR and reduces its polling rate on RATE.


πŸ”„ What is the difference between SNTP, NTP and PTP?

The difference from NTP is not in the packet format but in what the client does with the responses. Full NTP queries several servers, filters outliers, selects the best source and steers the clock gradually. SNTP relies on one server at a time, with at most a second one as a backup.

Protocol Typical accuracy Characteristic Use in OT
SNTP A few ms to tens of ms on a LAN, depending on the implementation One server, no filtering, often clock steps Switches, simple PLCs, HMIs, protection relays under IEC 61850 edition 1
NTP Below 1 ms on a LAN, tens of ms over the internet Multiple sources, filtering, gradual steering Servers, domain controllers, SCADA, historian, time servers
PTP (IEEE 1588) Below 1 Β΅s with hardware timestamping Hardware support in switches and end points Motion control, synchrophasors, sampled values in substations

According to RFC 5905, SNTP is intended for two situations: a primary server with a single reference clock, or a client with a single upstream server and no dependent clients of its own. An SNTP client should therefore sit at the edge of the hierarchy and must not pass time on to other devices. SNTP and NTP are fully interoperable on the network, so an SNTP client can use an NTP server without any changes.


🏭 Where do you find SNTP in industry?

  • Managed switches - many industrial switches include an SNTP client so that syslog messages and SNMP traps carry a usable time.
  • PLCs and HMIs - simpler controllers and panels synchronise via SNTP so that alarms and recipes receive a correct timestamp.
  • Energy sector - the first edition of IEC 61850 used SNTP for time synchronisation of protection relays (IEDs). IEC 61850-5 defines accuracy classes from T1 (Β±1 ms, for event timestamps) to T5 (Β±1 Β΅s). Standard SNTP only reaches T1 with a good implementation; for the stricter classes the PTP profile standard IEC/IEEE 61850-9-3 was published in 2016.
  • Building automation and IoT - controllers, cameras and sensors with limited processing power often use SNTP.
  • Fallback - on some devices SNTP serves as a backup source when the primary PTP or NTP synchronisation fails.

πŸ› οΈ How do you set up SNTP properly?

You build a reliable time chain in an OT network in layers that follow the Purdue Model:

  1. Your own primary source - install a stratum 1 time server with a GNSS receiver and a holdover oscillator, and take GNSS interference such as jamming and spoofing into account.
  2. Full NTP servers per zone - let a server running full NTP (for example chrony) distribute time in each zone or DMZ, for instance a SCADA server or domain controller. Never let SNTP devices reach the internet or the IT environment directly.
  3. SNTP clients as leaves - assign end devices a primary and a backup NTP server in their own zone.
  4. Restrict the traffic - allow UDP 123 in firewall rules only to the intended time servers, and separate traffic with network segmentation and VLANs.
  5. Monitor - report offset, stratum and synchronisation status via Syslog or SNMP to network monitoring, with an alarm at stratum 16 or an offset above, for example, 100 ms.
  6. Redundancy - duplicate time servers are part of network redundancy, because an SNTP client with a single source falls back on its own drifting clock when that source fails. Include the time server configuration in your backup as well.
Setting Typical value Explanation
Poll interval 64 s to several hours Never shorter than 15 s (RFC 4330); longer for stable clocks
Number of servers 1 active + 1 backup SNTP does not combine sources; it only switches on failure
Offset alarm threshold 100 ms to 1 s Depends on requirements for alarm and log sequence
Time zone UTC in the device Local time only in the presentation layer, which avoids daylight saving problems

πŸ” What are the security risks of SNTP?

Time is an attack target: whoever shifts the clock can make logs useless, cause certificates to expire or disrupt time-based logic. SNTP devices are vulnerable because they trust one source and rarely check it. A forged response is accepted without a plausibility check.

  • Spoofing and man-in-the-middle - without authentication, the client accepts any packet that looks like a valid response.
  • Broadcast mode - in broadcast mode, any device on the segment can pose as a time server.
  • No NTS - Network Time Security (RFC 8915, 2020) protects NTP traffic with TLS keys, but most embedded SNTP clients do not support it.
  • Year 2036 - the 32-bit seconds counter of NTP timestamps rolls over on 7 February 2036. RFC 4330 describes how clients should handle this, but older firmware may show a wrong date.

IEC 62443-3-3 requires internal time synchronisation from security level 2 (SR 2.11 RE 1) and protection of the integrity of the time source at the highest level (RE 2). Because SNTP rarely offers that protection, you compensate with segmentation, fixed server addresses and monitoring. Under NIS2 and the Dutch Cyberbeveiligingswet, a reliable timeline is also needed to reconstruct an incident within the reporting deadlines.


❓ Frequently asked questions

Is SNTP compatible with a regular NTP server?

Yes, SNTP uses the same packet format and the same UDP port 123 as NTP. An SNTP client can therefore query any NTP server, and RFC 5905 describes SNTP and NTP as fully interoperable within one network.

How accurate is SNTP?

On a local network, SNTP typically achieves a few milliseconds to tens of milliseconds, depending on the implementation and network load. Because SNTP does not filter outliers and often corrects the clock in steps, it is less accurate and less stable than full NTP.

Can an SNTP device act as a time server for other devices?

According to RFC 4330 and RFC 5905, an SNTP client should not pass time on to other clients. Only a primary server with a single reference clock of its own, such as a GNSS receiver, may use SNTP as a server; intermediate time servers should run full NTP.

Does SNTP use the same port as NTP?

Yes, SNTP runs over UDP port 123, just like NTP. In firewall rules between OT zones, you allow that port only from the SNTP clients to the designated internal time servers.

When do you choose PTP instead of SNTP?

PTP is needed when devices must be aligned at microsecond level, as in motion control, synchrophasor measurements or sampled values in digital substations. For timestamps on logs, alarms and historical data, SNTP or NTP is usually sufficient.

Is SNTP secure enough for critical OT environments?

SNTP has no authentication by default, so an attacker with network access can forge the time. In critical environments you therefore use SNTP only behind proper segmentation, with internal time servers and monitoring for deviations, and choose NTP with NTS wherever possible.


πŸ“Œ In summary

SNTP is the lightweight variant of NTP for end devices: it uses the same packet format, but relies on a single server and leaves out filtering and gradual clock steering. Use SNTP on switches, PLCs and HMIs at the edge of the OT network, let them synchronise with internal NTP servers per zone, restrict the traffic and monitor the offset. Where microseconds count, PTP is the right choice, and reliable time remains a fixed part of OT convergence.