Who is accountable when non-human accounts access cardholder data?

The organisation remains accountable, but ownership should be assigned to the system, service, or application team that controls the non-human identity. PCI governance should require the same review, authentication, and logging evidence for machine access as for human access. That is especially important when service accounts can reach sensitive payment workflows.

Why This Matters for Security Teams

When a non-human account can reach cardholder data, the accountability question is not about who clicked a button. It is about who owns the system that issued the credential, who approved the access path, and who can prove the control operated as intended. PCI expectations still apply to machine identities, and governance must treat service accounts, API keys, and application tokens as privileged access paths, not background plumbing. The OWASP Non-Human Identity Top 10 and PCI DSS v4.0 both reinforce that weak identity control is a security failure, regardless of whether the actor is human or software.

NHI Management Group research shows that 97% of NHIs carry excessive privileges and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That matters because over-privileged machine access often reaches payment workflows long before teams notice the exposure. In practice, many security teams encounter the ownership gap only after a service account has already been used to move into sensitive data paths.

How It Works in Practice

Accountability should be assigned to the business or technical team that operates the application, service, or integration using the non-human identity. That team owns the credential lifecycle, the access rationale, the logging evidence, and the remediation path when the identity is misused. Central security and PCI governance define the standard, but operational ownership sits with the team that can actually change the system.

For cardholder data environments, the practical control set is familiar: know every non-human identity, map each one to a named owner, restrict it to the minimum payment workflow it needs, and prove that authentication and logging are present. A strong program usually includes:

• Unique, named ownership for every service account, API key, certificate, or token.
• Short-lived credentials where possible, with rotation and revocation tied to change events.
• Logged authentication events, privilege use, and access to cardholder data paths.
• Periodic review of machine entitlements by the same control owner who can approve or remove access.
• Escalation paths that make application teams accountable for exceptions, not just security operations.

This model aligns with Ultimate Guide to NHIs, which frames NHI governance around lifecycle control, visibility, and Zero Trust. It also fits PCI’s emphasis on evidence, least privilege, and traceability, as described in PCI DSS v4.0. Security teams should not accept “shared service account” as an ownership model, because shared accountability usually becomes no accountability. These controls tend to break down when legacy batch jobs or third-party integrations depend on unmanaged static credentials because there is no reliable owner to approve rotation or investigate misuse.

Common Variations and Edge Cases

Tighter machine-identity controls often increase operational overhead, so organisations must balance payment-data protection against deployment speed and service continuity. Current guidance suggests that the strongest accountability model is not always the most centralised one; it is the one that produces clear ownership, auditable approvals, and rapid remediation.

There are several edge cases. Third-party processors may manage part of the access chain, but the merchant still owns the decision to connect that system to cardholder data and must verify the vendor’s controls. Shared platform identities in CI/CD or batch processing are especially risky because multiple teams may depend on the same secret, making attribution difficult after an incident. In high-availability environments, teams sometimes resist short TTLs because they fear outages, yet long-lived secrets are exactly what expand blast radius when a machine account is compromised.

The right test is simple: if the identity can read, write, or transform cardholder data, then there must be an accountable owner who can show review, approval, and revocation evidence. NHI Management Group’s Ultimate Guide to NHIs — Key Research and Survey Results highlights how often organisations lack visibility into service accounts, which makes ownership assignment more than a compliance formality. For deeper incident patterns, see the 52 NHI Breaches Analysis. The model becomes weakest when ownership is split across multiple vendors and no single team can revoke access without a change-board delay.

Related resources from NHI Mgmt Group

• Why do non-human identities create more audit risk than human accounts?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern non-human identities alongside human accounts?