This is educational guidance, not a compliance determination
This article explains how PCI DSS's published requirements generally apply to password practices. It does not constitute a compliance determination or Qualified Security Assessor (QSA) guidance, and it is not a substitute for consulting your acquiring bank, a QSA, or the PCI Security Standards Council's own published materials. Your organization's specific PCI DSS obligations depend on your merchant level and how you process, store, or transmit cardholder data.
Unlike HIPAA, PCI DSS is specific and prescriptive about authentication requirements — it names concrete parameters rather than leaving them to organizational risk analysis. This article summarizes what PCI DSS requires for passwords in systems that fall within the cardholder data environment (CDE), and how that differs from the NIST-aligned approach recommended elsewhere in this cluster.
In short
PCI DSS Requirement 8 is prescriptive: 12-character minimum (8 with documented compensating controls), unique IDs, mandatory MFA for all CDE and remote access, and a documented risk analysis supporting whatever rotation frequency you choose — "NIST says no rotation" is not sufficient justification on its own for CDE systems. Generate a PCI DSS-preset policy with the Password Policy Generator.
PCI DSS Requirement 8: identification and authentication
Password and authentication requirements sit under PCI DSS Requirement 8, "Identify users and authenticate access to system components," maintained by the PCI Security Standards Council (PCI SSC). Requirement 8 covers unique user IDs, authentication methods, password/passphrase construction, and multi-factor authentication for access into the cardholder data environment.
| Provision | General Requirement |
|---|---|
| Unique IDs | Every user with access to system components in the CDE must have a unique identifier — no shared or generic accounts for individual access |
| Password/passphrase minimum length | At least 12 characters (or 8 characters if the system does not support 12, with compensating controls) containing both numeric and alphabetic characters, or equivalent complexity via a documented alternative |
| Multi-factor authentication | Required for all access into the CDE, and for all remote network access originating from outside the entity's network |
| Password/passphrase change frequency | Passwords must be changed periodically or dynamically based on risk analysis, or immediately upon suspected compromise, per the entity's targeted risk analysis |
| Account lockout | Limit repeated access attempts by locking out the user ID after a defined number of invalid attempts |
| Password history | New passwords/passphrases must differ from previously used values, per the entity's defined policy |
| Vendor default credentials | Default passwords and other security parameters supplied by vendors must be changed before a system is placed into production |
PCI DSS version matters
PCI DSS is periodically revised — version 4.0 introduced changes to how some of these requirements can be met, including allowing certain parameters (like exact rotation frequency) to be set via a documented targeted risk analysis rather than a single fixed number for every organization. Always confirm which PCI DSS version and requirement numbering applies to your current assessment, since specific sub-requirement details and effective dates shift between versions.
Where PCI DSS and NIST-style guidance align — and where they differ
PCI DSS's minimum length requirement (12 characters, or 8 with compensating controls) is consistent with the length-first approach in NIST Password Guidelines — both frameworks treat length as the primary strength driver. Multi-factor authentication is mandatory under both a NIST-aligned approach and PCI DSS for CDE access, so that control requires no reconciliation.
The clearest difference is rotation: PCI DSS's current framing allows rotation frequency to be set based on a documented risk analysis rather than mandating a fixed calendar interval for every entity — meaningfully closer to NIST's position than older PCI DSS versions were, but it is not simply "no rotation required" the way NIST's general guidance is often summarized. An organization in PCI DSS scope should not assume that removing calendar-based rotation across the board, based solely on general NIST guidance, satisfies Requirement 8 without a specific, documented risk analysis supporting that choice for the systems in scope.
Do not apply general NIST guidance to CDE systems without verification
For systems within the cardholder data environment specifically, PCI DSS Requirement 8's specific provisions govern — general password guidance elsewhere in this cluster (including the NIST-aligned recommendations) should be treated as background context, not as a substitute for confirming the specific PCI DSS requirement text and your QSA's guidance for systems actually in PCI scope.
Practical implementation for CDE systems
- Enforce unique user IDs for every individual with access to CDE system components — no shared administrative or service logins used for individual human access.
- Set minimum password/passphrase length to at least 12 characters on CDE systems, using compensating controls and documentation if any legacy system cannot support that length.
- Enforce MFA for all CDE access, including all remote access originating from outside the network — this applies more broadly than just interactive login for privileged users.
- Document a targeted risk analysis supporting your chosen password change frequency, rather than defaulting to either "no rotation" or an arbitrary fixed interval without documented reasoning.
- Change all vendor-default credentials before production deployment — a frequently cited finding in PCI assessments, particularly for network devices, point-of-sale systems, and third-party applications.
- Enforce account lockout after a defined number of failed attempts, and maintain password history to prevent immediate reuse of a recently retired password.
- Segment the cardholder data environment clearly so that Requirement 8's stricter provisions are scoped to the systems that actually need them, rather than applied inconsistently across the whole network — proper scoping is itself a foundational PCI DSS practice that affects how every other requirement, including Requirement 8, gets applied.
Common mistakes
- Applying general "NIST says no rotation" guidance directly to CDE systems without the specific documented risk analysis PCI DSS expects to support that choice.
- Leaving vendor default credentials unchanged on network devices or point-of-sale terminals, a persistent and heavily cited finding in payment-card breach investigations.
- Shared administrative logins on CDE systems for operational convenience, undermining both the unique-ID requirement and audit trail integrity.
- Unclear CDE scoping, leading to inconsistent application of Requirement 8's provisions and unnecessary compliance burden on systems that could have been properly segmented out of scope.
FAQ
Does PCI DSS require passwords to be changed every 90 days? Under current PCI DSS versions, change frequency can be set based on a documented targeted risk analysis rather than a fixed universal interval — but this requires the documented analysis to be in place; it is not automatically "no rotation required" without that documentation.
Is 8-character minimum length ever acceptable under PCI DSS? Only where a system genuinely cannot support 12 characters and compensating controls are documented — 12 characters is the standard expectation, with the 8-character allowance intended as a documented exception, not a default choice.
Does MFA satisfy PCI DSS Requirement 8 by itself, without other password controls? No — MFA is one specific, mandatory sub-requirement for CDE and remote access; it does not replace the other Requirement 8 provisions covering unique IDs, password construction, lockout, and history.
Who should confirm our specific PCI DSS scope and requirements? Your acquiring bank and a Qualified Security Assessor (QSA) are the authoritative sources for your organization's specific PCI DSS scope and assessment requirements. This article is educational background, not a scoping or compliance determination — see Compliance Governance for how IT KORR supports this process operationally.
Related reading
- NIST Password Guidelines
- HIPAA Password Guidance
- Building a Password Policy Template
- Password Manager Guide — secure storage and sharing for CDE administrative credentials
- PCI DSS 4.0 Overview — the full requirement set this password guidance supports
- Password Policy Generator — generate a PCI DSS-preset policy document
- Download: Password Compliance Checklist