What does PCI-DSS v4.0 Requirement 10.6 require for NTP?

Requirement 10.6 is the headline obligation: 'Time-synchronization mechanisms support consistent time settings across all systems'. It is broken into three sub-requirements: 10.6.1 mandates that system clocks be synchronized using time-synchronization technology; 10.6.2 prescribes designated central time servers, restricts which sources can update them, and requires that internal systems only receive time from those designated servers; 10.6.3 requires that time-synchronization settings and data be protected against tampering and that changes be tracked.

Is NTP explicitly named in PCI-DSS 10.6?

PCI-DSS v4.0 uses the phrase 'time-synchronization technology' rather than naming NTP. Guidance from the PCI SSC and informed-opinion publications make clear that NTP (or its Microsoft analogue W32Time, when synchronized over NTP) is the de facto answer; no other production-grade time-synchronization stack is in common use for in-scope cardholder data environments (CDE). Auditors universally accept NTP/chrony evidence for 10.6.

What does 'industry-accepted external source' mean in 10.6.2?

10.6.2 requires that designated time servers 'accept time updates only from specific industry-accepted external sources'. In 2026 the accepted set typically includes: national metrology institutes (NIST, PTB, NPL, INRIM, OP), GNSS-disciplined Stratum 1 servers operated by reputable infrastructure providers, NTS-capable public sources (Cloudflare, Netnod). Random selection from the public NTP pool is not industry-accepted in this sense — it can be used downstream of the designated server, not as its source.

How do I protect time-synchronization settings under 10.6.3?

Three layers: (1) Filesystem — chrony.conf / ntp.conf owned by root, mode 0640 or stricter, no world-writable. (2) Change management — every modification raised as a ticket with reviewer signoff, history retained for the PCI audit window. (3) Channel authentication — NTS (RFC 8915) for the designated server's upstream, ensuring an attacker on the path cannot inject a forged time update.

What audit evidence does a QSA expect for 10.6?

Typical QSA evidence requests during the on-site or remote assessment: (1) network diagram showing the designated time server(s) and the boundary between CDE and external time sources, (2) running configuration of the designated server(s), (3) running configuration of a sample of internal systems showing them point to the designated server only, (4) the list of approved external sources and the rationale, (5) change-control tickets for the most recent twelve months, (6) a sample of NTP synchronization status (chronyc tracking, w32tm /query /status) collected during the assessment window.

PCI-DSS NTP | Requirement 10.6 Time-Sync Compliance Guide (v4.0)

Published 12 May 2026 · By Richard DEMONGEOT, RDEM Systems · Target audience: ISMs of in-scope cardholder data environments, QSAs, Internal Security Assessors preparing PCI-DSS v4.0 / v4.0.1 assessments.

1. Scope: when does 10.6 apply to your CDE?

Requirement 10 of PCI-DSS v4.0 — "Log and monitor all access to system components and cardholder data" — applies to every system component in the cardholder data environment (CDE). Requirement 10.6 is the time-synchronization sub-set. It applies to:

Every system processing, storing or transmitting account data;
Every security service supporting those systems (logging infrastructure, SIEM, IDS/IPS, firewalls, jump hosts);
Every system that an attacker could use to access in-scope systems (administrative workstations, bastion hosts);
Connected service providers' time servers when they fall within the assessed CDE boundary.

The headline requirement reads:

10.6 Time-synchronization mechanisms support consistent time settings across all systems.

The "support consistent time" wording matters: the QSA looks at outcomes, not at the technology. A CDE with all systems within ±50 ms of a verified external reference passes; a CDE running chrony but with one host at +180 s drift fails — even though "NTP is configured everywhere".

2. 10.6.1 — Synchronization technology in use

10.6.1 — System clocks and time are synchronized using time-synchronization technology.

The implementation answer is virtually always NTP, plus Windows W32Time when configured as an NTP client (Type=NTP). The QSA expects:

The synchronization daemon is installed and enabled at boot on every in-scope system;
It is actively synchronizing — chronyc tracking or w32tm /query /status shows a stratum less than 16 and a non-zero reach value;
If the daemon is configured but the system is failing to synchronize, that is a finding even if the configuration is correct on paper.

Practical commands the QSA runs. Linux: chronyc tracking, chronyc sources, timedatectl status. Windows: w32tm /query /status, w32tm /query /peers. ESXi: ntpq -p. A clean output is part of the evidence; a stale "Last Successful Sync Time" is not.

3. 10.6.2 — Designated time servers and approved sources

10.6.2 — Systems are configured to the correct and consistent time as follows: one or more designated time servers are in use; only the designated central time server(s) receives time from external sources; time received from external sources is based on International Atomic Time (TAI) or Coordinated Universal Time (UTC); the designated time server(s) accept time updates only from specific industry-accepted external sources; where there is more than one designated time server, the time servers peer with one another to keep accurate time; internal systems receive time information only from designated central time server(s).

This sub-requirement is dense. Six checks for the QSA:

#	Check	Evidence
1	Designated central time server(s) exist	Architecture diagram + DNS name/IP of the central server.
2	Only the designated server(s) receive external time	Firewall rule allowing UDP/123 egress only from the designated server's IP; `chrony.conf` on all other systems pointing internally.
3	External source is TAI/UTC-based	List of upstream NTP sources documented; all standard sources qualify (TAI/UTC is what NTP carries).
4	Only industry-accepted external sources	Approved-list document; typical: NIST, PTB, Cloudflare NTS, Netnod, INRIM, OP, or a GNSS Stratum 1 operated by a reputable infrastructure provider.
5	Multiple designated servers peer with each other	chrony.conf with `peer` directive (or pool members configured to peer); demonstrated by `chronyc sources` showing peer entries.
6	Internal systems only receive from designated	chrony.conf / w32tm config on a sample of internal hosts; each lists only the designated server(s), no public sources.

What "industry-accepted external sources" actually means

The PCI SSC has not published an exhaustive list. The convention that QSAs apply in 2026:

Not accepted (common findings). Random members of pool.ntp.org as the direct source of the designated server (no authentication, no SLA, no audit trail); residential ISP routers; the AWS metadata IP 169.254.169.123 when no documentation links it to a TAI/UTC chain; servers whose operator cannot be identified.

4. 10.6.3 — Protecting settings and data

10.6.3 — Time synchronization settings and data are protected.

This sub-requirement is short but bites in three places:

Filesystem. chrony.conf or ntp.conf owned by root, mode 0640 or stricter, located outside any world-readable share. On Windows, the W32Time registry keys protected by the default ACL plus group-policy enforcement.
Change management. Every modification of the configuration raised as a ticket, peer-reviewed, history retained for at least the assessment window (typically 12 months).
Channel authentication. The designated server's upstream channel must resist tampering. In 2026, NTS (RFC 8915) is the only standardized answer; symmetric keys are accepted if rotation and storage controls are documented (the latter often fails 10.6.3 — keys in clear in the config repo are a classic finding).

5. Reference topology for a 10.6-compliant CDE

The shape most QSAs find immediately defensible:

           ┌─────────────────────────────────────────┐
           │  External (industry-accepted sources)   │
           │  ───────────────────────────────────────  │
           │  • NIST time.nist.gov     (UDP 123)      │
           │  • Cloudflare NTS         (UDP 4460 NTS) │
           │  • Netnod NTS             (UDP 4460 NTS) │
           │  • GNSS Stratum 1 vendor  (UDP 123)      │
           └─────────────────┬───────────────────────┘
                             │ UDP 123 / 4460 egress restricted
                             │ to designated servers only (FW rule)
                             ▼
           ┌─────────────────────────────────────────┐
           │  Designated central time servers         │
           │  ───────────────────────────────────────  │
           │  ntp-cde-a.internal  (chrony 4.x, NTS)   │
           │  ntp-cde-b.internal  (chrony 4.x, NTS)   │
           │  ── peer with each other ──              │
           └─────────────────┬───────────────────────┘
                             │ Internal UDP 123 only
                             │ to ntp-cde-a/b
                             ▼
           ┌─────────────────────────────────────────┐
           │  In-scope CDE systems                    │
           │  ───────────────────────────────────────  │
           │  Payment apps · DBs · Firewalls · SIEM   │
           │  Jump hosts · Bastions · IDS · Auth      │
           └─────────────────────────────────────────┘

Two designated servers (10.6.2 requires multiple), peering with each other, fed only by industry-accepted external sources, with strict firewall containment between layers.

6. Evidence pack for the QSA assessment

Assemble in pci-dss/req-10.6/ before the assessment:

Diagram. The three-tier topology above with actual hostnames and IPs.
Designated server config. chrony.conf of both designated servers, sanitized.
Internal sample. chrony.conf / W32Time export from a representative sample of in-scope systems (databases, application servers, firewalls, jump hosts).
Firewall rules. Export of the egress rules restricting UDP/123 and UDP/4460 (NTS) to designated servers only.
Approved sources document. One page listing each upstream and the rationale for "industry-accepted".
Synchronization status. Output of chronyc tracking and chronyc sources on each designated server, dated within the assessment window.
NTS proof. If using NTS, evidence of certificate validity and rotation procedure.
Change history. Ticketing export covering NTP-config changes in the last 12 months.
Test report. Output of the Online NTP Validator against each external source — stratum, offset, refID — collected within the assessment window.

7. v3.2.1 (legacy 10.4) → v4.0 (10.6) — what changed

PCI-DSS v3.2.1 located the time-synchronization requirement at 10.4 with three sub-requirements. v4.0 renumbered it to 10.6 and tightened the wording:

Aspect	v3.2.1 (10.4)	v4.0 (10.6)
Numbering	10.4 / 10.4.1 / 10.4.2 / 10.4.3	10.6 / 10.6.1 / 10.6.2 / 10.6.3
External source restriction	Implicit	Explicit: "industry-accepted external sources"
Peering	Implicit	Explicit: "time servers peer with one another"
Protection of settings	One sub-requirement	Two distinct angles: ACL + change management
Effective date	—	v4.0 mandatory 31 March 2025

If your v3.2.1 evidence pack is robust, the v4.0 transition is mostly a re-tagging exercise plus a documented "approved sources" list and the explicit peering check.

8. Cross-framework reuse

A 10.6-compliant evidence pack closes time-sync requirements across the major frameworks with no additional artefacts:

Requirement	PCI-DSS v4.0	ISO 27001:2022	NIS 2	DORA
Designated/approved source	Req. 10.6.1, 10.6.2	A.8.17	Art. 21(2)(c)	Art. 11
Authenticated channel	Req. 10.6.2 (industry-accepted)	A.8.17 (implicit)	Art. 21(2)(e)	Art. 9(3)
Protected settings	Req. 10.6.3	A.8.24 (key mgmt)	Art. 21(2)(h)	Art. 10
Audit-trail retention	Req. 10.7	A.8.15	Art. 23	Art. 12

Different angle? Use the right tool:

Measure jitter, offset, latency → ntp-tester.eu
Diagnose firewall / port 123 / daemon → check-ntp.net
Enterprise reference architecture → ntp.rdem-systems.com