Who is accountable when a third-party NHI causes PCI scope exposure?

Accountability sits with the organisation that owns the payment environment and the business relationship, even if a vendor operates the access path. The practical question is whether the third-party identity is contract-bound, monitored, and revoked when the relationship changes. If not, the risk remains inside your control boundary.

Why This Matters for Security Teams

PCI scope exposure from a third-party NHI is rarely a pure vendor problem. If a service account, API key, or workload token can reach cardholder data systems, the owning organisation still carries the compliance and breach impact. That is why PCI-DSS, identity governance, and third-party risk need to be treated as one control plane, not separate workstreams. In NHI terms, the real issue is whether the identity is discovered, bounded, rotated, and revoked across the full relationship lifecycle.

This is not theoretical. NHIMG research shows that 92% of organisations expose NHIs to third parties, while only 20% have formal processes for offboarding and revoking API keys, according to the Ultimate Guide to NHIs. When the same identity is reused across applications or left active after the relationship changes, PCI scope expands quietly and remains sticky. The OWASP OWASP Non-Human Identity Top 10 frames this as an identity lifecycle and privilege problem, not just a vendor management issue. In practice, many security teams encounter this only after an assessor, incident, or expired contract reveals that access was never truly removed.

How It Works in Practice

Accountability starts with clear ownership of the environment boundary and then extends to the technical and contractual controls around the third party. The organisation that processes payments must be able to prove who created the NHI, what it can reach, how long it lives, and how quickly it is revoked when the business need ends. A mature program treats third-party NHI access like any other privileged path: inventory it, classify it, monitor it, and tie it to explicit approval.

Current guidance suggests four practical controls:

• Bind the NHI to a named business purpose and an accountable internal owner.
• Issue access with just-in-time limits where possible, rather than standing credentials.
• Use short-lived tokens, workload identity, and strong rotation for any access that touches PCI systems.
• Revoke access automatically when the contract ends, the integration changes, or the vendor no longer needs the path.

NHIMG research also shows how fragile this gets in the real world: 91% of former employee tokens remain active after offboarding, and 44% of NHI tokens are exposed in the wild, according to the 2025 State of NHIs and Secrets in Cybersecurity. That is why runtime control matters more than policy documents. For agentic or tool-using systems, the same logic applies, except the identity must prove what the workload is doing at the moment of access. Frameworks such as the OWASP Non-Human Identity Top 10 and the Anthropic report on AI-orchestrated cyber espionage both reinforce the same point: access must be scoped to the task, not the relationship alone. These controls tend to break down when vendors share credentials across multiple customers because the revocation blast radius becomes opaque.

Common Variations and Edge Cases

Tighter NHI controls often increase integration overhead, so organisations have to balance speed against assurance. That tradeoff is especially visible in managed service models, outsourced development, and embedded payment platforms, where the vendor may operate the access path but the buyer still owns the regulated environment. There is no universal standard for this yet, but current guidance leans toward shared accountability: the vendor must protect its credentials, while the buyer must verify that those credentials are bounded and removed when no longer needed.

Edge cases usually appear when credentials are long-lived, copied into scripts, or reused across environments. In those situations, PCI scope can spread beyond the original integration and into CI/CD, support tooling, or secondary applications. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks notes that excessive privilege and weak visibility are common failure modes, which is why role reviews alone are not enough. Best practice is evolving toward intent-based authorisation, ephemeral secrets, and continuous validation of workload identity, especially where autonomous systems can chain tools or move laterally. PCI-DSS v4.0 reinforces the need to minimise access and track it continuously, but the practical enforcement still depends on whether the organisation can actually see and revoke the NHI. The hardest cases are legacy integrations with no API inventory, because accountability exists on paper while the technical proof of control does not.

Related resources from NHI Mgmt Group

• Who is accountable when a third-party integration keeps an NHI active after the business need ends?
• Who is accountable for third-party access after a campaign or project ends?
• Why do service accounts and third-party identities complicate compliance reviews?
• Who should own third-party access risk in a banking GRC programme?