Service Provider Customer Password Changes

PCI DSS requires service providers to address customer accounts that log in with only a password: you must either enforce password/passphrase changes at least once every 90 days, or implement dynamic, real-time security posture analysis that automatically determines access. Your fastest path is to inventory single-factor customer logins, pick one option per system, and collect audit-ready evidence. (PCI DSS v4.0.1 Requirement 8.3.10.1)

Key takeaways:

• Scope is narrow and specific: customer user access where a password is the only factor. (PCI DSS v4.0.1 Requirement 8.3.10.1)
• You have two compliant patterns: scheduled password changes or real-time, risk-based access decisions. (PCI DSS v4.0.1 Requirement 8.3.10.1)
• Evidence matters: exam teams will test configuration, not intent, and will ask for proof at the system level.

“Service provider customer password changes requirement” refers to a PCI DSS service-provider-only control that targets a specific risk pattern: customer-facing access where a password is the only authentication factor. If you still allow customer users to sign in with just a password (no MFA, no client cert, no SSO with strong upstream auth), PCI DSS 4.0.1 pushes you to either rotate that password at least every 90 days, or replace the static rule with dynamic, real-time analysis that decides whether the account can access resources. (PCI DSS v4.0.1 Requirement 8.3.10.1)

Operationally, this requirement tends to trip teams up because it cuts across product, identity, customer support, and compliance. The “customer user” population often lives in a different identity store than workforce users, and password policy controls can be inconsistent across legacy apps, admin consoles, and APIs. Your goal is to make a clean, auditable decision per customer-authenticated system: (1) enforce timed password changes, or (2) implement dynamic posture-based access controls, then prove it works in production with retained artifacts.

This page gives requirement-level steps, evidence expectations, and common audit hangups so you can implement quickly and defend it cleanly.

Regulatory text

PCI DSS 4.0.1 Requirement 8.3.10.1 (service providers only) states: if passwords/passphrases are used as the only authentication factor for customer user access, then either (a) passwords/passphrases are changed at least once every 90 days, or (b) 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.10.1)

Operator meaning (what you must do):

1. Identify every customer access path where a password is the only factor. (PCI DSS v4.0.1 Requirement 8.3.10.1)
2. For each in-scope path, implement one of two compliant approaches:
   • Timed rotation: force password/passphrase changes at least once every 90 days, or
   • Dynamic access decisions: continuously analyze account security posture and make automatic, real-time allow/deny (or step-up) decisions for resource access. (PCI DSS v4.0.1 Requirement 8.3.10.1)
3. Keep evidence that the control is enforced in production and applies to customer users, not only internal workforce accounts.

Plain-English interpretation

If your customers can log in with just a password, you need a compensating control that reduces the risk of long-lived, reused, or stolen credentials. PCI DSS gives you two choices: rotate passwords on a fixed cadence, or implement a system that evaluates account risk in real time and automatically grants or restricts access based on that evaluation. (PCI DSS v4.0.1 Requirement 8.3.10.1)

A practical way to read this requirement:

• It is not a general “all passwords everywhere” rule.
• It is aimed at service providers and customer user access with single-factor passwords. (PCI DSS v4.0.1 Requirement 8.3.10.1)
• It expects technical enforcement, not a policy statement.

Who it applies to (entity and operational context)

Entity scope: Service providers assessed against PCI DSS 4.0.1. (PCI DSS v4.0.1 Requirement 8.3.10.1)

Operational scope (typical in-scope scenarios):

• Customer portal login to manage payment-related services
• Customer user access to dashboards, reports, ticketing portals, or configuration UIs tied to the service provider environment
• Customer-facing admin console where customers manage their own users and roles
• API authentication using a username/password where no additional factor exists (even if used infrequently)

Out-of-scope (for this specific requirement):

• Customer accounts that already use multi-factor authentication, or any access where a password is not the only factor, because the triggering condition is “passwords/passphrases used as the only authentication factor.” (PCI DSS v4.0.1 Requirement 8.3.10.1)

Implementation decision: rotation vs. dynamic posture

Use this operator-focused decision matrix.

Question you must answer	If “yes”	Preferred approach
Can you confidently enforce password rotation in every customer identity store and login path?	You can implement consistently	90-day password change
Do you have an identity/risk engine that can evaluate posture and automatically gate resource access in real time?	You can prove automated decisions	Dynamic posture analysis
Do you support B2B customers who strongly resist periodic password expiration?	You’ll face support churn	Consider dynamic posture analysis, or move to MFA (outside this requirement but reduces scope)
Are there many legacy apps with fragmented auth?	Rotation will be uneven	Prioritize consolidating auth, then choose one approach per system

A common operator move: treat this requirement as a forcing function to eliminate password-only access. That can reduce scope, but the requirement itself still expects one of the two controls wherever password-only access remains. (PCI DSS v4.0.1 Requirement 8.3.10.1)

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

Step 1: Inventory customer authentication paths (system-level)

Create an inventory that is audit-friendly:

• Application/system name and owner
• Customer identity store (IdP, app database, external directory)
• Login methods (UI, API, mobile, SSO)
• Factors used (password only vs. password + something else)
• Whether the system provides access to resources within the PCI DSS scope

Output artifact: “Customer Authentication Path Register” with a clear flag for “password-only customer access.”
Tip: include screenshots or config exports that show the configured factors per app to reduce debate during assessment.

Step 2: Select the compliant control per in-scope system

For each password-only system, record a decision:

• Option A: Password change at least once every 90 days, or
• Option B: Dynamic posture analysis with real-time automated access decisions. (PCI DSS v4.0.1 Requirement 8.3.10.1)

Output artifact: Control selection log tied to the inventory. Include rationale and a technical owner.

Step 3A: Implement 90-day customer password changes (Option A)

Operational requirements you should implement:

1. Configure password expiration to force a change at least once every 90 days. (PCI DSS v4.0.1 Requirement 8.3.10.1)
2. Ensure the rule applies to:
   • All customer users (not just newly created accounts)
   • All auth paths (UI and API tokens derived from passwords if applicable)
3. Define operational handling:
   • Customer notification workflow (pre-expiration and at expiration)
   • Self-service reset process
   • Support escalation for locked-out customers
4. Validate in production:
   • Test account created, password aged past the threshold, login forces change
   • Confirm the same behavior for different customer roles and tenants

Evidence you will need: see “Required evidence and artifacts” below.

Step 3B: Implement dynamic posture analysis (Option B)

PCI DSS allows an alternative: dynamically analyze the security posture of accounts and automatically determine access to resources in real time. (PCI DSS v4.0.1 Requirement 8.3.10.1)

To make this auditable, define:

1. Signals: what “security posture” means in your environment (examples: anomalous login patterns, impossible travel, known compromised credentials, device trust, account behavior). Your exact signals are your design choice, but they must be real-time inputs that drive access decisions.
2. Decisioning: explicit rules or models that result in automated actions tied to resource access (allow, deny, require step-up, restrict to limited functionality).
3. Enforcement points: where the decision is enforced (gateway, IdP, app layer).
4. Logging: event logs that show posture evaluation and resulting access decision for customer users.
5. Tuning governance: how you change rules without breaking access, and how changes are approved.

Audit risk to manage: Assessors often challenge “dynamic analysis” if it is only monitoring or alerting. The requirement expects real-time access to be “automatically determined accordingly,” so prove the control actually gates access. (PCI DSS v4.0.1 Requirement 8.3.10.1)

Step 4: Build the evidence package (don’t wait for the assessor)

Assemble evidence per system, not as a generic policy binder. That is where teams lose time.

If you run third-party risk operations through Daydream, map each customer-authenticated system (and any third party identity components that support it) to a single control decision, then track evidence requests and renewals against that system owner. This keeps the evidence package current and reduces scramble during PCI assessment.

Required evidence and artifacts to retain

Keep artifacts that demonstrate design, implementation, and operation:

Core artifacts (both options):

• Customer authentication inventory with factor analysis and system owner
• Data flow or architecture diagram showing where customer auth is enforced
• Access control policy or standard that states which option is used for password-only customer access (aligned to the PCI DSS requirement text) (PCI DSS v4.0.1 Requirement 8.3.10.1)
• Change records showing the configuration was implemented (tickets, pull requests, change approvals)

Option A (90-day changes) artifacts:

• System configuration screenshots/exports showing password expiration configured to at least once every 90 days (PCI DSS v4.0.1 Requirement 8.3.10.1)
• Test evidence: timestamped test script/output showing forced change behavior
• Customer communications templates (if used) and support runbook for resets/lockouts

Option B (dynamic posture) artifacts:

• Documented posture signals, decision logic, and enforcement points
• Logs showing real-time decisions affecting access to resources for customer accounts
• Evidence of automated deny/step-up/restriction for risky sessions (redacted examples)
• Governance: approvals for rule changes, plus periodic tuning review notes

Common exam/audit questions and hangups

Expect these questions and pre-answer them in your evidence pack:

• “Show me which customer accounts are password-only and how you determined that.”
• “Demonstrate the control in production for a customer user, not a workforce user.”
• “If you chose dynamic analysis, show where access is automatically determined, not just alerted.” (PCI DSS v4.0.1 Requirement 8.3.10.1)
• “Do API logins follow the same rules as the web UI?”
• “How do you ensure the rule applies across all tenants/customers?”

Common hangup: teams present a corporate password policy and assume it covers customer auth. Assessors usually need system configuration evidence.

Frequent implementation mistakes and how to avoid them

1. Mistake: Applying rotation to workforce accounts only.
   Avoid: Keep separate controls and evidence for customer identity stores.

2. Mistake: Missing “side doors” (legacy admin portal, older API endpoint, mobile login).
   Avoid: Inventory by auth path, not by application name alone.

3. Mistake: “Dynamic posture analysis” that only creates alerts.
   Avoid: Prove real-time access gating with logs that show automatic deny/step-up tied to resource access. (PCI DSS v4.0.1 Requirement 8.3.10.1)

4. Mistake: Inconsistent enforcement across tenants or customer roles.
   Avoid: Test multiple role types and at least one customer tenant with custom settings.

5. Mistake: Weak evidence hygiene (no dated screenshots, no config exports, no traceability to change approvals).
   Avoid: Standardize an evidence checklist per system and store it centrally with ownership.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat enforcement expectations as assessment-driven. Practically, the risk is straightforward: password-only customer access is a common credential compromise path, and this control forces either time-bounded passwords or a real-time mechanism to reduce the blast radius of stolen credentials. (PCI DSS v4.0.1 Requirement 8.3.10.1)

Practical execution plan (30/60/90-day)

You still need a plan you can run, but avoid calendar promises you cannot keep. Use phased execution.

First 30 days (Immediate)

• Build the customer authentication inventory and identify password-only paths.
• Assign an owner per in-scope system and pick Option A or Option B per system. (PCI DSS v4.0.1 Requirement 8.3.10.1)
• Draft evidence checklists and start collecting “as-is” configuration exports.

Days 31–60 (Near-term)

• Implement the chosen control on the highest-risk and highest-usage customer access paths first.
• Write the runbooks: customer password reset, lockout handling, posture-rule change process.
• Start producing recurring evidence (config snapshots and sample logs).

Days 61–90 (Stabilize and audit-ready)

• Close gaps: legacy apps, APIs, and tenant-specific exceptions.
• Run an internal “mock assessor” walkthrough: demonstrate one customer account end-to-end per system.
• Finalize the evidence binder per system with traceability from requirement to config to test proof.

Frequently Asked Questions

Does this requirement apply if we already require MFA for customer logins?

The trigger is “passwords/passphrases used as the only authentication factor for customer user access.” If MFA is required, the condition is not met for that login path. (PCI DSS v4.0.1 Requirement 8.3.10.1)

Are service providers required to pick password rotation, or can we always choose dynamic posture analysis?

You can choose either option where passwords are the only factor for customer user access, as long as the chosen approach is implemented and evidenced at the system level. (PCI DSS v4.0.1 Requirement 8.3.10.1)

What counts as “customer user access” in practice?

Any customer-initiated authentication to your systems where the user is part of a customer tenant or customer-managed account set. Document your definition and apply it consistently across portals, admin consoles, and APIs.

Our customer portal is separate from our cardholder data environment. Is it still in scope?

PCI scoping is broader than this single requirement page can decide. For this requirement, start by identifying customer access paths tied to systems in PCI scope and apply the control where the password-only condition exists. (PCI DSS v4.0.1 Requirement 8.3.10.1)

If we force password changes, do we still need dynamic posture analysis?

The requirement is written as an either/or: change passwords at least once every 90 days, or implement dynamic posture analysis with real-time access decisions for those accounts. (PCI DSS v4.0.1 Requirement 8.3.10.1)

What’s the fastest way to get audit-ready evidence?

Create one evidence folder per customer-authenticated system with (1) factor determination proof, (2) the selected option, (3) production configuration exports, and (4) a dated test showing enforcement. Track owners and refresh cycles in Daydream so evidence stays current across teams.