PCI DSS 4.0 and NHI access control: what teams must rework

At a glance

What this is: This is a step-by-step PCI DSS checklist that maps the 12 requirements to cardholder-data protection and access control.

Why it matters: It matters to IAM and NHI practitioners because PCI environments expose the same access, logging, and lifecycle gaps that make non-human identities hard to govern.

By the numbers:

• The 12 requirements are organized into six broader goals and have more than 300 sub-requirements.

👉 Read StrongDM's PCI DSS compliance checklist and step-by-step requirements

Context

PCI DSS is a control framework for protecting cardholder data, but it also reveals where access governance breaks down under real operational pressure. In practice, the hardest problems are not limited to payment systems themselves. They include unique identity assignment, privileged access review, logging, credential rotation, and policy enforcement across both human and non-human identities.

For IAM and NHI teams, this is familiar territory. Service accounts, application accounts, and automation credentials often sit inside payment-adjacent workflows, which means PCI controls become a test of whether lifecycle management is actually enforced or only documented. That starting position is typical for organisations that have grown around application access first and governance second.

Key questions

Q: How should security teams govern non-human identities in PCI environments?

A: Treat every service account, token, and certificate as a governed identity with an owner, a business purpose, and an expiry. Apply least privilege, require rotation, and log all use centrally. PCI compliance is easier to prove when machine credentials are managed with the same discipline as human access.

Q: When does static credential management become a PCI risk?

A: Static credentials become a PCI risk as soon as they can reach cardholder data or supporting systems and are not regularly rotated. At that point, they create standing access that is hard to audit and harder to revoke. A credential that never changes is a weak control, even if it is documented.

Q: What is the difference between PCI access control and NHI governance?

A: PCI access control defines what the environment must prove for compliance, while NHI governance defines how machine identities are owned, restricted, rotated, and retired. In practice, PCI is the requirement and NHI governance is the operating model that makes the requirement sustainable across automation-heavy systems.

Q: Why do automation credentials create more audit risk than human logins?

A: Automation credentials create more audit risk because they often act silently, run continuously, and touch many systems without a clear human session boundary. If logs do not tie each action to a specific machine identity and privilege level, investigators lose the evidence needed to prove scope, intent, and containment.

Technical breakdown

Why PCI access control requirements map directly to NHI governance

PCI DSS Requirement 7 and Requirement 8 are fundamentally identity controls. Requirement 7 limits access by business need, while Requirement 8 requires unique identity and authentication for each user. In modern environments, those controls must extend beyond employees to service accounts, API clients, batch jobs, and automated workflows. If a non-human identity can read cardholder data, change a configuration, or trigger a transaction, it is part of the compliance boundary whether or not it has a human owner. The technical failure mode is shared entitlement reuse: one credential is copied across systems and never retired. Practical implication: model every machine credential as a governed identity with an owner, purpose, and expiry.

Practical implication: model every machine credential as a governed identity with an owner, purpose, and expiry.

How logging and monitoring expose hidden non-human identity risk

PCI Requirement 10 exists so teams can reconstruct who accessed what, when, and from where. That becomes much harder when actions are performed by scripts, integrations, or service accounts that do not behave like interactive users. Logs must capture identity, privilege context, and the specific resource touched, otherwise the organisation cannot distinguish legitimate automation from abuse. For NHI governance, this means access telemetry is not optional evidence. It is the only way to prove that a token, certificate, or service account stayed within its intended scope. Practical implication: tie every machine identity to centralized logging and alert on privilege drift, not just failed logins.

Practical implication: tie every machine identity to centralized logging and alert on privilege drift, not just failed logins.

Why rotation and lifecycle controls matter more than static compliance

PCI guidance on passwords, defaults, and authentication assumes credentials change over time and that stale access can be removed. That assumption is often violated in NHI environments, where tokens are long-lived, certificates are renewed inconsistently, and service accounts survive application changes. The result is standing access that outlives the system it was created for. Lifecycle controls matter because compliance evidence ages quickly when credentials are copied into pipelines, containers, and config files. Practical implication: automate provisioning, rotation, and retirement for every non-human identity, then verify that decommissioned systems cannot still authenticate.

Practical implication: automate provisioning, rotation, and retirement for every non-human identity, then verify that decommissioned systems cannot still authenticate.

Threat narrative

Attacker objective: The attacker aims to reach cardholder data or payment-adjacent systems with a credential that looks legitimate enough to evade basic detection.

1. Entry occurs when attackers obtain a reusable credential, such as a default password, copied secret, or exposed service account tied to a payment workflow.
2. Escalation follows when that identity has broader access than its job requires, allowing the attacker to move from one system to cardholder-data infrastructure or adjacent admin functions.
3. Impact comes when the attacker can read, alter, or exfiltrate payment data while blending into normal automation because the identity was never uniquely governed.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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 is now an identity-governance problem as much as a payment-security problem. The checklist is often treated as a compliance artifact, but its strongest controls are about access, auditability, and lifecycle discipline. That matters because NHI populations usually expand faster than governance processes. Practitioners should treat PCI scope as a forcing function for machine identity inventory and control ownership.

Non-human identities create the quietest PCI failures. Service accounts and automation tokens rarely appear in manual review workflows, yet they often sit on the shortest path to cardholder data. When access reviews focus only on employees, the environment can look compliant while machine credentials remain over-privileged. The practitioner conclusion is simple: PCI evidence must include machine identities, not just people.

Credential rotation is the real control behind many of PCI DSS' password rules. A static secret that is never rotated is operationally equivalent to standing privilege, even if it is wrapped in policy language. That is why lifecycle discipline matters more than one-time hardening. Teams should assess whether their NHI rotation process can be audited, enforced, and tied to decommissioning.

Identity blast radius is the right way to think about payment-environment risk. Once a service account can touch multiple systems, the compliance boundary is no longer a single application. The security question becomes how far one credential can travel before it is detected or revoked. Practitioners should shrink the blast radius of every non-human identity before they rely on annual attestations.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, including 38% with no or low visibility and 47% with only partial visibility.
• For a broader control framework, review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs alongside PCI access review requirements.

What this signals

Identity scope is the first programme decision, not the last audit finding. If PCI controls are mapped only to human users, the machine-identity layer will keep producing exceptions that never fit the checklist cleanly. Teams should expect the governance model to shift from account review to workload and credential lifecycle management, with Ultimate Guide to NHIs , Key Challenges and Risks as the right reference point.

The security baseline for payment environments is moving toward continuous visibility, not annual documentation. With two-thirds of enterprises having endured a successful cyberattack resulting from compromised non-human identities, the control question becomes whether the organisation can spot machine access before it becomes a payment incident.

Identity blast radius: the smaller the reachable set of systems for each machine credential, the easier PCI evidence becomes to defend. Teams that align NIST Cybersecurity Framework 2.0 with NHI lifecycle discipline will have a cleaner path from policy to audit trail.

For practitioners

• Implement machine identity inventory for PCI scope Catalog every service account, API key, token, and certificate that can touch cardholder data or supporting systems. Assign an owner, system of record, and expiration date for each identity so review cycles are based on evidence rather than tribal knowledge.
• Apply least privilege to application and service accounts Review entitlements for automation identities and remove broad database, shell, and admin access that is not required for the specific workload. Use role separation so a payment workflow cannot reuse the same credential across staging, production, and backup systems.
• Automate rotation for long-lived secrets Set rotation intervals for tokens, keys, and certificates that match their operational risk, then validate that dependent systems can tolerate the change. Include break-glass procedures so rotation does not become a manual exception path.
• Centralize logging for non-human identity activity Record authentication events, privilege changes, and resource access for every machine identity in a searchable platform. Correlate those events with application context so investigators can separate expected automation from suspicious reuse or privilege drift.

Key takeaways

• PCI DSS is not only about payment data protection, it is also a test of whether access governance works for machine identities.
• Service accounts, tokens, and certificates can create compliance gaps that human-focused reviews never see.
• Organizations that automate NHI ownership, rotation, and logging will find PCI evidence easier to produce and harder to dispute.

Key terms

• Non-Human Identity: A non-human identity is any credentialed entity that acts on behalf of software rather than a person. That includes service accounts, API keys, tokens, certificates, and AI agents. These identities need ownership, scope, rotation, and revocation controls because they can access systems without human presence.
• Standing Privilege: Standing privilege is persistent access that remains available even when a task is complete. In NHI environments it often appears as long-lived keys, over-permissioned service accounts, or certificates that outlast their original use case. It increases blast radius because compromise does not need a fresh approval path.
• Credential Rotation: Credential rotation is the planned replacement of secrets, tokens, keys, or certificates before they become stale or exposed. For non-human identities, rotation must be automated and validated against dependent systems. Otherwise, the organisation keeps the old trust path alive even after the credential should have been retired.
• Identity Blast Radius: Identity blast radius is the amount of damage a single credential can cause if it is misused or stolen. It is shaped by privilege scope, system reach, and how quickly the credential can be detected and revoked. Smaller blast radius means faster containment and cleaner audit evidence.

Deepen your knowledge

PCI access control, identity review, and credential lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are adapting PCI workflows to include service accounts and automation credentials, it is worth exploring.

This post draws on content published by StrongDM: PCI Compliance Checklist: The 12 Requirements (Step-by-Step). Read the original.