Password History

PCI DSS 4.0.1 requires you to prevent password reuse by blocking users from setting a new password/passphrase that matches any of their last four. Implement this as a technical control in every in-scope authentication system (including admin consoles), then prove it works with configuration evidence and change-control records. (PCI DSS v4.0.1 Requirement 8.3.7)

Key takeaways:

• Enforce password history in the system, not “by policy,” and cover all in-scope accounts and authentication stores. (PCI DSS v4.0.1 Requirement 8.3.7)
• Your audit story must include: where it’s enforced, how many previous passwords are remembered (four), and how you validate it stays on. (PCI DSS v4.0.1 Requirement 8.3.7)
• Exceptions and compensating behaviors (like “Password1” → “Password2”) are exam hot spots; address them with configuration plus monitoring.

The password history requirement is a narrow control with outsized audit visibility because assessors can test it quickly and because password reuse is a common operational failure mode. For PCI DSS, the rule is specific: users must be blocked from choosing any of their last four passwords/passphrases. (PCI DSS v4.0.1 Requirement 8.3.7)

For a Compliance Officer, CCO, or GRC lead, the work is less about debating password theory and more about scoping and execution: identifying every in-scope system that authenticates users, confirming each one enforces password history at the right depth, and making the evidence package easy for a QSA (or internal audit) to follow.

The main implementation trap is partial coverage. Teams often configure password history in the corporate directory but forget local accounts, SaaS admin panels, jump boxes, network devices, and application-native user stores that touch the cardholder data environment (CDE) or support it. Your goal is consistent enforcement, documented ownership, and repeatable testing.

Regulatory text

Requirement (excerpt): “Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used.” (PCI DSS v4.0.1 Requirement 8.3.7)

What the operator must do

• Configure each in-scope authentication system so it remembers at least the last four passwords/passphrases per user and rejects any attempt to reuse them. (PCI DSS v4.0.1 Requirement 8.3.7)
• Ensure the control applies to individuals (human users). If you have shared or generic accounts, treat that as a separate access-control problem; don’t let it distract from enforcing history for real users. (PCI DSS v4.0.1 Requirement 8.3.7)

Plain-English interpretation (requirement-level)

If a user changes a password, they must not be able to cycle back to a recent password. The system must stop them. A policy statement (“don’t reuse passwords”) is not enough by itself; you need a technical setting or mechanism that prevents reuse of the last four passwords/passphrases. (PCI DSS v4.0.1 Requirement 8.3.7)

What “same as” means operationally:

• Treat it as exact match prevention against the last four stored password hashes in that credential store.
• Don’t rely on user honesty or manager approvals. Build it into the password change workflow.

Who it applies to

Entities

• Merchants, service providers, and payment processors that must meet PCI DSS. (PCI DSS v4.0.1 Requirement 8.3.7)

Operational context (what systems are in scope)

Apply password history anywhere a user authenticates to systems that are part of, connected to, or could impact the security of the CDE. In practice, that usually includes:

• Central identity systems (directory/IdP) used for workforce authentication into in-scope assets.
• Privileged access paths: bastions/jump hosts, virtualization management, cloud consoles, database admin tools.
• System-local authentication for servers, network gear, and security tools in-scope.
• Application-level user stores for in-scope apps (including administrative user stores).

If you have multiple credential stores, you must enforce password history in each store where passwords are set. A control in your IdP does not automatically cover a separate local account database.

What you actually need to do (step-by-step)

1) Build the inventory of credential stores (scope it like an assessor)

Create a list of every place a human can set or reset a password for in-scope access:

• Directory/IdP (workforce)
• PAM vault / privileged identity tooling (if it issues passwords)
• OS local accounts (Windows local, Linux local)
• Network devices (TACACS+/RADIUS-backed vs local)
• SaaS/admin consoles for in-scope services
• Application-native auth databases

Deliverable: a “Password History Coverage Map” table (see evidence section) showing each system, owner, enforcement method, and test result.

2) Decide where enforcement lives for each system

Use this decision rule:

• If authentication is centralized (IdP/directory is the source of truth): enforce password history there, and confirm downstream systems do not allow local password changes that bypass the central store.
• If authentication is local or app-native: enforce password history in that system’s native password policy or via a control that governs password changes.

Document the rationale per system. Auditors look for gaps more than elegance.

3) Configure the password history depth to “last four”

Set the password history value to four or more everywhere it is supported. If a system caps at fewer than four, treat it as a compliance issue requiring remediation planning (replacement, integration to centralized auth, or another acceptable design that blocks reuse of the last four in that system’s workflow). The requirement is explicit. (PCI DSS v4.0.1 Requirement 8.3.7)

4) Close bypass paths

Common bypasses:

• Helpdesk reset workflows that set a temporary password and then allow the user to set their old password again.
• Local admin accounts that are excluded from domain policy.
• Break-glass accounts with weaker settings “for emergencies.”

Controls to add:

• Ensure resets still respect history (or force a random reset plus a user-chosen password that is checked against history in the same store).
• Restrict who can change password policy settings and log the changes.
• Standardize “break-glass” handling with separate approvals and review, but keep password history enforced unless there is a documented, risk-accepted exception path.

5) Test it like a QSA will test it

For each credential store:

• Pick a test user.
• Change the password multiple times.
• Attempt to set the password back to one of the previous four.
• Capture the rejection message or control evidence.

Keep the test repeatable. Document exact steps so you can rerun it after upgrades.

6) Operationalize: monitoring and change control

You need assurance the setting stays enabled:

• Include password history settings in configuration baselines (for systems that support policy-as-code or baseline configuration).
• Track changes via change tickets for any modification to authentication policy.
• Add periodic control checks (manual or automated) to confirm the history depth remains compliant.

If you use Daydream to manage control evidence, set a recurring task for system owners to attest to password-policy configuration and attach screenshots/exports and test logs each cycle, so you have clean evidence before assessment requests arrive.

Required evidence and artifacts to retain

Keep evidence that proves (a) the setting exists, (b) it is configured to last four, and (c) it applies across in-scope systems.

Recommended artifact set:

1. Password policy standard stating password history must block reuse of the last four (map it to PCI DSS 4.0.1 Req 8.3.7). (PCI DSS v4.0.1 Requirement 8.3.7)
2. Password History Coverage Map (table) with columns:
   • System / platform
   • In-scope role (CDE, connected, security tooling)
   • Auth type (centralized vs local)
   • Control location (where history is enforced)
   • Config value (history = 4+)
   • Evidence link (screenshot/export)
   • Last test date and tester
   • Owner
3. Configuration evidence per system (screenshots, exported policy objects, CLI outputs, or admin settings pages) showing history depth of four or more. (PCI DSS v4.0.1 Requirement 8.3.7)
4. Test evidence: a short test script and a captured result showing rejection of a recently used password (retain per system or per control family, depending on architecture). (PCI DSS v4.0.1 Requirement 8.3.7)
5. Change-control records for password policy changes (tickets, approvals, implementation notes).
6. Exception register (if any) with documented rationale, risk acceptance, and remediation plan.

Common exam/audit questions and hangups

Expect these questions and prepare crisp answers with attached artifacts:

• “Show me where the system blocks reuse of the last four passwords.” Provide config export/screenshot and a test record. (PCI DSS v4.0.1 Requirement 8.3.7)
• “Which systems are in scope for this control?” Present the coverage map and how you determined scope.
• “Do admins and break-glass accounts follow the same rule?” Be ready to show those accounts are governed, or explain a documented exception path.
• “Does the helpdesk reset process allow users to reuse old passwords?” Walk through the reset workflow and show it still enforces history.
• “What happens after an upgrade or directory migration?” Show baseline configuration, post-change validation steps, and change tickets.

Frequent implementation mistakes (and how to avoid them)

1. Only configuring the corporate directory

• Fix: enumerate app-native stores and local accounts; either integrate them to centralized auth or configure history locally.

2. Confusing “minimum password age” with “password history”

• Fix: confirm the history count is set to four and test actual reuse blocking. (PCI DSS v4.0.1 Requirement 8.3.7)

3. Helpdesk resets that re-enable reuse

• Fix: require reset workflows that still check against password history in the same credential store.

4. Privileged accounts excluded “to avoid lockouts”

• Fix: keep history enabled and solve lockout risk through access process and recovery controls, not weaker password policy.

5. No durable evidence

• Fix: store configuration exports and a dated test log per system; tie them to control owners and change management.

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this specific requirement, so treat enforcement primarily as an assessment and contractual risk under PCI programs.

Risk-wise, password history reduces the chance that a password change event is security theater. Without history, users can rotate and revert, which undermines incident response (forced resets), administrative remediation, and general credential hygiene. For PCI DSS assessments, the more credential stores you have, the more likely an assessor finds one misconfigured. Reduce your attack surface by consolidating authentication where feasible and documenting the exceptions you cannot eliminate.

Practical 30/60/90-day execution plan

First 30 days (stabilize and scope)

• Identify all in-scope systems and credential stores; draft the Password History Coverage Map.
• Confirm current password history settings in your primary directory/IdP and privileged access paths.
• Write or update the password policy standard to explicitly require blocking reuse of the last four. (PCI DSS v4.0.1 Requirement 8.3.7)
• Start collecting configuration evidence for the top-risk systems (admin consoles, jump hosts, directory).

By 60 days (close gaps and prove operation)

• Remediate gaps: systems with no history control, history set below four, or bypass paths through resets/local accounts. (PCI DSS v4.0.1 Requirement 8.3.7)
• Implement a standard test procedure and execute it across systems; store results with dates and owners.
• Add change-control hooks: any password policy change requires approval and post-change validation.

By 90 days (make it durable)

• Add periodic checks (manual attestation or automated configuration checks) to ensure history remains at four or more.
• Normalize evidence collection in Daydream (or your GRC system): recurring tasks per system owner, evidence attachments, and an exceptions workflow.
• Run an internal “mini-assessment” by sampling systems and repeating the password reuse test the way an assessor would.

Frequently Asked Questions

Does “password history” mean I must store users’ old passwords in plaintext?

No. Systems typically enforce history by storing password hashes and comparing new submissions against prior hashes. Your obligation is to prevent reuse of the last four, not to store readable passwords. (PCI DSS v4.0.1 Requirement 8.3.7)

If we use SSO, are we automatically compliant everywhere?

Only if SSO is the sole place passwords are set and the downstream systems don’t allow local password changes that bypass SSO. If an app has its own password store for some users, you must enforce history there too. (PCI DSS v4.0.1 Requirement 8.3.7)

What about service accounts or non-human accounts?

The requirement text is written for “Individuals,” so focus enforcement on human users. Still, assessors will scrutinize any shared or unmanaged accounts as a separate access-control risk; manage them under your broader account management controls. (PCI DSS v4.0.1 Requirement 8.3.7)

Our platform supports only “remember last 3 passwords.” What do we do?

Treat it as a compliance gap because the requirement specifies the last four. Your remediation options are to upgrade, reconfigure authentication to a system that supports four, replace the component, or redesign the password change workflow so reuse of the last four is blocked in that credential store. (PCI DSS v4.0.1 Requirement 8.3.7)

How do auditors typically test password history?

They usually review configuration settings and then attempt a password change sequence for a sample account to verify the system rejects reuse of one of the last four. Keep a documented test procedure and repeatable evidence to avoid ad hoc testing during the assessment. (PCI DSS v4.0.1 Requirement 8.3.7)

Do we need to keep evidence for every system every year?

Keep enough evidence to show continuous compliance: current configuration evidence, a recent test result, and change-control records for modifications. If your environment changes often, increase the frequency of evidence refresh to match that change pace.