PCI DSS v4.0 raises the bar for access reviews and third-party risk

At a glance

What this is: This is a Zluri analysis of PCI DSS v4.0 that finds the standard now places heavier weight on access reviews, MFA, continuous monitoring, and third-party risk governance.

Why it matters: It matters because IAM, PAM, and NHI teams now have to evidence not just who can access cardholder data, but how access is reviewed, monitored, and governed across supplier relationships.

By the numbers:

• PCI DSS v4.0 introduces 64 new requirements, some of which become mandatory by March 2025.
• The current version, PCI DSS v3.2.1, remained valid until March 31, 2024.
• If your organization handles payment card data, it must comply with v4.0 by March 31, 2025.

Context

PCI DSS v4.0 is the payment industry’s latest security standard for protecting cardholder data, but the practical challenge is governance rather than wording. The article frames the shift around access control, continuous monitoring, and third-party security, which places identity teams at the centre of compliance evidence.

For IAM and NHI programmes, the important change is that compliance now depends on proving access is reviewed and remediated continuously, not only at audit time. That creates direct pressure on service accounts, supplier access, and any identity path that can reach the cardholder data environment.

The article’s emphasis on regular assessments and documented evidence reflects a broader move from static controls to operating controls. That is a familiar pattern in mature identity programmes, but PCI DSS v4.0 makes it explicit for cardholder-data governance.

Key questions

Q: How should organisations use access reviews to support PCI DSS compliance?

A: Use access reviews to prove that only approved identities can reach cardholder data, and that revocation happens when access is no longer needed. The review process should include users, privileged accounts, and non-human identities, with remediation evidence stored alongside the decision so auditors can verify the full control path.

Q: Why do third-party identities create more PCI DSS v4.0 risk?

A: Third-party identities expand the compliance boundary because the organisation still owns the risk even when access is granted to vendors or connected services. If those accounts are not inventoried, scoped, and offboarded with the same discipline as internal identities, cardholder-data exposure and audit failure become much more likely.

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. The result is stale entitlement, hidden privilege creep, and control evidence that does not reflect current reality. PCI DSS 4.0 pushes organisations toward continuous validation because point-in-time approval is not enough.

Q: What should teams do when supplier access is no longer needed?

A: They should revoke the access, confirm that connected tokens or delegated permissions are disabled, and retain evidence that the offboarding action was completed. In PCI environments, leaving supplier access in place after need ends is a control failure, not an administrative delay.

Technical breakdown

Customized compliance controls and evidence in PCI DSS v4.0

PCI DSS v4.0 allows a customized approach, meaning organisations can design controls that fit their environment if they can prove the controls meet the security objective. That shifts the burden from checkbox implementation to defensible control design and validation. For identity teams, the key question is whether access governance, logging, and remediation produce auditable evidence that stands up under assessor scrutiny. The article’s point is that flexibility does not reduce accountability; it increases the need to show control effectiveness.

Practical implication: treat customised access controls as evidence-producing controls, not exceptions to governance.

Why third-party access and supplier systems are now a compliance issue

The article explicitly ties PCI DSS v4.0 to third-party security and supply-chain exposure. That matters because third-party access often bypasses the clean assumptions embedded in internal IAM processes, especially when supplier-owned identities or integrations retain access longer than the business relationship requires. In PCI environments, that extends the scope of identity governance beyond employees and into external identities, delegated access, and offboarding discipline. The control problem is not just trust, but proving that external access is continuously bounded.

Practical implication: inventory supplier-owned identities and prove offboarding, review, and scope limitation for every third-party access path.

Continuous access review as a compliance control, not an administrative task

The article positions access review as a recurring compliance requirement, with automation proposed to reduce errors and gaps. Technically, that reflects a move from periodic attestation to ongoing entitlement validation, where access evidence must be current enough to support assessment. For NHI and human IAM alike, the issue is whether permissions can be mapped to ownership, reviewed against actual use, and revoked when no longer justified. In PCI terms, access review becomes a control for proving least privilege and operational discipline.

Practical implication: automate entitlement review workflows so evidence, remediation, and reporting stay aligned throughout the compliance cycle.

Threat narrative

Attacker objective: The objective is to exploit unmanaged or excessive access paths to reach sensitive payment data or create compliance failure conditions that increase breach exposure.

1. Entry occurs when a third party or internal user retains access that is broader than the current business need, creating an exposure path into payment data systems.
2. Escalation follows when access is not reviewed or remediated quickly enough, allowing unauthorized permissions to persist across systems and roles.
3. Impact occurs when stale or excessive access reaches cardholder data environments, increasing the chance of data leakage, audit failure, or policy violation.

Breaches seen in the wild

• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
• Canvas Instructure Data Breach: ShinyHunters exploits Canvas LMS platform to expose millions of student records via third-party NHI credential abuse.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PCI DSS v4.0 turns access governance into an evidence problem, not just a control problem: the standard’s emphasis on continuous monitoring, access reviews, and third-party security means organisations now have to prove that access is current, justified, and remediated. That aligns PCI compliance with modern identity governance practice, where the audit trail matters as much as the permission model. The practical conclusion is that access governance must be operationalised as an always-on discipline.

Third-party access is the sharpest governance edge in PCI environments: the article’s focus on supplier systems reflects a reality that many programmes still under-model. Supplier-owned accounts, integrations, and delegated access often sit outside normal joiner-mover-leaver discipline, yet they can still reach cardholder data. The implication is that third-party identity lifecycle control is now a PCI compliance issue, not a procurement side note.

Continuous access review is the real compliance control behind the standard: if permissions cannot be reviewed, evidenced, and remediated on a recurring basis, the organisation cannot demonstrate sustained alignment with PCI DSS v4.0. That makes access review automation and reporting integrity central to compliance maturity. Practitioners should treat review quality as a control outcome, not a workflow metric.

Manual compliance processes no longer scale to the level of assurance PCI DSS v4.0 expects: the article repeatedly points to monitoring, documentation, and validation as ongoing requirements, which exposes the limits of spreadsheet-driven governance. That is especially true where human access, service accounts, and supplier identities intersect in the same environment. The field should read this as a validation standard for continuous identity control, not a one-time audit exercise.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs

What this signals

Third-party access is now a first-class compliance issue: PCI DSS v4.0 pushes organisations to treat supplier identities, delegated access, and external integrations as governed parts of the payment-data attack surface. The control question is whether those identities are inventoried, reviewed, and removed with the same rigor as employee access. A programme that cannot answer that question will struggle to evidence compliance.

Continuous review is replacing periodic audit thinking: the standard’s operational direction rewards identity teams that can show current evidence, not historic intent. That changes the programme design problem from “prepare for the audit” to “keep entitlement evidence continuously defensible.” Identity governance, not point-in-time certification, becomes the compliance substrate.

92% of organisations expose NHIs to third parties, according to the Ultimate Guide to NHIs: that scale explains why third-party access is so difficult to contain once integrations, supplier accounts, and machine credentials spread across environments. For practitioners, the signal is clear: if third-party and NHI lifecycle controls are not joined up, PCI evidence will remain fragmented.

For practitioners

• Map cardholder-data access paths Identify every human, service, and third-party identity that can reach the cardholder data environment, then assign ownership for each access path.
• Automate recurring access reviews Use workflow automation to collect entitlement evidence, flag stale permissions, and push remediation for users and integrations on a fixed review cycle.
• Tighten third-party offboarding Remove supplier access when the business relationship ends, and verify that integrations, tokens, and delegated permissions are revoked as part of offboarding.
• Document assessor-ready evidence Keep review results, remediation records, and control exceptions in a form that a QSA can trace back to the exact entitlement and approval event.

Key takeaways

• PCI DSS v4.0 raises the bar by tying compliance more tightly to continuous access governance, especially where third-party access can reach cardholder data.
• The article cites 64 new requirements and a March 31, 2025 compliance deadline, which makes evidence quality and control automation more urgent.
• Practitioners should focus on entitlement inventory, recurring review, and supplier offboarding because those are the controls most likely to determine audit readiness.

Key terms

• Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.
• Cardholder Data Environment: The cardholder data environment is the set of systems, users, and processes that store, process, or transmit payment card data. For NHI governance, it includes every machine identity that can influence those systems, even when the identity itself is invisible to end users.
• Customized approach: A customized approach lets an organisation design controls that meet a security objective without using the exact prescriptive method in the standard. In PCI DSS v4.0, that flexibility only works if the organisation can demonstrate the control is effective, measurable, and auditable in practice.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.