CMMC Navigatorby Foxx Cyber Bedrock CMMC

↑↓ to move, Enter to open, Esc to close. Try 3.5.3, AC.L2-3.1.1, MFA or unmarked.

3.3.7Synchronize clocks in Rev. 3

Reworded: 03.03.07 Time Stamps. Gains organization-defined parameters.

Status as of 2026-09-08

Rev. 2 is what a contract requires today. DFARS 252.204-7012 and the CMMC rule at 32 CFR 170 point at NIST SP 800-171 Rev. 2, and a standing DoD class deviation keeps it there. NIST has published Rev. 3, but publishing a revision does not change an obligation. A move to Rev. 3 would arrive through the Department's reform process and formal rulemaking, a change to that deviation or an amendment to the rule, not through publication. The Department has published its organization-defined parameter values for Rev. 3 in preparation; that is groundwork, not adoption.

Side by side

Rev. 2 · in force 3.3.7 Authoritative Time Source

Provide a system capability that compares and synchronizes internal system clocks with an authoritative source to generate time stamps for audit records.

Assessment objectives · 800-171A

  1. [a] internal system clocks are used to generate time stamps for audit records
  2. [b] an authoritative source with which to compare and synchronize internal system clocks is specified
  3. [c] internal system clocks used to generate time stamps for audit records are compared to and synchronized with the specified authoritative time source

Rev. 3 · not adopted 03.03.07 Time Stamps

a. Use internal system clocks to generate time stamps for audit records.

b. Record time stamps for audit records that meet [Assignment: organization-defined granularity of time measurement] and that use Coordinated Universal Time (UTC), have a fixed local time offset from UTC, or include the local time offset as part of the time stamp.

Determination statements · 800-171A Rev. 3

  1. 03.03.07.a internal system clocks are used to generate time stamps for audit records.
  2. 03.03.07.b[01] time stamps are recorded for audit records that meet <A.03.03.07.ODP[01]: granularity of time measurement>.
  3. 03.03.07.b[02] time stamps are recorded for audit records that use Coordinated Universal Time (UTC), have a fixed local time offset from UTC, or include the local time offset as part of the time stamp.

Organization-defined parameters

  • A.03.03.07.ODP[01] granularity of time measurement for audit record time stamps is defined.

Draws on Rev. 2 3.3.7.

Left: NIST SP 800-171 Rev. 2 and 800-171A, verbatim. Right: NIST SP 800-171 Rev. 3 and 800-171A Rev. 3, verbatim, with organization-defined blanks highlighted.

Word by word

The Rev. 2 requirement compared with its Rev. 3 successor. A mechanical comparison of the two verbatim texts, not an interpretation.

removed in Rev. 3 added in Rev. 3

Rev. 2 3.3.7 → Rev. 3 03.03.07 Time Stamps

Provide a system capability that compares and synchronizes Use internal system clocks with an authoritative source to generate time stamps for audit records. Record time stamps for audit records that meet [Assignment: organization-defined granularity of time measurement] and that use Coordinated Universal Time (UTC), have a fixed local time offset from UTC, or include the local time offset as part of the time stamp.

10 words kept, 12 removed, 42 added. Rev. 3 statement labels omitted for the comparison.

What NIST says changed

  • New security requirement title
  • Aligned with SP 800-53, Rev 5 to provide more comprehensive detail on and foundational tasks for time stamps
  • Added new ODP: granularity of time measurement

NIST, SP 800-171 Rev. 2 to Rev. 3 change analysis, class “Significant change”. At adoption, Bedrock files this under “Rework”.

NIST's Rev. 3 discussion for 03.03.07

Time stamps generated by the system include the date and time. Time is often expressed in Coordinated Universal Time (UTC) — a modern continuation of Greenwich Mean Time (GMT) — or local time with an offset from UTC. The granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks (e.g., clocks synchronizing within hundreds or tens of milliseconds). Organizations may define different time granularities for system components. Time service can be critical to other security capabilities (e.g., access control and identification and authentication), depending on the nature of the mechanisms used to support those capabilities.

What this means for you now

Nothing changes in what you are assessed against until a class deviation or a published rule adopts Rev. 3. Keep meeting 3.3.7 as written in Rev. 2, and if you already choose a value for the parameters above in practice, write it down where your system security plan can find it.

Bedrock CMMC shows this same comparison against your own package, with your current status on the Rev. 2 side, so the day adoption lands the migration is a review, not a rewrite.

Back to the Rev. 2 vs Rev. 3 overview

Where this page's facts come from
Rev. 2 text and objectives
bedrock-cmmc-api@89b8e8e:migrations/004_reference_requirements.sql#Requirement.basicRequirement@rev2; bedrock-cmmc-api@89b8e8e:migrations/005_reference_objectives.sql#AssessmentObjective.description@rev2
Mapping and change class
bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/r2_r3_transition_map.json#r2_to_r3
Rev. 3 03.03.07
bedrock-cmmc-api@89b8e8e:docs/reference/nist-800-171-rev3/normalized/rev3.json#requirements[]