SC-45 asks you to synchronize system clocks within and between systems and system components. It reads like housekeeping. It is also the reason your logs line up during an investigation and your certificates and tokens validate.
800-53 binds US federal systems and contractors. For others it is a reference that auditors use because bad time quietly breaks other controls.
What it means in practice
NIST says time synchronization is essential for many services, including identification and authentication that involve certificates and time of day restrictions in access control. Without it, you can see denial of service, or a failure to reject expired credentials. Time is usually kept in UTC, or local time with a stated offset from UTC. The granularity, meaning how closely clocks agree with a reference, is something you define. Hundreds of milliseconds suits many systems. Tens of milliseconds is stricter.
The guidance also says time service supports other security capabilities. Audit records are the obvious one. If one server is five minutes off, the timeline of an incident across servers is wrong.
Two enhancements cover sources: SC-45(1) Synchronization with Authoritative Time Source, and SC-45(2) Secondary Authoritative Time Source.
Evidence to collect
- A statement of your time standard: UTC everywhere, your chosen granularity, and your reference sources.
- Time service configuration on servers, containers hosts and network devices, such as NTP or chrony settings pointing to named sources.
- Cloud provider time service settings, where you rely on them.
- A report of clock offset across a sample of hosts, with dates.
- Alerts for drift beyond your threshold.
- Documentation of a secondary source.
Common gaps
Appliances and network gear that use their own clocks. Virtual machines that drift after being paused. Containers that inherit time from hosts that are wrong. Different time zones in application logs. A single time source with no backup. No alert on drift, so the first sign is a failed certificate check.
How to implement it
- Choose UTC as the standard and configure every system to log in it.
- Point systems at at least two reliable sources, one primary and one secondary.
- Include network devices, hypervisors and appliances in the inventory of clocks.
- Measure offset on a schedule, and alert when it exceeds your threshold.
- Keep a monthly offset report as evidence.
- During incident response, record any known clock offset in the timeline.
Quick check
Why does time matter for authentication?
Certificates and tokens have validity windows, and time of day restrictions depend on correct time. Bad clocks can accept expired credentials or reject valid ones.
What does SC-45(2) add?
A secondary authoritative time source, so one failure does not leave you without reliable time.
