Time Synchronization Configuration

Time is a security control. If system clocks drift, your logs stop lining up, your incident timelines become disputable, and correlating events across endpoints, firewalls, and applications turns into guesswork. PCI DSS treats this as a concrete configuration requirement, not a “nice to have,” because accurate time underpins audit trails and investigations.

Requirement 10.6.2 is narrow but operationally cross-cutting: infrastructure teams own NTP, network teams own egress/ingress rules, platform teams own gold images and device baselines, and security teams validate that the control works end-to-end for the cardholder data environment (CDE) and connected systems. The compliance job is to define the standard, assign owners, and collect evidence that stands up to assessor scrutiny.

This page translates the requirement into an implementable build: a time hierarchy, restricted upstream sources, peering for redundancy, and hard blocks to prevent “shadow NTP.” It also outlines the artifacts to retain and the exam questions you should be ready to answer quickly.

Regulatory text

PCI DSS 4.0.1 Requirement 10.6.2 states: “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 or Coordinated Universal Time (UTC), the designated time server(s) accepts 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, and internal systems receive time information only from designated central time server(s).” (PCI DSS v4.0.1 Requirement 10.6.2)

Operator interpretation (what you must do):

• Establish a time synchronization hierarchy with designated central time server(s).
• Permit external time ingress/egress only for those designated central servers.
• Ensure upstream time is UTC/International Atomic Time-based.
• Configure the central servers to accept time updates only from specific, industry-accepted sources.
• If you have more than one central time server, configure them to peer for accuracy and resilience.
• Force all internal systems to sync time only from those designated central servers. (PCI DSS v4.0.1 Requirement 10.6.2)

Plain-English interpretation of the time synchronization configuration requirement

You need a single, controlled source of truth for time inside your environment. The only systems allowed to “talk to the internet for time” are your designated time servers. Everything else must sync to them and only them. Your designated time servers must sync to specific reputable upstream time sources using UTC/atomic time, and you must be able to prove the configuration and the enforcement.

Who it applies to

Entities: Merchants, service providers, and payment processors that must comply with PCI DSS. (PCI DSS v4.0.1 Requirement 10.6.2)

Operational scope (where it shows up in practice):

• CDE systems: payment applications, databases, jump hosts, admin workstations used to manage CDE, and supporting infrastructure.
• Security tooling that supports PCI logging/monitoring: SIEM collectors, log forwarders, WAFs, IDS/IPS, EDR managers.
• Network and virtualization layers: firewalls, routers/switches that produce logs, hypervisors, Kubernetes control plane nodes if in-scope.
• Third parties: hosting providers or managed security providers if they operate time services or enforce NTP restrictions for your environment. You still need evidence.

What you actually need to do (step-by-step)

1) Define the time architecture (the hierarchy)

Decide and document:

• Which host(s) are your designated central time server(s) (often two for redundancy).
• Which upstream sources they use (specific FQDNs/IPs).
• Which networks must consume time from the designated servers (CDE and connected systems).
• The standard protocol and service (typically NTP; some environments use chrony).

Deliverable: a one-page “Time Synchronization Standard” diagram that shows Upstream sources → Central time servers → Internal systems.

2) Build and harden the designated time servers

On the designated servers:

• Configure them to sync with specific, industry-accepted external sources (don’t leave default pools unpinned). (PCI DSS v4.0.1 Requirement 10.6.2)
• Confirm time basis is UTC/International Atomic Time (practically: set OS timezone consistently, store timestamps in UTC where possible, and ensure NTP reports correct reference). (PCI DSS v4.0.1 Requirement 10.6.2)
• Restrict which upstream sources are allowed to provide updates. This is both:
  • Service config (allowed peers/servers), and
  • Network controls (firewall rules limiting NTP to upstream IPs only).

3) If you run more than one central server, configure peering

If you designate multiple central time servers:

• Configure them to peer with one another so they can keep accurate time even if an upstream source is unavailable. (PCI DSS v4.0.1 Requirement 10.6.2)
• Decide which server is “preferred” for your internal clients and how failover works (DNS, DHCP option, config management).

4) Enforce “only central servers receive external time”

This is where many implementations fail: teams configure the central servers but don’t prevent everything else from going direct to the internet.

Controls to implement:

• Egress firewall policy: block NTP to the internet from all internal subnets except the designated central time server(s).
• Cloud controls: security groups/NACLs and cloud firewall policies that restrict outbound UDP/123 (and any other time protocol you use) to only the central servers.
• Proxy/NAT exceptions: ensure no hidden path allows other systems to reach external NTP.

Requirement mapping: “only the designated central time server(s) receives time from external sources.” (PCI DSS v4.0.1 Requirement 10.6.2)

5) Force internal systems to sync only to designated servers

On every in-scope system:

• Set NTP/chrony configuration to point only to the designated central time server(s).
• Remove any default pool entries.
• Lock the configuration through your standard mechanism (gold image, MDM, GPO, configuration management).
• For appliances, set the management UI/CLI NTP settings and restrict admin changes.

Requirement mapping: “internal systems receive time information only from designated central time server(s).” (PCI DSS v4.0.1 Requirement 10.6.2)

6) Validate consistency and detect drift

Assessors will expect you to show the control works, not just that configs exist.

• Run a validation procedure that checks:
  • Central servers sync to approved upstream sources
  • Clients point to the central servers
  • Network rules prevent non-central hosts from reaching external NTP
• Add monitoring alerts for time sync failure or excessive drift (implement with your existing monitoring stack; keep the alert logic and a sample alert as evidence).

7) Operationalize change control

Every infrastructure change can break time synchronization (new subnets, new VPCs, new firewall policies, new appliance installs).

• Add “NTP/time sync configured to designated servers” as a required item in build checklists.
• Add “egress NTP blocked except central servers” to firewall standards.
• Review exceptions explicitly and time-box them.

Where Daydream fits (without adding process overhead)

If you track PCI requirements and evidence centrally, Daydream can act as the system of record for the “Time Synchronization Configuration” control: owners, scope, validation runs, and the actual artifacts listed below. The goal is faster assessor response: one requirement page, current configs, and last validation proof.

Required evidence and artifacts to retain

Keep artifacts that prove designation, restriction, and enforcement:

Designation & standard

• Time Synchronization Standard (policy/procedure) naming the designated time servers and upstream sources.
• Network/time architecture diagram showing hierarchy.

Central server configuration

• Config export or screenshots of NTP/chrony settings listing specific upstream sources.
• Host configuration showing UTC/time settings as implemented.
• Proof of peering config if multiple central servers exist. (PCI DSS v4.0.1 Requirement 10.6.2)

Network enforcement

• Firewall/security group rules showing:
  • Only central time servers can reach external NTP sources
  • Internal systems can reach the central time servers for time
• Change tickets/approvals for the firewall rules (to show this is controlled, not ad hoc).

Client enforcement

• Configuration baselines (GPO, MDM profile, Ansible/Chef/Puppet state, golden image docs) that set internal systems to sync only to designated time servers.
• Spot-check outputs from representative in-scope systems showing their configured NTP servers.

Validation evidence

• A repeatable validation script/runbook and a recent execution record (command outputs, monitoring report, or ticket evidence).
• Exception register for any systems that cannot comply, with compensating controls and an end date.

Common exam/audit questions and hangups

Expect these questions from a QSA or internal audit:

1. “Show me which systems are designated time servers.” Have the names, IPs, and function documented.
2. “Prove only those systems get time from external sources.” This is usually a network evidence request (firewall rules + a test result). (PCI DSS v4.0.1 Requirement 10.6.2)
3. “What external sources do you use, and are they specific?” If you use a generic pool without pinning, be ready for pushback because the requirement calls for “specific” sources. (PCI DSS v4.0.1 Requirement 10.6.2)
4. “Do your time servers peer with each other?” If you claim more than one designated server, show peering configuration. (PCI DSS v4.0.1 Requirement 10.6.2)
5. “Pick three CDE systems and show their NTP settings.” Be ready to produce outputs quickly.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Allowing endpoints to use public NTP directly.
  Fix: Egress block UDP/123 except for designated time servers; validate with a network test.

• Mistake: “Designated time server” exists but clients still point to defaults.
  Fix: Enforce through baselines (GPO/MDM/config management) and remove local admin ability to change NTP where feasible.

• Mistake: Using non-specific upstream sources.
  Fix: Document and configure explicit upstream sources; keep the approved list and config exports aligned. (PCI DSS v4.0.1 Requirement 10.6.2)

• Mistake: Redundant time servers without peering.
  Fix: Configure peering and document the intended failover behavior. (PCI DSS v4.0.1 Requirement 10.6.2)

• Mistake: No proof the control is working.
  Fix: Add a periodic validation runbook and retain the latest run output as evidence.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, assessors treat time synchronization as a foundational dependency for logging and incident investigation. If time is inconsistent, you can fail to reconstruct events across systems, weakening your ability to support PCI logging expectations and security response.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and design)

• Identify in-scope networks and system classes (servers, endpoints, appliances, cloud services).
• Designate central time server(s) and document the hierarchy.
• Choose and document the approved external time sources and UTC approach. (PCI DSS v4.0.1 Requirement 10.6.2)
• Create the evidence checklist and assign owners (infra, network, security).

Next 60 days (implement and enforce)

• Configure central time server(s) with restricted upstream sources.
• Add peering if multiple time servers exist. (PCI DSS v4.0.1 Requirement 10.6.2)
• Deploy client configurations to point only to central servers.
• Implement firewall/security group rules that prevent non-central systems from reaching external time sources. (PCI DSS v4.0.1 Requirement 10.6.2)

By 90 days (prove it and make it durable)

• Run validation across representative samples per environment (on-prem, cloud, endpoints, appliances).
• Set monitoring/alerting for time sync failures and document response steps.
• Put “time sync compliance” into build standards and change control checklists.
• Centralize artifacts and validation results in your GRC workflow (Daydream or your existing repository) so evidence stays current.

Frequently Asked Questions

Do all systems in the environment need to sync to the designated time servers?

Systems in scope for PCI DSS logging and security monitoring should follow the hierarchy, and Requirement 10.6.2 explicitly requires internal systems to receive time only from designated central time server(s). Keep scope decisions documented and consistent with your PCI scoping.

Can we use multiple designated time servers for redundancy?

Yes. If you designate more than one, the requirement expects those time servers to peer with one another to keep accurate time (PCI DSS v4.0.1 Requirement 10.6.2).

Are public NTP pools allowed as external sources?

The requirement calls for “specific industry-accepted external sources,” so relying on broad pools without pinning to specific sources creates audit friction. Document approved sources explicitly and configure your time servers to accept updates only from those sources (PCI DSS v4.0.1 Requirement 10.6.2).

What does “UTC or International Atomic Time” mean operationally?

Your external time feed must be based on UTC/atomic time (PCI DSS v4.0.1 Requirement 10.6.2). In practice, standardize on UTC for system timestamps and ensure your designated time servers reference upstream sources that provide UTC-based time.

How do we prove that only the central time servers receive external time?

Keep firewall and cloud security policy evidence showing only the central servers can reach external time sources, plus a test result demonstrating that a non-central system cannot sync externally (PCI DSS v4.0.1 Requirement 10.6.2).

What if a third party hosts parts of our CDE or logging stack?

You still need evidence that the time synchronization hierarchy and restrictions are in place for the in-scope environment. Obtain configuration attestations, diagrams, and change-control artifacts from the third party, and store them with your PCI evidence set.