TL;DR: Teleport argues that PCI DSS 4.0 shifts assessments toward evidence that links access, ownership, remediation, and closure across Requirements 7, 8, and 10, so teams must prove that least privilege, account lifecycle control, and log review are operating in the environment, not just documented on paper. For practitioners, the real test is whether infrastructure identity records can survive assessor scrutiny as living control evidence.
At a glance
What this is: This is a PCI DSS 4.0 evidence-focused analysis of infrastructure identity and access, showing that assessors now expect traceable proof across access grants, reviews, logging, and remediation.
Why it matters: It matters because IAM, IGA, PAM, and infrastructure teams must be able to prove that human and non-human access is controlled, reviewed, and revoked with defensible records.
👉 Read Teleport's analysis of PCI DSS 4.0 evidence for infrastructure identity
Context
PCI DSS 4.0 is less forgiving of undocumented control operation than earlier versions. For infrastructure identity, that means assessors want evidence that access, review, logging, and remediation are tied together across servers, databases, Kubernetes, and cloud IAM, not just written into a policy.
The governance gap is not whether least privilege or account reviews exist in theory. The gap is whether the organisation can produce proof that a specific access event, review, or privilege change was owned, acted on, and closed within the in-scope environment.
That shifts the burden from security intent to auditable execution. It also widens the spotlight on service accounts and other non-human identities, because their privileges often persist outside the normal human review rhythm.
Key questions
Q: What breaks when infrastructure access reviews do not produce revocation evidence?
A: The review stops being a control and becomes a worksheet. If the assessor cannot see who reviewed the access, what was changed, and where that change took effect, the organisation has no defensible proof that the review reduced risk.
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 should teams prove automated log review for PCI DSS 4.0?
A: They should show the log source, the automated review mechanism, the alert or exception it generated, and the ticket or resolution that followed. Logging alone is not enough. The evidence must show that monitored events were actually reviewed and acted on.
Q: What should security teams do when access is granted but not clearly owned?
A: Treat ownership as part of the control, not an administrative nice-to-have. Assign a named owner, confirm the business justification, and require that every retained privilege can be traced back to an approval and a review record.
Technical breakdown
How PCI DSS 4.0 turns access control into evidence
PCI DSS 4.0 pushes access control beyond policy statements and into demonstrable records. For infrastructure, that means IAM roles, RBAC assignments, account provisioning tickets, and privilege change records have to show not only what access exists, but why it exists and who approved it. Assessors look for the chain from role assignment to review outcome. If the control exists but the evidence does not, the control fails the assessment even if the environment is technically hardened. The practical shift is from describing access governance to proving it through system-generated artefacts.
Practical implication: Keep access grants, role changes, and approval records aligned so the evidence chain survives assessment.
Why periodic access reviews are weaker without remediation proof
A periodic access review is only useful if it leads to a change when access is no longer justified. PCI DSS 4.0 raises the bar by expecting the review record, the revocation or privilege change, and the resulting state in the target system to line up. That is especially important for application and system accounts, where privileges can linger after role changes or operational drift. The technical problem is not reviewing access in isolation, but showing that review output modified the live permission set. Without that linkage, a review becomes a paper exercise rather than control evidence.
Practical implication: Verify that every review finding maps to a real permission change in IAM, Kubernetes RBAC, or database grants.
How automated log review supports requirement 10 evidence
Requirement 10.4.1.1 expects automated mechanisms to review audit logs, not just store them. In infrastructure environments, this includes authentication events, privilege elevation, administrative actions, and access to cardholder data systems. The evidence value comes from the full loop: log capture, alerting or detection, ticketing, analyst review, and resolution. If the review identifies an exception but no follow-up exists, the log trail shows activity but not control. For PCI assessments, that distinction matters because monitoring is only credible when it produces traceable action.
Practical implication: Preserve alert history, tickets, and closure records alongside the logs that triggered them.
NHI Mgmt Group analysis
PCI DSS 4.0 is now an evidence standard as much as a control standard. The article's central message is that access control only counts when the organisation can prove ownership, review, and closure. That matters because assessors are no longer satisfied by control intent alone; they want an auditable trail that connects access decisions to operational outcomes. Practitioners should treat every access pathway as a record-keeping problem as well as a security problem.
Infrastructure identity governance is being pulled into the same evidentiary model as human IAM. The article makes clear that roles, reviews, revocation, and logging now have to align across users, service accounts, Kubernetes bindings, and database permissions. That is a useful correction: non-human accounts are not a separate governance category, only a different lifecycle expression of the same access control discipline. Practitioners should unify review evidence across human and non-human access paths.
Service account governance is the most fragile part of the PCI evidence chain. The article notes that application and system accounts can keep privileges after workload or dependency changes, and that they often sit outside the rhythm of user-access reviews. That creates a durable evidence gap, not just a technical one, because the organisation may be unable to show why the account still needs its privileges. Practitioners should surface service accounts into the same accountability model as privileged human access.
Documented remediation is the missing control plane in many PCI findings. The article repeatedly returns to the gap between identifying an issue and showing what happened next. That is the real governance weakness: findings without closure create a control story that is incomplete, even when the technical issue is understood. Practitioners should make remediation evidence part of the control itself, not a postscript to the audit.
From our research library:
- Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey.
- Read next: NHI Lifecycle Management Guide
What this signals
PCI evidence is increasingly about traceability, not just restriction. Teams that can show access, review, and remediation as one continuous record will have a much easier path through assessment than teams that rely on policy language alone. The practical shift is to treat the audit trail as part of the control design, not a by-product of it.
Service account oversight deserves human-grade governance. Non-human access can persist across role changes, workload changes, and dependency changes long after the original justification has faded. That means lifecycle review for service accounts should sit inside the same accountability model as privileged user access, with evidence that proves what changed and when.
For practitioners
- Trace one access event end to end Start with a recent infrastructure access event in scope, then collect the approval, the privilege record, the log entry, and the follow-up action that proves ownership and closure.
- Pair every access review with live permission validation Compare a periodic access review against current IAM roles, Kubernetes RBAC bindings, or database grants so revocations and changes are visible in the target system.
- Bring service accounts into the same review cadence Inventory application and system accounts, document why each one exists, and verify that role changes or system changes trigger a fresh review of its privileges.
- Retain remediation evidence with monitoring output Store alerts, tickets, analyst notes, and closure records beside the log events that triggered them so audit review can follow the entire detection-to-resolution chain.
Key takeaways
- PCI DSS 4.0 makes infrastructure identity evidence central to assessment, especially where access, review, logging, and remediation must be tied together.
- The article highlights that service accounts and over-privileged RBAC are common weak points because access can persist after the original justification no longer applies.
- Teams should be able to trace a finding from detection to ownership to closure, or the control will look incomplete under audit scrutiny.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, and PCI DSS v4.0 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centers on excessive infrastructure access and scoped privileges. |
| NHI-01 — Improper Offboarding | It stresses revocation and lifecycle closure when access changes or ends. | |
| NHI-07 — Long-Lived Secrets | Service-account access that persists after changes behaves like long-lived credential exposure. | |
| Recommendation — Review NHI roles and service accounts for excess privilege and remove permissions that exceed business need. Revoke NHI access on role change or termination and verify the live permission state matches the record. Shorten credential lifetimes for infrastructure accounts and force revalidation at each lifecycle change. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle and revocation underpin the access evidence discussed here. |
| Recommendation — Apply IA-5 to govern issuance, review, and revocation of infrastructure authenticators and service credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | PCI evidence in the article maps directly to entitlement control and review. |
| Recommendation — Use PR.AA-05 to validate that permissions are approved, reviewed, and removed when no longer required. | ||
| PCI DSS v4.0 | 7.2.4 — User Account Reviews | The article explicitly discusses the six-month review cadence for user accounts. |
| 8.6 — Interactive Login-Capable Service Accounts | Service-account governance is a central example in the article's PCI evidence discussion. | |
| 10.4.1.1 — Automated Log Review | Automated log review is called out as a key evidence requirement in the article. | |
| Recommendation — Perform documented user account reviews at least every six months and retain the evidence of changes made. Inventory interactive service accounts and document justification, ownership, and traceable use. Use automated review of audit logs and preserve alert, ticket, and closure evidence for assessment. | ||
Key terms
- Infrastructure Identity: Infrastructure identity is the set of credentials and trust relationships that allow systems, workloads, and automation to authenticate to other systems. It is the machine-facing layer of identity governance, and it often carries more operational risk than human access because it is persistent and widely reused.
- Access review evidence: Access review evidence is the record that shows an entitlement was examined, assessed, and either retained or removed for a reason. Strong evidence includes the reviewer, the date, the decision, and any remediation path, which is what makes governance auditable rather than assumed.
- 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.
- Audit Log Event: An audit log event is a recorded action that shows what happened in a system, who or what caused it, when it occurred, and whether it succeeded or failed. It is a structured security record used for traceability, investigation, compliance evidence, and detection of suspicious behavior across users, services, devices, and automated agents.
What's in the full article
Teleport's full article covers the operational detail this post intentionally leaves for the source:
- Requirement-by-requirement evidence examples for access controls, account management, and logging
- Concrete artefacts to prepare, including IAM and RBAC configurations, tickets, audit logs, and sign-offs
- Assessment-oriented examples of how reviewers connect access events to responsibility and closure
- Audit-readiness guidance for tracing remediation from detection through documented completion
👉 Teleport's full post shows the access-review, logging, and remediation evidence assessors expect.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 22, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org