PCI DSS 4.0 makes NHI governance a compliance control

At a glance

What this is: PCI DSS 4.0 broadens compliance pressure on non-human identities by tying least privilege, access reviews, secret handling, and third-party monitoring to explicit requirements.

Why it matters: IAM, NHI, and PAM teams need to treat system and application accounts as regulated access paths because PCI scope, evidence, and accountability now extend beyond human users.

By the numbers:

• PCI DSS 4.0 includes over 200 updates that reshape compliance expectations across in-scope environments.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Oasis Security's guide to PCI DSS 4.0 and NHI governance

Context

PCI DSS 4.0 is not only a payment security update. It is a governance reset that pulls non-human identities, secret handling, access review, and third-party monitoring into the compliance perimeter for organisations that process, store, or transmit cardholder data.

For identity teams, the practical shift is that system and application accounts can no longer sit outside formal control design. If those identities can authenticate, inherit privilege, or connect through third parties, they now need the same evidence discipline that auditors expect from human access programmes.

Key questions

Q: What breaks when NHI controls are not included in PCI DSS 4.0 scope?

A: Audits become incomplete because the organisation can prove human access governance while leaving service accounts, API keys, and deployment credentials outside the control set. That creates hidden pathways into cardholder-data environments, especially where secrets live in code or connected tooling. The result is a compliance gap and a security gap at the same time.

Q: Why do machine identities complicate PCI least-privilege reviews?

A: Machine identities are often provisioned once and then allowed to accumulate permissions as systems change. Unlike human users, they do not trigger natural lifecycle events such as role changes or offboarding. Without explicit ownership and review, privilege drift can persist long after the original business need has passed.

Q: How do teams know whether NHI governance is working for PCI compliance?

A: Look for evidence that every machine identity has an owner, a defined business purpose, a review cadence, and a documented revocation path. If accounts cannot be tied back to a current process or service, governance is incomplete. Strong programmes can produce traceable evidence quickly, not just policy statements.

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

A: 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.

Technical breakdown

How PCI DSS 4.0 changes NHI scope

PCI DSS 4.0 widens the operational surface by treating more system components and access paths as in scope, including source code repositories and deployment tools. That matters because NHI credentials often live inside the same delivery chain that moves code into production. When a service account, API key, or application login reaches those tools, the control boundary is no longer just the server or database. It is the full path where identity, secrets, and automation intersect. For compliance teams, scope now depends on understanding where machine identities are created, used, stored, and reused.

Practical implication: map every NHI that can touch cardholder-data flows, deployment tooling, or third-party integrations before the audit window opens.

Least privilege and access review for machine identities

PCI DSS 4.0 aligns closely with classic least-privilege logic, but machine identities expose a different failure pattern than human accounts. A service account does not need convenience-based access, yet it often accumulates broad permissions because teams provision once and forget the lifecycle. Requirement 7.2.5 pushes organisations toward periodic review, while Requirement 8.6 pressures them to remove hard-coded passwords and manage secrets more carefully. In practice, the issue is not just excess privilege. It is entitlement drift that becomes invisible when no one owns the identity end to end.

Practical implication: recertify machine entitlements on the same governance cadence as human access, then prove the review outcome with evidence.

Third-party access monitoring and unusual behaviour

PCI DSS 4.0 also elevates monitoring for third-party access, especially where privileged access and unusual behaviour are involved. That is significant because many NHIs are created for vendor support, integrations, or outsourced operations, then left in place long after the original need changes. Behaviour-based anomaly detection is useful here because NHI misuse often looks normal at the account level until the calling pattern, destination, or timing shifts. The control problem is not only whether the account exists, but whether its activity matches the business relationship that justified it.

Practical implication: correlate third-party NHI activity with contract scope, approval records, and access logs so dormant or misused accounts stand out.

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 4.0 turns NHI governance from an adjacent hygiene issue into a compliance control. The article is right to treat system and application accounts as materially in scope because payment environments fail when machine access is broad, unowned, or poorly evidenced. That is a governance problem, not just a technical one. Practitioners should read the standard as a demand for provable machine-identity control, not only stronger human account security.

Visibility is now the first control, not the last audit step. You cannot prove least privilege or access review for NHIs you cannot enumerate, especially when those identities live outside the IdP or inside deployment tooling. PCI scope expansion makes hidden machine accounts an evidence gap as much as a security gap. The practitioner conclusion is simple: if the identity is not discoverable, it is not governable.

Role assignment and accountability become the real test of compliance maturity. PCI DSS 4.0 assigns responsibilities more explicitly, which exposes a common failure mode in NHI programmes: no single owner for the account, secret, or integration. That is where access reviews stall and remediation lags. The implication is that machine-identity governance must be owned like a control domain, not treated as a side effect of infrastructure management.

Third-party NHI monitoring is a supply-chain control, not just a logging requirement. Once vendor accounts can reach privileged systems, every dormant token or long-lived secret becomes a residual access path. The new standard direction validates what identity teams already see in practice: third-party access is only safe when it is time-bound, reviewable, and tied to an active business relationship. Practitioners should expect auditors to ask who owns the account lifecycle, not just whether logs exist.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• Use NHI Lifecycle Management Guide to align revocation, rotation, and offboarding with payment-scope control evidence.

What this signals

Secret sprawl is now a payment-compliance problem, not just an operational nuisance. When credentials sit in code or CI/CD, PCI evidence becomes dependent on development hygiene as much as security policy. That creates a new expectation for identity teams: prove where secrets live, who can retrieve them, and how quickly they can be revoked across the full delivery chain.

A useful concept here is compliance-visible machine identity: a service account or API key that can be enumerated, owned, reviewed, and retired on demand. If an NHI cannot meet those four tests, it is already outside the practical boundaries of PCI control even before an auditor asks the question.

For teams formalising control design, the next step is to align payment-scope identity governance with the NHI lifecycle model in NHI Lifecycle Management Guide and the broader control logic in the PCI DSS v4.0 library. The programme signal is clear: ownership and revocation are now evidence-producing controls, not back-office tasks.

For practitioners

• Inventory every payment-scope machine identity Build a register of service accounts, API keys, application logins, and certificates that can touch cardholder-data flows, deployment pipelines, or connected third parties. Include owner, business purpose, expiry, and where the secret is stored so auditors can trace the full lifecycle.
• Re-run access reviews for NHI accounts on a fixed cadence Tie machine-identity recertification to the same review calendar used for regulated human access, then require explicit approval for any privilege that cannot be justified by current payment processing needs.
• Eliminate hard-coded secrets from code and delivery tooling Search repositories, config files, and CI/CD systems for embedded credentials, then move them into controlled secret storage with rotation and revocation procedures that are owned by the application team.
• Separate third-party access from standing operational access Assign vendor or integrator accounts only when a live business relationship exists, and pair them with monitoring that flags unusual behaviour against the approved scope of work.

Key takeaways

• PCI DSS 4.0 makes non-human identities part of the compliance boundary, especially where system access touches cardholder-data environments.
• The scale of hidden secret storage and delayed revocation shows why machine-identity governance is an audit issue as much as a security issue.
• Teams that can enumerate, review, and revoke NHI access quickly will be better positioned to satisfy PCI evidence demands and reduce residual access risk.

Key terms

• Non-Human Identity: A non-human identity is a machine or software account used by systems, services, integrations, or automation. In PCI environments, these identities matter because they can authenticate, hold privilege, and move data without a person present. Governance depends on ownership, lifecycle control, and evidence of legitimate use.
• Standing Privilege: Standing privilege is persistent access that remains available without being provisioned for a specific task or time window. For machine identities, it often appears as broad entitlement granted once and never reviewed. In regulated environments, standing privilege increases residual access risk and weakens auditability.
• Secret Sprawl: Secret sprawl is the uncontrolled distribution of credentials across code, configuration files, deployment systems, and other unmanaged locations. It becomes a governance problem when teams cannot tell where a secret exists or how many copies are active. In PCI scope, secret sprawl undermines both rotation and revocation.
• Machine-Identity Lifecycle: Machine-identity lifecycle is the end-to-end management of a non-human identity from creation through review, rotation, and offboarding. Unlike a policy statement, it is a control process that proves who owns the identity, why it exists, and when it should be removed. That lifecycle evidence is essential in compliance settings.

Deepen your knowledge

PCI DSS 4.0 NHI scope, secret handling, and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building payment-scope controls for machine identities, it is worth exploring.

This post draws on content published by Oasis Security: Understanding PCI DSS 4.0: NHIM Essential Guide. Read the original.