Password Complexity Requirements

PCI DSS 4.0.1 requires that if you use passwords or passphrases as an authentication factor (to meet Requirement 8.3.1), they must be at least 12 characters long, or at least eight characters only where the system cannot support 12, and must include both alphabetic and numeric characters (PCI DSS v4.0.1 Requirement 8.3.6). To operationalize this quickly, enforce the rule centrally, document any system limitations, and retain configuration evidence and exception records.

Key takeaways:

• Enforce minimum 12 characters plus letters and numbers anywhere passwords/passphrases satisfy PCI authentication requirements (PCI DSS v4.0.1 Requirement 8.3.6).
• If a system cannot support 12 characters, you need proof of the limitation and enforced minimum eight characters with letters and numbers (PCI DSS v4.0.1 Requirement 8.3.6).
• Auditors will look for technical enforcement, not just a policy statement; keep screenshots, exports, and exception approvals tied to in-scope systems.

“Password complexity requirements requirement” sounds basic until you try to prove it across identity providers, admin consoles, legacy payment apps, third-party hosted platforms, and break-glass accounts. PCI DSS 4.0.1 Requirement 8.3.6 is narrow and testable: if passwords or passphrases are used as an authentication factor to meet PCI’s authentication requirement, they must meet minimum complexity. That means you need two things at the same time: (1) the technical setting that forces the minimum, and (2) evidence that the setting covers every in-scope authentication path (including admin access, service desks, and “temporary” accounts).

This page gives you requirement-level implementation guidance you can execute without turning it into a multi-quarter identity program. The goal is fast, defensible coverage: identify where passwords are used for PCI in-scope access, enforce the rule in the system of record (IdP, directory, application, PAM), handle the “can’t do 12 characters” edge case with documented proof, and package the evidence for your assessor.

Regulatory text

PCI DSS 4.0.1 Requirement 8.3.6 states: “If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity: a minimum length of 12 characters (or if the system does not support 12 characters, a minimum length of eight characters) and contain both numeric and alphabetic characters.” (PCI DSS v4.0.1 Requirement 8.3.6)

Operator interpretation:

• If a password/passphrase is part of how a user authenticates into the PCI scope (the CDE and connected systems in scope for PCI testing), you must enforce:
  • Minimum length: 12 characters, and
  • Character composition: letters + numbers, and
  • Fallback only if technically impossible: minimum length eight characters when the system cannot support 12 (PCI DSS v4.0.1 Requirement 8.3.6).
• This is a technical control requirement, not a “write a policy” requirement. Your policy helps, but enforcement settings and test evidence are what pass assessments.

Plain-English interpretation (what the requirement really means)

If your environment uses passwords anywhere for PCI authentication, every in-scope password must be long enough and not “letters-only” or “numbers-only.” PCI’s baseline here is simple: 12+ characters with letters and numbers. If a platform truly cannot support 12 characters, PCI allows eight as a fallback, but you need to treat that as a constraint to justify, document, and contain.

What this does not say:

• It does not require specific special characters, entropy scoring, banned password lists, or password rotation. (Those controls may exist elsewhere in your program, but don’t claim they are mandated by 8.3.6 unless your assessor maps them.)
• It does not let you “offset” weak length rules with MFA and call it done. If passwords are used to meet Requirement 8.3.1, the password must meet 8.3.6 (PCI DSS v4.0.1 Requirement 8.3.6).

Who it applies to

Entities: Merchants, service providers, and payment processors that must comply with PCI DSS (PCI DSS v4.0.1 Requirement 8.3.6).

Operational context (where you should look):

• Workforce accounts authenticating to CDE systems (directly or through jump hosts/bastions).
• Administrative access paths (OS admin, database admin, network device admin, hypervisor/admin consoles).
• Local accounts on systems where directory/SSO is not used (common audit trap).
• Third-party support access into in-scope systems (remote support portals, managed service accounts).
• Break-glass or emergency accounts used for recovery or incident response.

A fast scoping test: if an account can log into a system that stores, processes, or transmits cardholder data, or can administer the security of that environment, assume it is in scope for this requirement until you prove otherwise.

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

Step 1: Build an “in-scope password surface” inventory

Create a short register (spreadsheet is fine) with these columns:

• System/application name
• Authentication method (SSO/IdP, directory, local, application-native)
• Are passwords/passphrases used for PCI authentication? (yes/no)
• Where the complexity policy is enforced (IdP policy, AD GPO, local PAM, app setting)
• Minimum length supported (12 / less than 12)
• Owner (system + identity/control owner)
• Evidence source (screenshot/export/log)

Outcome: you can point an assessor to a bounded list of systems and controls instead of hand-waving “we enforce it everywhere.”

Step 2: Enforce 12+ characters with letters and numbers at the control point

Pick the highest-level enforcement point you control:

• Centralized IdP/Directory: set the password policy to minimum 12 and require alphanumeric composition.
• Application-native auth: configure the application’s password policy to minimum 12 and require letters and numbers.
• Local accounts: enforce via OS security policy where possible; otherwise manage through PAM or configuration management and document compensating governance.

Practical check: “letters and numbers” means a password like ProjectAtlas2026 qualifies, while aaaaaaaaaaaa and 123456789012 do not.

Step 3: Find and eliminate bypass paths

Assessors often find a compliant SSO policy plus noncompliant local accounts. Search specifically for:

• Local admin accounts on servers and appliances
• Default accounts that can be re-enabled
• Service desk “temporary password” flows
• Vendor-maintained accounts (ask for their password policy evidence or enforce through your access method)

Your goal is binary: either the path is disabled, or it is covered by the same complexity requirement.

Step 4: Handle the “system cannot support 12 characters” exception correctly

PCI allows eight characters only when the system does not support 12 (PCI DSS v4.0.1 Requirement 8.3.6). Treat this as a controlled exception:

• Capture proof of the limitation (vendor documentation excerpt, configuration screen showing max length, or a change ticket showing technical constraint).
• Configure the strongest supported setting (minimum eight with letters and numbers).
• Restrict exposure: limit accounts on that system, enforce MFA where available, isolate network access, and plan for replacement or upgrade.
• Record an exception approval tied to the system owner and a remediation plan.

Do not rely on verbal claims like “the system is old.” Auditors want evidence of the limitation and evidence you set the maximum supported control.

Step 5: Test and document (don’t guess)

For each in-scope system, perform a quick validation:

• Attempt to set a password of length 11 (should fail under a 12-min policy).
• Attempt to set abcdefghijkl (letters only) and 123456789012 (numbers only) (both should fail).
• Capture evidence (screenshots, system policy export, or administrative configuration report).

Step 6: Operationalize ongoing control

Add these items to BAU:

• Joiner/mover/leaver procedures reference the password policy enforcement point.
• Change management requires review of authentication settings for any system in PCI scope.
• Quarterly (or your normal cadence) control check: export password policy settings and revalidate exception systems.

Required evidence and artifacts to retain

Keep evidence that maps cleanly to “policy exists” + “technical enforcement exists” + “exceptions are justified.”

Core artifacts

• Password/Authentication policy statement that specifies minimum 12 characters and alphanumeric requirement for PCI in-scope authentication (PCI DSS v4.0.1 Requirement 8.3.6).
• System configuration evidence:
  • IdP/directory password policy screenshots/exports showing minimum length and composition rules
  • Application password policy configuration screenshots
  • OS/local policy settings where relevant
• Inventory of in-scope systems and where enforcement occurs (from Step 1)

Exception artifacts (only if needed)

• Proof the system cannot support 12 characters
• Approved exception record (owner, scope, compensating restrictions, remediation plan)
• Evidence that minimum eight plus alphanumeric is enforced (PCI DSS v4.0.1 Requirement 8.3.6)

Testing artifacts

• A simple test script or checklist and dated results (tickets, screenshots, or exported settings)
• Change tickets showing when settings were enabled or modified

If you use Daydream to run control management, store the per-system evidence and exception approvals against the control so you can produce an assessor-ready packet without rebuilding it each cycle.

Common exam/audit questions and hangups

Expect questions like:

• “Show me where the 12-character requirement is enforced for all in-scope users.” (They want config evidence, not policy.)
• “Are there any local accounts or appliance accounts that bypass SSO?” (Have your bypass-path analysis ready.)
• “Which systems can’t support 12 characters, and how do you know?” (Bring proof, not a narrative.)
• “How do third parties authenticate for support?” (Prove their access path is subject to the same complexity requirement or is otherwise controlled.)
• “How do you ensure the setting didn’t drift?” (Show periodic exports, configuration management, or monitoring.)

Frequent implementation mistakes and how to avoid them

1. Policy-only compliance.
   Fix: collect screenshots/exports from the actual enforcing system and tie each to an in-scope system list.

2. Assuming SSO covers everything.
   Fix: explicitly inventory and disable or govern local accounts, appliance logins, and break-glass accounts.

3. Uncontrolled “legacy system” exceptions.
   Fix: require proof of max password length, enforce the strongest supported setting, restrict access, and track remediation.

4. Confusing “complexity” with “special characters required.”
   Fix: implement exactly what the requirement says (letters + numbers, length). Add extra rules only if they do not create operational failures, and document them as internal standards.

5. Inconsistent enforcement across environments.
   Fix: if non-production systems can access production data or administrative tooling, treat them as in-scope for authentication controls.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page avoids attributing PCI-related enforcement outcomes.

Risk-wise, weak passwords raise the likelihood of credential stuffing, brute force attempts, and lateral movement after an initial foothold. From an assessment perspective, password complexity failures are easy to test and hard to explain away because the evidence is direct: the system either blocks noncompliant passwords or it does not.

A practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Identify all in-scope systems where passwords/passphrases are used for authentication tied to PCI access.
• Set or confirm the central password policy: minimum 12 characters and must contain letters and numbers (PCI DSS v4.0.1 Requirement 8.3.6).
• Capture “current state” evidence exports/screenshots for the assessor file.
• Open tickets for systems with app-native password stores or local-only authentication.

By 60 days (Close coverage gaps)

• Remediate bypass paths: local accounts, appliance defaults, and unmanaged admin accounts.
• Implement app-level password policies where central policy cannot reach.
• Create exception records for systems that cannot support 12 characters, with proof and enforced minimum eight plus alphanumeric (PCI DSS v4.0.1 Requirement 8.3.6).
• Add the control check to your change management checklist for in-scope systems.

By 90 days (Make it durable)

• Standardize evidence collection: repeatable exports, named owners, and storage location.
• Establish periodic validation (settings export + sampling test) and document results.
• Reduce exception footprint by upgrading/replacing constrained systems or moving them behind stronger authentication front-ends.

Frequently Asked Questions

Does PCI DSS 8.3.6 require special characters or mixed case?

The text provided for this requirement only specifies minimum length and that passwords contain both numeric and alphabetic characters (PCI DSS v4.0.1 Requirement 8.3.6). You can require more internally, but you still must meet the stated minimums.

If we have MFA, can we relax password complexity?

Not for this requirement when passwords/passphrases are used as authentication factors to meet Requirement 8.3.1 (PCI DSS v4.0.1 Requirement 8.3.6). MFA may reduce risk, but it does not remove the stated complexity requirement.

What counts as “system does not support 12 characters”?

Treat it as a technical constraint you can demonstrate, such as a documented maximum length or a configuration limit you can show. Keep proof and enforce the minimum eight-character, alphanumeric rule as the fallback (PCI DSS v4.0.1 Requirement 8.3.6).

Do service accounts have to meet the same password complexity rule?

If a password/passphrase is used as an authentication factor to meet PCI authentication requirements for that account, then it must meet the minimum complexity (PCI DSS v4.0.1 Requirement 8.3.6). Where possible, reduce reliance on static passwords for non-human accounts and tightly control any that remain.

How do we prove compliance to an assessor quickly?

Provide a list of in-scope systems and the enforcement point for each, then attach configuration exports/screenshots showing minimum length and alphanumeric requirements (PCI DSS v4.0.1 Requirement 8.3.6). Include exception records with proof for any eight-character systems.

What if a third party support team authenticates into our environment?

If they authenticate with a password/passphrase as part of the in-scope access path, their authentication must meet this complexity requirement (PCI DSS v4.0.1 Requirement 8.3.6). Put the third party behind your IdP/jump host policy or obtain equivalent configuration evidence for the access method.