CMMC NUGGET #11

Access Controls in Action

AC.L2-3.1.5: Employ the principle of least privilege, including for specific security functions and privileged accounts

Every user receives the minimum access necessary to perform their job and nothing beyond that. This was introduced in Nugget #6 in the context of IAM and is worth reinforcing here with specific implementation requirements:

• Privileged accounts are defined, documented, and restricted to the minimum number of individuals operationally required
• Privileged accounts are used only for privileged functions. Administrators maintain separate standard accounts for email, browsing, and general productivity work
• Access is reviewed periodically and adjusted when roles change
• The principle applies to security functions specifically. Access to audit logs, security tools, and monitoring systems must be restricted to those with a documented need

Assessor Reality Check: Assessors will request your privileged account list and verify it against active directory or your identity platform. Undocumented privileged accounts are a direct finding.

AC.L2-3.1.7: Prevent non-privileged users from executing privileged functions and capture execution of such functions in audit logs

This control has two distinct assessment objectives that must both be satisfied:

Objective 1 — Prevention: Technical controls must prevent standard users from executing functions reserved for privileged accounts. This is typically enforced through user account configuration, group policy, and Role Based Access control (RBAC). A policy statement alone does not satisfy this objective.

Objective 2 — Logging: Every execution of a privileged function by an authorized privileged user must be captured in audit logs. Assessors will verify that your logging configuration captures privileged function execution events and that those logs are retained and reviewed.

Assessor Reality Check: Organizations frequently satisfy prevention but fail logging. Confirm that your audit logging configuration specifically captures privileged function execution and that those events appear in your log review process.

AC.L2-3.1.8: Limit unsuccessful logon attempts

Configure systems to lock accounts after a defined number of failed login attempts. Key implementation requirements:

• A specific lockout threshold must be defined in policy. Five attempts is a commonly accepted standard
• The technical configuration must match the documented policy exactly
• Service accounts and automated processes that cannot tolerate lockout must be documented as exceptions with compensating controls defined
• The lockout threshold and duration must be documented in your SSP

AC.L2-3.1.10: Use session lock with pattern-hiding displays after a period of inactivity

After a defined period of inactivity, sessions must lock and the display must show a pattern-hiding screen rather than the last active content. This prevents visual eavesdropping on screen content when a device is left unattended.

Implementation requirements:

• A specific inactivity period must be defined in policy. 15 minutes is a commonly accepted standard for CUI environments
• The lock must engage automatically, not rely on user action
• The pattern-hiding display must obscure all content, not simply dim the screen
• This applies to all endpoints within the CUI environment including workstations, laptops, and any device used to access CUI

AC.L2-3.1.11: Automatically terminate user sessions after a defined condition

Where 3.1.10 locks a session, 3.1.11 terminates it. The two controls work together and both must be implemented. Session termination ends the session entirely after a longer inactivity period, requiring the user to authenticate again from the beginning.

Key distinctions from 3.1.10:

• Lock (3.1.10) preserves the session and requires only credential re-entry to resume. Termination (3.1.11) ends the session entirely
• A common implementation: lock after 15 minutes of inactivity, terminate after 30 minutes
• The termination condition and timeframe must be defined in policy and match the technical configuration
• Termination conditions can include inactivity period, time of day, or other defined triggers

Assessor Reality Check: Organizations frequently implement screen lock but not session termination, treating them as the same control. They are two separate assessment objectives. Confirm your systems are configured to both lock and terminate sessions at the defined thresholds.

AU.L2-3.3.7: Synchronize system clocks with an authoritative time source

System clocks across all devices in your CUI environment must be synchronized with an authoritative time source. This is a foundational requirement for audit integrity because without synchronized timestamps, log correlation, forensic analysis, and incident response are all compromised.

Implementation requirements:

• All systems must be configured to synchronize with a reliable, authoritative time source such as NIST time servers (time.nist.gov) or a GPS-based time source
• Network Time Protocol (NTP) is the standard synchronization mechanism
• The synchronization configuration must be documented and verified
• Time zone consistency must be maintained across all systems in scope or accounted for in log management tooling

Assessor Reality Check: This control is frequently overlooked because it seems purely administrative. Assessors use log timestamps to verify the sequence of events during assessment. Systems with unsynchronized clocks create correlation gaps that undermine your entire audit trail.

IA.L2-3.5.5: Prevent reuse of identifiers for a defined period

When a user account or identifier is retired or deactivated, it must not be reassigned to a new user for a defined period. This prevents a new user from inheriting the access history, permissions, or residual associations of a prior user who held the same identifier.

Implementation requirements:

• A specific identifier reuse prevention period must be defined in policy
• Your identity platform must be configured to enforce this period technically
• Service account identifiers are subject to this requirement as well as user accounts

IA.L2-3.5.6: Disable identifiers after a defined period of inactivity

User accounts that have not been used for a defined period must be automatically disabled. Dormant accounts are a significant insider threat and external attack vector because they can represent valid credentials that may not be actively monitored.

Implementation requirements:

• A specific inactivity threshold must be defined in policy. 30 to 90 days is a commonly accepted range
• The threshold must be enforced technically, not just monitored manually
• Disabled accounts must be reviewed before reactivation to confirm the user still requires access
• Service accounts with no interactive login activity must be evaluated separately as they may appear inactive while still performing automated functions

Assessor Reality Check: Assessors will request a list of accounts and check for accounts that have not logged in within your documented inactivity period. Dormant accounts that have not been disabled are a direct finding.

IA.L2-3.5.7: Enforce minimum password complexity when new passwords are created

This control requires enforcing minimum password complexity requirements at the technical level when passwords are created or changed. Key implementation guidance:

• Password complexity requirements must be defined in policy and enforced technically through system configuration
• Minimum requirements typically include length, character class diversity (uppercase, lowercase, numbers, special characters), and prohibition of common or easily guessed passwords

IA.L2-3.5.8: Prohibit password reuse for a specified number of generations

Users must not be permitted to reuse previously used passwords for a defined number of password changes. This prevents users from cycling through a small set of passwords to avoid the practical effect of the complexity requirement.

Implementation requirements:

• A specific password history count must be defined in policy. A minimum of 24 generations is a commonly cited standard
• The history enforcement must be technical, not reliant on user compliance
• The policy count and technical configuration must match

IA.L2-3.5.9: Allow temporary password use with immediate change requirement

When temporary passwords are issued (for new account setup, password resets, or initial access) users must be required to change the temporary password to a permanent password immediately upon first login. The temporary password must not be usable beyond the initial authentication event.

Implementation requirements:

• Systems must be configured to force a password change on first login when a temporary password has been set
• Temporary passwords must meet the same complexity requirements as permanent passwords or be sufficiently random to resist guessing
• The process for issuing and invalidating temporary passwords must be documented

The controls in this nugget span three families: AC, AU, and IA. A common SSP error is placing AU.L2-3.3.7 under the AC or IA section because it appears alongside access and authentication controls conceptually. It belongs under the Audit and Accountability section of your SSP. Similarly, the IA controls in this nugget belong under Identification and Authentication, not Access Control, even though they support access control objectives.

For each control your SSP must document:

• The specific technical implementation and configuration
• The policy that governs the control including all defined thresholds and periods
• Who is responsible for implementation and ongoing management
• How compliance is verified and how often

For assistance configuring and documenting the access and authentication controls covered in this nugget, contact DTC’s C3PAO team.