Skip to main content
NetStable
Level 2 IA.L2-3.5.8

Prohibit password reuse for a specified number of generations

📖 What This Means

This control ensures that users cannot reuse their previous passwords for a certain number of password changes. For example, if the policy specifies that users cannot reuse the last 10 passwords, they must create a new password that hasn't been used in the last 10 iterations. This reduces the risk of unauthorized access if an old password is compromised. Think of it like locking a door with a new key every time; even if someone finds an old key, it won't work. This practice is especially important for accounts with access to sensitive defense-related information.

🎯 Why It Matters

Password reuse is a major security risk because attackers often exploit old passwords gained from breaches or phishing attacks. For example, in the 2012 LinkedIn breach, millions of passwords were leaked, and attackers reused them to access other accounts. In a defense contractor context, reused passwords could lead to unauthorized access to classified systems, resulting in data theft, operational disruption, or compliance penalties. The DoD emphasizes this control to ensure that even if a password is compromised, it cannot be reused, thereby protecting sensitive information.

How to Implement

  1. 1. In Azure, navigate to Azure Active Directory > Password Reset > Password Policy. Set 'Enforce password history' to the desired number (e.g., 10).
  2. 2. For AWS, use AWS IAM Password Policies. Enable 'Prevent password reuse' and specify the number of previous passwords to remember.
  3. 3. In GCP, go to IAM & Admin > Settings > Password Policy. Configure 'Password reuse prevention' to the required number.
  4. 4. Ensure MFA is enabled alongside password policies for added security.
  5. 5. Regularly audit compliance using cloud-native tools like Azure Security Center or AWS Config.
⏱️
Estimated Effort
2-4 hours for implementation, 1 hour for testing. Requires intermediate IT skills.

📋 Evidence Examples

Password Policy Document

Format: PDF/Word
Frequency: Annually or when updated.
Contents: Policy stating the number of previous passwords to remember (e.g., 10).
Collection: Export from policy management tool or document manually.

Active Directory Password Policy Screenshot

Format: PNG/JPG
Frequency: Annually or when updated.
Contents: Screenshot showing 'Enforce password history' setting.
Collection: Take screenshot from Group Policy Management Console.

Password Reset Log

Format: CSV/Log File
Frequency: Quarterly.
Contents: Log showing password resets and enforcement of reuse prevention.
Collection: Export from Active Directory or cloud IAM tool.

Test Results

Format: PDF/Word
Frequency: Annually.
Contents: Documentation of testing password reuse prevention.
Collection: Manual testing and recording results.

Training Records

Format: Excel/PDF
Frequency: Annually.
Contents: Records of training users on password policies.
Collection: Export from training management system.

📝 SSP Guidance

Use this guidance when writing the System Security Plan (SSP) narrative for this control.

How to Write the SSP Narrative

For IA.L2-3.5.8 ("Prohibit password reuse for a specified number of generations"), your SSP narrative should specifically describe: (1) the tools and technologies you use to implement this control, (2) the configuration or process that enforces it, (3) who is responsible for maintaining it, and (4) what evidence proves it's working. Describe how users, devices, and processes are identified and authenticated, including your IAM platform, password policies, MFA implementation, certificate management, and service account controls. Be specific -- name your actual products, settings, and responsible personnel.

Example SSP Narratives

Cloud (Azure/AWS)

"IA.L2-3.5.8 is implemented using cloud-native controls. [Organization] uses [specific cloud service/feature] to prohibit password reuse for a specified number of generations. The configuration is managed through [Azure Policy/AWS Config/Terraform] and monitored via [SIEM tool]. Responsible party: [IT Security Manager]. Evidence: [specific artifact, e.g., 'Azure AD Conditional Access policy screenshot, CloudTrail logs']."

On-Premise

"IA.L2-3.5.8 is implemented through on-premise infrastructure controls. [Organization] uses [Active Directory/Group Policy/specific tool] to prohibit password reuse for a specified number of generations. Configuration is documented in [location] and audited [frequency]. Responsible party: [System Administrator]. Evidence: [specific artifact, e.g., 'Group Policy export, Windows Event logs']."

Hybrid

"IA.L2-3.5.8 is implemented across both cloud and on-premise environments. [Organization] uses [Azure AD Connect/hybrid tool] to ensure consistent enforcement. Cloud resources are managed via [cloud tool] and on-premise systems via [on-prem tool]. Both environments report to [centralized SIEM]. Responsible party: [IT Director]. Evidence: [artifacts from both environments]."

System Boundary Considerations

  • Identify all authentication entry points (local login, VPN, cloud, API)
  • Document the identity provider(s) and authentication flow
  • Specify MFA methods and coverage
  • Ensure this control covers all systems within your defined CUI boundary where prohibit password reuse for a specified number of generations applies
  • Document any systems where this control is not applicable and explain why

Key Documentation to Reference in SSP

  • 📄 Identification and Authentication Policy
  • 📄 Password policy configuration
  • 📄 MFA enrollment records
  • 📄 Service account registry
  • 📄 Evidence artifacts specific to IA.L2-3.5.8
  • 📄 POA&M entry if control is not fully implemented

What the Assessor Looks For

The assessor will test authentication mechanisms, verify MFA is enforced for required access paths, check password policy configuration, and review service account documentation.

💬 Self-Assessment Questions

Use these questions to assess your compliance. Each "NO" answer provides specific remediation guidance.

Question 1: Is there a documented password policy that prohibits password reuse?

✅ YES → Proceed to Q2.
❌ NO → GAP: Create and document a password policy. Timeline: 1 week.

Question 2: Is the password reuse prevention setting configured in your authentication system?

✅ YES → Proceed to Q3.
❌ NO → GAP: Configure the setting in Active Directory or cloud IAM. Timeline: 2 days.

Question 3: Have you tested the password reuse prevention mechanism?

✅ YES → Proceed to Q4.
❌ NO → GAP: Conduct testing and document results. Timeline: 3 days.

Question 4: Are all users trained on the password reuse policy?

✅ YES → Proceed to Q5.
❌ NO → GAP: Conduct training and record attendance. Timeline: 1 week.

Question 5: Is the policy enforced for both privileged and non-privileged accounts?

✅ YES → Compliant.
❌ NO → GAP: Apply the policy to all accounts. Timeline: 2 days.

⚠️ Common Mistakes (What Auditors Flag)

1. Not applying the policy to privileged accounts.

Why this happens: Focusing only on regular user accounts.
How to avoid: Ensure the policy applies to all accounts, including admins.

2. Incorrectly configuring the password history count.

Why this happens: Misunderstanding the setting or typo in configuration.
How to avoid: Double-check the configuration and test it.

3. Lack of documentation.

Why this happens: Assuming the configuration is self-evident.
How to avoid: Document the policy and configuration steps.

4. Not testing the mechanism.

Why this happens: Assuming the configuration works without verification.
How to avoid: Regularly test password reuse prevention.

5. Failing to train users.

Why this happens: Overlooking the importance of user awareness.
How to avoid: Include password policies in regular training sessions.

📚 Parent Policy

This practice is governed by the Identification and Authentication Policy

View IA Policy →

📚 Related Controls