Topic starter
22/09/2026 3:43 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Teleport: “What PCI DSS 4.0 Requires for Infrastructure Identity and Access Evidence”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: PCI DSS 4.0 makes infrastructure identity evidence central to assessment, especially where access, review, logging, and remediation must be tied together.
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
👉 Read Teleport's analysis of PCI DSS 4.0 evidence for infrastructure identity →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
22/09/2026 3:43 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: PCI DSS 4.0 raises the bar for infrastructure identity evidence
This post was modified 5 days ago by NHI Mgmt Group