PCI DSS 4.0 and identity controls: what changes for teams?

TL;DR: PCI DSS 4.0 shifts payment security toward continuous validation, stronger authentication, and tighter oversight of vendor and third-party accounts across the cardholder data environment, according to 1Kosmos. For IAM teams, the practical change is that card data protection now depends as much on identity lifecycle and access discipline as on perimeter controls.

NHIMG editorial — based on content published by 1Kosmos: PCI DSS 4.0 identity and authentication requirements

By the numbers:

• PCI DSS 4.0 was released on March 31, 2022, and the previous version remained active until March 31, 2024.
• After a maximum of 10 unsuccessful login attempts, users must be locked out for at least 30 minutes or until they verify their identity through the service desk or other means.

Questions worth separating out

Q: How should organisations apply PCI DSS 4.0 to third-party access?

A: Organisations should treat third-party access as a governed identity population with explicit ownership, expiry, and monitoring.

Q: Why do privileged accounts need stronger controls under PCI DSS 4.0?

A: Privileged accounts can change system state, expand exposure, and bypass ordinary business controls, so PCI DSS 4.0 requires stronger authentication and tighter oversight.

Q: What breaks when access reviews are only periodic in a PCI environment?

A: Periodic reviews miss access that becomes risky between audit cycles, especially for vendors, administrators, and cloud-based accounts.

Practitioner guidance

• Map every identity that can reach cardholder data Build an inventory that includes employees, administrators, vendors, service accounts, and cloud-based access paths into the CDE.
• Tighten privileged access by path and use case Apply stronger authentication controls to remote, non-console, and cloud-based administrative access, then review whether the same controls are enforced consistently across all administrative paths.
• Put third-party accounts on a usage clock Require explicit business need for vendor and third-party accounts, review them continuously, and remove access when the work ends.

What's in the full article

1Kosmos's full article covers the operational detail this post intentionally leaves for the source:

• Specific PCI DSS 4.0 authentication requirements for remote, cloud, and non-console administrative access
• The article’s own explanation of password length, reset, and lockout expectations for cardholder data environments
• How 1Kosmos maps its identity proofing and biometric methods to those compliance requirements
• The vendor’s description of immutable audit logs and distributed-ledger storage choices

👉 Read 1Kosmos’s analysis of PCI DSS 4.0 identity and authentication requirements →

PCI DSS 4.0 and identity controls: what changes for teams?

Explore further

View Full Forum →  |  NHI Foundation Course →