PCI DSS · Identity Lens

PCI DSS

PCI DSS v4.0 raised the identity bar materially — phishing-resistant MFA, scripted user management, and continuous validation are no longer aspirational.

Back to Thinking

Full name: PCI Data Security Standard v4.0 / v4.0.1
Region: International (mandated by payment-card brands)
Applies to: Any entity that stores, processes, or transmits cardholder data, plus the service providers that support them. The standard scales with merchant volume but applies to all in-scope environments.

PCI DSS v4.0 (with the v4.0.1 errata effective from March 2025) is the current Payment Card Industry Data Security Standard. The v4.0 revision significantly strengthened identity requirements — particularly around multi-factor authentication, automated user management, and credential strength — and moved several controls from best-practice into mandatory after the 31 March 2025 transition date.

What it asks for

The Identity Lens

The clauses that bite when identity architecture is weak, rewritten in plain English. Authoritative text is linked below.

Requirement 7 — Restrict access by business need to know

Access to cardholder data and the supporting systems must be assigned based on role, with documented approval, and reviewed at least every six months. Privileged access requires explicit assignment and review.

Requirement 8 — Identify users and authenticate access

Unique IDs, strong authentication, MFA for all non-console access into the CDE (and from March 2025, MFA also for all access from outside the entity's network into any system in the CDE). Authenticators must meet defined strength criteria.

Requirement 8.6 — System and application accounts

v4.0 added explicit requirements for service-account credentials: rotation, interactive-use prohibition, and strict password requirements. This is where most v4.0 deficiencies surface.

Requirement 10 — Log and monitor all access

Audit logs for individual access to cardholder data and all administrative actions. Daily log review (or automated review with documented exceptions) is required.

Where teams miss it

Common Misses

Patterns we see again and again — usually because the identity programme runs in parallel to the compliance programme rather than inside it.

MFA implemented for human users into the CDE, while application service accounts continue to use static passwords stored in configuration files.

Role definitions that grant access to entire database schemas where row-level or column-level scoping would meet the business need without expanding scope.

Six-monthly access reviews completed in spreadsheets exported from the system, with no closed-loop evidence that revocations actually executed.

Service-provider responsibility matrix that assumes the cloud provider handles 'identity' generically, without naming which sub-controls each party owns.

What works

Where Design Pays Off

Patterns we have seen survive supervisory review, audit, and the next change.

PCI scope reduction through identity tokenisation — using identity attributes to limit which users and systems can request cardholder-data access, so the actual CDE shrinks.

Phishing-resistant MFA (FIDO2, mTLS) for human admin access and short-lived workload identity for application access — both eliminate the static credential the standard now treats as risky.

Quarterly internal validation of v4.0 identity requirements, ahead of the annual external assessment, so the AOC is never reconstructed under deadline pressure.

Authoritative sources

Read the source

Every claim above is checkable. Start here.

PCI Security Standards Council

PCI DSS v4.0.1 (current standard)

PCI Security Standards Council

PCI DSS v4.0 transition timeline and FAQs

Related Services

Need a PCI DSS-ready identity baseline?

We start with an assessment that maps your identity controls to PCI DSS requirements, then design and operate the gaps.

Book a Conversation