What AU.L2-3.3.7 authoritative time source requires for CMMC Level 2
Defense contractors that handle CUI need every system that writes audit records to agree on what time it is. AU.L2-3.3.7 asks for a capability that compares and synchronizes internal system clocks with an authoritative time source, so the time stamps on audit records are consistent across systems. In practice, an assessor will want to see that each in-scope system uses its clock to stamp records, that one specified time source has been chosen, and that the clocks are actually compared and synchronized against it. The NIST SP 800-171A assessment objectives for this requirement break it into those three parts, and an assessment is only as strong as the proof for each. Under 32 CFR 170.24, AU.L2-3.3.7 is worth 1 point in the scoring model, which is low, but it is not on the exclusion list in 32 CFR 170.21, so it can sit on a POA&M for Conditional Level 2 status if the overall score qualifies.
Drifting clocks cause real investigation problems. If a firewall log, a domain controller log and a CUI file server log each show a different time for the same login, an analyst cannot build a reliable sequence of events, and correlation and user accountability records become hard to defend. The engineering work is usually modest: pick a central time server (a network device or directory service, as the CMMC Assessment Guide Level 2 describes), point each system at it, and confirm the settings persist after reboots. Chrony, which is licensed under GPL-2.0-only, is one open-source option that can synchronize Linux hosts with NTP servers or reference clocks and can also serve time to other machines. The heavier part is evidence: configuration files, service status output, and sync records that show the settings were in force during the assessment period.
Timing matters because of the current Department of War position. On 13 July 2026 the Department suspended CMMC Phase II, which had been scheduled to begin 10 November 2026, and started a 60-day review by a CMMC Reform Task Force. Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place. Contractors should confirm the current requirements for their contracts with the contracting officer and their assessor before deciding how far to take the evidence package. Whatever the timing, a time source configured now and documented with dated evidence will still be needed when an assessment or a contract review asks for it.
Which systems and time sources fall under AU.L2-3.3.7
AU.L2-3.3.7 applies to every system in the CUI boundary that generates audit records, because each one stamps events with its own clock. The cards below cover which assets belong in scope, how to choose the central time source, and how cloud and third-party systems are handled.
Servers and workstations in the CUI boundary
Any server, workstation or virtual machine that stores or processes CUI and writes audit records falls under AU.L2-3.3.7. Each one keeps its own system clock, so each must be configured to synchronize with the central time source. Build the list from the system security plan and the asset inventory, not from memory. Check that domain-joined Windows hosts and Linux servers both appear, since they often sync through different mechanisms.
Network devices and firewalls
Routers, switches, firewalls and VPN concentrators that log to a central repository produce time stamps that must match the rest of the environment. Many of these devices have a time setting that is easy to overlook after a firmware update or reset. Confirm each device points to the designated time server, and record the configuration in the device baseline so assessors can compare it against the logs.
Security tools and SIEM collectors
SIEM collectors, log forwarders, EDR consoles and vulnerability scanners generate or relay audit records, so their time stamps are in scope. A collector with a drifting clock can misorder events and break correlation across sources. Include these tools in scope even when they are managed by a separate team, and verify their time sources during the same review as the systems they monitor.
Cloud workloads and managed services
Cloud virtual machines, containers and managed services that handle CUI are in scope when they produce audit records under the organization's control. Some providers synchronize their infrastructure clocks automatically, but the assessment asks whether your systems use an authoritative source you specified. Document the provider's time source, confirm it is authoritative, and state in the SSP where responsibility for synchronization sits.
Choosing the central time source
The central source may be an internal stratum-based NTP server, a directory service such as Active Directory, or a network device that serves time. Each option must be specified and documented, and the choice must be the same across the boundary. An internal NTP server that synchronizes with external references is commonly used; chrony can act as an NTPv4 server for other machines. Confirm which source your environment uses and that it is named in the configuration baseline.
Out-of-boundary and third-party systems
Systems outside the CUI boundary that do not store, process or transmit CUI are generally not in scope for this requirement. A third-party service that handles CUI, however, must be assessed as part of the boundary or covered by an appropriate agreement. Ask each provider how it synchronizes time and whether it can supply records with consistent time stamps. Confirm these answers with your assessor before finalizing the scope statement.
How an assessor tests the time source requirement
This table maps each of the three NIST SP 800-171A assessment objectives for AU.L2-3.3.7 to the test an assessor runs, the evidence they ask for and the findings that most often cause a gap. Read each row as a question the assessor will ask of your environment, and prepare the proof before the assessment begins.
| Assessment objective | What the assessor tests | Evidence requested and common findings |
|---|---|---|
| Internal clocks are used to generate audit time stamps | Sample audit records from several in-scope systems and confirm each record carries a time stamp generated by the system clock | Evidence: sample log entries, time zone and format settings. Finding: a device or application that stamps events from a local default or a vendor appliance clock |
| An authoritative time source is specified | Confirm the organization has named the time source (for example, an internal time server or a designated external source) and that systems are configured to use it | Evidence: a documented time source, the configuration showing the server address, and the system security plan entry. Finding: no named source, or a source that nobody documented as authoritative |
| Internal clocks are compared and synchronized with the authoritative source | Check that each in-scope host compares its clock to the source and corrects drift, and that the mechanism works in practice | Evidence: synchronization status output, time daemon configuration, and logs showing successful sync. Finding: unsynced hosts, stopped services, or hosts that point to a source that no longer responds |
| Configuration consistency across systems | Verify the same time source is used across the assessment boundary, including cloud, virtual and network devices | Evidence: a host inventory with the time source for each system. Finding: configuration drift, where a rebuilt or newly added system uses a different or default source |
| Monitoring of time synchronization | Ask how the organization learns that a clock has drifted or a time source has failed | Evidence: a monitoring check or alert record. Finding: no monitoring, so drift is discovered only when logs no longer correlate |
How to implement time synchronization step by step
This sequence moves a defender from an unknown mix of system clocks to one documented time source that every audit-writing system follows. Each step ends with an artifact an assessor can inspect.
Inventory every system that writes audit records
The system owner, working with the IT team, lists every host, appliance, virtual machine, cloud workload, network device and application that generates audit records for the CUI environment. Record the operating system, the clock source each one uses today and who administers it. The step is done when the inventory covers every asset inside the assessment boundary and the system security plan references it, so no logging source is left without a time configuration.
Specify the authoritative time source in writing
The organization names the authoritative time source in a written standard, such as an internal central time server or a directory service that synchronizes to an external reference. The document states the upstream reference, the server that will serve time to the environment, and who approves changes. Assessors test this objective by looking for the specification, so the output is a signed time source standard tied to the system security plan.
Configure the central time server
The infrastructure team builds or designates a central time server inside the boundary. An open-source option is chrony (GPL-2.0-only), which can synchronize with NTP servers or reference clocks such as GPS receivers and can act as an NTPv4 server for other computers. Configure the upstream sources, the allowed client networks and the access controls on the server, then confirm it is reachable from the hosts that need it. The output is a working server with a saved configuration file under change control.
Point each system at the central time server
Administrators configure every inventoried system to synchronize with the central server, using the native time service of each platform, such as chrony, systemd-timesyncd or the Windows Time service on domain-joined machines. For network devices and appliances, the vendor documentation sets the procedure, so confirm the exact settings with the vendor. The output is a per-system configuration record showing the server name, the synchronization method and the change ticket that applied it.
Verify clock offsets across systems
Testers check that each system reports synchronization with the designated source and that clock offsets between systems stay within the tolerance the organization set in its standard. Commands such as chronyc tracking and chronyc sources show status on chrony hosts, and equivalent status commands cover other platforms. Generate a test audit event on several systems and confirm the time stamps line up. The output is a dated verification report with the raw command output attached, and any out-of-tolerance system is returned to the administrator for correction.
Confirm audit records carry consistent time stamps
Because time stamps only help investigators when they are correct in the stored logs, the logging team checks that the time zone, timestamp format and clock source appear consistently in the records that reach the log repository. They also confirm that the logs are not timestamped by a different host after collection. The output is a short sample of stored records from several sources showing matching time formats and sources, filed with the verification report.
Document the configuration baseline and monitor drift
The organization records the final time synchronization baseline, including the authoritative source, the server configuration, the per-system settings and the verification results, and places it under configuration management control. It also sets a review step so changes are approved and any system that stops synchronizing raises an alert to administrators. The output is a controlled baseline document that is reviewed with each assessment and whenever the environment changes.
Choosing a time source: directory, network device or self-hosted chrony
The CMMC Assessment Guide Level 2 expects each system to synchronize with a central time server, and that server may be a network device or a directory service. In many environments the directory already keeps domain members in step with one another, so it is often the first option an organization evaluates. The identity or infrastructure team that runs the directory usually owns the time configuration, and that ownership should be written down.
- Ownership: Assign the time configuration to the team that administers the directory, with its change history kept under the same change control as other directory settings.
- Scope check: Confirm that every in-scope system, including systems outside the directory domain, synchronizes with the same time source.
- Upstream source: Document which external or reference source the domain controllers use, because that answer satisfies the requirement to specify an authoritative time source.
- Drift reporting: Record how the directory reports clock offset and sync status, and who receives alerts when sync fails.
Before relying on this option, confirm with your assessor that the directory design, its upstream source and its evidence will satisfy the three assessment objectives for AU.L2-3.3.7.
A dedicated time appliance, or a router or firewall that serves time, can act as the central time server for in-scope systems. This option moves ownership to the network team, which typically manages the device lifecycle, firmware and access. The device itself becomes part of the assessed environment if it is in scope, so its own access controls and records must hold up under review.
- Ownership: The network or infrastructure team usually owns the device, and the organization should record that owner in the system security plan.
- Role clarity: A general-purpose router or firewall often has other duties. Confirm that the time function is documented and managed alongside those duties.
- Configuration export: Keep current exports of the time settings, including the configured sources and which clients are allowed to query the device.
- Device hardening: Because the device sits in the environment, apply the same access, change and logging expectations you apply to other in-scope systems.
- Sync evidence: Confirm the device can show its sync status and offset history, since assessors look for records of clocks being compared and synchronized.
Confirm the device's time features and reporting with its vendor before you commit to this design, and ask your assessor how they expect those records to be presented.
chrony is open-source software under the GPL-2.0-only license. It synchronizes the system clock with NTP servers or reference clocks such as GPS receivers, and it can act as an NTPv4 server for other computers. Running chrony inside your own infrastructure lets the platform team control the time source, the clients and the records without depending on a directory or appliance. The platform team typically owns this option, and the organization still owns the compliance outcome.
- Upstream choice: Use
serverdirectives for upstream NTP sources, or a GPS or other reference clock where your environment supports one, and document the choice. - Central role: Designate one or more chrony hosts as the internal server, and limit which networks may query them using
allowdirectives. - Client configuration: Configure every in-scope system to synchronize with the designated internal server, and keep that configuration in version control.
- License review: If you modify chrony or distribute it, have counsel review the GPL-2.0-only obligations that apply.
Whatever sources you choose, confirm with your assessor which configuration files, command outputs and logs they will accept as evidence of synchronization.
Accuracy expectations depend on the network path between a client and its time source. The chrony project describes typical accuracy as within milliseconds over the Internet and within tens of microseconds on a LAN. Those figures describe what chrony can typically achieve, not what an assessor will require. The supplied requirement asks that clocks be compared and synchronized with the authoritative source, so the tolerance your organization sets and documents becomes the standard you must meet.
- Internet paths: Round trips over the Internet vary more, so expect larger offsets than on a local network and set tolerances that reflect that variation.
- LAN paths: Local networks usually allow much tighter offsets, so a single internal server is often easier to hold to a strict tolerance.
- Defined tolerance: Write down the maximum acceptable offset for each system class and the action taken when a system exceeds it.
- Offset alerting: Route offset warnings to the team responsible for time, and keep the alert history as evidence.
- Air-gapped networks: Where no Internet path exists, document which internal or reference source provides time and how it is verified.
Ask your assessor to confirm the tolerance they expect for your environment, and record that agreement in your evidence file.
Evidence that proves clocks stay synchronized
An assessor testing AU.L2-3.3.7 wants to see that a named time source was chosen, that every in-scope system is pointed at it, and that the clocks really agree. The cards below cover the documents and outputs that prove each of those points, and the routine that keeps them current between assessments.
Documented authoritative time source
A short, dated document that names the authoritative time source, its address or reference, who owns it, and which systems must use it. This is the first thing an assessor checks, because the requirement is that a specified source exists. Record whether the source is an internal time server, a directory service or an external NTP pool, and state the reason for the choice. Review the document whenever the source changes, and confirm the owner still exists.
Time server configuration files
The configuration on the central time server and on each client, such as the chrony.conf file on Linux systems, showing which upstream sources are used and whether the host serves time to other machines. Keep a copy of each file under version control so the state at assessment time can be shown. Check that client files point to the documented source and not to a default vendor pool that nobody approved.
Sync status output from each system
Captured output from each in-scope system showing its current synchronization state, such as chronyc tracking or chronyc sources on chrony hosts, or the equivalent Windows time status. The output should show the reference source, the offset and whether the clock is synchronized. Collect it from a sample of systems across each system type, and record the date and host name with each capture so it can be tied to a specific system.
Audit records with consistent time stamps
Samples of audit records from two or more systems covering the same event, showing time stamps that line up within the tolerance the organization has defined. Assessors use these to test whether the synchronization works in practice, not only in configuration. Pull the samples from the central log store, note the time zone and format used, and explain any system whose time stamps differ. Illustrative example: a failed login on a workstation and the matching domain controller entry should fall within the same second.
Change records for time source updates
Tickets, approvals and change logs showing when the time source, its upstream servers or client settings were modified, who approved the change and what was tested afterwards. These records show that clock settings are managed like other configuration. Keep them in the same change system used for configuration management, and link each entry to the affected systems and the updated documentation.
Routine that keeps evidence current
A recurring check, owned by a named role, that collects sync output, compares it with the documented source and files any drift as a finding. Set the frequency in the security plan and automate collection where the platform allows it. Between assessments, rerun the check after patches, host rebuilds and network changes, because those are the events most likely to break synchronization without anyone noticing.
What meeting AU.L2-3.3.7 costs in effort and tooling
This table breaks down who pays for each part of meeting AU.L2-3.3.7, whether each cost is one-time or recurring, and what pushes it up or down. No supplied figures exist for these costs, so use the rows to structure a quote request and to check that each line item is covered. The main takeaway is that the clock source itself is inexpensive open-source software, and most of the effort lies in design, documentation and keeping evidence current.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Design of the time architecture | Organization staff or implementation partner | One-time | Number of systems, sites and cloud accounts; whether a central time server already exists |
| Configuration of time servers and clients | Internal engineers or implementation partner | One-time, plus changes when hosts are added | Mix of Linux, Windows, network devices and appliances that each need a configured source |
| chrony licensing | No license fee; chrony is GPL-2.0-only | Not applicable | Avoidable license spend, so effort and support contracts are the main variables |
| Specifying the authoritative time source | Organization decision, documented in the system security plan | One-time, reviewed on change | Whether the source is a network device, directory service or GPS-based reference, which the CMMC Assessment Guide Level 2 permits as a central time server |
| Validation and test evidence | Internal staff or implementation partner, with assessor testing later | One-time, repeated after major changes | Number of clock comparisons and log samples needed to show consistent time stamps across systems |
| Monitoring offset and synchronization status | Operations or platform team, often through existing monitoring tools | Recurring | Alert tuning, number of hosts, and whether monitoring already covers time services |
| Evidence refresh for assessments | Compliance lead or security team | Recurring | Assessment cycle, frequency of configuration changes, and how well evidence is kept in final form |
| Review of time sources after changes | Infrastructure team, with change control | Recurring, triggered by changes | Frequency of network, cloud or directory changes that affect the time source |
Where organizations fail AU.L2-3.3.7 and how to close the gap
Most failures on AU.L2-3.3.7 are not technical. They come from a missing written decision about which time source is authoritative, then drift across cloud instances, appliances and undocumented exceptions that an assessor finds during testing. Each card below names one gap, why it matters for the three assessment objectives, and the fix that produces evidence an assessor can check.
No written authoritative time source
The most common gap is that nobody has named the authoritative source. The requirement expects the organization to specify one, so a default vendor pool or an engineer's memory does not count. Write a short time standard that names the primary source, the fallback, the stratum or hierarchy, and the owner. Assessors will ask for this document first and compare it against what the systems actually query.
Cloud instances on default time settings
Cloud images often ship with the provider's default time service, which may differ from the central server named in the standard. Check each image and autoscaling template for its time configuration, not just the ones built by hand. Confirm that every instance queries the designated server, and record the query output as evidence.
Appliances excluded from synchronization
Firewalls, storage arrays, hypervisors and OT devices often keep their own clocks and are left out of the sync scope. Their audit records then carry a different time base, which breaks correlation across systems. Inventory every device that writes audit records, mark which cannot sync, and either configure them to use the central server or document a compensating step with an owner and date.
Undocumented clock offsets
A system running several seconds or minutes off the reference, often after a virtual machine restore or a manual clock change, produces records that look out of order. Set a tolerance, monitor offset against it, and alert when a system exceeds it. Keep the offset reports and the actions taken when a threshold is crossed, since assessors test whether time stamps are consistent in practice.
Chrony configuration without evidence
On Linux hosts, chrony often runs with a configuration nobody has reviewed since the build. Confirm the server or pool lines point to the designated source, that makestep and allow settings match your policy, and that the service is enabled at boot. Export the configuration and the output of chronyc tracking and chronyc sources on a schedule so the evidence stays current.
Using a POA&M for a one-point gap
AU.L2-3.3.7 is a 1-point requirement that may be placed on a POA&M for Conditional Level 2 status, but only if the overall score meets the threshold and the item closes within the allowed window. Treating the POA&M as a place to park an unconfigured time server is risky, because the item still needs a working fix and evidence before closeout. Fix the configuration now where practical, and use the POA&M only for a documented, time-bound exception.
Who configures, who outsources and who assesses
The organization is accountable for AU.L2-3.3.7 whether or not it hires help. It decides which authoritative time source its systems use, approves the configuration, assigns someone to operate it, and answers for the audit records that depend on it. The System Security Plan should name that time source and the owner of the setting, because an assessor will ask who decided and who checks it.
- Time source decision: Name the authoritative source (an internal time server, a directory service, or an external reference) and record why it was chosen.
- Named control owner: Assign one accountable role for the time configuration and its review.
- Policy and scope: Define which systems in the CUI boundary must synchronize, including network devices, servers and endpoints that write audit records.
- Operational checks: Decide how drift is detected and who receives the alert.
- Final evidence: Keep the signed-off configuration and review records in final form, not drafts.
Confirm that the owner can produce the configuration and a recent sync check on request without asking a consultant to do it.
An implementation partner such as DeployOpen can prepare the systems and the paperwork. Typical work includes installing and configuring a time daemon such as chrony on the in-scope hosts, pointing clients at the central time server, building the configuration baseline, and writing the procedures that staff follow. The partner works inside the organization's environment and hands over the configuration, documentation and evidence. It does not decide the organization's control design on the organization's behalf, and it does not certify the result.
- Configuration build: Set up the time server and client settings, including the sources and the NTP service, in the organization's own infrastructure.
- Documentation: Write the procedure, the baseline and the description used in the System Security Plan.
- Evidence preparation: Collect configuration files, sync status output and change records in a form an assessor can review.
- Knowledge transfer: Train the internal owner to run checks and respond to drift.
- Scoped deliverables: Agree the systems covered, deliverables and timeline in writing before work starts.
Ask whether the partner's scope includes handover of all configuration files and whether any ongoing monitoring is a separate retainer.
An assessor tests AU.L2-3.3.7 independently of anyone who helped build the control. For Level 2 certification, that is a C3PAO authorized or accredited by the CMMC Accreditation Body. For self-assessments, the organization or its own qualified staff performs the test. Assessors work from the assessment objectives in NIST SP 800-171A, which check that internal clocks are used for audit time stamps, that an authoritative time source is specified, and that clocks are compared and synchronized with it. They inspect configuration and run tests, and they decide whether the requirement is met.
- Objective testing: Review the configuration, observe sync status and test the mechanisms that generate time stamps.
- Independence: A consultant who designed the control should not also be the assessor who scores it.
- Result authority: Only the C3PAO issues the certification result. DeployOpen does not issue audit reports, attestations or certifications.
- Final-form evidence: Assessors score against final evidence, not drafts.
- Assessment guide: Use the CMMC Assessment Guide for Level 2 to understand expected evidence.
Before engaging any assessor, confirm its authorization or accreditation status with The Cyber AB.
Independence is about who scores the control, not who touches the system. Helping to configure and document AU.L2-3.3.7 is normal implementation work. Problems start when the same party writes the evidence, approves it and then certifies it. The line falls between preparing and testing: preparation produces configuration and records, while assessment examines them and reaches a conclusion. Organizations should keep those activities separate in both people and contracts.
- Permitted help: Configuring clocks, writing procedures and organizing evidence.
- Restricted activity: Acting as the C3PAO or grading the control for the same certification.
- Contract language: Ask the implementation partner to confirm in writing that it will not perform the assessment.
- Assessor selection: Choose an assessor that has no role in building the environment.
- Scope clarity: Document which parts of the environment the partner touched so the assessor can plan its testing.
Ask any consultant to state in the statement of work which activities it performs and which it will not perform.
Costs for AU.L2-3.3.7 fall into a few groups: the internal time spent by the control owner, the partner's configuration and documentation work, the assessment fee if a certification is required, and any monitoring that continues after go-live. Setup work is largely one-time, while checking drift, reviewing configuration and maintaining documentation recur. Pricing depends on how many systems and sites are in scope and how much of the environment is already configured. DeployOpen does not publish a price list, so a quote follows from written scope.
- One-time work: Configuration, documentation and first evidence collection.
- Recurring work: Sync monitoring, periodic review and updates after system changes.
- Cost drivers: Number of in-scope systems, network segmentation, and whether an external time source is permitted.
- Quote items to request: Systems covered, deliverables, handover format, retainer terms and exclusions.
- Assessment fees: Obtain these from the assessor directly, separate from implementation.
Compare quotes on the same scope and confirm which party owns the final configuration files after the engagement ends.
Questions buyers ask about AU.L2-3.3.7 cost and effort
Can we do AU.L2-3.3.7 time synchronization in-house instead of hiring a partner?
Yes, most organizations with an internal systems team can configure time synchronization themselves, because the work is a bounded set of server and client configuration changes plus evidence collection. The effort is usually small compared with the broader Level 2 program, but it still needs a named owner, a documented time source, and a repeatable way to show that every in-scope system syncs to it. A partner is worth considering when your team lacks the time to document the configuration to the assessment objectives or when the in-scope environment spans many platforms. Whichever path you choose, the organization owns the requirement and the evidence.
What internal staff time does AU.L2-3.3.7 actually require?
Internal staff time goes mainly to deciding the authoritative time source, configuring each in-scope system to use it, and recording the settings. A systems administrator or network engineer typically handles configuration, while a compliance lead confirms the documentation matches the three assessment objectives in NIST SP 800-171A. Expect some time for testing that clocks stay aligned after reboots and for updating the system security plan. The amount depends on how many systems, operating systems and time servers are in scope, which you should confirm against your own asset inventory before estimating hours.
How long does it take to implement AU.L2-3.3.7?
No supplied source gives a duration for this requirement, so the honest answer depends on your environment. The configuration itself is often short for a small, homogeneous network, while larger estates with mixed platforms, isolated enclaves or cloud accounts take longer because each segment needs its own verification. Plan for the time to design the time hierarchy, test changes in a non-production segment and collect evidence. Ask any partner to state the duration against a written scope rather than relying on a generic estimate.
Can AU.L2-3.3.7 go on a POA&M if we are not fully compliant?
Under 32 CFR 170.24, AU.L2-3.3.7 is worth 1 point, and it is not on the exclusion list in 32 CFR 170.21, so it can be placed on a plan of action and milestones for Conditional Level 2 status if your score is at least 88 of 110. The POA&M must close within 180 days. Confirm the current status of the CMMC program with your contracting officer, because the Department of War suspended Phase II in July 2026 and the rules you are assessed under depend on your contract. Do not assume a POA&M is available for every requirement, and check the exclusion list in the rule yourself.
What should we ask for in a quote for this work?
Ask for a written scope that names the in-scope systems, the time source design, the configuration steps per platform, and the evidence package. Request the deliverables in plain terms: the documented time source, configuration exports or screenshots, a sync verification report, and updates to the system security plan. Confirm who performs the work, what is one-time versus recurring, and how changes after go-live are handled. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and provides quotes that follow from that scope. Ask any provider to be clear that an independent assessor, not the implementation partner, issues the assessment result.
What drives the cost of AU.L2-3.3.7 up or down?
The main drivers are the number of in-scope systems, the variety of operating systems and network devices, whether the environment is cloud, on-premises or air-gapped, and how much existing documentation you already have. A single directory-based time source is simpler than several isolated enclaves that each need a reference clock. Recurring effort comes from keeping new systems pointed at the time source and reviewing configuration during change control. Costs are usually lower when the time architecture is designed once and applied through standard build templates.
Is open-source time software enough to meet the requirement?
Open-source tools can meet the technical need. For example, chrony (GPL-2.0-only) synchronizes the system clock with NTP servers or reference clocks such as GPS receivers and can act as an NTPv4 server for other computers. The license cost is typically zero, so the effort sits in configuration, monitoring and evidence. Confirm with your assessor which time sources and configurations they will accept, and make sure the chosen design lets you show every in-scope system syncing to one authoritative source.
How DeployOpen implements and documents time synchronization
DeployOpen starts this work with a written scope that lists every system whose audit records must carry a time stamp, including servers, network devices, directory services, security tools and any cloud workloads that write logs inside the assessed boundary. For each system the scope records how the clock is currently set, which time source it reads from today and who owns that setting. This inventory is the basis for the single authoritative time source decision: the client chooses the source, and DeployOpen configures a self-hosted server to match that choice. Where a client already runs a directory service or network device that serves time, the scope records it as the candidate source and the reason it was selected.
On the self-hosted side, DeployOpen typically builds the time server on the client's own infrastructure using an open-source daemon such as chrony (GPL-2.0-only), which can take time from upstream NTP servers or reference clocks and serve it to other machines on the network. The configuration is kept in version-controlled files, for example /etc/chrony.conf on Linux hosts, and each client system is pointed at the same internal server through its own time client settings. Configuration changes go through the client's change control process, so the record of who changed the time source, when and why is preserved. Clients should confirm which upstream sources their security policy permits and whether the network path to them is allowed by the boundary rules.
The evidence package is what the assessor tests, so DeployOpen documents the configuration, the systems that use it, the synchronization status output and the procedure for checking drift, then hands it to the client for review. The assessor looks for evidence that the time stamps on audit records from different systems agree, so the package should show sample audit records from two or more systems that line up with the same reference. DeployOpen prepares this material but does not issue assessment results, scores or certifications. Those decisions belong to the client, its Affirming Official and the independent assessor, and clients should confirm the current assessment rules directly with the Department of War and their assessor before relying on any particular evidence form.
