Identification and Authentication 3.5.8 (3.5.8)
Prohibit password reuse for a specified number of generations.
Get Full GuidanceWhat Is This CMMC Control?
Organizations must prevent users from reusing their previous passwords for a defined number of password changes. This control ensures that when users change their passwords, they cannot simply rotate back to a recently used password, which would undermine the security benefits of password changes. The password history requirement applies to all user accounts except temporary passwords, which are typically short-lived and used for initial access or password resets.
Control Intent
Prevent users from circumventing password security by cycling through a small set of familiar passwords, thereby reducing the risk of compromised credentials and unauthorized access to CUI.
Who This Control Applies To
- •All user accounts with password-based authentication
- •Interactive user accounts accessing systems containing CUI
- •Service accounts and application accounts using password authentication
- •Privileged and administrative accounts
- •Standard user accounts
- •Remote access accounts
Not Applicable When
- •Temporary passwords issued for initial access or password resets
- •One-time passwords or single-use credentials
- •Systems using only non-password authentication methods (e.g., certificate-based, biometric, hardware tokens)
- •Service accounts that never require password changes
- •Accounts authenticated exclusively through federated identity providers where password management is external
Key Objectives
- 1Enforce password history policies that prevent reuse of recently used passwords
- 2Maintain a record of previous passwords for each user account to enable enforcement
- 3Ensure password changes result in genuinely new credentials rather than rotation of familiar passwords
Sample Self-Assessment Questions (Partial)
Does your organization enforce a password history policy that prevents password reuse?
How many previous passwords does your system remember and prevent from being reused?
Implementation Approaches (High-Level)
Active Directory Group Policy Password History
Enforce password history through Active Directory Group Policy Objects applied to all domain-joined systems and user accounts
Cloud Identity Provider Password History
Configure password history enforcement in cloud-based identity providers such as Azure AD, Okta, Google Workspace, or AWS IAM
Linux/Unix PAM Password History
Enforce password history using Pluggable Authentication Modules (PAM) on Linux and Unix systems
Application-Level Password History
Implement password history enforcement within custom applications or commercial off-the-shelf applications that manage their own authentication
Hybrid Centralized and Per-System Enforcement
Combine centralized identity provider password history with per-system enforcement for systems that cannot integrate with central authentication
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If password history is not currently enforced, create POA&M with milestone to configure password history on all systems within 30-60 days For systems incapable of enforcing password history, document compensating controls or plan for system replacement/upgrade If password history setting is less than 24, create POA&M to increase to 24 passwords remembered For inconsistent password history across systems, create POA&M to standardize settings across all system types If legacy applications cannot enforce password history, document as POA&M with plan to implement compensating controls or migrate to compliant authentication system Include specific milestone dates for configuration changes, testing, and verification Document any systems requiring extended timelines due to technical limitations or business impact Ensure POA&M includes verification testing to confirm password history enforcement is working as intended
Frequently Asked Questions
How many previous passwords should be remembered to satisfy this control?
While the control does not specify an exact number, NIST SP 800-53 recommends 24 password generations, and this is widely accepted in CMMC assessments. Organizations should document their chosen number and ensure it is consistently enforced across all systems. The number should be sufficient to prevent users from quickly cycling back to a preferred password.
Do password history requirements apply to service accounts and application accounts?
Yes, password history requirements apply to all accounts using password-based authentication, including service accounts and application accounts. However, if these accounts use alternative authentication methods (certificates, API keys) or never require password changes due to technical constraints, password history may not be applicable. Any exceptions should be documented with justification.
What are temporary passwords and why are they excluded from password history?
Temporary passwords are short-lived credentials issued for initial account setup, password resets, or emergency access. They are excluded from password history because they are designed to be changed immediately upon first use and are not part of the user's regular password rotation. The system should force users to change temporary passwords on first login to a permanent password that is subject to history requirements.
Can users bypass password history by changing their password multiple times in succession?
This is a common weakness in password history implementations. Organizations should implement controls to prevent rapid password changes, such as minimum password age requirements (control 3.5.9) that prevent users from changing passwords more than once per day. Without minimum password age, users can cycle through the required number of changes and return to their original password.
How is password history enforced for users who authenticate to multiple systems?
For users authenticating through centralized identity providers (Active Directory, Azure AD, Okta), password history is maintained centrally and applies across all connected systems. For users with separate local accounts on multiple systems, password history must be enforced independently on each system. Organizations should minimize local accounts and use centralized authentication where possible to ensure consistent enforcement.
What should we do if a legacy system cannot enforce password history?
If a legacy system cannot technically enforce password history, you should document this limitation and implement compensating controls such as more frequent password changes, stronger password complexity requirements, enhanced monitoring for unauthorized access, or plans to migrate to a compliant system. This limitation should be documented in a POA&M with a remediation plan and timeline.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.