1Overview
IA.L2-3.5.8 stops users from cycling back to old passwords. It requires that the organization prohibit password reuse for a specified number of generations, so that a password retired for security reasons is not simply set again a change or two later. It is a one-point requirement and may be deferred on a plan of action.
Password changes lose their value if users can rotate straight back to a favorite old password, since a password that was compromised or is simply weak returns to service. This control asks the organization to specify how many generations of past passwords are remembered and blocked from reuse, and to prohibit reuse within that history, so a retired password stays retired for a meaningful span of changes. It works with password complexity and change-of-character rules to keep passwords genuinely fresh.
Prohibit password reuse for a specified number of generations.
The requirement has two parts: specify the number of generations and prohibit reuse within them. The number of generations is the password history the system remembers, and reuse of any password within that history is blocked. This is enforced through directory password history settings, which keep users from returning to a recent password until enough generations have passed.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.5.8 into two objectives: specify the generations and prohibit reuse within them.
The number of generations during which a password cannot be reused is specified. The organization has set the password history length.
Reuse of passwords is prohibited during the specified number of generations. Users cannot return to a password within the history.
The two objectives are the specification and the prohibition. The common gap is at objective [b], where a history length is specified but not enforced, so reuse remains possible. The assessor looks for enforced password history.
3Failure Patterns
The failures are about unenforced or unspecified password history.
No password history enforced
Where the system does not remember past passwords, users can rotate straight back to an old one, defeating the point of a change. Enforcing password history blocks this.
History too short to matter
A history of only one or two generations lets users cycle through a small set of passwords. A generation count long enough to prevent easy cycling is what the control intends.
Inconsistent enforcement
Where some systems enforce history and others do not, passwords on the unenforced systems can be reused freely. Enforcement has to reach the in-scope systems.
4Ownership
This is an IT-owned technical control, delivered through directory password history.
| Role | Responsibility for this control |
|---|---|
| IT and system administrator | Specifies and enforces password history across systems. Owns the technical evidence. |
| Security or compliance lead | Confirms a meaningful generation count is specified and enforced. |
| Program lead | Reviews password policy coverage and retains the evidence. |
5Tooling
The control is delivered by directory password history settings.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | Specified password history length | The number of generations blocked from reuse. |
| [b] | Directory password history enforcement | Prohibition of reuse within the specified generations. |
The caveat is that the history must be both specified meaningfully and enforced across systems. A history length set but not enforced, or enforced only on some systems, leaves reuse possible where the enforcement does not reach. The assessor examines the enforced history, so it has to be present on the in-scope systems.
6Evidence
The satisfied version of 3.5.8 shows specified and enforced password history.
| Evidence | What it demonstrates |
|---|---|
| Password history setting | Objective [a]. The specified generation count. |
| Enforcement configuration | Objective [b]. Reuse prohibited within the history. |
The evidence should show a specified password history enforced across systems. The password history configuration is the clearest demonstration of the control.
A retired password should not come straight back
Password changes lose their value when users can rotate back to an old favorite, and this control asks for a specified history that blocks reuse. Setting and enforcing password history across systems is part of the onsite readiness work this practice does.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.5.8. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.5.8[a] and 3.5.8[b]. csrc.nist.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, governing which requirements may remain open at a Level 2 assessment. ecfr.gov