Password Change Frequency

PCI DSS 4.0.1 requires that if a user account relies on a password/passphrase as the only authentication factor, you must either force a password change at least every 90 days or implement dynamic, real-time account security posture analysis that automatically determines access. Your job is to identify single-factor accounts in scope, pick an approach per system, then prove it through configuration evidence and operational records. (PCI DSS v4.0.1 Requirement 8.3.9)

Key takeaways:

• Requirement 8.3.9 only triggers when passwords are the only authentication factor; MFA users can fall outside this specific requirement. (PCI DSS v4.0.1 Requirement 8.3.9)
• You can comply via traditional 90-day rotations or by dynamic risk-based access decisions, but you must show how the system enforces the choice. (PCI DSS v4.0.1 Requirement 8.3.9)
• Auditors will test reality, not policy, so retain system configuration screenshots/exports plus identity and access logs for the in-scope population.

“Password change frequency requirement” in PCI DSS 4.0.1 is no longer a one-size-fits-all mandate. Requirement 8.3.9 creates a conditional obligation: if passwords/passphrases are the only authentication factor for user access, you need either a recurring password change at least every 90 days or a modern control that evaluates account security posture dynamically and uses that to decide access in real time. (PCI DSS v4.0.1 Requirement 8.3.9)

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalize this is to treat it as a scoping-and-design problem, then a proof problem. First, confirm which accounts and access paths are truly single-factor in your cardholder data environment (CDE) and connected systems. Next, select the compliance approach per platform: rotate passwords on a schedule, or implement risk-based access that can automatically allow, challenge, or block access based on current posture signals. Finally, build an evidence package that stands on its own: written standard, system configurations that enforce it, and logs showing it works for real users.

This page gives requirement-level implementation guidance you can hand to IAM, IT, and Security Operations and then audit against.

Regulatory text

Requirement statement (verbatim): “If passwords/passphrases are used as the only authentication factor for user access, then either passwords/passphrases are changed at least once every 90 days, or the security posture of accounts is dynamically analyzed and real-time access to resources is automatically determined accordingly.” (PCI DSS v4.0.1 Requirement 8.3.9)

Operator interpretation (what the assessor will expect)

• Trigger condition: The user authenticates with only a password/passphrase. If you have MFA for that access path, this specific requirement may not apply to that path, but you still must meet other PCI DSS authentication controls.
• Two compliant options:
  1. Rotate passwords at least every 90 days, enforced by the system; or (PCI DSS v4.0.1 Requirement 8.3.9)
  2. Use dynamic, real-time security posture analysis that automatically determines access to resources (for example, allow vs block vs step-up), enforced by the system. (PCI DSS v4.0.1 Requirement 8.3.9)
• Prove enforcement: A written policy is not enough. You need configuration evidence and operational proof that accounts actually follow the chosen method.

Plain-English requirement

If a user can get into an in-scope system with just a password, you must either (a) make them change it at least every 90 days, or (b) run a real-time “is this account safe right now?” check that automatically decides whether access is allowed. (PCI DSS v4.0.1 Requirement 8.3.9)

Who it applies to (entity and operational context)

In-scope entities

• Merchants
• Service Providers
• Payment Processors

(PCI DSS v4.0.1 Requirement 8.3.9)

In-scope operational contexts (what to look for)

Focus on user access into environments that store, process, or transmit cardholder data, plus connected systems that can affect CDE security. Practically, this includes:

• Interactive user logins (admins and standard users) to servers, databases, network devices, security tools, and applications in scope.
• Break-glass or emergency accounts if they are password-only.
• Third-party support access if they authenticate with password-only into in-scope resources (for example, a third party helpdesk portal or jump host).

Quick scoping test

Create a list of access paths where the user enters only a password/passphrase:

• OS login (console/remote)
• VPN
• VDI / jump host
• SaaS admin portal
• Privileged access tooling
• Network device login

For each path, mark “password-only” vs “MFA present”. Requirement 8.3.9 only attaches to the password-only set. (PCI DSS v4.0.1 Requirement 8.3.9)

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

Step 1: Inventory password-only authentication populations

Deliverable: Password-only access register (system, access method, user groups, owner).

1. Pull users and auth methods from your identity provider (IdP), directory, VPN, and key apps.
2. Identify exceptions: service accounts, shared accounts, break-glass accounts, legacy apps.
3. Confirm MFA coverage for each access path, not just “we have MFA in the company.”

Step 2: Choose a compliance approach per system (decision matrix)

Situation	Recommended approach	Why it works for 8.3.9
Legacy system cannot do risk-based access	Enforce 90-day change	Meets the explicit rotation option. (PCI DSS v4.0.1 Requirement 8.3.9)
Modern IdP front-doors multiple apps	Dynamic posture + real-time access decisions	Centralized enforcement, consistent evidence. (PCI DSS v4.0.1 Requirement 8.3.9)
Admin access is high risk	Prefer MFA (outside this requirement) + reduce password-only	Reduces the population that triggers 8.3.9.
Third party remote support	Enforce MFA, or rotate if password-only remains	Avoids unmanaged password-only access paths.

Note: If you adopt the dynamic option, confirm it is automatic and real-time (not a weekly report reviewed by analysts). (PCI DSS v4.0.1 Requirement 8.3.9)

Step 3A: Implement the 90-day rotation path (where used)

Deliverable: System-enforced password expiration configuration.

1. Set password expiration to at least once every 90 days for the specific in-scope population. (PCI DSS v4.0.1 Requirement 8.3.9)
2. Ensure the system blocks reuse per your broader password controls (do not treat reuse prevention as optional, even if 8.3.9 doesn’t spell it out).
3. Validate the user experience: warning window, reset mechanism, helpdesk workflow, and lockout protections.
4. Create an exception process for accounts that cannot rotate (then treat them as a remediation item, not “accepted risk” by default).

Step 3B: Implement the dynamic posture / real-time access determination path (where used)

Deliverable: Risk-based access policy and technical enforcement proof.

1. Define what “security posture of accounts” means in your environment (examples: compromised credentials signals, anomalous login patterns, impossible travel alerts, device trust, IP reputation, account age, recent password reset).
2. Configure the access engine (commonly in IdP/conditional access) to make automatic decisions: allow, deny, or step-up.
3. Document the decision logic at the rule level: what triggers a block vs a challenge.
4. Turn on logging at the control point (IdP, PAM, VPN, app gateway) so you can demonstrate decisions and outcomes.
5. Test with real scenarios: suspicious IP, new device, risky geo, repeated failed logins. Preserve test evidence.

The assessor will look for “dynamic,” “real-time,” and “automatically determined.” Treat those words as acceptance criteria. (PCI DSS v4.0.1 Requirement 8.3.9)

Step 4: Operationalize (keep it working)

Deliverable: Runbook + periodic control checks.

• Add an access-control drift check: confirm expiration settings or conditional access policies did not change.
• Tie IAM changes into change management: policy edits require approval and evidence capture.
• Review newly onboarded apps and third-party connections for password-only access.

Step 5: Build your evidence package (audit-ready)

Do this as you implement, not at audit time. Store artifacts in a system of record (GRC tool, ticketing system, or a structured evidence repository). Daydream is a practical place to centralize control narratives, attach configuration exports, and map systems/accounts to the chosen 8.3.9 approach so you can answer assessor questions without reconstructing history.

Required evidence and artifacts to retain

Keep evidence aligned to the two compliance paths. Aim for artifacts that show (1) scope, (2) enforcement configuration, (3) operational proof.

Evidence for either path

• Access scope register showing which systems are password-only and in scope for 8.3.9. (PCI DSS v4.0.1 Requirement 8.3.9)
• Control narrative describing which option is used where and why. (PCI DSS v4.0.1 Requirement 8.3.9)
• List of in-scope user groups and account types (admins, standard users, third party, break-glass).

Evidence for 90-day rotation

• System configuration screenshots/exports showing password expiration is set to at least once every 90 days. (PCI DSS v4.0.1 Requirement 8.3.9)
• Samples of user/account records showing last password change and expiration behavior.
• Exception tickets with compensating actions (if any) and time-bound remediation plans.

Evidence for dynamic posture / real-time access

• Conditional access / risk policy configuration exports (rules, conditions, actions).
• Logs showing automated allow/deny/step-up outcomes tied to posture signals.
• Test cases and results demonstrating the control in action (with timestamps).

Common exam/audit questions and hangups

Expect these, and prepare crisp answers with attachments:

1. “Which accounts are password-only?” Provide your register and show how you validated it.
2. “Is MFA enforced everywhere?” Be ready to discuss specific access paths (VPN, admin consoles, jump hosts).
3. “Show me the configuration.” Auditors want system settings, not just policy PDFs.
4. “How do you know it’s real-time and automatic?” For the dynamic option, show logs with decisions at login time. (PCI DSS v4.0.1 Requirement 8.3.9)
5. “What about third-party access?” Show how third party accounts are included in the same enforcement model or how you prevent password-only access.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Policy says 90 days, systems are set differently.
   Fix: Treat configuration exports as the source of truth; reconcile policy to actual settings.

2. Mistake: “We have MFA” assumed, but some access paths bypass it.
   Fix: Test each path (VPN, legacy admin portals, service consoles) and document the results.

3. Mistake: Dynamic posture analysis implemented as a manual review.
   Fix: Ensure the access control makes automated decisions at the time of access. (PCI DSS v4.0.1 Requirement 8.3.9)

4. Mistake: Break-glass accounts excluded because “they’re emergency.”
   Fix: Include them in the register, define how rotation or dynamic control applies, and restrict/monitor use.

5. Mistake: Evidence gathered at audit time.
   Fix: Bake evidence capture into change management tickets and scheduled exports.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this guidance focuses on assessor expectations and control intent. From a risk lens, password-only access is a high-value target because compromised credentials can translate directly into unauthorized access. Requirement 8.3.9 pushes you to either reduce credential exposure through periodic changes or adopt stronger, context-aware access decisions that can react to active threats. (PCI DSS v4.0.1 Requirement 8.3.9)

Practical execution plan (30/60/90)

You asked for speed; the right plan prioritizes scoping, then enforcement, then durable evidence.

First 30 days: Scope and choose the approach

• Build the password-only access register across CDE-connected systems.
• Confirm where MFA is truly enforced vs optional.
• Decide per system: 90-day rotation or dynamic posture-based decisions. (PCI DSS v4.0.1 Requirement 8.3.9)
• Draft the control narrative and get system owners to sign off.

Next 60 days: Implement and test enforcement

• Configure password expiration where rotation is the chosen path. (PCI DSS v4.0.1 Requirement 8.3.9)
• Implement conditional access / risk policies where dynamic is the chosen path, with logging enabled. (PCI DSS v4.0.1 Requirement 8.3.9)
• Run tabletop tests and live tests for both paths; collect evidence as you go.
• Stand up an exception workflow for accounts that cannot meet the standard yet.

By 90 days: Evidence hardening and audit readiness

• Perform a control self-test: sample accounts per system, verify expiration or policy decisions.
• Lock in evidence routines: configuration exports after changes, monthly/quarterly sampling, and retained logs.
• Conduct an internal audit-style walkthrough using the exam questions above.
• Centralize artifacts in a repository (or Daydream) with clear labeling by system and control option.

Frequently Asked Questions

Does PCI DSS always require password changes every 90 days?

No. Requirement 8.3.9 applies when a password/passphrase is the only authentication factor; in that case you must rotate at least every 90 days or implement dynamic, real-time posture analysis that automatically determines access. (PCI DSS v4.0.1 Requirement 8.3.9)

If we use MFA, can we ignore password change frequency?

For access paths where MFA is enforced, this specific 8.3.9 trigger condition may not apply because the password is not the only factor. You still need to meet other PCI DSS authentication and access control requirements.

What counts as “dynamic security posture” and “real-time access determination”?

The standard requires that account posture is dynamically analyzed and access is automatically determined at the time of access. A periodic manual review of alerts is not sufficient for the dynamic option. (PCI DSS v4.0.1 Requirement 8.3.9)

Do service accounts have to rotate every 90 days?

If a service account uses a password as its only authentication factor for access, it falls into the same decision: rotate at least every 90 days or move the access control to a dynamic, real-time decision model. Many teams redesign service authentication to reduce or eliminate password-only patterns. (PCI DSS v4.0.1 Requirement 8.3.9)

How do we handle third party access for support?

Treat third party identities as in-scope users for this requirement when they have password-only access into in-scope systems. Enforce the same rotation or dynamic access decision controls, and retain the same configuration and log evidence. (PCI DSS v4.0.1 Requirement 8.3.9)

What evidence is most persuasive to an assessor?

Configuration exports/screenshots that show enforcement (expiration settings or conditional access rules) plus logs that demonstrate outcomes for real accounts. Pair that with a scoped inventory showing which systems are password-only and which option you applied. (PCI DSS v4.0.1 Requirement 8.3.9)