Access reviews certify only the identities that were included in the scoping model. If connected systems, service accounts, or vendor users are missing from that model, the review gives false confidence and leaves real payment exposure untouched.
Why This Matters for Security Teams
PCI access reviews are only useful when the scoping model is complete. If payment-connected systems, service accounts, API keys, vendor identities, or background jobs sit outside that model, the review can certify the wrong population and miss the paths that actually reach cardholder data. That creates audit comfort without operational control, which is especially dangerous when non-human identities carry broad or persistent access. NHI Mgmt Group notes that Ultimate Guide to NHIs reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
The practical issue is not whether a quarterly review happened, but whether the review covered every identity that can touch PCI scope in production, test, or support paths. Teams often assume scope is a static inventory problem, when it is really a living access graph that changes with integrations, third parties, and automation. That is why guidance from OWASP Non-Human Identity Top 10 is so relevant here: unmanaged machine identities frequently become the hidden layer underneath compliance evidence. In practice, many security teams discover the gap only after an assessor asks how an identity was excluded from scope, rather than through intentional scoping discipline.
How It Works in Practice
Effective reviews start with the PCI scoping boundary, then trace every identity that can create, move, read, or export cardholder data. That includes human users, but also service accounts, batch jobs, connectors, secrets, vendor support identities, and admin tooling. If an identity can influence a system in scope, it belongs in the review set even if it does not have a human login. Current practice is to align review populations to the same asset and data-flow map used for PCI scope, not to a separate IAM export.
Practitioners usually need three checks:
- Confirm the identity exists in the authoritative inventory, including ephemeral and non-interactive accounts.
- Verify the identity’s actual permissions against the minimum access needed for its payment-related task.
- Validate that every exclusion from the review has a documented scoping reason tied to a system boundary, data-flow decision, or compensating control.
This is where NHI governance becomes operational. The NHI Lifecycle Management Guide is useful because lifecycle control determines whether an identity is still active, rotated, or orphaned when a PCI review is run. For control design, the OWASP Non-Human Identity Top 10 reinforces that long-lived secrets and weak ownership are common failure points. The point is to make the review traceable from scoping decision to entitlement record to evidence of current use. These controls tend to break down in hybrid environments with unmanaged SaaS integrations and shared service accounts because the identity inventory and the PCI asset inventory drift apart.
Common Variations and Edge Cases
Tighter scoping often increases review workload, requiring organisations to balance compliance precision against operational overhead. That tradeoff matters because not every environment has clean ownership data or reliable asset tagging. Best practice is evolving, but there is no universal standard for this yet: some teams review all machine identities that can reach cardholder data, while others apply a tiered model based on system criticality and connectivity.
Edge cases usually appear in three places. First, vendor users may be outside the core IAM process but still have remote support access into PCI-relevant systems. Second, shared automation accounts may serve multiple applications, so excluding one app from scope does not make the identity irrelevant. Third, ephemeral pipelines and break-glass access can be missed if the review cadence is slower than the privilege lifecycle.
For stronger assurance, review evidence should show how scope was determined, which identities were included, and why any adjacent accounts were excluded. That approach aligns well with the broader NHI risk patterns documented in the Ultimate Guide to NHIs — Key Challenges and Risks, especially where visibility is partial and privileges are excessive. It also helps identify the failure mode that matters most: scope drift after architecture changes, when review artifacts remain current on paper but no longer reflect the real payment environment.
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 periodic review of access to system components and data in scope. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Addresses missing inventory and ownership for machine identities in scope. |
| NIST CSF 2.0 | PR.AC-4 | Supports least-privilege access governance for users and non-human identities. |
Inventory service accounts and secrets that can touch PCI systems before running access reviews.
