Skip to content
ControlVerdict
Sign in
IA.L2-3.5.8CMMC Level 2Level 2

Password Reuse

Submit your own example

Practice statement

Prohibit password reuse for a specified number of generations.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.5.8.Source

The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.

Assessment Objectives(2)

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

  1. [a]

    the number of generations during which a password cannot be reused is specified and

    1 example covers this

  2. [b]

    reuse of passwords is prohibited during the specified number of generations.

    1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

Implementation examples(1)

Submit your own example
  • addresses
    IA.L2-3.5.8Password Reuse
    Prohibit password reuse for a specified number of generations.

    • [a]

      the number of generations during which a password cannot be reused is specified and

    • [b]

      reuse of passwords is prohibited during the specified number of generations.

    24 remembered generations, one-day minimum age, and random vault secrets for shared accounts

    ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
    Community is just starting — add yours. No verdicts yet.

    Implementation

    AO coverage. Addresses both Password Reuse objectives: the number of generations is specified, and reuse is prevented across them.

    Specified generations. 24 for domain and IdP accounts, matching the domain policy default we chose to keep, and 24 on the Linux bastions via pam_pwhistory remember=24. The figure is written in the password standard, not just left as whatever the platform shipped.

    Enforcement. Domain policy holds 24 hashes and pairs with a one-day minimum password age so a user cannot walk through history in one session. The bastions apply pwhistory in the system auth stack, which covers both console and SSH password changes. Vaulted shared credentials sidestep history entirely: rotation generates a random 32-character value, so reuse is structurally impossible.

    Maintenance. Quarterly export of the effective policy from a domain-joined host and from each bastion. After OS or package upgrades, re-check that PAM configuration was not reverted by the package manager — this has bitten us once, so it is an explicit line item on the patch checklist.

    Accepted gap. One network appliance stores only three password generations. Because its credential is vault-managed and rotated to a random value, history depth there is not load-bearing; the exception notes that compensating logic.

    What the evidence looks like

    • Password standard specifying 24 generations and the minimum age
    • Effective domain policy export from a member host
    • pam_pwhistory configuration from both bastions
    • Vault rotation policy and a recent rotation log for a shared appliance credential
    • Patch checklist line item covering PAM configuration verification

    Environment

    Small OSC, ~90 accounts. Windows domain plus two Linux bastions with local PAM stacks; a handful of appliance accounts live in a credential vault.

    Tools

Discussion(0)

No discussion on this control yet

Edge cases, scoping questions, and “would this pass?” scenarios belong here.

Sign in to start a thread.