PCI DSS 4.0 and CIAM: Identity Requirements for Payment Workloads

Key takeaways

• PCI DSS 4.0 made MFA mandatory for all access into the cardholder data environment (CDE), not just remote/admin — fully enforced from March 2025.
• Requirement 7 (need-to-know access), 8 (authentication), and 10 (logging) are the three CIAM-relevant sections; together they consume most of the QSA's CIAM time.
• Phishing-resistant MFA (FIDO2/passkeys) is the trajectory; PCI DSS 4.0 strongly encourages it and 4.1 will likely require it for high-risk access.
• Service account credentials in the CDE need rotation, justification, and removal of interactive use — the easiest area to fail audit for CIAM that doesn't surface NHIs cleanly.
• Authentication audit log retention is 12 months total, 3 months immediately available — design for searchable hot storage on 3-month windows.

Where PCI DSS intersects with CIAM

The standard applies to any organization that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). Scope reduction (tokenization, point-to-point encryption, outsourcing to a PCI-certified provider like Stripe) shrinks but does not eliminate the CIAM requirements — anyone with administrative access to the payment integration is still in scope.

The three CIAM-heavy requirements:

• Requirement 7: Need-to-know access controls — RBAC, least-privilege, periodic access reviews.
• Requirement 8: User identification and authentication — unique IDs, MFA, strong credentials, account lockout, no shared accounts.
• Requirement 10: Logging and monitoring — comprehensive audit logs with 12-month retention and SIEM integration.

Requirement 7: Need-to-know access

The Requirement 7 controls are role-based access and periodic review. In CIAM terms:

• Every CDE user role is documented with the data classifications and operations it covers.
• Access is granted only to roles required for the user's job.
• Default access is "no access"; access must be explicitly granted.
• A documented approval workflow gates role assignment.
• Access is reviewed periodically (the standard says "at least every six months" for 4.0; many QSAs prefer quarterly).
• Terminated users have access revoked promptly.

CIAM products that ship RBAC with documented role-to-permission mapping, approval workflows for role assignment, and access-review tooling cover this cleanly. The vendors known for strong access governance on the workforce side: Okta Workforce (Identity Governance add-on), Microsoft Entra (Entitlement Management), SailPoint (full IGA — beyond CIAM but often the answer for large enterprises), ForgeRock, Ping Identity.

For Customer Identity workloads where the "customer" is a B2B end user with role-based access to a CDE-touching application, the same Requirement 7 logic applies. Per-Organization role assignment with audit-loggable changes is the CIAM primitive.

Requirement 8: Authentication

This is the largest CIAM section. The relevant subsections:

8.2 Unique IDs

Every user has a unique identifier. No shared accounts for human users. Group accounts are explicitly prohibited (8.2.2). This is trivially satisfied by any modern CIAM; the audit question is whether anyone in the CDE actually shares an account, which means searching the deployment, not just the policy.

8.3 Strong authentication

Passwords (when used) must be 12+ characters and meet complexity requirements, change on first use, rotated at least every 90 days for accounts not using MFA, and not match the previous four passwords (8.3.1-8.3.7). For 4.0 compliance, requirements 8.3.x are largely satisfied by enforcing MFA — see 8.4 below — which lifts most password constraints.

8.4 Multi-factor authentication

The most operationally significant 4.0 change. MFA is required for:

• 8.4.1: All non-console administrative access into the CDE.
• 8.4.2: All non-console access into the CDE (the 4.0 extension — not just admin).
• 8.4.3: Remote network access originating from outside the entity's network.

8.4.2 is the one that hit most organizations in 2024-2025: every user accessing any system in the CDE from inside or outside the corporate network must MFA. The deadline for full enforcement was March 31, 2025.

Acceptable MFA factors per 8.5: at least two of (something you know, something you have, something you are), independent (compromise of one does not compromise another), and the MFA system itself must be replay-resistant. SMS OTP technically qualifies but PCI SSC guidance from 2023-2024 strongly discourages it; phishing-resistant MFA (FIDO2 / passkeys, covered in detail) is the trajectory.

8.6 Application and system accounts

The other 4.0 sleeper. Service accounts (anything PCI calls "application and system accounts") must:

• Have their authentication credentials managed (8.6.1).
• Not have interactive use unless explicitly justified and documented (8.6.2).
• Have credentials changed periodically and on suspicion of compromise (8.6.3).

The CIAM compliance question: does the platform model service accounts as a distinct principal type? Vendors that treat them as regular users with strong passwords fail this audit; vendors with first-class service-account / non-human-identity primitives (with secret rotation, scope restriction, and audit) pass.

CIAM and IGA vendors that surface non-human identity well: CyberArk (PAM-and-CIAM combo), HashiCorp Vault for service credential storage, Auth0 (Machine-to-Machine clients), Okta (Service Accounts), Microsoft Entra (Managed Identities for Azure resources).

Requirement 10: Logging and monitoring

The audit-log requirement. The minimum events to log:

• All access to cardholder data (10.2.1).
• All authentication attempts, success and failure (10.2.1.x).
• All privileged user actions (10.2.2).
• Initialization, stopping, or pausing of audit logs (10.2.4).
• Account changes (creation, modification, deletion) (10.2.5).
• Use of identification and authentication mechanisms (10.2.6).
• All actions performed by users with privileged roles (10.2.7).

Each log entry needs: user identifier, type of event, date/time, success/failure indication, origination, identity of affected data/system/component.

Retention is 12 months total, with 3 months immediately available for analysis (10.5.1). In practice this means hot, searchable storage for ~3 months and cold storage for the remainder. The "immediately available" criterion is interpreted by QSAs as "can produce specific log entries within reasonable analytic time" — direct query, not "restore from tape."

CIAM audit log integration with SIEM (Splunk, Sumo, Elastic, Datadog) is the standard production pattern. The CIAM streams events to the SIEM in real-time; the SIEM handles correlation, alerting, and long-term storage. PCI requires daily review of security-event logs (10.4.1); SIEM automation is how organizations meet this without manual reviewer fatigue.

Service accounts: the easy audit failure

PCI DSS 4.0 requirement 8.6 is the area where CIAM deployments most commonly fail audit. The recurring problems:

• The deployment uses service accounts but the CIAM models them as users with passwords — no first-class service-account type. The QSA looks at the user list and asks "which of these are non-human?" and the team has to grep through application configs to answer.
• Service account credentials are stored in application config files or environment variables without a secret manager. The credentials don't rotate. They're not in the CIAM's audit log.
• Service accounts have broader access than needed because the team didn't want to debug per-service scope.
• Service accounts log in interactively for "emergency" troubleshooting, violating 8.6.2.

The fixes:

1. Use a CIAM that models service accounts as a distinct principal type. Machine-to-machine clients in Auth0, Service Accounts in Okta, Service Principals in Microsoft Entra, M2M tokens in Curity.
2. Pair with a secrets manager (Vault, AWS Secrets Manager, Doppler) for the credentials.
3. Rotate on a schedule. Quarterly minimum; monthly for high-sensitivity. The secret manager + CIAM combination should do this automatically.
4. Scope per service. Each service has its own service account with its own scope. No shared accounts across services.
5. Disable interactive login for service accounts at the CIAM layer. If a human needs to act with service-level access, they elevate to a separately-audited role.

Phishing-resistant MFA and PCI DSS 4.x

PCI DSS 4.0 does not yet require phishing-resistant MFA, but the standard's text and guidance strongly signal the direction. The 2024-2025 PCI SSC bulletins on MFA implementation explicitly discourage SMS OTP, push notification without binding, and similar phishing-susceptible factors. PCI DSS 4.1 (expected 2026-2027) is likely to require phishing-resistant authentication for high-risk access.

The CIAM choices that get ahead of this:

• FIDO2 / WebAuthn / passkeys as the default MFA factor for CDE access. FIDO2 Explained and Passkeys Explained cover the mechanics.
• Push with number-matching as the fallback when hardware authenticators aren't an option. The 2023 mass-MFA-fatigue attacks (Uber, Cisco, etc.) led to number-matching becoming the production default for push.
• No SMS OTP for CDE access. It still works for password reset on low-sensitivity accounts; not for primary CDE authentication.

The CDE-vs-non-CDE policy split

A CIAM serving both CDE-touching and non-CDE-touching workloads needs to apply different policies based on what the user is accessing. The mechanisms:

• Step-up authentication on CDE access. The user authenticates with their normal flow; when they request access to a CDE-classified resource, they're prompted for a stronger factor (FIDO2). The CIAM's adaptive auth engine handles the step-up.
• Separate authorization servers per resource class. The CDE has its own OAuth issuer with stricter scopes and shorter token lifetimes. The non-CDE has its own with more relaxed policies.
• Per-resource MFA requirement in the policy engine. OPA, Cedar, or the CIAM's native policy language conditions MFA enforcement on the resource being accessed.

The cleanest pattern is the policy-engine approach — one CIAM, one user identity, policies enforce the CDE-specific requirements based on what's being requested. The adaptive auth pattern is what most production CIAMs ship today.

Implementation guidance

1. MFA for all CDE access, not just admin. The 4.0 deadline was March 2025; if you're not there yet, fix this first.
2. Phishing-resistant MFA as default for CDE. FIDO2/passkeys. SMS OTP is on borrowed time.
3. Service accounts as first-class principals. Use a CIAM that models them; pair with a secrets manager; rotate quarterly minimum.
4. Audit log retention: 12 months total, 3 months hot. Plan storage and SIEM integration accordingly.
5. Daily log review automated via SIEM. Manual review of CIAM logs doesn't scale at PCI volume.
6. Quarterly access reviews. The standard says six months; the QSA prefers quarterly; the operational cost is low if the CIAM ships access-review tooling.
7. Document the CDE boundary precisely. Which resources are in scope, which CIAM policies apply where, who is in scope and who isn't.
8. Pre-audit the CIAM section with a QSA before the formal audit. A two-hour readiness review saves weeks of remediation.