Initial Password Requirements

“Initial password requirements” sounds simple, but teams fail audits on it because they implement it as a helpdesk habit rather than a system-enforced control. PCI DSS 4.0.1 Requirement 8.3.5 is specific: if you use passwords/passphrases as an authentication factor (under Requirement 8.3.1), initial and reset passwords must be set to a unique value for each user, and users must be forced to change that password immediately after first use (PCI DSS v4.0.1 Requirement 8.3.5).

For a Compliance Officer, CCO, or GRC lead, the operational goal is to eliminate any path where two users can receive the same initial/reset secret, or where a password reset leaves a long-lived known password in place. This requires coordination across IAM/IdP settings, HR-driven onboarding, helpdesk password reset processes, and access to in-scope systems in the cardholder data environment (CDE) or connected systems.

This page gives requirement-level implementation guidance you can hand to IT and then test yourself: what to configure, what evidence to collect, and the audit questions that commonly expose gaps.

Regulatory text

Requirement: “If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows: set to a unique value for first-time use and upon reset, and forced to be changed immediately after the first use.” (PCI DSS v4.0.1 Requirement 8.3.5)

What the operator must do:
You must ensure two things for any in-scope account that uses a password/passphrase as an authentication factor:

1. Uniqueness of initial/reset password: The first-time password (new account) and any reset password must be unique per user. No shared “TempPassword!23” pattern, no department-wide default, no technician favorite.
2. Forced change on first use: The system must require the user to change the password immediately after first login using that initial/reset password. This should be technically enforced, not dependent on instructions.

Plain-English interpretation

If anyone (HR, IT, a third party helpdesk, an app admin) can set or reset a password, then the password they set cannot be reusable across users, and it cannot remain valid beyond the user’s first successful sign-in. The reset flow should create a short-lived bridge to get the user authenticated, then compel a change right away (PCI DSS v4.0.1 Requirement 8.3.5).

Who it applies to (entity and operational context)

Entities: Merchants, service providers, and payment processors that must meet PCI DSS (PCI DSS v4.0.1 Requirement 8.3.5).

Operational scope: Any system in scope for PCI DSS where passwords/passphrases are used as authentication factors (PCI DSS v4.0.1 Requirement 8.3.5). In practice, that usually includes:

• Administrative access to in-scope systems (servers, databases, network devices, security tools).
• Workforce user access to in-scope applications.
• Break-glass/emergency accounts, unless they are truly non-interactive or controlled differently (you still need to evaluate whether passwords are used).

Third parties: If a third party operates your helpdesk, manages your IAM, or administers in-scope systems, their processes are part of your control surface. They must follow the same uniqueness and forced-change rules for any resets they perform.

---

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

1) Inventory where “initial” and “reset” passwords can be created

Build a list of:

• IAM/IdP platforms (for example, enterprise directory, SSO provider) that create accounts.
• Applications with local user stores (where admins can set passwords directly).
• Network/security devices with local logins.
• Privileged access tooling (if it can issue credentials).
• Helpdesk tools and runbooks used for resets.

Deliverable: A scoped “password issuance points” register tied to your PCI in-scope system list.

2) Choose the reset pattern that will pass audit and reduce risk

You typically have two workable patterns:

Pattern A: Force change at next login (preferred where supported)
Admin sets a temporary password that is unique for the user, and sets “User must change password at next logon.” This meets the requirement directly (PCI DSS v4.0.1 Requirement 8.3.5).

Pattern B: One-time password reset link/token (often better, if implemented correctly)
Instead of giving a password, the system sends the user a one-time token or link to set a new password. If the user never receives an initial password and is instead forced to set their own, you can still satisfy the intent: the “first-time use” experience forces a change immediately because the user sets it before access is granted (PCI DSS v4.0.1 Requirement 8.3.5). Validate that your assessor accepts this as meeting the “set and reset” behavior for your environment.

Decision tip: If any in-scope system can only do local passwords (no reset tokens), implement Pattern A there and standardize controls across the fleet.

3) Configure systems to enforce “unique temporary password”

Implementation varies, but the control objective is consistent:

• Prohibit shared default passwords for new accounts.
• Prohibit helpdesk from reusing templates.
• Require a per-user randomly generated temporary value or a per-user reset token.

Practical control options:

• Configure the directory/IdP reset workflow to auto-generate temporary passwords instead of technician-chosen values.
• In apps with local admin-set passwords, document and train admins to use a password generator and to never reuse a prior reset password for that user.
• For systems that support it, prevent admins from setting passwords that match known defaults (policy-based checks).

4) Configure “forced to be changed immediately after first use”

This is the exam-critical part. Auditors want to see the platform enforce it.

• For directory accounts, enable “must change at next login” when creating users and when resetting passwords.
• For applications, enable “require password change on first login” if available.
• For devices, confirm “password change on first login” capability; if absent, implement an alternative that forces user-set credential before any privileged access is granted (for example, a just-in-time workflow through a management plane that requires credential update before enabling access).

Test case you should run:
Create a test user, issue an initial password, sign in, and verify the system forces a password change before granting normal access (PCI DSS v4.0.1 Requirement 8.3.5). Repeat for a reset scenario.

5) Lock down the helpdesk and third-party reset workflow

Most findings come from helpdesk behavior:

• Require identity verification before any reset (your process may be governed by other requirements, but it also protects this one).
• Prohibit sending temporary passwords in insecure channels (email, ticket notes) unless your risk acceptance explicitly allows it and compensating controls exist.
• If a third party performs resets, include this requirement in their runbook and your oversight testing.

Control language for the runbook:
“All initial and reset passwords must be system-generated unique values and must have ‘change at next login’ set. Technicians may not choose or reuse temporary passwords.” (PCI DSS v4.0.1 Requirement 8.3.5)

6) Build an evidence package that maps to the requirement

Auditors will accept strong configuration evidence plus a small set of live tests.

Evidence checklist (retain these artifacts):

• Policy/standard stating initial/reset passwords are unique and forced-change is required (PCI DSS v4.0.1 Requirement 8.3.5).
• System configuration screenshots/exports showing:
  • “Change password at next logon” is enabled for new accounts and on reset, where applicable.
  • Any relevant password reset workflow settings (auto-generated temporary passwords or token-based reset).
• Helpdesk procedure/runbook for onboarding and resets, including third parties.
• Training/acknowledgments for administrators/helpdesk staff who can reset passwords.
• Sample tickets or logs showing resets performed with the required flags/settings (redact secrets).
• Test results: documented walkthrough proving forced-change behavior for initial account and reset account.

If you use Daydream to manage control evidence, store the configuration exports, a quarterly “reset workflow test” record, and a small sample of redacted tickets as your standard evidence bundle for this requirement.

---

Common exam/audit questions and hangups

Expect variations of these:

• “Show me how a new user is created and prove they must change their password on first login.” (PCI DSS v4.0.1 Requirement 8.3.5)
• “Show me a password reset ticket and the system settings used for the reset.” (PCI DSS v4.0.1 Requirement 8.3.5)
• “How do you ensure reset passwords are unique and not reused across users?” (PCI DSS v4.0.1 Requirement 8.3.5)
• “Which systems still have local accounts, and how is this enforced there?” (PCI DSS v4.0.1 Requirement 8.3.5)
• “How do you oversee third parties who perform resets?” (PCI DSS v4.0.1 Requirement 8.3.5)

Hangup: Teams present a policy but can’t demonstrate enforcement in a specific system. Your best defense is a short, repeatable test script plus screenshots/log outputs.

---

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	How to avoid it
Using a shared default initial password for multiple new hires	Violates “unique value for first-time use” (PCI DSS v4.0.1 Requirement 8.3.5)	Require system-generated temp passwords or reset links; forbid templates in runbooks
Resetting passwords without setting “must change at next login”	Leaves a known password valid beyond first use (PCI DSS v4.0.1 Requirement 8.3.5)	Make the “force change” flag mandatory in tooling; spot-check reset tickets
Relying on “we tell users to change it”	Instruction is not enforcement (PCI DSS v4.0.1 Requirement 8.3.5)	Demonstrate UI-enforced password change gate on first login
Local accounts on appliances ignored	Auditors still sample them if in scope (PCI DSS v4.0.1 Requirement 8.3.5)	Inventory local accounts and document the specific enforcement mechanism per platform
Third-party helpdesk resets done “their way”	Your environment, your requirement (PCI DSS v4.0.1 Requirement 8.3.5)	Add contractual/process requirements; test their tickets/logs as oversight evidence

---

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied sources. Practically, this control is examined because shared or long-lived temporary passwords are easy to guess, easy to intercept, and hard to attribute. They also increase the risk that former technicians or anyone with ticket access can reuse a known reset credential. Treat this as a high-signal indicator of IAM maturity during PCI assessments.

---

A practical 30/60/90-day execution plan

First 30 days (stabilize and prove enforcement)

• Identify all in-scope systems where passwords are used for authentication (PCI DSS v4.0.1 Requirement 8.3.5).
• Map every place where accounts are created or passwords are reset.
• For your primary directory/IdP, confirm and document:
  • Unique temporary password generation approach.
  • “Must change at next login” setting on create and reset.
• Run and document one new-user test and one reset test with screenshots/log evidence.

By 60 days (close the long tail)

• Extend the same enforcement to apps with local user stores and to in-scope devices.
• Update helpdesk and admin runbooks; require a standard reset workflow.
• Add a third-party oversight step: obtain their reset procedure and validate it aligns to uniqueness and forced-change.

By 90 days (operationalize and make it auditable)

• Implement routine sampling: periodically pull a small sample of resets and verify the “force change” attribute was set.
• Centralize evidence in a control record (policy + configs + test results + samples). Daydream can act as the control workspace so evidence stays current and tied to the requirement.
• Add a change-management checkpoint: any new in-scope system must document how it meets initial password requirements before go-live.

---

Required evidence and artifacts to retain (quick list)

• Access control policy/standard covering initial/reset password uniqueness and forced-change (PCI DSS v4.0.1 Requirement 8.3.5).
• Configuration evidence for each in-scope identity store and any local-auth system.
• Helpdesk/admin runbooks, including third-party procedures.
• Redacted tickets/logs showing resets performed properly.
• Documented test cases proving forced change after initial and reset login.

Frequently Asked Questions

Does a “password reset link” satisfy initial password requirements?

It can, if the workflow results in the user setting a new secret before they gain normal access and the prior secret is not a reusable shared value (PCI DSS v4.0.1 Requirement 8.3.5). Confirm how your in-scope systems implement the flow and capture evidence of enforcement.

What does “unique value” mean in practice?

It means the initial or reset password cannot be the same value issued to another user (PCI DSS v4.0.1 Requirement 8.3.5). Avoid shared defaults and technician-chosen templates; prefer system-generated temporary secrets or per-user reset tokens.

Do we have to force a change after a helpdesk reset if the user requested it?

Yes. The requirement applies “upon reset” and requires the password be forced to change immediately after first use (PCI DSS v4.0.1 Requirement 8.3.5). Treat every reset as a temporary bridge, not a final credential.

How do we handle service accounts or non-human accounts?

Start by determining whether the account is in scope and whether it uses a password/passphrase as an authentication factor under your implementation of Requirement 8.3.1 (PCI DSS v4.0.1 Requirement 8.3.5). If a non-human account uses passwords, document a controlled reset/rotation mechanism that avoids shared defaults and prevents long-lived known temporary secrets.

What evidence is strongest for auditors?

System configuration exports/screenshots showing the “must change at next login” enforcement, plus a documented test of initial and reset flows (PCI DSS v4.0.1 Requirement 8.3.5). Add a small set of redacted tickets or logs to prove the process runs as designed.

Our application can’t force password change on first login. What now?

Treat it as a design gap and implement a compensating workflow that prevents access until the user sets a new password, then document how it meets the “forced to be changed immediately after the first use” intent (PCI DSS v4.0.1 Requirement 8.3.5). If you can’t enforce it technically, plan remediation or replacement and be ready to explain the risk and interim controls to your assessor.