EN FR Home

NTP Audit Checklist for CISOs:
Why "Ticking the Box" Is No Longer Enough

The 7 NTP checkboxes in your ISO 27001, NIS 2, PCI-DSS and DORA audits — their rationale, their limits, and how to achieve real temporal compliance

By Richard DEMONGEOT | February 19, 2026 | 12 min read

In most compliance audits (ISO 27001, NIS 2, SOC 2, PCI-DSS, DORA), time synchronization boils down to a handful of checkboxes. "Are clocks synchronized?" The auditor ticks the box, moves on to the next item.

The problem: these checkboxes were designed at a time when NTP was considered a harmless infrastructure service. In 2026, it is a documented attack vector, exploited in real-world compromise scenarios. Yet most CISOs still treat NTP as a "set and forget" service — a blind spot in their temporal compliance posture.

This NTP audit checklist dissects each typical checkbox, explains why it exists, reveals its limitations, and shows what CISOs and auditors should actually verify to achieve genuine time compliance — not just paper compliance.

The thesis of this article: NTP without authentication (NTS) passes audits but leaves your infrastructure exposed. Paper compliance is not security.

1. What Frameworks Actually Require

Before criticizing the checkboxes, let's look at what standards actually say about time synchronization and temporal compliance. The finding is striking: none explicitly require authentication of time sources. From the original NIS Directive to NIS 2, from PCI-DSS v3.2 to v4.0 — the gap persists.

Framework Requirement What's Missing
ISO 27001:2022
Control A.8.17		 "The clocks of all systems shall be synchronized to an approved reference time source" No mention of authentication. "Approved" is undefined.
NIS 2
Article 21		 "Appropriate and proportionate technical and organizational measures to manage risks" NTP is not even mentioned. Time synchronization falls under generic "technical measures."
SOC 2
CC6.1 / CC7.2		 "The entity authorizes, modifies and removes access [...] clocks must be reliable for audit trails" "Reliable" does not imply "authenticated." Reliability is self-declared.
PCI-DSS v4.0
Requirement 10.6		 "Time synchronization technology is deployed and kept up to date" The most specific framework, but still doesn't require NTS. Only mentions "reliable sources."
DORA
Article 11		 "Anomaly detection [...] reliable timestamping of activities" Finance/resilience-oriented. Reliable timestamping required but method unspecified.

Result: auditors tick "NTP configured = compliant" and move on. The infrastructure remains exposed to attacks on the NTP protocol itself.

2. The 7 Checkboxes — A Critical Anatomy

Here are the 7 most common NTP checks in security audits. For each: why it exists, what it actually verifies, and what it misses.

✓

Checkbox 1: "An NTP service is configured"

Insufficient

Why it exists: Ensures systems don't rely solely on their internal clock (RTC), which inevitably drifts.

Limitation: Verifying that ntpd or chronyd is running says nothing about the quality or security of the source. A server can be configured to pool.ntp.org over unauthenticated UDP and still pass this checkbox.
What should be verified: The service is running AND sources are authenticated via NTS (Network Time Security).
✓

Checkbox 2: "Multiple NTP sources configured"

Insufficient

Why it exists: Redundancy. If one source fails, others take over. The NTP algorithm also compares sources against each other to detect "false tickers."

Limitation: 4 sources from the same provider, in the same datacenter, on the same AS (autonomous system) = false redundancy. A network outage or provider compromise affects all sources simultaneously.
What should be verified: Real diversity — at least 2 distinct providers, on different ASes, ideally in separate geographic zones.
✓

Checkbox 3: "Stratum is acceptable (1-3)"

Insufficient

Why it exists: Stratum indicates distance from the atomic/GPS reference. Stratum 1 = directly connected. Lower numbers mean a theoretically more reliable source.

Limitation: Stratum is a self-declared value from the server. Without authentication, nothing prevents an attacker from announcing stratum 1 while serving falsified time. Stratum measures distance, not integrity.
What should be verified: Stratum is low AND the source is authenticated. Only NTS guarantees that the server announcing stratum 2 is actually who it claims to be.
✓

Checkbox 4: "Offset is within acceptable tolerance"

Insufficient

Why it exists: A low offset proves the local clock is properly synchronized with the reference. Typically < 100ms for compliance, < 1ms for critical environments.

Limitation: Offset is a snapshot at time T. A gradual time shifting attack (a few milliseconds per hour) won't trigger any alert but will shift the clock by several seconds within days. Without continuous monitoring, audit-day "good" offset guarantees nothing.
What should be verified: Continuous drift monitoring with alerts. Offset history over at least 30 days, not just the instantaneous value.

No time to manage NTP monitoring? Our team monitors your synchronization 24/7.

Discover managed services →
✓

Checkbox 5: "UDP/123 firewall rules are documented"

Necessary

Why it exists: UDP port 123 is a known DDoS amplification vector. Rules must limit access to authorized NTP sources only, preventing exploitation and unsolicited traffic.

Limitation: This checkbox is necessary but not sufficient. Even with strict firewall rules, authorized NTP traffic flows in cleartext. An attacker positioned between client and server (MITM) can modify NTP packets without the firewall detecting anything.
What should be verified: Strict firewall rules + NTS authentication. The firewall protects the perimeter; NTS protects the content.
!

Checkbox 6: "NTP logs are retained"

Insufficient

Why it exists: Synchronization logs prove after the fact that clocks were synchronized at the time of audited events. Essential for forensic evidence.

Limitation: Unauthenticated NTP synchronization logs only prove that the system believed it was synchronized. If the source was compromised, the logs confirm synchronization... with falsified time. In forensics, that's evidence against you, not for you.
What should be verified: Synchronization logs + proof of active NTS authentication. The chronyc authdata command should show Mode = NTS and NAK = 0 (no rejections).
!

Checkbox 7: "NTP configuration documentation is up to date"

Necessary

Why it exists: Traceability. Knowing which NTP servers are used, who manages them, and when the configuration was last reviewed.

Limitation: A well-written document describing an insecure NTP configuration is still... a document describing an insecure configuration. Documentation doesn't compensate for missing technical measures.
What should be verified: Documentation explicitly states whether NTS is active or not, and why. The absence of NTS must be a documented, justified choice with risk analysis — not an oversight.

3. Your Real Risk Level Based on Posture

Not all infrastructures are equally exposed. Here's a risk scale based on your current situation:

Low NTS active + multi-provider + monitoring
Moderate Legacy NTP + multi-source + strict firewall
High Legacy NTP + single source + no monitoring
Critical No NTP or NTP to unknown sources

Most audited infrastructures fall in the "High" zone: NTP is configured (the box is ticked), a few sources are defined, but without authentication or continuous monitoring.

3 Attacks That "Ticking the Box" Doesn't Prevent

Attack Mechanism Business Impact Blocked by NTS?
Time shifting (MITM) Modifying NTP packets in transit to shift the target's clock Expired TLS certificates accepted, Kerberos/2FA broken, trading windows skewed Yes
Replay (past time injection) Replaying old NTP packets to roll back the clock Revoked certificates re-validated, expirations bypassed, temporal fraud Yes
KoD spoofing Sending fake Kiss-o'-Death packets to force synchronization shutdown Progressive clock drift, cluster desynchronization, SIEM correlation failure Yes
The legacy NTP audit paradox
A legacy NTP system can be perfectly configured, pass every audit checkbox, and remain vulnerable to all three attacks above. Compliance and security are not synonymous.

4. The Compliance vs. Security Gap

To understand the problem, visualize the gap between what the audit checks and what the infrastructure actually needs:

What the audit checks What security requires
"Is NTP configured?" Are time sources authenticated?
"Is the offset acceptable?" Is offset continuously monitored with history and alerts?
"Multiple sources?" Are sources on distinct ASes, providers, and geographies?
"Firewall filters UDP/123?" Are NTP packet contents integrity-protected and tamper-proof in transit?
"Logs are retained?" Do logs prove authenticated synchronization, not just synchronization?

Preparing for an ISO 27001 or NIS 2 audit? We can deploy NTS on your infrastructure before the audit.

Contact us →

5. Decision Matrix for Auditors

If you're a CISO, auditor, security manager, or CTO, here's the evaluation grid we recommend for the NTP section of your temporal compliance audits:

Criterion Non-compliant Compliant (minimum) Robust (2026 target)
NTP Service Missing ntpd/chronyd active chronyd + NTS
Authentication None None (tolerated) NTS active (RFC 8915)
Sources 0-1 source 4+ sources 4+ NTS, 2+ providers
AS Diversity Not checked Single AS 2+ distinct ASes
Monitoring None Periodic check Continuous + alerting
Forensics No evidence Basic NTP logs NTS logs + authdata

6. Actionable Plan

Moving from "compliant on paper" to "secure in practice" doesn't require a revolution. Here are the steps:

Step 1: Audit your current setup (30 minutes)

Use our online NTP validator to test your server responses. Check stratum, offset, and reachability. For a deeper diagnostic, our NTP diagnostic tool identifies daemon and configuration issues. For a real-world example of this plan executed, see how a 4.2-second drift across 12 servers was brought under 50 ms (fr).

Step 2: Enable NTS on your sources

Replace your legacy NTP sources with authenticated NTS sources. RDEM Systems provides NTS infrastructure across 8 TLDs and 3 datacenters — configuration details are available on our dedicated NTS page.

Step 3: Set up monitoring

Continuously monitor offset, NTS status, and reachability for each source. Configure alerts on:

  • Offset exceeding your tolerance threshold
  • NTS authentication loss (NAK > 0)
  • Reach dropping to 0 (unreachable source)
  • Unexpected stratum change

Step 4: Document for audit readiness

Update your security documentation to reflect the NTS transition. The auditor must be able to verify:

  • The list of NTS sources and their justification
  • The provider diversity policy
  • Monitoring evidence (dashboards, alert history)
  • Response procedure for synchronization anomalies

The Bottom Line

NTP audit checkboxes aren't useless. They ask the right questions — "is it configured?", "is it redundant?", "is it documented?"

The problem is they don't ask the essential question:

"Can you prove the time you receive hasn't been tampered with?"

Without NTS, the answer is no. In 2026, that answer is no longer acceptable.

NTP without NTS = facade compliance.
NTP with NTS = real security.

Go deeper on this site: ISO 27001 Control 8.17 · NIS 2 Requirements · PCI-DSS Req. 10.6 · Dual-Stack (IPv6) NTP Audit · Online NTP Validator

Adjacent angles on related sites: measuring offset and jitter → NTP Jitter Analysis · diagnosing daemon/firewall issues → check-ntp.net · NTS deployment → NTS Infrastructure