Accountability sits with the team that owns the workload and its identity lifecycle, not with the secret store alone. PCI controls expect clear ownership for access, logging, and protection of sensitive data paths. If the machine identity is not assigned and reviewed like a governed asset, accountability is already broken.
Why This Matters for Security Teams
When cardholder data is exposed through a machine identity, the security question is not whether the vault failed first or the application failed first. The real issue is ownership. PCI DSS expects controlled access, logging, and protection of sensitive data paths, and that requires a named team that can approve, review, and revoke the identity behind the workload. If that ownership is unclear, accountability fragments across platform, application, and security teams.
This is a recurring pattern in NHI incidents: the identity exists, but nobody can answer who approved it, who last reviewed it, or who is responsible when it touches regulated data. NHIs now outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. That visibility gap is exactly where PCI scope becomes harder to defend.
PCI guidance is explicit that access control and monitoring must be managed, not assumed. See PCI DSS v4.0 and the broader breach patterns in 52 NHI Breaches Analysis. In practice, many security teams encounter the real owner only after the incident review has already started, rather than through intentional identity governance.
How It Works in Practice
Accountability should follow the workload that uses the machine identity, not the tool that stores the secret. The owning team needs to be responsible for the full lifecycle: request, approval, issuance, rotation, logging, review, and revocation. That means the identity is treated like a governed asset, with a clear service owner, a defined business purpose, and a review cadence tied to PCI risk.
Practically, that ownership model usually includes:
- Assigning a named system owner and backup approver for every service account, API key, and certificate.
- Mapping each identity to the cardholder data flow it can reach, so auditors can trace exposure paths.
- Using least privilege and removing standing access where JIT access is possible.
- Logging issuance, use, and revocation events so the team can prove control over sensitive paths.
- Reviewing dormant and over-privileged identities on a fixed schedule, not only during incidents.
That approach aligns with the control expectations described in PCI DSS v4.0, and it also reflects the NHI governance failures documented in Ultimate Guide to NHIs — Key Research and Survey Results and JetBrains GitHub plugin token exposure. The underlying lesson is simple: if the workload can access cardholder data, the workload owner must be accountable for the machine identity that makes that access possible.
These controls tend to break down when identities are created ad hoc in CI/CD pipelines or shared across multiple services, because no single team can prove effective ownership.
Common Variations and Edge Cases
Tighter identity governance often increases operational overhead, so organisations have to balance auditability against deployment speed. That tradeoff is real, especially in platform teams supporting many microservices, ephemeral jobs, or third-party integrations.
There is no universal standard for every edge case yet, but current guidance suggests the same accountability rule still applies even when the identity is short-lived or automated. For ephemeral workloads, ownership should attach to the service, pipeline, or orchestrator that issued the credential. For outsourced platforms, the internal team remains accountable for risk acceptance, vendor oversight, and evidence collection. For shared technical accounts, best practice is evolving toward eliminating the sharing model entirely because shared ownership makes review and incident response unreliable.
Risk becomes harder to manage when secrets are embedded in code, when a certificate outlives the workload, or when multiple teams can alter the identity without a single approval path. The broader NHI research shows why this matters: 79% of organisations have experienced secrets leaks, and 97% of NHIs carry excessive privileges, according to the Ultimate Guide to NHIs — Why NHI Security Matters Now. For incident patterns and governance blind spots, The 52 NHI breaches Report is a useful reference. The practical conclusion is that accountability should be documented before cardholder data access is granted, because exceptions tend to expand faster than review processes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0 set the technical controls, and PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 7.2.4 | Requires access rights to be assigned and reviewed with clear accountability. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Ownership and lifecycle control are core to preventing NHI-led data exposure. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access governance supports accountable control of workload access. |
Name an owner for each machine identity and review its access to cardholder data on a set cadence.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
