Identity Controls for PCI DSS

PCI DSS governs how organizations that handle payment card data protect it, and several of its requirements are squarely about identity. PCI DSS 4.0 raised the bar on authentication in particular. This maps the identity-relevant requirements to practice.

What PCI DSS expects of identity

• Requirement 7: restrict access to cardholder data by business need to know, with role-based access and least privilege.
• Requirement 8: identify and authenticate access. PCI DSS 4.0 expands MFA, requires it for all access into the cardholder data environment (CDE), and tightens password and credential rules.
• Requirement 8.6: application and system accounts (non-human identities) must be managed, with credentials protected and not hardcoded.

What good looks like

• MFA for all access to the CDE, including administrative and remote access, ideally phishing-resistant.
• Role-based access (RBAC) scoped tightly to the CDE, with documented business justification.
• Secrets management for application and service accounts so credentials are vaulted and rotated, never hardcoded.
• Privileged access controls with logging for anyone administering the environment.

Common pitfalls

• Treating MFA as satisfied by a single factor plus a password reset question.
• Shared admin accounts into the CDE with no individual attribution.
• Hardcoded application credentials, a direct 8.6 failure and a real breach risk.

Related

IAM audit preparation. Vendors: MFA, secrets, PAM.

Scoping is where identity programmes get this wrong

Under version 4.0 the MFA requirement extends to all access into the cardholder data environment, not just remote administrative access. That changes scope in ways teams underestimate: every account that can reach the environment counts, including service accounts, vendor support logins, and application identities.

The exercise worth doing first is an inventory of everything that can authenticate into scope, not everything that has 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 answer is not an exemption, it is replacing the static credential with something the platform can attest. See workload identity.

What good looks like

• Unique identification for every user and every non-human account, with no shared credentials in scope.
• Phishing-resistant MFA for administrative and remote access, ahead of the minimum, because relayable factors are defeated routinely.
• Privileged access controls with session recording for administrative work in the environment.
• Quarterly review of accounts with access to the environment, evidenced by revocations.
• Rotation and ownership for every application credential in scope, tested rather than documented.

Retail and e-commerce specifics

For merchants the customer-facing side matters as much as the environment: credential stuffing against consumer accounts and account takeover drive fraud losses that sit outside the compliance boundary but inside the risk. See the retail and e-commerce vertical and identity for retail and e-commerce.

Where to start