Time synchronization design

Design reference

Part III — NTP / Time Synchronization in Windows and Active Directory: Government & Vendor Guidelines Design Reference (October 2026)

The authorities agree on a single baseline. The forest-root PDC emulator is the only domain controller that takes time from outside the forest. It should use several traceable upstream sources (NIST, USNO, or a GPS/stratum-1 appliance traceable to them). Every other machine follows the domain hierarchy (NT5DS). The Kerberos skew limit stays at 5 minutes or less. Hypervisor time sync and Secure Time Seeding are turned off on domain controllers. Where the authorities part ways is authentication. The IETF, NSA and CISA call for authenticated time, but W32Time cannot authenticate to any external NTP server: it has no NTS and no symmetric-key client. Authenticated upstream time on an all-Windows estate therefore has to come from a non-Windows layer, such as a network device, an appliance, or a non-Microsoft NTP service.

TL;DR — design baseline

• Hierarchy and sources. Keep the default AD time hierarchy. The forest-root PDC emulator is set to Type=NTP and marked reliable, and points at several diverse upstream sources. Everything else stays NT5DS. The “how many sources” numbers differ:
  • CIS Safeguard 8.4, NSA and CISA: at least two.
  • Microsoft: three or more, or two with one marked fallback.
  • RFC 8633: four or more. DoD systems must use USNO or another approved DoD source (DISA V-243504 and WN25-00-000440). Federal civilian agencies are encouraged to use sources traceable to USNO or NIST (OMB M-26-14).
• Protect the hierarchy.
  • Kerberos “Maximum tolerance for computer clock synchronization” stays at 5 minutes, which is both the default and the DISA requirement.
  • Virtualized DCs must not take time from the host. Disable the Hyper-V Time Synchronization integration service, or set VMICTimeProvider Enabled=0.
  • Disable Secure Time Seeding (UtilizeSslTimeData=0) on Windows Server 2016–2022 DCs and VM hosts. It is already off by default on Windows Server 2025.
  • Monitor drift with w32tm /monitor and /stripchart, the W32Time events, and Kernel-General Event 1.
• Accuracy and authentication are the open decisions.
  • The default W32Time configuration only promises Kerberos-grade, loosely accurate time. The 1 s / 50 ms / 1 ms tiers require Windows 10 / Server 2016 or later plus strict latency, stratum, hop and CPU limits (Microsoft’s support boundary, formerly KB939322).
  • Authenticated upstream time is only available from: NIST’s registered symmetric-key service (IPv4 only, written request); USNO’s DoD NIPRNet symmetric-key service; NTS (RFC 8915) on non-Windows components.
  • W32Time supports none of these, so authentication must be terminated on routers, firewalls or time appliances.

Authoritative design-source overview

Date /

1. Time hierarchy design

Design decision. Which machine is the authoritative internal clock, and how does time flow down to DCs, member servers, clients and child domains?

Realistic options.

• (a) Default AD hierarchy. The forest-root PDC emulator is Type=NTP, synced to external sources and marked reliable. All other domain-joined machines are NT5DS.
• (b) Dedicated internal stratum-1 appliances (GPS or PTP). The forest-root PDC emulator syncs from them, and the AD hierarchy continues below it.
• (c) Flat manual peer lists (Type=NTP) on members. This bypasses the domain hierarchy.
• (d) AllSync. All available mechanisms are used.

What the sources say.

• Microsoft (Tools and Settings). Most domain-joined computers use NT5DS and sync from the domain hierarchy. The exception is the forest-root PDC emulator, which “is configured to synchronize time with an external time source.” The Type values are NTP, NT5DS and AllSync. AnnounceFlags bits are 0x01 always time server, 0x02 automatic, 0x04 always reliable and 0x08 automatic reliable; the default is 10 (0x0A). w32tm /config /reliable:yes marks a DC as a reliable time source and “is only meaningful on domain controllers.”
• Microsoft (STS article). Within AD, most machines discover their time server dynamically; the exception is DCs marked “Good Time Server,” and the forest-root PDC defaults to this role.
• DISA (AD Forest STIG V-243504). The forest-root PDC emulator is “the normal default to provide the authoritative time source for the entire forest” and must get its time from an external DoD time source. The rule is N/A for other DCs. “Clients and lower-level servers will synchronize with an authorized time server in the hierarchy.” Windows Server STIG checks treat NT5DS on domain members as compliant and flag Type=NTP systems (including the PDC emulator) that point at a non-DoD server.
• CISA. Document the timing topology, including which servers distribute time and their traceability to stratum-1.

Child domains and members. Members and member servers sync from a DC in their domain; DCs sync from DCs, including the PDC emulator of their own domain; a child domain’s PDC emulator syncs up the hierarchy into the parent or forest root. Only the forest-root PDC emulator, or an explicitly configured reliable DC or appliance, should hold an external peer list.

PDC emulator role transfer. The W32Time settings that make the forest-root PDC emulator authoritative are local registry or GPO values on that server; they do not travel with the FSMO role. After a transfer or seizure, the design must point the new role holder at external peers (/syncfromflags:manual, /reliable:yes), return the old holder to NT5DS with /reliable:no (or reset it with w32tm /unregister and /register), and check with w32tm /query /source and /monitor. A common pattern is a GPO scoped by a WMI filter to the current PDC emulator; this is community practice, with no Microsoft or DISA mandate for it.

Trade-offs. The default hierarchy needs almost no configuration and gives Kerberos-grade consistency; its weak point is one key server that must be reconfigured whenever the role moves. Manual peer lists on members break the “single source of truth” and trigger STIG findings unless the peers are DoD-approved. AllSync has no clear design rationale in the sources and is rarely used.

Conflicts. None of substance. Microsoft and DISA describe the same hierarchy, and DISA adds the DoD-source constraint.

2. External upstream source selection design

Design decision. What does the top of the hierarchy sync from, and how many sources?

Realistic options.

• (a) NIST ITS public servers — time.nist.gov (round-robin) or named servers (Gaithersburg time-a-g…time-f-g; WWV Fort Collins time-a-wwv…time- e-wwv; Boulder time-a-b…time-e-b), some with IPv6.
• (b) NIST authenticated servers — ntp-b, ntp-wwv, ntp-d.nist.gov, registered users only.
• (c) USNO public stratum-1 servers — Eastern: tick, tock, ntp2.usno.navy.mil; Mountain: tick, tock.usnogps.navy.mil; plus authenticated servers for DoD NIPRNet customers only.
• (d) An on-premises GPS/GNSS-disciplined stratum-1 appliance, optionally combined with network sources.
• (e) A protective or filtering upstream (routers/firewalls/appliances that authenticate to NIST or USNO and re-serve internally).
• (f) The community pool.ntp.org, or vendor services such as time.windows.com (time.windows.com is Microsoft’s default NtpServer value).

What the sources say.

• NIST. Use the generic name time.nist.gov; hard-coding a particular server name/address is “a bad practice”; clients must never query more than once every 4 seconds.
• USNO/CNMOC. The stratum-1 servers are open to stratum-2 servers in the same time zone; individual users should use public stratum-2 servers. USNO “strongly recommend[s]” picking one or more nearby servers plus others for redundancy. DoD entities should use only the DoD authenticated USNO servers, not the public hosts. USNO notes Windows lacks a symmetric-key NTP client and advises authenticating to USNO on routers/firewalls and having Windows sync from those devices.
• DISA. The forest-root PDC emulator and any Type=NTP system must use a DoD time source; the fix text points to the USNO/CNMOC NTP pages.
• OMB M-26-14. Network time must be synchronized “to a traceable time source designated within the agency”; agencies are encouraged to use sources traceable to USNO or NIST where feasible. The memo excludes national security systems and DoD/IC systems.
• CISA (Time Guidance). UTC(USNO) and UTC(NIST) are the principal official US time sources; use “at least two or more traceable time sources with the lowest possible stratum”; diversify receiver types and sources.
• NSA (Network Infrastructure Security Guide). Network devices should use at least two NTP servers, with NTP authentication enabled.
• CIS Controls v8.1, Safeguard 8.4. “Configure at least two synchronized time sources across enterprise assets, where supported” (IG2/IG3). Version 7.1 had asked for three.
• IETF RFC 8633. Use at least four independent, diverse sources; two cannot resolve a disagreement between them.
• Microsoft. Since Server 2016’s algorithm changes, use three or more time servers; with only two, flag one UseAsFallbackOnly (0x2). The STS article adds that “an odd number of comparable time servers (more than one)” helps redundancy.

pool.ntp.org. A volunteer, community service with no government standing; under DISA rules not a DoD source, and it does not give the documented traceability OMB asks for. Common in non-regulated environments.

Trade-offs. NIST/USNO public servers give documented traceability at no cost but are unauthenticated over the internet and rate-limited (and USNO restricts its stratum-1 servers to stratum-2 servers). A GPS appliance gives internet independence and low stratum but brings GNSS spoofing/jamming risk and firmware-lifecycle work (CISA cites the 2019 GPS week- rollover failures). More sources improve fault detection but need more firewall egress and monitoring.

Conflicts. Source count: two (CIS, NSA, CISA), three/odd (Microsoft), four (IETF). DoD vs civilian: DoD must use USNO or an approved DoD source; civilian agencies under OMB are only “encouraged” toward USNO/NIST traceability.

3. Accuracy and performance design

Design decision. What accuracy does the estate need, and what will it cost to support?

Options. Default Kerberos-grade time; 1 s; 50 ms; 1 ms. Beyond 1 ms, non-W32Time solutions (PTP-capable third-party software or appliances) are needed.

What Microsoft says (Support boundary page, updated 2026-02-12).

• Before Windows 10 1607 / Server 2016: W32Time only gave Kerberos-grade, “loosely accurate” time; tighter accuracy was unsupported.
• Windows 10 / Server 2016 and newer: can deliver 1 s, 50 ms or 1 ms “under the right operating conditions.” Accuracy depends on an accurate, stable stratum-1 root and the end-to-end path; asymmetry or high CPU load degrades it.
• 1 s tier: Windows 10 / Server 2016+; an NTP hierarchy ending in a highly accurate, Windows-compatible source; every node configured per “Configuring Systems for High Accuracy”; cumulative one-way latency of 100 ms or less.
• 50 ms tier: latency under 5 ms to the source; stratum 5 or less; six or fewer hops; one-day average CPU of 90% or less on every stratum (and the host for VMs).
• 1 ms tier: latency under 0.1 ms; stratum 5 or less; four or fewer hops; CPU 80% or less (including host).
• Default (“Configuring systems for high accuracy”). “most customers don’t require highly accurate time.” The default aims to satisfy Kerberos v5 and loosely accurate time; higher tiers require registry/GPO changes (polling intervals, update rates).

Other sources. CISA: validate whether applications really need time and at what accuracy relative to UTC(NIST)/UTC(USNO) (its example: trading firms timestamping within 50 µs). USNO: typical internet NTP accuracy is 1–30 ms. NIST SP 800-53 AU-8: leaves timestamp granularity to the organization.

Stratum depth. Each AD tier (forest-root PDC, child PDC, DC, member) adds a stratum; a deep multi-domain forest can hit the stratum-5 limit for the 50 ms and 1 ms tiers. Shallow hierarchies or appliances near consumers address this.

Trade-offs. Higher tiers need tighter polling (more traffic and DC load), latency engineering, CPU headroom and monitoring. Regulated sectors (finance, telecom, energy) are the usual drivers; for most AD estates, the default plus good sources and monitoring is enough.

Conflicts. None. Other authorities leave the accuracy target to the organization and do not contradict Microsoft’s tiers.

4. Kerberos skew dependency design

Design decision. What clock-skew tolerance is acceptable, and how does time sync protect authentication?

What the sources say.

• Microsoft. “Maximum tolerance for computer clock synchronization” sets the maximum difference Kerberos v5 tolerates between client and KDC clocks; Microsoft advises 5 minutes (also the default). It lives in the Default Domain Policy under Account Policies > Kerberos Policy. W32Time was originally built to meet the Kerberos requirement that clocks be synchronized.
• DISA. WS2022: V-254390 / WN22-DC-000060 (Medium). WS2025: V-278137 / WN25-DC-000060 (Medium). Both require the setting to be 5 minutes or less; the Windows Server STIG time rules justify time sync as “essential for authentication and auditing purposes.”
• DISA (V-243504 rationale). Inaccurate forest time can cause access to resources on computers with accurate time to be denied, and weakens audit data as forensic evidence.

Dependencies. Kerberos ticket issuance and replay protection depend on time, and so does everything built on Kerberos (Group Policy, LDAP and SMB authentication). X.509 certificate validity windows and token lifetimes depend on it too. Separately, large backward time jumps on DCs can cause replication problems (Microsoft’s virtualization guidance cites lingering objects and replication stopping).

W32Time correction behavior. MaxPosPhaseCorrection/MaxNegPhaseCorrection: default 172,800 s (48 h) on DCs and 0xFFFFFFFF on domain members (corrections larger than these are logged rather than applied). MaxAllowedPhaseOffset: default 300 s on domain members (offsets above it are stepped rather than slewed).

Trade-offs. Raising the tolerance hides time faults and widens the replay window; lowering it below 5 minutes increases authentication failures when time degrades.

Conflicts. None. Microsoft’s default and DISA’s maximum are the same.

5. Virtualized domain controller time design

Design decision. Should virtualized DCs take time from the hypervisor or from the AD hierarchy?

Options.

• (a) Fully disable host time sync. In Hyper-V, clear the “Time synchronization” integration service with the VM off.
• (b) “Partially disable.” Leave the integration service on (guest gets correct time at boot/restore) but set HKLM\SYSTEM\CurrentControlSet\ Services\W32Time\TimeProviders\VMICTimeProvider\Enabled = 0 so W32Time ignores the host as a source.
• (c) Leave host sync on. Not recommended for DCs.

Other hypervisors have equivalent “sync guest time with host” settings.

What the sources say. Microsoft (Virtualizing DCs with Hyper-V): disable time sync between host and guest for VMs acting as DCs so the DC syncs from the domain hierarchy. Microsoft AskDS (2024): disable VMICTimeProvider on DCs and other VMs that should follow the AD hierarchy; check with w32tm /query /source (“VM IC Time Synchronization Provider” in the output means the host is the source). Microsoft (STS article): VM hosts are time-sensitive machines where STS should be disabled, and the host’s own clock should come from a reliable source. Older Microsoft guidance suggested leaving host sync on and later moved to “partial disable”; the current Learn page resolves this by recommending host sync be disabled for DCs.

Trade-offs. Full disable removes the conflict between two time authorities but the VM may boot with a stale clock after save/restore until W32Time corrects it within phase-correction limits. Partial disable keeps boot-time seeding but Windows updates or integration-service resets can re-enable the provider, so it needs monitoring. The forest-root PDC emulator as a VM is a special case: it must not take host time, and its host should itself be synced to a reliable source.

Conflicts. None among current documents; the conflict is only historical.

6. Time authentication design

Design decision. How is the integrity of time protected, inside the forest and at the external boundary?

Mechanisms. Symmetric-key NTP (RFC 5905 MAC) — pre-shared key/key ID with MD5, SHA- 1 or SHA-2 digest, manual key management. NTS (RFC 8915) — TLS-based key establishment (NTS-KE on TCP 4460), then authenticated NTP on UDP 123, automatic key management, scales. Autokey (RFC 5906) — known vulnerabilities; RFC 8633 says “Autokey SHOULD NOT be used.” Inside AD, W32Time protects time samples with domain security extensions (MS-SNTP using the Netlogon secure channel); Microsoft describes AD as “NTP augmented with ADDS security extensions within the AD domain/forest,” and “typically bridged outside the AD forest through standard plaintext NTP.”

What W32Time can do. It does not implement NTS; it does not implement symmetric-key client authentication to standard NTP servers (USNO states this explicitly). So any external peer configured on the forest-root PDC emulator is unauthenticated.

Government authenticated options.

• NIST Authenticated NTP. Free, symmetric key, IPv4 only; request by US mail or fax listing up to four static IPv4 addresses; key types MD5, SHA1, SHA256, HMAC-SHA256, SHA3-256; NIST never sends keys by email; unused keys (no use over a 30-day window at the annual survey) are deleted without notice; NAT/proxies complicate registration; NIST does not support Autokey and does “not yet” support NTS-KE.
• USNO. Symmetric-key authentication offered only to DoD on NIPRNet, by signed-email request (SHA256 recommended; MD5/SHA1 legacy); the public service has no authentication. The DoD page still says NTS is “coming soon,” projected for NIPRNet in “1QTR 2025” — a date that has passed with no update, so current availability is unconfirmed.

Policy drivers. NSA: enable NTP authentication on all network devices, strong unique keys, at least two servers. CISA: have an authentication scheme to verify time comes from legitimate servers, and block non-authenticated ports at the perimeter. RFC 8633: do not use Autokey; NTS is the replacement.

What is achievable on an all-Windows estate. (1) Rely on AD’s built-in authenticated distribution inside the forest. (2) Terminate authenticated upstream time on a non-Windows component the forest-root PDC emulator then syncs from over plaintext NTP on a trusted segment — routers/firewalls with NIST/USNO or other symmetric keys; GPS/stratum-1 appliances; Linux chrony/NTPsec using NTS or symmetric keys (USNO itself recommends this pattern). (3) Add egress filtering so only designated time hosts reach external UDP 123. (4) Monitor for time jumps.

Trade-offs. Symmetric keys are mature but need manual key handling and IPv4 registration with NIST; NTS scales but neither W32Time nor (yet) NIST/USNO public service supports it; the intermediary pattern adds components that must be inventoried and patched (CISA stresses timing devices in lifecycle management).

Conflict. IETF, NSA and CISA expect authenticated time, but the Microsoft time service cannot provide it externally. This is the main standing gap in this reference.

7. Secure Time Seeding design

Design decision. Should STS be enabled on servers?

What STS is. A heuristic in W32Time that estimates the current time from metadata in outbound SSL/TLS connections and uses it to correct large clock errors. Controlled by UtilizeSslTimeData (registry or GPO under Windows Time Service > Global Configuration Settings); needs a reboot to change.

Defaults (Microsoft, updated 2026-02-12). Enabled by default on all editions of Windows Server 2016, 2019 and 2022, and on Windows 10 1511+ and Windows 11 clients. Disabled by default on Windows Server 2025, “based on customer feedback.” The Tools and Settings registry reference confirms default 1 everywhere except Server 2025 (0); domain membership does not change it. Note: the GPO “Global Configuration Settings” default table still lists UtilizeSslTimeData = 1 when the policy is enabled, so enabling that GPO on Server 2025 without setting the value explicitly could re-enable STS (an inference from the published defaults, not a Microsoft statement).

Microsoft’s recommendation. Disable STS on Windows Server machines with time-sensitive workloads, explicitly including AD DS domain controllers and VM hosts; consider disabling it on all Windows Server machines even if no problems have been seen. The reported failures were random time jumps of days to years (some self-corrected, some persisted). Roll out gradually, test first, and confirm the setting through events 257, 260 or 263, or the W32Time debug log; put time monitoring in place (e.g., Kernel-General Event 1) before and after. The guidance is not extended to client SKUs.

Design pattern. Server 2016–2022: explicitly set UtilizeSslTimeData=0 by GPO, at minimum on DCs and hypervisor hosts. Server 2025: verify the value rather than assume it. Clients: leave STS at default unless problems appear (some devices, e.g., with flat CMOS batteries, rely on STS to recover).

Trade-offs. Disabling STS removes a source of unexplained time jumps on servers; it also removes a recovery path for machines that boot with grossly wrong time and cannot reach NTP, so monitoring compensates.

Conflicts. None among the authorities reviewed. STIG and CIS coverage of STS was not verified for this report.

8. Monitoring, logging, and leap-second design

Design decision. How is time health monitored, how are log timestamps standardized, and how are leap seconds handled?

Monitoring tools (Microsoft). w32tm /monitor (domain-wide offsets; prefix a computer name with * to treat it as PDC); w32tm /stripchart /computer:<target>; w32tm /query /status /verbose; w32tm /query /source, /configuration, /peers; w32tm /debug private logging.

Event sources. Microsoft-Windows-Time-Service events (source changes logged by default, EventLogFlags=2); events 257, 260 and 263 record configuration including STS state; Kernel- General Event 1 records every system-time change and the process that made it; commonly cited W32Time warnings include no-usable-source and unsynchronized-for-extended-period events (exact IDs not verified against a current Microsoft page); TimeJumpAuditOffset and ClockAdjustmentAuditLimit tune auditing.

Logging requirements. NIST SP 800-53 Rev 5 AU-8: audit records carry timestamps from internal clocks at an organization-defined granularity, using UTC, a fixed UTC offset, or an embedded offset; the synchronization enhancements AU-8(1)/(2) were withdrawn and moved to SC-45(1) (authoritative source) and SC-45(2) (secondary authoritative source). DISA maps its time rules to AU-8(1)/SC-45(1). CIS Control 8.4 treats time sync as part of audit log management. OMB M-26-14 Appendix B: logs “must include a consistently accurate timestamp”; network time via NTP or equivalent to an agency-designated traceable source, preferably traceable to USNO or NIST. CISA/NSA/FBI joint event-logging guidance (Aug 2024): set up an accurate, trustworthy time source and use it consistently, with the same date-time format everywhere; use multiple sources where possible; prefer UTC. CISA: timestamps and correctly correlated offsets are critical to reconstructing intrusion timelines. NIST SP 800-92: broader log-management planning, including clock consistency across log sources.

Leap seconds. Windows: W32Time historically “does not implement a leap second” — it passes the NTP Leap Indicator downstream but does not insert the second and corrects through normal sync; the same archived Microsoft page (KB2722715) states WS2019 and Windows 10 October 2018 Update support leap seconds in the platform. Dissemination: NIST and USNO disseminate leap-second information, and NTP carries leap warnings (NIST lists this as a protocol feature); NIST publishes a leap-seconds data file (current location not re-verified). CISA: test before and after known time events such as leap seconds and DST, and document how systems handle them. CGPM status: in 2022 the 27th CGPM (Resolution 4) decided to raise the UT1–UTC tolerance by or before 2035; at the 28th CGPM on 15 October 2026, delegates adopted Resolution 5 (“On the technical actions needed to ensure the continuity of UTC”), under which “continuous UTC will become effective on 20 May 2027” and the maximum |UT1– UTC| becomes 3,600 seconds (1 hour), per the BIPM-published resolution text. The last leap second was 31 December 2016; no negative leap second has ever been applied.

Design implications. Monitor and alert on offset against designated references, and on time- jump events; standardize log timestamps on UTC; keep leap-second handling in test plans until May 2027, then treat leap seconds as a legacy concern while keeping code paths tolerant.

Conflicts. None material. The authorities differ only in how strongly they mandate UTC: CISA/NSA prefer it, while NIST also allows a fixed or embedded offset.

Where authorities agree, differ, or conflict

Agree. The forest-root PDC emulator is the external boundary (Microsoft, DISA). Time must be traceable to national standards; UTC(NIST) and UTC(USNO) are the official US references (CISA, OMB, DISA). Use more than one upstream source. Kerberos tolerance stays at 5 minutes or less (Microsoft, DISA). Synchronized time is required for logging and forensics (NIST, OMB, CISA/NSA, CIS, DISA). Virtualized DCs must not take host time (Microsoft). Autokey should not be used (IETF; NIST does not support it).

Differ. Number of sources: CIS, NSA and CISA say at least two; Microsoft says three or more (or an odd number), with two as a fallback configuration; IETF says four or more. Default accuracy vs high accuracy: Microsoft’s default only promises Kerberos-grade time; CISA and NIST leave granularity to the organization; regulated workloads need the 50 ms or 1 ms tiers and their conditions. Direct NIST/USNO vs internal hierarchy: NIST encourages time.nist.gov and discourages hard-coding; USNO restricts its stratum-1 servers to stratum-2 servers; DISA requires DoD sources; all three favor syncing only the top of an internal hierarchy externally. pool.ntp.org: acceptable as community context but not a government source (does not satisfy DISA; weaker documented traceability than OMB prefers). Leap seconds: NIST and USNO historically disseminate them, while Windows historically does not insert them; the October 2026 CGPM decision ends new leap seconds from 20 May 2027.

Conflict. W32Time vs authenticated-time guidance: NSA and CISA call for authenticated NTP, and IETF points to NTS; NIST offers only symmetric-key (and no NTS yet); USNO offers authentication only to DoD; W32Time supports neither symmetric-key nor NTS to external servers. USNO’s own workaround (authenticate on network devices) is the only government-documented answer. Secure Time Seeding defaults: Microsoft ships STS enabled on Server 2016–2022 but recommends disabling it on servers; it changed the default only in Server 2025; meanwhile the GPO default table still shows 1, a source of configuration drift.

Caveats and items that could not be verified

• DISA versions. Taken from third-party STIG mirrors (cyber.trackr.live, stigviewer, stigaview, NIST NCP), not opened on cyber.mil directly. Windows Server 2025 V1R4 is listed but its date and rule revisions are unconfirmed; the Windows Server 2016 STIG is confirmed only to V2R10 (2025); recent releases change titles to “DoW time source”; the V-278137 revision ID was not found.
• USNO. The NTS “coming soon (1QTR 2025)” statement is stale, and current NTS availability on NIPRNet is unknown. The exact timeline of the post-2023 migration of USNO web content to CNMOC-hosted pages (and retirement of tycho.usno.navy.mil URLs) was not reconstructed; some older STIG and Tenable content still cites dead USNO URLs.
• Leap seconds. The 15 Oct 2026 CGPM decision (Resolution 5; effective 20 May 2027; maximum |UT1–UTC| of 3,600 s) is taken from the BIPM-published resolution text; NIST/USNO post-decision notices were not checked.
• CIS Benchmark. Specific W32Time recommendation numbers and values were not verified for this report; they are commonly “Enable Windows NTP Client = Enabled,” with the NTP Server setting varying by profile. Check the current benchmark for your OS version.
• NIST SP 800-92. NIST CSRC lists Rev 1 as an Initial Public Draft (11 Oct 2023) that will replace the 2006 Final version once finalized.
• W32Time event IDs. Apart from 257/260/263 and Kernel-General 1, the specific event IDs were not verified against current Microsoft pages.
• PDC role transfer. That the W32Time external configuration does not follow a PDC role transfer is standard practice and follows from W32Time being configured per machine; no single current Microsoft page states it verbatim. GPO/WMI-filter automation is community practice.
• OMB M-26-14. Applies to federal civilian agencies; national security systems and DoD/IC systems are excluded, so DoD estates follow DISA/USNO instead. CISA published the Logging Reference Architecture in August 2026 (reported 20 Aug 2026), which puts Agency Logging Plans due within 90 days (about 18 Nov 2026); its contents were not reviewed for this report.
• Lead authorship. The joint event-logging guide was led by Australia’s ASD ACSC and co-sealed by CISA, NSA and FBI; it is used here only as a US co-authored source.
• Licensing. Microsoft Learn content is under Microsoft Terms of Use; some MicrosoftDocs repositories carry open licences, which were not verified per page. CIS licences are as stated by CIS for v8.1 and the Benchmarks. US federal works are generally not subject to US copyright.

Annotated source catalog

Reference Collection: NTP and Time Synchronization for Windows/Enterprise Environments (verified October 2026)

The baseline is consistent across sources. Inside an Active Directory forest, time flows down a hierarchy from the forest-root PDC emulator, and that PDC emulator should take time from an authoritative external source such as NIST, USNO (US Naval Observatory), GPS or a stratum- 1 appliance. Kerberos tolerates 5 minutes of clock skew. Most items from the prior pass held up, but several were wrong or out of date: STIG severities, NIST authenticated-server details, the leap-second timeline, how W32Time authenticates, and the USNO page URLs.

1. TL;DR

• Microsoft’s baseline:
  • The domain hierarchy is NT5DS. The forest-root PDC emulator is the root and syncs to an external NTP source.
  • The Kerberos skew policy is 5 minutes.
  • Secure Time Seeding (STS) is on by default in Server 2016/2019/2022 and off by default in Server 2025. Microsoft recommends disabling it on time-sensitive servers such as DCs and VM hosts, and suggests considering it for all Windows Server machines.
  • Up to 1 ms accuracy is supported only on Windows 10 / Server 2016 or later, and only under strict network, stratum and CPU conditions.
  • W32Time documents no support for NTS (RFC 8915). Its only built-in authentication works inside the domain and is signed with Kerberos/Net Logon session keys. Manually configured external peers are unauthenticated.
• The government baseline is “sync to an authoritative source, with redundancy”:
  • NIST SP 800-53 Rev. 5 AU-8 covers timestamps. Synchronization moved from AU-8(1)/(2) to SC-45(1)/(2).
  • OMB Memorandum M-26-14 (22 May 2026) rescinded M-21-31. It requires log timestamps synchronized by NTP or equivalent “to a traceable time source designated within the agency”, and encourages sources traceable to USNO or NIST.
  • DISA STIGs require a DoD source. AD Forest V-243504 (forest-root PDC external source) is CAT II. The Windows Server 2022/2025 “DOD time source” rules are CAT III (Low).
  • CIS Safeguard 8.4 requires at least two synchronized time sources.
  • NSA recommends at least two NTP servers plus NTP authentication on network devices.
• Live services, checked on publisher pages:
  • NIST ITS lists 20+ stratum-1 hostnames behind time.nist.gov and a “never more than once every 4 seconds” rule.
  • NIST’s symmetric-key authenticated servers are ntp-b, ntp-wwv and ntp-d. They are free but need a mailed or faxed request and registered static IPv4 addresses.
  • USNO publishes tick/tock/ntp2.usno.navy.mil as public servers on its CNMOC site. It tells DoD entities not to use them and to use its authenticated DoD servers instead.
  • On 15 October 2026 the 28th CGPM (the General Conference on Weights and Measures) adopted Resolution 5, which makes UTC continuous from 20 May 2027. This ends leap seconds earlier than the 2022 “by 2035” resolution. A BIPM statement by CCTF President Noël Dimarcq says “continuous UTC will take effect on 20 May 2027” and sets “a long-term limit of one hour” for UTC−UT1.

2. Guidance landscape overview

3. Section A: Microsoft official guidance by topic

A1. Support boundary for high accuracy time

• URL: learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/support-boundary- high-accuracy-time. A parallel copy sits at /windows-server/networking/windows-time- service/support-boundary.
• Version: last updated 2026-02-12. This is the successor to KB939322. The Learn articles still cite “Knowledge Base article 939322” by name.
• Applies to: “Supported versions of Windows Server” and “Windows Server (All supported versions) including Azure Stack HCI, Windows client (All supported versions)”. Server 2025 is not named, but the “all supported versions” wording covers it.
• Scope: systems before Windows 10 1607 / Server 2016 1607 “can’t guarantee highly accurate time”. They were designed only for Kerberos- level accuracy.
• Accuracy tiers: Windows 10, Server 2016 and newer releases “can deliver 1 second (s), 50 milliseconds (ms), or 1 ms accuracy” under the right conditions. Accuracy is “highly dependent on using an accurate, stable root (stratum 1) time source”.

• Licence: Microsoft Terms of Use.

A2. Accurate Time / Configuring systems for high accuracy

• These pages back the “up to 1 ms” claim. The W32Time hub page says “you can maintain a 1-ms accuracy with respect to UTC or better” for Server 2016 / Windows 10 Anniversary Update domain members “under reasonable operating conditions”.
• “Configuring systems for high accuracy” says “most customers don’t require highly accurate time”.
• It requires every device in the chain, including the Hyper-V host and the upstream Windows time server, to be Windows 10 / Server 2016 or later.
• It covers the W32Time startup type. Third-party summaries paraphrase this as “Automatic, always running”. I did not re-read the exact sentence in this pass.
• The content is Server 2016-era but still the current publication.

A3. Secure Time Seeding recommendations for Windows Server

• URL: learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/sts- recommendations-for-windows-server. Last updated 2026-02-12.
• Defaults (confirmed):
  • STS is “enabled by default in all editions of Windows Server 2016, Windows Server 2019, and Windows Server 2022”, and in Windows clients from Windows 10 version 1511 onward.
  • It is “disabled by default in Windows Server 2025, based on customer feedback”.
• Recommendations:
  • Disable STS on Server 2016+ machines running time-sensitive workloads, explicitly naming AD DS domain controllers and VM hosts.
  • “Consider disabling” it on all other Windows Server machines.
  • On Server 2025, verify that the settings meet your needs.
• Control:
  • GPO: Computer ConfigurationTemplatesTime ServiceConfiguration Settings → UtilizeSslTimeData.
  • Registry: HKLM32Time(REG_DWORD; 0 = disabled, 1 = enabled). A reboot is required.
• Verification: Time-Service Operational events 257/260/263, or the w32time debug log.
• Monitoring: the page suggests watching System log Kernel-General Event 1 for large time changes.
• Scope: the recommendation does not extend to client SKUs.
• Message center: a Microsoft 365 message center post (MC1085489, mid-2025) was reported by third-party trackers as recommending disablement on Server 2016–2025. I did not view it on a Microsoft page.

A4. Maximum tolerance for computer clock synchronization

• This is a Kerberos policy. It sets “the maximum time difference (in minutes) that Kerberos V5 tolerates” between client and DC clocks.
• The current page advises 5 minutes. The legacy Server 2003 page states the policy “is set to 5 minutes by default” and explains the replay-attack rationale.
• Location: Default Domain Policy → Computer ConfigurationSettingsSettingsPoliciesPolicy.

A5. Windows Time service tools and settings

• Version: last updated 2025-09-18. Applies to Server 2025/2022/2019/2016, Windows 11/10 and Azure Local.
• Network: W32Time uses UDP 123. The built-in client always uses 123 as its source port. /stripchart uses an ephemeral port.
• w32tm syntax (confirmed):
  • /config [/computer:] [/update] [/manualpeerlist:] [/syncfromflags:MANUAL|DOMHIER] [/reliable:YES|NO] [/largephaseoffset:]
  • /query {/source|/configuration|/peers|/status} [/verbose]
  • /monitor [/domain:] [/computers:] [/threads:]
  • /resync [/computer:] [/nowait] [/rediscover] [/soft]
  • /stripchart /computer: [/period:] [/dataonly] [/samples:] [/rdtsc]
  • Also /debug, /dumpreg and /tz.
• Multiple peers: with more than one peer, Microsoft recommends “three or more time servers”. With only two, flag one as UseAsFallbackOnly (0x2).

• GPO caveat: the “Global Configuration Settings” GPO table lists UtilizeSslTimeData = 1 as its default. Enabling that GPO without editing the value could re-enable STS. This is my inference from the published table, not a Microsoft warning.

A6. How the Windows Time Service works; AD time hierarchy

• Version: last updated 2025-07-25.
• Protocol: W32Time “isn’t an exact implementation” of NTP. Its NTP provider “follows the standards specified by NTP version 3”. It does not support broadcast or multicast peers.
• Hierarchy:
  • In a forest, the forest-root PDC emulator “holds the position of best time source, unless another reliable time source has been configured”.
  • The first DC is automatically a reliable source and should sync externally.
  • The PDC emulator of a child domain can sync from the parent domain.
• Ranking: DCs are scored as follows: same site 8, reliable 4, parent domain 2, PDC emulator 1.
• Moving the PDC emulator role: the external configuration does not follow the role. This comes from the legacy Server 2008 R2 page “Configuring a time source for the forest”, which tells admins to reconfigure both old and new PDC emulators when the role moves. As an alternative, it suggests configuring a non-PDC DC in the forest root as the reliable source. I found no current Learn page restating this, so treat it as legacy-sourced.

A7. NTP authentication and NTS

• Inside the forest: packets are signed with the computer’s Kerberos session key, managed by Net Logon. Unsigned or badly signed replies are rejected.
• Outside the forest: “Manually specified time sources are not authenticated unless a specific time provider is written for them”. Cross-forest sync “is not secure”.
• NTS: no Microsoft page documents NTS (RFC 8915) support. Microsoft also documents no RFC 5905 symmetric-key (key ID / MAC) configuration for W32Time’s external peers. Autokey is not mentioned. NIST’s authenticated servers do not support Autokey either.
• Practical effect: NIST’s and USNO’s authenticated services require an NTP implementation or appliance that supports keyed MACs, not built-in W32Time. This is my inference from the absence of any configuration surface.

A8. Virtualized domain controllers

• “Virtualizing domain controllers with Hyper-V” (current) recommends disabling host-to-guest time sync for DC VMs, “If the guest DC doesn’t synchronize with the host system, then it synchronizes with the domain hierarchy instead”. The method is to turn off the VM, open Integration Services and clear Time synchronization.
• The AskDS TechCommunity post “VMICTimeProvider vs AD” recommends disabling the VMICTimeProvider (W32Time, Enabled=0) on DCs so they follow the forest-root PDC.
• Older archived Microsoft blogs recommended a “partial disable”: leave the integration service on but set VMICTimeProvider Enabled=0, so host time applies only after a restore from saved state. The two approaches differ, so check them against your hypervisor platform.
• When the host is the source, w32tm /query /status shows “VM IC Time Synchronization Provider”.

A9. W32Time event IDs (System log, Microsoft-Windows-Time-Service)

Most of these descriptions sit on Server 2008 R2 “previous-versions” pages, which are legacy but still the only Microsoft catalogue of these events. Events 137/138 indicate recovery, and 139/143 indicate the server started advertising.

4. Section B: Government and standards guidance by publisher

NIST (Time and Frequency Division, Boulder/Gaithersburg)

• Internet Time Service (nist.gov/pml/time-and-frequency-division/time-distribution/internet-time-service-its; updated 2026-06-09):
• NIST runs stratum-1 servers traceable to UTC(NIST) over NTP, DAYTIME and TIME. Users are urged to move from TIME/DAYTIME to NTP.
• The status mailing list (a Google Group) is joined by emailing internet-time-service@nist.gov.
• A NIST data-repository record puts ITS accuracy “on the order of 0.001 seconds (one millisecond)”, depending on network conditions. The ~1 ms claim is therefore confirmed as NIST’s own wording, about UTC(NIST) as distributed and not end-user accuracy.
• Server list (tf.nist.gov/tf-cgi/servers.cgi; live):

• Some hosts also have IPv6 addresses.
• time.nist.gov resolves round-robin across all servers, and NIST encourages using that name.
• Users must “NEVER” query more often than “once every 4 seconds”. Faster clients are refused, and extreme cases “may be considered as attempting a denial-of-service attack”.
• NIST also warns against hard-coding server names or addresses.
• Authenticated NTP Service (updated 2026-09-17):
  • It uses symmetric-key MACs per RFC 5905. Servers: ntp-b.nist.gov (Boulder), ntp-wwv.nist.gov (Fort Collins) and ntp-d.nist.gov (Gaithersburg).
  • It is free. Requests must arrive in writing by US mail or fax, with up to four static IPv4 addresses. NIST “will not use email for sending key data”.
  • Supported key types: MD5, SHA1, SHA256, HMAC-SHA256 and SHA3-256.
  • The servers answer only registered IPv4 addresses. NAT can complicate registration.
  • Keys with no logged use over a 30-day window near fiscal year-end (September 30) are deleted without notice.
  • Autokey: “No”. NTS key exchange: “Not yet”.
• Discrepancy: an older NIST data-repository record says the authenticated service “uses public key encryption”. The current service page says symmetric key. The service page is the authoritative one.
• Leap seconds:
  • tf.nist.gov/leap-seconds.list is confirmed. It lists past and announced leap seconds and is updated at least twice a year from IERS (International Earth Rotation and Reference Systems Service) bulletins.
  • NIST servers insert a positive leap second by repeating 23:59:59 and announce it from 00:00 UTC on the last day of the month.
• SP 800-53 Rev. 5 (Release 5.2.0, 27 Aug 2025):
  • AU-8 “Time Stamps”: use internal system clocks to generate audit timestamps, at organization-defined granularity, in UTC, at a fixed UTC offset, or with the offset included.
  • AU-8(1) and AU-8(2) are “[Withdrawn: Moved to SC-45(1)]” and “[…SC-45(2)]”. This is a Rev. 5 change from 2020, not a 5.1.1 or 5.2.0 change.
  • SC-45(1) is compare-and-sync with an authoritative source. SC-45(2) is a secondary authoritative source in a different geographic region.
  • Third-party mappings report that SC-45 is not in the SP 800-53B Low, Moderate or High baselines, though it appears in SP 800-82r3 OT overlays. This should be checked against the 800-53B spreadsheet.
  • All are public domain US government works.
• SP 800-92: Guide to Computer Security Log Management (final, 13 September 2006) is still the current final version. NIST’s CSRC lists SP 800-92 Rev. 1, “Cybersecurity Log Management Planning Guide”, as “Status: Draft”, with an initial public draft dated 11 October 2023.

USNO (US Naval Observatory, via cnmoc.usff.navy.mil)

• Public servers: the “US Eastern Time Zone NTP Servers” page is live and lists tick.usno.navy.mil, tock.usno.navy.mil and ntp2.usno.navy.mil. Each is described as “NTP V4 primary (USNO Master Clock H-masers)” with “Open access for MIL, GOV, and other stratum 2 servers”.
• Other pages: a “US Mountain Time Zone Servers” page also exists; I did not fetch it. The Network Time Foundation wiki entries for these hosts were updated by USNO on 10 Jul 2026. They list stratum 1, “Supports NTS · No” and no symmetric key on the public hosts.
• DoD Customer Servers page:
  • DoD entities should use only the DoD authenticated USNO NTP servers “and NOT” the public tick, tock, ntp2, tick.usnogps or tock.usnogps.
  • The authenticated service covers DoD and US government agencies on NIPR and SIPR. Requests go by signed email to usno-ops-center@us.navy.mil.
  • SHA256 keys are “highly recommended”. SHA1 and MD5 are legacy and “may soon be deprecated”.
  • The NTS notice is stale: it still says “projected… beginning in 1QTR 2025” under “COMING SOON”.
• URL change: the old usno.navy.mil/USNO/time/ntp/dod-customers address has been replaced by the CNMOC pages. Some STIG text still cites the old URL.
• What could not be confirmed: whether the hosts answer NTP right now, since I could not run a live NTP probe, and the details of the 2023 disruption. The publisher pages and the July 2026 directory updates suggest the service is operational.

CISA / NSA / OMB

• NSA, Network Infrastructure Security Guide (v1.2, Oct 2023): sync devices “with at least two different NTP servers”, enable NTP authentication with strong, unique keys, and verify synchronization after configuration.
• Best Practices for Event Logging and Threat Detection (21 Aug 2024): led by Australia’s ASD/ACSC and co-sealed by CISA, NSA and FBI. It recommends “an accurate and trustworthy time source” used consistently, “multiple accurate time sources”, UTC as the “preferred time standard”, and millisecond timestamps. Because the lead author is non-US, cite it via CISA’s page.
• Enhanced Visibility and Hardening Guidance for Communications Infrastructure (Dec 2024, multinational, CISA-hosted): apply secure authentication to NTP where possible.
• CISA “Time – The Invisible Utility” (Feb 2023): general resilient-timing guidance. Not specific to logging.
• OMB M-26-14 (22 May 2026, signed by Director Russell T. Vought): states “Effective immediately, OMB Memorandum M-21-31 is rescinded.”
• Its Appendix B requires logs to “include a consistently accurate timestamp” with network time synchronized by NTP or equivalent “to a traceable time source designated within the agency”.
• It encourages “authoritative time sources traceable to the U.S. Naval Observatory or the National Institute of Standards (NIST), where feasible”.
• It does not apply to national security systems.
• Its predecessor, M-21-31 (27 Aug 2021), had required a GPS master clock first, then NIST’s authenticated service, with public unauthenticated NTP pools only as “an option of last resort”.
• No CISA or NSA item found is specific to DHCP or NTP server configuration on Windows.

DISA STIGs (free; public.cyber.mil)

• For the Windows Server rules, domain-joined systems must use NT5DS. The PDC emulator and stand-alone systems set to Type NTP must point at a DoD server.
• The Server 2025 V1R1 release removed draft rule V-277984 (“government-approved time source”).
• Kerberos skew: Windows Server 2019 rule V-205706 (WN19-DC-000060, Medium) requires 5 minutes or less.

CIS (Center for Internet Security)

• CIS Controls v8.1, Safeguard 8.4 “Standardize Time Synchronization”: “Standardize time synchronization. Configure at least two synchronized time sources across enterprise assets, where supported.” It applies to IG2 and IG3. It replaced v7.1 6.1, “Utilize Three Synchronized Time Sources”. The Controls are free under a CIS licence.
• CIS Windows Server Benchmarks: I could not confirm the specific W32Time recommendations from the current benchmark documents, which are registration-gated PDFs. Treat the prior pass’s list (EventLogFlags, MaxPos/NegPhaseCorrection, AnnounceFlags, NtpClient Type/SpecialPollInterval, NtpServer Enabled) as unverified.

IETF (primary for protocol)

• RFCs are free under the IETF Trust Legal Provisions.
• pool.ntp.org is a volunteer community project, not a government source. Rescinded OMB M- 21-31 treated such pools as a last resort. Its successor, M-26-14, instead calls for an agency-designated traceable source and encourages USNO/NIST traceability.

5. Topic crosswalk

6. Agreements, differences and conflicts

• Default accuracy vs high accuracy. All sources agree that “loose” sync is enough for Kerberos’s 5 minutes. Microsoft supports tighter accuracy only under explicit conditions: Windows 10 / Server 2016 or later throughout, a stratum-1 root, stratum 5 or less, and latency and CPU caps. NIST’s ~1 ms is the accuracy at the server, not what a Windows client is guaranteed. In practice, sub-second goals need the Microsoft support- boundary conditions, and audit granularity (AU-8) is set by the organization.
• W32Time lacks NTS vs authenticated time in IETF and government guidance.
  • RFC 8915 is the current IETF standard. NSA, NIST and USNO all favour authenticated time, as did the now-rescinded OMB M-21-31.
  • W32Time authenticates only inside the forest. External peers, including the PDC emulator’s upstream, are unauthenticated.
  • NIST does not offer NTS yet, and USNO’s NTS is “coming soon”. The authenticated government options today are symmetric-key services that need a keyed-MAC-capable client or appliance, not built-in W32Time.
• STS default debate. Microsoft changed the Server 2025 default and recommends disabling STS on DCs and VM hosts. It does not extend this to Windows clients, where STS stays on by default. The DISA and CIS items reviewed say nothing about STS, which is a gap rather than a conflict.
• Direct NIST/USNO vs internal hierarchy. Every source agrees that only the top of the hierarchy (the PDC emulator or an appliance) should reach external sources. Everyone else uses NT5DS. NIST’s 4-second limit and anti-hard-coding advice, and USNO’s “stratum 2 servers” access policy, both assume enterprises run an internal tier and do not point every host at them.
• pool.ntp.org.
  • It is non-governmental. Rescinded OMB M-21-31 limited unauthenticated public pools to a last resort. Its successor, M-26-14 (22 May 2026), drops that wording and requires “a traceable time source designated within the agency”, encouraging USNO- or NIST-traceable sources.
  • Microsoft’s own default for non-domain machines is time.windows.com, not the pool.
  • STIG environments must use DoD sources.
• Leap seconds.
  • NIST still publishes leap-seconds.list and implements leap seconds by repeating 23:59:59.
  • The CGPM’s 2022 Resolution 4 committed to ending leap seconds by or before 2035. The 28th CGPM (15 Oct 2026) adopted Resolution 5, which makes UTC continuous from 20 May 2027 with a one-hour long-term limit on |UT1−UTC|. This is confirmed in a BIPM statement by CCTF President Noël Dimarcq.
  • Leap-second handling becomes moot after May 2027. Until then the existing NIST and IETF mechanisms apply.
• STIG severity vs importance. DISA rates the forest-root PDC rule CAT II but the per- server “DOD time source” rules CAT III. This makes the PDC configuration the higher- priority control.

7. Caveats, corrections and unverified items

Corrections to the prior pass 1. W32Time authentication. W32Time’s built-in authentication is not RFC 5905 symmetric-key. It is a Microsoft domain mechanism using Kerberos/Net Logon session keys, and it works only inside the forest. External peers are unauthenticated. “Symmetric-key” correctly describes the NIST and USNO services, not W32Time. 2. STIG severity. Windows Server 2022 V-254281 and Server 2025 V-278029 are Low / CAT III. Only AD Forest V-243504 is CAT II. The Server 2025 equivalent is V-278029 / WN25-00-000440. 3. NIST 800-53. AU-8(1)/(2) were withdrawn to SC-45(1)/(2) in Rev. 5 itself (2020). This is not a 5.1.1 or 5.2.0 change. Release 5.2.0 (Aug 2025) is current. 4. Leap seconds. “End by 2035” is outdated. The October 2026 CGPM Resolution 5 sets 20 May 2027, as confirmed in a BIPM statement by the CCTF President. 5. USNO URLs. The usno.navy.mil/USNO/time/ntp/dod-customers URL is legacy. The current pages are under cnmoc.usff.navy.mil. The public hostnames remain listed, but USNO tells DoD users not to use them. 6. Support boundary applicability. The support boundary’s “applies to” now reads “all supported versions”. Server 2025 is not listed by name.

Unverified or secondary-only

• OMB: M-21-31 is no longer the controlling memo. OMB M-26- 14 (22 May 2026, whitehouse.gov) states “Effective immediately, OMB Memorandum M-21-31 is rescinded”, and its Appendix B now sets the logging timestamp/NTP requirement.
• USNO: live NTP reachability of the hosts was not tested. Details of the 2023 outage were not verified.
• CIS: the CIS Windows Server Benchmark W32Time items were not confirmed. DISA V-224862 (Server 2016) and the V-205800 (Server 2019) severity were not re-verified.
• W32Time event 29: no Microsoft page was found. Most event descriptions come from legacy Server 2008 R2 pages.
• Microsoft pages:
  • The PDC-emulator role-transfer guidance comes from a legacy Server 2008 R2 page.
  • The STS message center item MC1085489 was seen only via third-party trackers.
  • The exact wording of the “always running” startup-type statement was not re-read.
• NIST: SC-45’s absence from the 800-53B baselines is based on third-party mappings. NIST’s CSRC confirms SP 800-92 Rev. 1 is still a Draft (initial public draft 11 October 2023).
• Joint logging guide: it is ASD-led with CISA, NSA and FBI co-sealing. It is included only as a CISA/NSA co-sealed product.

Licence and reuse notes

• US government works: NIST, OMB, NSA, CISA, DISA and USNO materials are generally US government works not subject to US copyright (17 U.S.C. §105). Check individual pages for third-party content.
• Microsoft Learn: governed by Microsoft’s Terms of Use. Some source repositories carry their own open licences.
• IETF RFCs: IETF Trust Legal Provisions.
• CIS Controls and Benchmarks: free under CIS’s own licence terms, which generally allow non-commercial use. Check before redistributing.
• Third-party STIG viewers (stigviewer, Tenable, cyber.trackr.live) were used only to read rule text. Download the authoritative STIGs from DISA (public.cyber.mil).