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
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.1 — the gap persists.
| Framework | Requirement | What's Missing |
|---|---|---|
| ISO 27001:2022 Control A.8.17 |
Clocks of information processing systems used by the organization synchronized to approved time sources (our paraphrase; the ISO text is not freely available) | No mention of authentication. "Approved" is undefined. |
| NIS 2 Article 21 · Impl. Reg. (EU) 2024/2690 |
Art. 21: “appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems”. Implementing Regulation (EU) 2024/2690, Annex point 3.2.6: synchronised time sources on all systems, to the extent feasible (entities listed in its Art. 1) | NTP is not even mentioned. Outside the entities covered by 2024/2690, time synchronization falls under the generic measures of Art. 21. |
| SOC 2 Trust Services Criteria · CC7.2 |
The Trust Services Criteria contain no clock requirement; time sync is a control the entity chooses (CC7.2: monitoring for anomalies). | Nothing on time sources or authentication: the control and its evidence are the entity's own. |
| PCI DSS v4.0.1 Requirement 10.6 (text identical to v4.0) |
10.6.1: “System clocks and time are synchronized using time-synchronization technology.” | The most specific framework, but still doesn't require NTS. 10.6.2 asks for updates from “specific industry-accepted external sources”; v4.0.1 Guidance (non-normative) suggests protecting updates with a symmetric key. |
| MiFID II RTS 25 — |
Numeric clock accuracy: tiered divergence from UTC (down to 100 µs) and timestamp granularity | The only framework with a hard number — but says nothing about authenticating the source it traces to. |
| DORA Reg. (EU) 2022/2554 · RTS (EU) 2024/1774, Art. 12(2)(f) |
“the synchronisation of the clocks of each of the financial entity’s ICT systems upon a documented reliable reference time source” | Finance/resilience-oriented. No numeric threshold; method and time integrity 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"
InsufficientWhy 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.
Checkbox 2: "Multiple NTP sources configured"
InsufficientWhy it exists: Redundancy. If one source fails, others take over. The NTP algorithm also compares sources against each other to detect "false tickers."
Checkbox 3: "Stratum is acceptable (1-3)"
InsufficientWhy it exists: Stratum indicates distance from the atomic/GPS reference. Stratum 1 = directly connected. Lower numbers mean a theoretically more reliable source.
Checkbox 4: "Offset is within acceptable tolerance"
InsufficientWhy it exists: A low offset proves the local clock is properly synchronized with the reference. The threshold is for your policy to set; the texts give none, except MiFID II and ANSSI (one second, as a recommendation).
No time to manage NTP monitoring? Our team monitors your synchronization 24/7.
Discover managed services →Checkbox 5: "UDP/123 firewall rules are documented"
NecessaryWhy 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.
Checkbox 6: "NTP logs are retained"
InsufficientWhy 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).
Checkbox 7: "NTP configuration documentation is up to date"
NecessaryWhy it exists: Traceability. Knowing which NTP servers are used, who manages them, and when the configuration was last reviewed.
3. Your Real Risk Level Based on Posture
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.
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 | Partially (asymmetric delay still possible, bounded to RTT/2) |
| 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 | Off-path: yes; on-path: denial of service still possible |
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 | Insufficient | Minimal | Recommended (RDEM) |
|---|---|---|---|
| NTP Service | Missing | ntpd/chronyd active | chronyd + NTS |
| Authentication | None | None (tolerated) | NTS active (RFC 8915) |
| Sources | 0-1 source | 2+ 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 authentication (NTS, or symmetric keys), the answer is no. In 2026, that is a risk worth closing.
NTP without authentication = time taken on trust.
NTP with NTS = time whose origin you can verify.
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