PCI DSS 4.0 became mandatory in March 2025. If you are running payment workloads on Kubernetes, you need to demonstrate compliance across a set of controls that were not designed with containers in mind. Here is what actually matters in a Kubernetes environment.
What Changed in PCI DSS 4.0
The customised approach now allows organisations to propose alternative controls that meet the intent of each requirement, which is useful for container-native implementations. MFA requirements expanded to cover all access to the CDE, including service accounts in some interpretations. Each requirement now needs a documented targeted risk analysis rather than blanket application. New software security requirements are relevant for teams building payment services. Authenticated scanning is now required and scan frequency has tightened.
Scoping Your Kubernetes Environment
PCI DSS scope in Kubernetes is the hardest part. Namespaces that store, process, or transmit cardholder data are clearly in scope. Any namespace with network connectivity to the CDE is also in scope unless isolated by compensating controls. The cluster control plane must be treated as in-scope since a compromised control plane can access CDE workloads. If CDE and non-CDE pods share nodes, those nodes are in scope, which is why dedicated node pools for CDE workloads are strongly recommended.
Network Segmentation (Requirement 1)
Default-deny NetworkPolicy on all CDE namespaces is essential — no ingress or egress unless explicitly allowed. Every allowed network flow must be documented since your QSA will ask for this. mTLS between CDE services, provided natively by Istio or Cilium, satisfies the encryption in transit requirement. NodePort and HostNetwork must not be used for CDE pods since they bypass network policies.
Access Control (Requirements 7 and 8)
No cluster-admin for application service accounts — minimum RBAC permissions only. MFA must be enforced for all kubectl access to in-scope clusters via your IdP. All API server access must be audited by enabling Kubernetes audit logging to an immutable sink. All credentials including service account tokens and image pull secrets must rotate on a defined schedule. Long-lived kubeconfig files should be replaced with short-lived tokens via OIDC.
Vulnerability Management (Requirement 6)
All container images must be scanned before deployment using Trivy or Grype in the CI pipeline. Trivy Operator in-cluster provides continuous scanning of running workloads. No Critical CVEs should reach production — enforce this with an admission webhook or CI gate. Using distroless or scratch base images minimises the OS-level attack surface. Regular penetration testing of the CDE is required at least annually or after significant changes.
Logging and Monitoring (Requirement 10)
Kubernetes audit logs must capture all API server requests and be stored in a tamper-evident log system. All payment transactions must be logged with sufficient detail. Log retention requires 12 months minimum with 3 months immediately available. Alerting must detect and report on suspicious activity including failed authentication attempts and privilege escalation. Falco provides runtime threat detection with syscall-level visibility into container behaviour.
Conclusion
PCI DSS 4.0 on Kubernetes is achievable, but it requires deliberate architecture decisions from the start. The teams that struggle are those who scoped Kubernetes as an afterthought. Scope carefully, isolate aggressively, and automate your evidence collection.