PCI DSS access control controls expose the NHI governance gap

At a glance

What this is: This is an analysis of PCI DSS access control controls and the associated requirements, with a focus on how identity governance, least privilege, and approval workflows shape cardholder-data protection.

Why it matters: It matters because IAM, PAM, and NHI programmes all feed the same control plane: if access is overbroad, poorly reviewed, or weakly offboarded, compliance and breach resistance degrade together.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Zluri's guide to PCI DSS access control controls and requirements

Context

PCI DSS access control is about limiting who can reach cardholder data, who can approve that access, and how quickly it is removed when it is no longer needed. The article frames the problem around a familiar identity failure mode: broad internal access, default credentials, and weak third-party governance create paths to sensitive payment data that policy alone does not close.

For IAM and NHI teams, the real issue is lifecycle control. PCI-style access rules only work when unique IDs, least privilege, JIT access, and periodic review are enforced across human users, service accounts, and delegated vendor access. That is why payment-data governance quickly becomes an identity governance problem rather than a purely compliance checklist.

Key questions

Q: What breaks when PCI DSS access control is treated as a one-time policy exercise?

A: Access remains usable after the original business need has ended, which is how overprivileged identities become breach paths. PCI DSS access control only works when approvals, unique IDs, and revocation are operational, not just documented. Otherwise the organisation can prove policy exists but cannot prove that cardholder-data access was actually removed.

Q: Why do service accounts and vendor credentials increase PCI DSS risk?

A: Service accounts and vendor credentials often bypass normal user oversight, yet they can still reach cardholder data, databases, and administrative interfaces. When those identities are shared, long-lived, or poorly reviewed, they increase the attack surface and make it easier for an attacker to move from initial access to payment-data exposure.

Q: How do security teams know whether PCI access controls are actually working?

A: They should look for evidence that access is scoped, approved, time-bound, and removed on schedule. If recertification finds standing access, shared credentials, or vendor entitlements that cannot be tied to an owner, the control is not working even if the policy language looks complete.

Q: Who is accountable when third-party access reaches cardholder data?

A: Accountability sits with the organisation that granted the access and the teams that own the lifecycle of that entitlement. Third-party relationships do not transfer governance responsibility. Under PCI DSS, the business must still prove that access was authorized, monitored, and revoked when the need ended.

Technical breakdown

PCI DSS access control requirements and identity enforcement

PCI DSS access control controls map closely to identity governance mechanics: unique IDs, business need-to-know restrictions, approval gates, and restricted decryption access. In practice, the control fails when access is shared, inherited, or left standing after the task ends. That is especially true where cardholder data sits behind SaaS applications, internal firewalls, or third-party integrations. The article also points to JIT access and role-based access as operational patterns, but those patterns only work when entitlement scope is tightly defined and reviewed. Practical implication: treat cardholder-data access as an entitlement lifecycle problem, not a one-time policy setting.

Practical implication: map every CHD path to an owner, an approval rule, and a revocation trigger.

Third-party credentials, default access, and payment-data exposure

The Target example in the article shows the classic third-party access pattern: attackers steal credentials from a vendor, move into the environment, and then reach sensitive databases. PCI DSS control 2 on default credentials matters here because weak defaults and inherited vendor access often sit in the same trust chain. In NHI terms, the issue is not only credential strength but also whether the credential is scoped, monitored, and revoked when a relationship changes. That makes supplier access governance a core control surface, not an add-on to procurement. Practical implication: treat third-party and service-account entitlements as active attack paths, not administrative convenience.

Practical implication: review all vendor-linked accounts and retire anything that outlives the business need.

Vulnerability management does not replace access governance

The article places access control alongside vulnerability management, encryption, and policy maintenance for a reason. Strong patching and malware defence reduce exploitability, but they do not correct overprivileged identities or stale approvals. In other words, a hardened system can still expose cardholder data if a valid identity can walk directly to it. That is why PCI DSS works best when control design joins technical hardening with entitlement hygiene and evidence-based review. Practical implication: align vulnerability remediation with access review cycles so the same system is not simultaneously hardened and overexposed.

Practical implication: pair vulnerability fixes with access recertification for the same applications and data stores.

Threat narrative

Attacker objective: The attacker sought access to payment-card data by abusing trusted vendor credentials and then pivoting into customer databases.

1. Entry occurred through stolen third-party credentials, which gave the attacker a legitimate path into the Target environment rather than a direct exploit of cardholder data.
2. Escalation followed when the attacker installed malware and used that foothold to reach customer databases containing payment-card information.
3. Impact was the theft of sensitive cardholder data at scale, which ultimately produced a multistate settlement and exposure affecting nearly 42 million payment card accounts.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PCI DSS access control is really an identity lifecycle problem, not a policy problem. The article correctly ties cardholder-data protection to role-based access, JIT access, and approval workflows, but those controls only work when access is scoped, reviewed, and removed on time. In practice, the programme fails when entitlement lifecycle management is treated as administrative overhead rather than the control that keeps payment data off-limits. Practitioners should judge PCI readiness by whether access can be proven to expire, not by whether a policy exists.

Third-party access without lifecycle offboarding is the failure mode this article exposes. The Target example is not just about weak perimeter defence. It is about vendor access that remained useful long enough to be exploited, which is exactly the kind of control gap that lifecycle governance is meant to close. The implication is that supplier access, especially where it can reach CHD, must be governed as a living entitlement with a named owner and a removal event.

Identity blast radius: broad access and weak review multiply the damage when a single credential is compromised. PCI DSS controls are supposed to reduce blast radius by narrowing who can see cardholder data and how they get there. When organisations rely on shared permissions, overbroad roles, or unmanaged service accounts, the blast radius expands far beyond the original access request. Practitioners should treat every CHD-connected identity as a potential containment boundary.

Unique IDs and approval gates are only as strong as the offboarding process behind them. The article emphasises traceability, but traceability without removal still leaves usable access in place. That is why access reviews, recertification, and deprovisioning are inseparable from PCI control design. The governance standard is not visibility alone. It is whether access can be removed before it becomes a breach path.

PCI compliance validates NHI governance maturity, it does not substitute for it. The controls discussed here overlap heavily with NHI discipline: least privilege, secret handling, third-party access, and periodic verification. That overlap matters because the same entitlement weaknesses that create PCI exposure also create cloud and SaaS exposure. Practitioners should use PCI DSS as a pressure test for the broader identity programme, not as a narrow compliance exercise.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which is why access lifecycle control remains a persistent weak point.
• For a deeper control model, compare that finding with NHI Lifecycle Management Guide, which focuses on provisioning, rotation, and offboarding as a single governance loop.

What this signals

Identity blast radius will remain the decisive metric for PCI programmes. The article’s emphasis on least privilege and unique IDs is correct, but the operational question is whether a compromised vendor account can still reach the systems that matter. With 97% of NHIs carrying excessive privileges, according to Ultimate Guide to NHIs, the risk is structural, not exceptional. Practitioners should measure how far a single credential can move before the control plane stops it.

PCI-style access control is converging with broader NHI governance because the same entitlement failures repeat across applications, databases, and third-party integrations. The organisation that can remove standing access quickly will outperform the one that only documents policy. That is where lifecycle discipline, not compliance theatre, becomes the real differentiator.

Control evidence, not control intent, will drive audit confidence. Review artefacts, revocation logs, and owner-attributed access decisions matter more than policy statements alone. Teams that can show access removal and scoped approval across CHD environments will be better positioned for both PCI scrutiny and wider identity governance maturity.

For practitioners

• Map every cardholder-data path to a named identity owner Inventory human accounts, service accounts, API credentials, and vendor-linked identities that can reach CHD. Require a named owner for each entitlement so approval, review, and removal are always assignable.
• Enforce business-need access with time-bound approvals Replace standing access with task-scoped approvals for systems that store or process CHD. Make approval expiry explicit so access cannot outlive the business reason that justified it.
• Eliminate default credentials and shared accounts Change all vendor-supplied defaults before deployment and remove shared logins from CHD environments. Use unique IDs so every access event can be attributed and revoked without collateral impact.
• Tie access review to remediation, not reporting Use access recertification to remove overprivileged CHD access, not just document it. If review findings do not trigger revocation or re-scoping, the programme is producing evidence instead of control.
• Treat third-party credentials as active risk assets Review vendor access on the same cadence as internal privileged access. Revoke credentials immediately when service relationships, scope, or support obligations change.

Key takeaways

• PCI DSS access control is only effective when it is enforced as an identity lifecycle process, not a static policy.
• The article’s Target example shows how third-party credential abuse can turn weak governance into large-scale cardholder-data loss.
• Practitioners should focus on ownership, time-bound approval, and timely revocation if they want PCI controls to reduce real attack paths.

Key terms

• Cardholder data environment: The cardholder data environment is the set of people, systems, and processes that store, process, or transmit payment card data. In practice, it is a governance boundary, not just a network segment, because access rules, approvals, logging, and revocation all determine whether the boundary is actually defensible.
• Need-to-know access: Need-to-know access means granting data access only when a user or identity requires it for a specific business purpose. In PCI and identity governance terms, it is a scope control that should be time-bound, owner-approved, and removable when the task ends, otherwise it becomes standing privilege by another name.
• Third-party identity governance: Third-party identity governance is the discipline of controlling external vendor, partner, and supplier access with the same rigor as internal access. It covers onboarding, scoping, monitoring, review, and offboarding so that outside credentials do not remain valid longer than the relationship that justified them.

Deepen your knowledge

NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity, it is worth exploring.

This post draws on content published by Zluri: Access Management 6 PCI DSS Controls & Their Requirements. Read the original.