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

Why This Matters for Security Teams

PCI DSS 4.0 does not treat third-party access as a paperwork exercise. It expects organisations to control who can reach cardholder data, why that access exists, and when it ends. That matters because external vendors, contractors, and integrators often arrive with broad support needs, then retain access long after the business justification has expired. NHI Management Group’s Ultimate Guide to NHIs shows why this is dangerous: 92% of organisations expose NHIs to third parties, creating a persistent supply chain risk.

The practical challenge is that third-party access is usually a mix of human accounts, service accounts, API keys, and delegated tooling. If those identities are not owned, time-bound, and monitored, they become standing pathways into the cardholder data environment. That is exactly the kind of exposure PCI DSS 4.0 is designed to reduce, and it aligns closely with the baseline expectations in the PCI DSS v4.0 documentation and the attack patterns documented in 52 NHI Breaches Analysis. In practice, many security teams discover third-party overreach only after a vendor review, incident, or audit exception exposes how long the access has been drifting.

How It Works in Practice

Applying PCI DSS 4.0 well means treating each third-party relationship as a scoped identity lifecycle, not a one-time onboarding event. Start by assigning an internal owner for every external account, token, and remote access path. Then define the business purpose, approved systems, expiry date, and removal trigger. If a vendor needs access to production cardholder systems, give the narrowest access needed and record the justification in a control system that supports evidence collection.

From a governance perspective, the access model should include approval, review, and revocation. Current guidance suggests tying third-party access to both business need and ongoing validation, rather than leaving it enabled until someone remembers to close it. This is where NHI discipline matters: secrets should be rotated, access should be short-lived where possible, and authentication paths should be visible to the security team. NHI Management Group’s Regulatory and Audit Perspectives section is useful here because it frames offboarding, rotation, and inventory as audit evidence, not optional hygiene.

Practitioners should also validate that third parties do not retain indirect access through shared integrations, CI/CD credentials, remote administration tools, or unmanaged API keys. The OWASP view is consistent with this: the OWASP Non-Human Identity Top 10 highlights overprivilege, weak lifecycle control, and secret sprawl as recurring failure modes. A simple operating pattern helps:

• Inventory every third-party identity and map it to an owner.
• Approve access for a defined purpose and time window.
• Require MFA, logging, and segmentation for any access into the cardholder data environment.
• Review access continuously and revoke it when the task ends.
• Track evidence of offboarding, token rotation, and exception closure.

These controls tend to break down when vendors rely on shared credentials, unmanaged service accounts, or long-lived integrations embedded in automation pipelines because revocation becomes technically difficult and operationally delayed.

Common Variations and Edge Cases

Tighter third-party control often increases operational friction, requiring organisations to balance auditability against vendor support speed. That tradeoff is real, especially for managed service providers, payment processors, and incident-response partners who may need rapid, temporary access during live support windows.

There is no universal standard for every access pattern, so the control design should match the risk. A read-only auditor may need a different process than a remote administrator or an integration account that can move data between systems. Where access is unavoidable, best practice is evolving toward just-in-time approval, stronger segmentation, and credential expiry rather than permanent entitlements. For highly privileged paths, the organisation should prefer short-lived access and frequent reauthorization over standing accounts.

One useful indicator is whether the third party can operate without a reusable secret. If not, the organisation should at least reduce blast radius through scoped tokens, separate environments, and tight logging. The broader NHI risk profile makes this especially important: NHI Management Group reports that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why vendor access often lingers after contract end. That gap is visible in real-world breach cases and in supply-chain incidents such as the Reviewdog GitHub Action supply chain attack and the Shai Hulud npm malware campaign.

Related resources from NHI Mgmt Group

• What do organisations get wrong about third-party privileged access?
• How should organisations respond when a third-party integration has broad access?
• Who is accountable when third-party cloud access is abused in a data breach?
• Who is accountable when third-party access remains active after the task is complete?