Service Provider Customer Password Guidance

PCI DSS v4.0.1 Requirement 8.3.10 requires service providers to give customer users clear password-change guidance when a password/passphrase is the only factor used for customer access to cardholder data. You must publish and deliver instructions that cover periodic password changes and specific events that require an immediate change, then keep evidence that customers received the guidance. (PCI DSS v4.0.1 Requirement 8.3.10)

Key takeaways:

• This is a service-provider-only requirement triggered by password-only customer access to cardholder data. (PCI DSS v4.0.1 Requirement 8.3.10)
• You need customer-facing guidance, not just an internal policy, and it must address both periodic changes and event-based changes. (PCI DSS v4.0.1 Requirement 8.3.10)
• Auditors will look for distribution, acknowledgment, versioning, and applicability logic (who gets what guidance and why).

“Service provider customer password guidance” sounds lightweight, but it is a recurring audit tripwire because teams treat it as an internal standard rather than a customer-delivered control. PCI DSS v4.0.1 Requirement 8.3.10 is narrow and conditional: it applies only if customer users access cardholder data and a password/passphrase is the only authentication factor. When it applies, you must provide guidance to those customer users that (1) tells them to change passwords periodically and (2) tells them when and under what circumstances passwords must be changed. (PCI DSS v4.0.1 Requirement 8.3.10)

Operationally, this requirement sits between identity governance and customer communications. The work is less about password complexity rules (covered elsewhere in PCI DSS Requirement 8) and more about making sure your customers receive actionable instructions, through the right channels, tied to the right product surfaces, and maintained as your authentication model evolves.

This page gives you requirement-level implementation guidance: how to determine applicability, what to publish, how to distribute it, what evidence to retain, and how to avoid common assessment failures.

Regulatory text

PCI DSS v4.0.1 Requirement 8.3.10 (service providers only): “If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data, then guidance is provided to customer users including guidance for customers to change their user passwords/passphrases periodically and guidance as to when and under what circumstances passwords/passphrases are to be changed.” (PCI DSS v4.0.1 Requirement 8.3.10)

Operator meaning: you must deliver customer-facing password-change guidance whenever your customers can reach cardholder data using only a password/passphrase. Your guidance must cover (a) periodic password changes and (b) event-driven changes (for example, suspected compromise). (PCI DSS v4.0.1 Requirement 8.3.10)

Plain-English interpretation

If your service lets customer users log in with only a password and then view, process, administer, or otherwise access cardholder data, you must tell those users:

1. How often they should change their password/passphrase (periodic guidance), and
2. Exactly which events require an immediate password change (circumstance-based guidance). (PCI DSS v4.0.1 Requirement 8.3.10)

This is not satisfied by having a general “Security Tips” webpage that mentions passwords. The guidance needs to be clearly applicable to your environment and delivered to the relevant customer users.

Who it applies to (entity and operational context)

Applies to

• Service providers assessed against PCI DSS v4.0.1. (PCI DSS v4.0.1 Requirement 8.3.10)

Applies when all of the following are true

• Customer users (your customers’ employees, admins, operators, support staff, or other customer-designated users) authenticate to your environment, and
• Their authentication uses passwords/passphrases as the only factor, and
• That access reaches cardholder data (directly or through functions that expose it). (PCI DSS v4.0.1 Requirement 8.3.10)

Common scoping examples

• A customer portal where users can view cardholder data and sign in with username/password only.
• A support or admin console provided to customers that includes cardholder data and is password-only.
• API or file-transfer access where the “customer user” authentication is a shared password/passphrase and no second factor exists.

Non-applicability notes (document these)

• If customer access to cardholder data requires multi-factor authentication, this specific requirement may not trigger because passwords are not the only factor. Your assessor will still expect you to show how you reached that conclusion. (PCI DSS v4.0.1 Requirement 8.3.10)

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

1) Make an applicability decision you can defend

Create a short scoping memo that answers:

• Which customer-facing systems allow access to cardholder data?
• For each system, is customer authentication password-only?
• If not applicable, what control prevents password-only access (for example, MFA enforced for all customer users)? (PCI DSS v4.0.1 Requirement 8.3.10)

Practical tip: auditors dislike “N/A” with no logic. Tie the decision to system diagrams, authentication configurations, or SSO/MFA enforcement screenshots.

2) Draft customer password-change guidance that meets the two required topics

Your customer-facing guidance must include both:

• Periodic password-change guidance (what you recommend/require and how to do it), and
• Circumstance-based guidance (what events require a change, and what steps customers should take). (PCI DSS v4.0.1 Requirement 8.3.10)

A usable structure:

• Where to change a password (UI path, self-service reset link, or admin-driven workflow)
• Periodic change expectation (state the cadence you instruct customers to follow, and whether it is required vs recommended)
• Change immediately if… list (suspected compromise, phishing, credential reuse concern, unauthorized access signs, shared account exposure, employee offboarding with shared credentials, etc.)
• What to do if compromise is suspected (reset steps, revoke sessions/tokens if applicable, contact support, review access logs)
• Admin responsibilities (if customer admins manage other users, include how they enforce resets)

Keep it customer-ready: short, procedural, and written for the person clicking the buttons.

3) Decide how the guidance is delivered (and ensure it reaches the right people)

Pick at least one controlled distribution path:

• In-product banner or help panel in the login/account area
• Customer admin guide in your documentation portal
• Onboarding/security configuration checklist sent to customer admins
• Contractual exhibit or security addendum with an operational handoff process

Whatever you choose, make it provable. A PDF in a sales folder is weak evidence if you cannot show customers actually received it.

4) Implement a maintenance and versioning process

Treat the guidance like a controlled document:

• Owner (often Security/GRC with Product/Support input)
• Review trigger events (authentication changes, incident learnings, product UI changes)
• Version history and publication date
• Retirement process for outdated screenshots or flows

5) Align customer guidance with your actual platform behavior

Your guidance must match reality:

• If customers cannot change passwords themselves and must file a ticket, say that.
• If you offer SSO/MFA but do not enforce it, don’t imply it is enforced.
• If you do enforce periodic changes in the platform, the guidance should reflect the platform prompt.

6) Train customer-facing teams to reinforce the guidance

Support, Customer Success, and Implementation teams should know:

• Where the guidance lives
• When to point customers to it (new tenant setup, adding admins, suspected compromise)
• Escalation path for account compromise claims

Required evidence and artifacts to retain

Assessors typically want to see both the guidance and proof it was provided.

Maintain:

• Customer-facing guidance document/page (current version) showing both periodic and circumstance-based instructions (PCI DSS v4.0.1 Requirement 8.3.10)
• Version history or change log (what changed and when)
• Distribution evidence, such as:
  • Documentation portal publication record
  • In-product release note or feature flag showing help content availability
  • Onboarding email template and sample sends
  • Customer acknowledgment workflow output (if you require customers to acknowledge)
• Scoping memo showing which customer access paths are password-only and reach cardholder data (PCI DSS v4.0.1 Requirement 8.3.10)
• Support runbooks for password reset and suspected compromise handling (to show operational readiness)

Common exam/audit questions and hangups

“Show me the guidance customers receive.”
Have the exact URL/PDF, plus screenshots capturing the required sections.

“How do you know it was provided to customers?”
Be ready with onboarding workflow evidence, in-product availability proof, or acknowledgment records.

“Which customers/users does this apply to?”
Auditors will press you on scope. Provide a list of portals/roles that can reach cardholder data and how they authenticate. (PCI DSS v4.0.1 Requirement 8.3.10)

“Your guidance says to change passwords periodically. What does ‘periodically’ mean here?”
PCI DSS requires that you provide periodic-change guidance; it does not supply your exact cadence in this excerpt. Make your instruction explicit and defensible, and ensure it matches your contractual and technical reality. (PCI DSS v4.0.1 Requirement 8.3.10)

Frequent implementation mistakes and how to avoid them

1. Publishing internal policy language to customers
   Customers need steps and triggers, not internal control statements. Rewrite into “If X happens, do Y.”

2. No distribution proof
   A doc that exists is not the same as guidance that was provided. Build a distribution mechanism you can evidence.

3. Guidance doesn’t match product UI
   Outdated screenshots and wrong menu paths cause audit friction and support tickets. Tie doc updates to product release management.

4. Forgetting “circumstances”
   Teams often cover periodic changes and miss event-driven resets. Include a clear “Change immediately if…” section. (PCI DSS v4.0.1 Requirement 8.3.10)

5. N/A without analysis
   If MFA is enforced and password-only access does not exist, document it with configuration evidence and keep it current.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat this as an audit and contractual compliance driver rather than a case-law-driven one.

Risk-wise, password-only customer access to cardholder data concentrates exposure in credential compromise scenarios. This requirement pushes you to reduce that risk through customer behavior guidance, but guidance will not compensate for weak authentication design. If you can enforce MFA for customer access to cardholder data, that often simplifies the 8.3.10 applicability question and reduces operational risk. (PCI DSS v4.0.1 Requirement 8.3.10)

Practical execution plan (30/60/90)

First 30 days (Immediate)

• Confirm scope: list customer access paths to cardholder data and identify any password-only authentication. (PCI DSS v4.0.1 Requirement 8.3.10)
• Draft guidance content with the two required elements (periodic and circumstance-based). (PCI DSS v4.0.1 Requirement 8.3.10)
• Pick your distribution channel(s) and define what evidence you can capture.

By 60 days (Near-term)

• Publish guidance to the chosen channel(s) with version control.
• Update onboarding materials and support macros to point to the guidance.
• Implement a lightweight acknowledgment or “evidenceable delivery” mechanism where feasible (for example, onboarding ticket checklist item recorded in your system).

By 90 days (Operationalize)

• Run a spot check: confirm new customers received the guidance and that the link/content is reachable without internal access.
• Add doc maintenance to your change-management checklist for authentication/login changes.
• Prepare an audit packet: scoping memo, guidance, distribution evidence, and samples.

Where Daydream fits: Daydream can track this requirement as a discrete control objective, attach the guidance, map it to customer-facing distribution evidence, and keep an audit-ready record of version history and reviews without chasing documents across teams.

Frequently Asked Questions

Does this apply if customers use SSO?

It depends on whether passwords/passphrases are the only authentication factor for customer user access to cardholder data. If SSO with MFA is enforced, document that configuration and your conclusion that password-only access does not exist. (PCI DSS v4.0.1 Requirement 8.3.10)

Is an internal password policy enough?

No. The requirement calls for guidance “provided to customer users,” so you need customer-facing content and proof of delivery or availability to those users. (PCI DSS v4.0.1 Requirement 8.3.10)

What counts as “periodically” for password changes?

PCI DSS v4.0.1 Requirement 8.3.10 requires that you provide periodic-change guidance, but the excerpt does not specify an exact interval. Choose a clear cadence aligned to your risk posture and customer operating model, and make sure your platform and contracts do not contradict it. (PCI DSS v4.0.1 Requirement 8.3.10)

Our product can’t force customers to change passwords. Are we non-compliant?

You can still comply with 8.3.10 by providing guidance that instructs periodic changes and defines when changes are required. If you cannot enforce the behavior, focus on clear instructions, strong delivery evidence, and consider roadmap options like MFA enforcement. (PCI DSS v4.0.1 Requirement 8.3.10)

Do we need customer acknowledgment that they read the guidance?

The text requires guidance be provided; it does not explicitly require acknowledgment in the excerpt. In practice, acknowledgment or onboarding checklists strengthen your evidence that guidance reached customer users. (PCI DSS v4.0.1 Requirement 8.3.10)

If we enforce MFA for all customer access to cardholder data, can we ignore this requirement?

If passwords are not the only factor, the condition may not be met, but you still need a documented scoping decision supported by configuration evidence. Keep it current as authentication flows change. (PCI DSS v4.0.1 Requirement 8.3.10)