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
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.
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.
Here are the 7 most common NTP checks in security audits. For each: why it exists, what it actually verifies, and what it misses.
Why it exists: Ensures systems don't rely solely on their internal clock (RTC), which inevitably drifts.
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.
Why it exists: Redundancy. If one source fails, others take over. The NTP algorithm also compares sources against each other to detect "false tickers."
Why it exists: Stratum indicates distance from the atomic/GPS reference. Stratum 1 = directly connected. Lower numbers mean a theoretically more reliable source.
Why it exists: A low offset proves the local clock is properly synchronized with the reference. Typically < 100ms for compliance, < 1ms for critical environments.
No time to manage NTP monitoring? Our team monitors your synchronization 24/7.
Discover managed services →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.
Why it exists: Synchronization logs prove after the fact that clocks were synchronized at the time of audited events. Essential for forensic evidence.
chronyc authdata command should show
Mode = NTS and NAK = 0 (no rejections).
Why it exists: Traceability. Knowing which NTP servers are used, who manages them, and when the configuration was last reviewed.
Not all infrastructures are equally exposed. Here's a risk scale based on your current situation:
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.
| 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 |
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 →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 |
Moving from "compliant on paper" to "secure in practice" doesn't require a revolution. Here are the steps:
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.
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.
Continuously monitor offset, NTS status, and reachability for each source. Configure alerts on:
NAK > 0)Update your security documentation to reflect the NTS transition. The auditor must be able to verify:
RDEM Systems handles all or part of your NTP/NTS infrastructure: deployment, 24/7 monitoring, audit-ready documentation.
Discover our managed services → View our NTS infrastructure →Need a quote? ntp@rdem-systems.com
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.
Test your infrastructure now: NTP Validator | NTP Diagnostic | NTS Security Tester | NTS Infrastructure