Which PCI DSS requirements cover identity and access management?

Requirement 7 restricts access to cardholder data by business need to know, using role-based access and least privilege. Requirement 8 covers identifying and authenticating users, including MFA and credential rules. Requirement 8.6 addresses application and system accounts, which must be managed with protected credentials that are never hardcoded. Together they define who can reach the cardholder data environment and how.

Does PCI DSS 4.0 require MFA for all access to the cardholder data environment?

Yes, under Requirement 8.4.2, mandatory since 31 March 2025, with narrow exceptions: application or system accounts performing automated functions, and single-card point-of-sale user IDs. Version 4.0.1 added a note that the requirement does not apply to user accounts authenticated only with phishing-resistant factors. Every human who can reach the environment counts, including vendor support logins, and a password plus a security question is not MFA.

What password length does PCI DSS 4.0.1 require?

Requirement 8.3.6 sets a minimum of 12 characters, or eight if the system cannot support 12, with both numeric and alphabetic characters. It became mandatory on 31 March 2025; before that the minimum was seven. Where a password is the only factor, Requirement 8.3.9 also requires changing it at least every 90 days or analyzing account security posture dynamically to decide access in real time.

How often must PCI DSS user access be reviewed?

Requirement 7.2.4 requires all user accounts and their access privileges, including third-party and vendor accounts, to be reviewed at least once every six months, with inappropriate access addressed and management acknowledging the result. Application and system accounts fall under 7.2.5.1, reviewed at a frequency set by your own targeted risk analysis. Keep the revocations as evidence, not just the sign-off.

How should service accounts be handled under PCI DSS?

Inventory everything that can authenticate into scope, not just accounts with a human behind them. Service and application accounts are where the gap usually sits, because they were exempted from MFA on the grounds that they cannot do MFA. Vault and rotate their credentials, assign an owner to each, never hardcode them, and replace static secrets with workload identity the platform can attest.

Are shared admin accounts allowed in a PCI DSS environment?

No. Every user and every non-human account in scope needs unique identification, with no shared credentials. Shared admin accounts into the cardholder data environment break individual attribution, which is a common audit pitfall. Pair unique identities with privileged access controls and session recording for administrative work, so every action in the environment traces back to a single accountable person.

Does PCI DSS cover customer account takeover for merchants?

Mostly not directly. Credential stuffing and account takeover against consumer accounts drive fraud losses that sit outside the compliance boundary of the cardholder data environment but inside the business risk. Retail and e-commerce teams should treat customer login protection as a separate program alongside PCI DSS identity controls rather than assuming the assessment covers it.

Compliance · Intermediate

Identity Controls for PCI DSS

By SWI Community Team · Updated 2026-11-05 · 13 min

PCI DSS identity controls are the requirements in PCI DSS v4.0.1 that decide who and what can reach cardholder data and how they prove it: Requirement 7 (access by business need to know) and Requirement 8 (identify users and authenticate access). Since 31 March 2025 they include MFA for all access into the cardholder data environment (CDE), 12-character passwords, six-monthly user access reviews, and managed credentials for system accounts. This guide is for IAM and security teams at merchants and service providers preparing for an assessment.

Version and dates

The current version is v4.0.1, a limited revision the PCI Security Standards Council published on 11 June 2024. It added no requirements and deleted none, but for identity it added one important note: the MFA requirement for non-administrative CDE access does not apply to accounts authenticated only with phishing-resistant factors, and Appendix G now defines phishing-resistant authentication. Version 4.0 was retired on 31 December 2024. The requirements v4.0 had marked as best practice until 31 March 2025 are now mandatory, and most of the identity ones are in that group.

Requirement map

Requirement text below is summarised from the PCI SSC's v4.0 SAQ D for merchants (v4.0.1 added and deleted no requirements); "2025" marks the items that were best practice until 31 March 2025.

Req.	What it requires	Since	What you build
7.2.4	Review all user accounts and privileges, including third-party and vendor accounts, at least once every six months; address inappropriate access; management acknowledges	2025	Six-monthly access certification in IGA
7.2.5, 7.2.5.1	System and application accounts get least privilege, and their access is reviewed at a frequency set by targeted risk analysis	2025	Owned service account inventory with review dates
8.2.2	Shared or generic accounts only by exception: prevented unless needed, time-limited, justified, approved	Existing	PAM check-out with individual attribution
8.2.6	Remove or disable inactive user accounts within 90 days	Existing	Automated dormancy job, deprovisioning
8.2.7	Third-party remote access accounts enabled only when needed and monitored	Existing	Time-bound vendor access with session recording
8.2.8	Re-authenticate after 15 minutes idle	Existing	Session timeout policy
8.3.4	Lock out after no more than 10 attempts, for at least 30 minutes or until identity is confirmed	Existing	Lockout plus password spraying detection
8.3.6	Passwords at least 12 characters (eight if unsupported), numeric and alphabetic	2025	Directory and app password policy
8.3.9	Single-factor passwords changed every 90 days, or dynamic posture analysis	Existing	Prefer removing single-factor access
8.4.1, 8.4.2	MFA for administrative non-console access, and for all access into the CDE	8.4.2: 2025	Phishing-resistant MFA at the CDE boundary
8.4.3	MFA for all remote network access from outside that could reach the CDE, including third parties	Existing	MFA on VPN, VDI and remote support
8.5.1	MFA not replayable, not bypassable without time-limited approved exception, two factor types, all factors must succeed	2025	Factor configuration review, bypass register
8.6.1-8.6.3	System accounts with interactive login controlled; their passwords not hardcoded; passwords rotated per risk analysis and on compromise	2025	Secrets management, workload identity

Service providers carry one more single-factor password requirement, 8.3.10.1, which FAQ 1591 treats alongside 8.3.9.

Scoping is where identity programmes get this wrong

MFA under 8.4.2 now covers all access into the CDE, not only remote administrators. The PCI SSC's FAQ 1591 clarifies the edges: MFA is not mandatory for in-scope systems outside the CDE, but it is required wherever a user's access to such a system can be used to connect into the CDE, and a password alone is acceptable inside the CDE only after the user has already authenticated into it with MFA.

So the first exercise is an inventory of everything that can authenticate into scope, not everything with a human behind it. Non-human access is where the gap usually is, because those accounts were exempted from MFA on the grounds that they cannot do MFA. The 8.4.2 exemption for automated accounts is real, but 7.2.5 and 8.6 then apply in full: least privilege, owners, review, and no hardcoded secrets.

Failure modes the requirements map to

Remote access without MFA (8.4.3). At Change Healthcare, attackers used compromised credentials on a Citrix remote access portal that did not have MFA, then deployed ransomware nine days later. At Medibank, a contractor's saved credentials opened a VPN that did not require MFA.
Infostealer credentials on cloud data platforms (8.4.2, 8.2.6). In the Snowflake customer campaign, about 165 customer accounts were accessed with infostealer credentials, some dating from 2020, on accounts that lacked MFA. Advance Auto Parts was one of them.
Vendor remote support as the path in (8.2.7). At the US Treasury, a stolen key for BeyondTrust Remote Support SaaS gave remote access to workstations.
Secrets in code and pipelines (8.6.2). See secrets in repositories and CI and the tj-actions/changed-files compromise.

Decision table: what to fix first

Finding	First fix	Tool category
Password-only access somewhere on the path into the CDE	MFA at the boundary, phishing-resistant for admins and vendors	IdP plus MFA
Shared admin or vendor accounts	Unique accounts, vaulted check-out, session recording	PAM
Hardcoded or never-rotated app credentials	Vault and rotate, then short-lived workload credentials	Secrets management
No six-month review evidence	Certification campaign with revocation counts	IGA

For MFA at the CDE boundary, Duo (Cisco), Okta and Microsoft Entra ID are common, with Yubico keys where phishing resistance lets you use the 4.0.1 note. For vaulted admin access, Idira (formerly CyberArk), now part of Palo Alto Networks, and Delinea, which now owns StrongDM, sit alongside BeyondTrust. For application secrets, HashiCorp Vault (IBM), AWS Secrets Manager and Idira Secrets Manager (formerly CyberArk Conjur) handle storage and rotation, and GitGuardian finds what is already hardcoded. For review evidence, see best compliant IGA platforms.

Retail and e-commerce specifics

For merchants the customer-facing side matters as much as the CDE. Credential stuffing against consumer accounts drives account takeover and fraud that sits outside the compliance boundary but inside the risk: at Chick-fil-A, attackers took over 71,473 loyalty accounts, exposing partial card numbers and reward balances. See the retail and e-commerce vertical and identity for retail and e-commerce.

Where to start

Confirm the version. Assess against v4.0.1 and treat the formerly future-dated requirements as mandatory.
Inventory everything that can authenticate into the CDE. Users, service accounts, application identities and vendor logins, each with a named owner.
Close MFA gaps for all CDE access. Administrators and remote access first on phishing-resistant factors, then everyone else who can reach the environment.
Remove shared and hardcoded credentials. Unique identities, vaulted and rotated application secrets, workload identity where the platform supports it.
Run and evidence the first review. Cover every user account and privilege, including third parties, under 7.2.4, and keep the revocations.

PCI DSS glossary entry, IAM audit preparation, phishing-resistant MFA matrix, identity controls for DORA.

Frequently asked questions

Which PCI DSS requirements cover identity and access management?: Requirement 7 restricts access to cardholder data by business need to know, using role-based access and least privilege. Requirement 8 covers identifying and authenticating users, including MFA and credential rules. Requirement 8.6 addresses application and system accounts, which must be managed with protected credentials that are never hardcoded. Together they define who can reach the cardholder data environment and how.
Does PCI DSS 4.0 require MFA for all access to the cardholder data environment?: Yes, under Requirement 8.4.2, mandatory since 31 March 2025, with narrow exceptions: application or system accounts performing automated functions, and single-card point-of-sale user IDs. Version 4.0.1 added a note that the requirement does not apply to user accounts authenticated only with phishing-resistant factors. Every human who can reach the environment counts, including vendor support logins, and a password plus a security question is not MFA.
What password length does PCI DSS 4.0.1 require?: Requirement 8.3.6 sets a minimum of 12 characters, or eight if the system cannot support 12, with both numeric and alphabetic characters. It became mandatory on 31 March 2025; before that the minimum was seven. Where a password is the only factor, Requirement 8.3.9 also requires changing it at least every 90 days or analyzing account security posture dynamically to decide access in real time.
How often must PCI DSS user access be reviewed?: Requirement 7.2.4 requires all user accounts and their access privileges, including third-party and vendor accounts, to be reviewed at least once every six months, with inappropriate access addressed and management acknowledging the result. Application and system accounts fall under 7.2.5.1, reviewed at a frequency set by your own targeted risk analysis. Keep the revocations as evidence, not just the sign-off.
How should service accounts be handled under PCI DSS?: Inventory everything that can authenticate into scope, not just accounts with a human behind them. Service and application accounts are where the gap usually sits, because they were exempted from MFA on the grounds that they cannot do MFA. Vault and rotate their credentials, assign an owner to each, never hardcode them, and replace static secrets with workload identity the platform can attest.
Are shared admin accounts allowed in a PCI DSS environment?: No. Every user and every non-human account in scope needs unique identification, with no shared credentials. Shared admin accounts into the cardholder data environment break individual attribution, which is a common audit pitfall. Pair unique identities with privileged access controls and session recording for administrative work, so every action in the environment traces back to a single accountable person.
Does PCI DSS cover customer account takeover for merchants?: Mostly not directly. Credential stuffing and account takeover against consumer accounts drive fraud losses that sit outside the compliance boundary of the cardholder data environment but inside the business risk. Retail and e-commerce teams should treat customer login protection as a separate program alongside PCI DSS identity controls rather than assuming the assessment covers it.

Last reviewed November 5, 2026By SWI Community TeamSuggest a correction How we research