PCI DSS 4.0 raises the bar for infrastructure identity evidence

At a glance

What this is: This article explains how PCI DSS 4.0 changes the evidence standard for infrastructure identity and access, especially for least privilege, account lifecycle management, and logging.

Why it matters: It matters because IAM, PAM, and infrastructure teams must be able to prove who had access, why it existed, and what changed after review or remediation.

By the numbers:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Teleport's analysis of PCI DSS 4.0 infrastructure identity evidence

Context

PCI DSS 4.0 is not only about what access exists. It is about whether organisations can produce defensible evidence that access was granted, reviewed, and revoked for the right reasons across human users, service accounts, and infrastructure workloads. In practice, that pushes identity from a configuration concern into an audit and accountability problem.

For infrastructure teams, the gap is often not the control itself but the proof trail around it. IAM and RBAC settings, access-review records, account lifecycle tickets, and log-review evidence now need to line up cleanly enough for assessors to trace ownership and follow-through across the cardholder data environment.

Key questions

Q: What breaks when PCI DSS 4.0 access evidence is incomplete?

A: The control itself may still exist, but the assessor cannot verify ownership, review, or remediation. That turns a working security process into an audit finding because access, action, and closure cannot be tied together across the evidence trail.

Q: Why do service accounts create PCI DSS 4.0 evidence gaps?

A: Service accounts often sit outside the review cadence used for human users, so their privileges persist without a clear lifecycle record. Under PCI DSS 4.0, that makes it hard to prove why access still exists and who approved it.

Q: How do organisations know whether access reviews are working?

A: Access reviews are working when they lead to timely removals, reduced exception volume, and role definitions that stop accumulating unused rights. If the same accounts keep reappearing with the same excess access, the review process is only producing paperwork. Evidence of change is the real success signal.

Q: What is the difference between logging access and proving accountability?

A: Logging shows that an event happened. Accountability requires a linked record showing who reviewed the event, what decision was made, and what action followed. PCI DSS 4.0 cares about both, because telemetry without follow-through does not demonstrate control.

Technical breakdown

How PCI DSS 4.0 turns access into evidence

PCI DSS 4.0 expects access to be both controlled and demonstrable. That means roles, grants, approvals, and lifecycle changes must be captured in artifacts that can be sampled and verified, not inferred from intent. In infrastructure environments, assessors look for IAM and RBAC configurations, account provisioning records, revocation tickets, and logging evidence that show who had access, why it existed, and what changed after review. The standard is less about whether a control exists in theory and more about whether it produces records that survive audit scrutiny.

Practical implication: treat identity evidence as an auditable system output, not a manual afterthought.

Why service account governance is now part of PCI evidence

Service and system accounts are a common blind spot because they do not sit naturally inside human access review workflows. PCI DSS 4.0 explicitly raises the bar for how these accounts are identified, justified, and reviewed, especially where interactive login is possible or privileges persist across changing workloads. When workloads shift but permissions do not, the evidence trail becomes weak even if the technical access still functions. The problem is not just privilege excess, but the inability to show that every permission still matches an active operational need.

Practical implication: maintain ownership and justification records for non-human accounts alongside their live permissions.

How automated log review supports assessor confidence

Audit logs only become strong evidence when they are tied to review and response. PCI DSS 4.0 expects automated review mechanisms for relevant security events, but assessors also want to see the follow-through: alerts, tickets, incidents, approvals, or remediation records. This closes the loop between detection and accountability. A log that shows privilege elevation is useful; a log plus an investigation record and a documented resolution is what demonstrates control maturity. In other words, telemetry alone is not evidence unless it can be connected to ownership and action.

Practical implication: pair automated log review with ticketing or incident records that prove a human decision followed.

Threat narrative

Attacker objective: The objective is to exploit unmanaged or over-scoped infrastructure access to reach sensitive systems without a defensible evidence trail.

1. Entry begins when excessive or stale infrastructure access exists without a current ownership record, review trail, or revocation trigger.
2. Escalation follows when over-privileged accounts, especially service accounts or admin roles, can reach production systems beyond their intended scope.
3. Impact occurs when assessors or attackers alike can no longer distinguish authorised access from forgotten access, weakening both audit posture and breach containment.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

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 is forcing identity teams to become evidence teams. The standard no longer rewards organisations for having access controls in place if they cannot prove who reviewed them, why they remained, and what changed after exceptions were found. That shifts identity governance from configuration management to defensible accountability, especially in infrastructure environments where access is distributed across cloud, cluster, and database layers. Practitioners need to treat the evidence chain as part of the control, not a report generated after the fact.

Non-human account governance is now a PCI evidence problem, not just an NHI hygiene problem. Service accounts and system accounts often sit outside human-centric review rhythms, yet PCI DSS 4.0 expects the same discipline around approval, scope, and lifecycle change. That is a familiar NHI governance failure mode: access persists because no one owns the review cadence. The implication is that infrastructure teams need lifecycle records that can survive audit sampling, not just working permissions.

Access without closure is the control gap PCI DSS 4.0 exposes most clearly. The article is right to focus on ownership after a finding is identified, because unresolved access issues are where documentation and practice diverge. A documented review that does not produce revocation, privilege change, or management sign-off is effectively incomplete. The practitioner takeaway is that remediation evidence has to be captured with the same discipline as the access itself.

PCI 4.0 validates a broader identity pattern: least privilege only matters if it is provable over time. This is where the category is heading across human IAM, NHI governance, and infrastructure access. Organisations that cannot show current role scope, account ownership, and log review will keep failing at the same seam between policy and operational proof. The field is moving toward continuous evidence, not point-in-time permission snapshots.

From our research:

• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time, 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 mirrors the lifecycle evidence gaps PCI assessors often surface.
• The governance pattern extends beyond PCI. See NHI Lifecycle Management Guide for the lifecycle controls that make access evidence defensible.

What this signals

Access evidence is becoming a lifecycle problem, not a single-control problem. PCI DSS 4.0 pushes teams to prove that permissions were granted, reviewed, and removed on schedule. For programmes that still separate human IAM, NHI governance, and infrastructure audit evidence, that siloing will increasingly show up as inconsistent proof rather than a clear control failure.

With 97% of NHIs carrying excessive privileges, the gap between what infrastructure teams think is approved and what actually exists in live systems is often larger than the paperwork suggests. That is why evidence collection has to include current permissions, lifecycle records, and review outcomes, not just policy statements.

Teams that are already aligning access reviews to current state will find PCI 4.0 easier to operationalise than teams that treat evidence as a quarterly scramble. The next maturity step is continuous reconciliation between entitlement data, logging, and closure records, with clear ownership across cloud, cluster, and database access.

For practitioners

• Document access as an evidence chain Capture the full path from grant to review to remediation for in-scope infrastructure access, including approvals, tickets, and closure records that an assessor can sample.
• Separate service account ownership from human review cadence Assign named ownership to every service and system account, then retain justification and lifecycle records that show why each permission still exists.
• Tie log review to documented follow-up Pair automated review of privilege elevation, administrative action, and denied access events with incident tickets or remediation records that prove action followed detection.
• Reconcile live permissions against periodic reviews Compare access-review outputs with current IAM, RBAC, Kubernetes, and database permissions so revoked or changed access is actually reflected in the environment.

Key takeaways

• PCI DSS 4.0 shifts identity from a permission problem to an evidence problem, which changes how access controls are assessed.
• Service accounts and other non-human identities are a recurring weak point because their lifecycle and ownership records are often incomplete.
• The strongest PCI posture pairs least privilege with documented review, revocation, and closure evidence that survives assessor sampling.

Key terms

• Access Evidence Trail: The access evidence trail is the set of records that proves who had access, why it was granted, who reviewed it, and what changed after review. In PCI DSS 4.0, the trail matters as much as the control because assessors need proof, not assumptions.
• Service Account Governance: The set of policies and operational controls used to manage non-human accounts across their full lifecycle. It covers provisioning, access scope, rotation, revocation, and review, with the goal of preventing long-lived credentials from becoming persistent paths into critical systems.
• Lifecycle Evidence: The operational proof that identity events such as provision, review, rotation, and revocation actually happened. For NHIs and AI-linked credentials, lifecycle evidence matters because a control cannot be trusted if the system cannot show who changed what, when, and why.
• Automated Log Review: Automated log review is the use of tooling to detect access anomalies, privilege changes, and security events without relying on ad hoc manual inspection. The control only becomes defensible when the alert, investigation, and response records are retained together.

What's in the full article

Teleport's full article covers the operational detail this post intentionally leaves for the source:

• The specific artifact sets assessors expect for Requirements 7, 8, and 10 across cloud, Kubernetes, and database environments.
• Examples of access-review records, remediation tickets, and audit logs that can support a PCI DSS evidence trail.
• The checklist for tracing one access exception from detection through closure in a production environment.
• Practical examples of service account, SSH, and RBAC evidence that can withstand audit sampling.

👉 Teleport's full post covers the access-review, logging, and remediation evidence patterns in more operational detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 NHI governance in your organisation, it is worth exploring.