PCI-DSS NTP — Requirement 10.6
Time-Sync Compliance Guide

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

Requirement 10 of PCI DSS v4.0.1 — "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:

PCI DSS sets no numeric tolerance; the defined-approach test examines configuration. A host visibly out of sync contradicts the customized-approach objective of 10.6.2: "The time on all systems is accurate and consistent."

2. 10.6.1 — Synchronization technology in use

The implementation answer is virtually always NTP, plus Windows W32Time when configured as an NTP client (Type=NTP). The 10.6.1 testing procedure verifies that the technology is "implemented and kept current". Our suggested evidence:

• The synchronization daemon is installed and enabled at boot on every in-scope system;
• It is kept current — daemon version and patch level, managed under Requirements 6.3.1 and 6.3.3 (10.6.1 applicability note);
• 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, treat it as a gap to fix, even if the configuration is correct on paper.

3. 10.6.2 — Designated time servers and approved sources

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

What "industry-accepted external sources" actually means

The PCI SSC has not published an exhaustive list. The standard speaks only of "specific industry-accepted external sources" and, in its guidance, of "reputable time servers". Our recommendation:

4. 10.6.3 — Protecting settings and data

This sub-requirement is short and has two elements: access restriction, and logged, monitored and reviewed changes. We implement them in three layers:

1. 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.
2. Change logging and review. Changes to time settings on critical systems are logged, monitored, and reviewed — that is what 10.6.3 requires. Raising each change as a peer-reviewed ticket is our recommendation on top; the logs themselves are retained at least 12 months under Requirement 10.5.1 ("Retain audit log history for at least 12 months").
3. Channel authentication. Not required by 10.6.3. As a hardening measure (our recommendation), authenticate the designated servers' upstream: NTS (RFC 8915) or symmetric keys (RFC 8573), the latter being the option PCI's 10.6.2 guidance mentions ("encrypt updates with a symmetric key"). With symmetric keys, document rotation and storage — in our experience, keys in clear in the config repo are a classic weakness.

5. Reference topology for a 10.6-compliant CDE

The shape we recommend:

           ┌─────────────────────────────────────────┐
           │  External (industry-accepted sources)   │
           │  ───────────────────────────────────────  │
           │  • NIST time.nist.gov     (UDP 123)      │
           │  • Cloudflare NTS, Netnod NTS            │
           │    (UDP 123 + TCP 4460 NTS-KE)           │
           │  • GNSS Stratum 1 vendor  (UDP 123)      │
           └─────────────────┬───────────────────────┘
                             │ UDP 123 + TCP 4460 (NTS-KE) 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 (our recommendation for resilience; 10.6.2 requires one or more), 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:

1. Diagram. The three-tier topology above with actual hostnames and IPs.
2. Designated server config. chrony.conf of both designated servers, sanitized.
3. Internal sample. chrony.conf / W32Time export from a representative sample of in-scope systems (databases, application servers, firewalls, jump hosts).
4. Firewall rules. Export of the egress rules restricting UDP 123 + TCP 4460 (NTS-KE) to designated servers only.
5. Approved sources document. One page listing each upstream and the rationale for "industry-accepted".
6. Synchronization status. Output of chronyc tracking and chronyc sources on each designated server, dated within the assessment window. That output shows one moment; to cover the whole window, the monthly sealed NTP compliance report (Time Evidence) from RDEM Systems measures offset continuously, from outside the designated servers, and seals each month when issued.
7. NTS proof. If using NTS, evidence of certificate validity and rotation procedure.
8. Change history. Logs showing that changes to time settings on critical systems are logged, monitored and reviewed (10.6.3), retained at least 12 months (10.5.1); ticketing export as well if you use tickets.
9. Test report. Output of the Online NTP Validator against each external source — stratum, offset, NTP and NTS verdicts — collected within the assessment window; the refID comes from your own chronyc sources.

7. What changes for NTP: v3.2.1 (10.4) → v4.0 / v4.0.1 (10.6)

PCI-DSS v3.2.1 located the time-synchronization requirement at 10.4 with three sub-requirements. v4.0 moved it to 10.6; the PCI SSC Summary of Changes from v3.2.1 to v4.0 classes the move of 10.4 to 10.6.1–10.6.3 as moved and reorganized, a structure or format change, not an evolving requirement. The substance is unchanged; elements that sat in the v3.2.1 testing procedures are now in the requirement text:

If your v3.2.1 evidence pack is robust, the v4.0 transition is mostly a re-tagging exercise (10.4.x → 10.6.x): the approved-sources list and the peering check were already expected under v3.2.1.

8. Cross-framework reuse

A 10.6 evidence pack can be reused as a starting point for the other frameworks' clock-synchronisation evidence; each framework's own text must be checked:

The NIS 2 cells cite Implementing Regulation (EU) 2024/2690, which applies only to the categories of digital entities listed in its Article 1.

Financial-services firms carry a stricter, metrology-grade clock-accuracy mandate on top of 10.6 — see MiFID II RTS 25 clock synchronization.

When the QSA evidence is better produced and maintained as a service, RDEM Systems operates the synchronization and assembles the documented traceability dossier to UTC — see the UTC time traceability audit.

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