PCI DSS 4.0 Explained: Key Changes and Security Implications

Key Takeaways

• PCI DSS 4.0 replaces annual check-the-box validation with continuous assurance. Version 3.2.1 was retired on March 31, 2024, and the majority of future-dated PCI DSS 4.0 requirements became mandatory on March 31, 2025.
• Requirement 8.6 is the most operationally significant change for security engineers: it treats application and system accounts as a distinct, explicitly governed identity class for the first time, targeting hardcoded secrets, rotation cadence, and interactive-use controls.
• Non-human identities in the cardholder data environment (CDE) are now a specific audit surface. Every service account, pipeline token, and database credential needs an owner, a purpose, and a documented rotation schedule backed by a risk analysis.
• The customized approach is powerful for mature programs and a trap for teams that cannot produce defensible Targeted Risk Analyses. If the TRA is not a strength, stay on the defined approach until it is.

Quick Answer

What is PCI DSS 4.0 and why does it change how security teams operate?

Most organizations in scope for PCI DSS compliance have run their programs the same way for years: an annual assessment, a Report on Compliance, a list of controls that passed. PCI 4.0 ends that model. The standard now expects continuous assurance, risk-justified control frequencies, and explicit governance of non-human identities that previous versions left in a grey area. The cardholder data environment (CDE) has not changed. What changed is how the standard expects you to prove that it is secure.

What are the biggest changes from PCI DSS 3.2.1 to PCI 4.0?

The six changes with the largest operational impact are Requirement 8.6 (application account governance), authenticated internal scanning (11.3.1.2), client-side script integrity on payment pages (6.4.3 and 11.6.1), Targeted Risk Analysis formalization (12.3.1), cryptographic inventory (12.3.3), and explicit scope documentation (12.5). The shift underneath all of them is the same: the standard moved from listing controls to requiring you to justify, test, and continuously evidence them. Auditors will ask about frequency, trigger events, and evidence freshness. That requires different tooling, different logging cadences, and in many cases a different way of resourcing the security team.

Where each major change lands in practice:

• Identity: Req 8.6 creates the first explicit NHI governance requirement in the standard
• Testing: Req 11.3.1.2 closes the authenticated scanning gap attackers have used for years
• Client-side risk: Req 6.4.3 and 11.6.1 make the payment page a testable, auditable surface
• Evidence: Req 12.3.1 replaces arbitrary control frequencies with documented risk rationale
• Crypto: Req 12.3.3 requires a formal, reviewed inventory of every key, cert, and cipher in scope

PCI DSS 4.0 Requirements: The Key Changes at a Glance

What changed, what it means, and where the work lands for your team.

The Timeline and What v4.0.1 Changed

PCI DSS v4.0 was published in March 2022. Version 3.2.1 was retired on March 31, 2024, which made v4.0 the only active version. The future-dated requirements that teams were relying on as a grace period became mandatory on March 31, 2025. Version 4.0.1, released in June 2024, is an errata update. It corrects formatting, resolves inconsistencies, and clarifies guidance. It does not introduce new control objectives. The authoritative source is the PCI SSC Document Library, and teams should be assessing against v4.0.1 today. Referencing an older version in a QSA conversation will raise questions.

Why the Shift Matters Operationally

The standard now expects you to justify your controls, not just list them. Auditors will ask about frequency, trigger events, and evidence freshness. That implies tooling changes, logging changes, and in many cases a different cadence for the security team. Mappings to NIST CSF and similar frameworks need to be revisited because the control language has moved closer to risk-based governance than point-in-time compliance.

The Customized Approach

The biggest structural addition to PCI DSS 4.0 requirements is the customized approach. Organizations can now meet a requirement by implementing compensating logic as long as they produce a Targeted Risk Analysis, document the objective, and show their QSA that the alternative meets the original intent. This is powerful for mature shops with strong telemetry. It is a trap for teams that cannot produce defensible risk artifacts. If you cannot write a good TRA, stay on the defined approach.

Risk Analysis Now Runs on a Clock

Requirement 12.3.1 formalizes Targeted Risk Analyses for any control where the standard permits the entity to set its own frequency. You must document the asset, the threat, the likelihood, the impact, and the justification for the chosen cadence, then review the analysis at least every 12 months or when conditions change. This closes a long-standing ambiguity where teams picked intervals without rationale. It also means that every PCI DSS compliance program now has a formal risk artifact tied to each flexible control, which auditors can and will request.

Scope Documentation

Requirement 12.5 pushes scope documentation from a best practice to an explicit obligation. You need a current diagram, a data flow inventory, and a mapping of all system components that store, process, or transmit account data, plus connected systems. Review this at least annually and after significant change. Teams mapping to NIST SP 800-53 will find this aligns cleanly with the CM and PM control families.

Cryptographic Inventory

Requirement 12.3.3 requires an inventory of trusted keys and certificates along with the cipher suites in use, reviewed at least every 12 months. This is often the first time an organization has to produce a single source of truth for its cryptographic estate. Expect surprises. Most enterprises discover expired certs, unknown CAs, and deprecated suites that have been quietly accepted by legacy systems for years. Machine identities in the CDE often present certificates as part of mutual TLS flows and belong in this inventory.

Scanning and Testing Requirements Now Have Teeth

The testing requirements were tightened to close gaps that attackers have been using for a decade. The changes hit both internal scanning and public-facing application protection.

Authenticated Internal Scanning

Requirement 11.3.1.2 mandates authenticated vulnerability scanning for internal systems. Unauthenticated scans miss patch-level issues, misconfigured services, and vulnerable libraries inside running processes. Authenticated scans expose that attack surface. The operational lift is real: you need credentialed access, vault integration, and a scanner identity that itself must be governed. Follow the OWASP Secrets Management Cheat Sheet on storing and rotating those scanner credentials. The scanner is a service account in scope for Requirement 8.6.

Public-Facing Applications and Client-Side Scripts

Requirement 6.4.3 and Requirement 11.6.1 target client-side script integrity on payment pages. You must inventory every script loaded on the payment page, justify its presence, ensure its integrity, and detect unauthorized changes. This requirement was written in direct response to years of Magecart-style skimming, which the Verizon DBIR has documented repeatedly. Subresource integrity, tamper detection, and a content security policy are the baseline. If a third-party tag can inject code at runtime, you own that risk.

Authentication Requirements: What PCI 4.0 Demands Now

Passwords and MFA

Requirement 8.3.6 sets a minimum password length of 12 characters for user accounts with access to the CDE. Requirement 8 expands MFA coverage and raises the bar on resistance to phishing and replay. Treat phishing-resistant MFA as the default target, not the stretch goal. The Zero Trust guidance in NIST SP 800-207 is a useful reference for designing the identity layer around least privilege and continuous verification.

Requirement 8.6 and Application Accounts

Requirement 8.6 is the section security engineers should memorize. It targets application and system accounts specifically. Credentials for these non-human identities must be protected, must not be hardcoded, must be changed on a defined frequency backed by a risk analysis, and interactive use must be controlled. This is where PCI 4.0 meets operational reality. Most breaches that escalate do so through valid accounts, and MITRE ATT&CK T1078 has been the top initial access and persistence technique for years. The payment security standard is finally catching up to how attackers actually move.

Non-Human Identity Hygiene in the Cardholder Data Environment

Requirement 8.6 is the entry point into PCI DSS 4.0 requirements for NHIs, but the implications run wider. The CDE is full of service accounts, pipeline tokens, cloud roles, database logins, and secrets embedded in deploy artifacts. Each one is an identity. Each one has permissions. Each one can be phished, leaked, or reused in ways that annual PCI validation has historically missed.

Inventory Before Controls

You cannot govern what you cannot see. Start with a continuous inventory of every NHI that touches the CDE. That includes IAM roles, Kubernetes service accounts, CI/CD tokens, API keys, database accounts, and secrets in vaults. Tie each identity to an owner, a purpose, and an expected behavior profile. The CIS Controls inventory disciplines map here cleanly.

Intent and Permission

Most NHIs are overprivileged because they were provisioned under deadline pressure. PCI 4.0 expects you to justify the scope of each account. That means right-sizing permissions to actual intent, flagging drift, and retiring stale credentials automatically. Privilege escalation paths from low-value service accounts to CDE systems are a common QSA finding, and the privilege escalation tactic in ATT&CK is a reliable guide to where adversaries look first. Least privilege principle applied to NHIs means tying permissions to declared purpose, not to historical accumulation.

Rotation and Lifecycle

Requirement 8.6.3 ties credential change frequency to a documented risk analysis. In practice that means token rotation on a defined schedule for long-lived secrets, short-lived credentials where feasible, and decommissioning workflows that actually run. Orphaned credentials are the PCI equivalent of back doors left open. The NHI lifecycle must cover creation, modification, and retirement, not just provisioning.

How Token Security Approaches PCI DSS Compliance for NHIs

The Challenge

Requirement 8.6 is the first time a major payment security standard has explicitly required governance for machine identities in the CDE. But the tooling most teams use for PCI DSS compliance was built for human identity governance: IAM and PAM platforms with approval workflows, directory integrations, and quarterly access reviews. None of that scales to the service accounts, pipeline tokens, and cloud roles that make up the bulk of the modern CDE. The annual Report on Compliance has historically captured this gap as a finding rather than closing it.

The Approach

Token Security gives security teams continuous discovery and contextual intelligence for every non-human identity that touches the CDE, across cloud, identity providers, secret vaults, CI/CD, Kubernetes, and AI systems. The platform maps each NHI to its owner, its intent, and the data it can reach, then flags drift, stale credentials, overprivilege, and policy violations that map directly to Requirement 8.6 and adjacent controls. The system is agentless and feeds evidence that QSAs and internal auditors can consume without a manual spreadsheet exercise.

Discover, Understand, and Enforce applied to PCI DSS 4.0 requirements:

• Discover: continuous NHI inventory across the CDE and all connected systems, covering Requirement 12.5 scope obligations automatically
• Understand: entitlement mapping, blast-radius analysis, and behavioral baselines per identity, producing the evidence artifacts 8.6 and 12.3.1 require
• Enforce: automated remediation, rotation workflows, and decommissioning that closes the lifecycle gap 8.6.3 defines

The Outcome

Token does not replace your vault or your IdP. It provides the identity lifecycle management layer that PCI 4.0 assumes you already have, and produces the evidence artifacts that make a QSA conversation straightforward rather than adversarial.

How Security Teams Are Operationalizing PCI 4.0 NHI Requirements

Getting Control of Secrets and API Keys Across a Complex Environment

Requirement 8.6 creates a specific governance obligation for every secret, API key, and credential in the CDE. For most organizations, that starts with a visibility problem: the secrets exist in multiple vaults, CI systems, cloud environments, and developer tooling, and there is no single inventory. GEHA's security team faced this directly. The operational goal was not just to find credentials but to reduce the overhead of managing them at scale while actually detecting new risks as they appeared.

"We've been using Token Security for the past few months, and it has significantly streamlined how we manage and secure our secrets, API keys, and other NHIs. The platform's visibility and discovery capabilities have helped us detect new and hidden risks while reducing operational overhead. With simple integration and quick time to value, Token Security has been a game-changer for our security operations!" — Eric Ullmann, Director of Information Security at GEHA

The GEHA situation is the Requirement 8.6 problem stated plainly. You cannot document the rotation cadence for credentials you have not inventoried. You cannot justify permissions for accounts you do not know exist. Visibility across secrets sprawl is the prerequisite for every 8.6 control, not a bonus capability.

Turning Compliance Obligations into Operational Accountability

PCI DSS 4.0 requirements create accountability obligations that teams have historically struggled to operationalize: who owns this account, what is it supposed to do, who gets paged when it misbehaves. The readiness program described in this article depends on translating those obligations from compliance language into operational workflows. Klaviyo's security leadership identified this translation problem directly.

"Token Security addresses a critical issue faced by companies — the growing threat introduced by non-human identities. Our experience shows that teams need non-human identity accountability, automated remediation, and actionable insights to manage these risks, and Token Security excels in meeting this demand." — Brian Kerr, Vice President of Security and Trust at Klaviyo

Accountability (named owner per NHI), automated remediation (rotation and decommissioning without a manual ticket queue), and actionable insights (specific findings the team can act on rather than a dashboard of counts) are exactly what Requirement 8.6.1 through 8.6.3 require. The PCI 4.0 language maps directly to operational needs teams like Klaviyo are already feeling.

Building a PCI DSS 4.0 Readiness Program

A PCI DSS compliance readiness program for PCI 4.0 is not a one-quarter project. It is a reset of how the security team handles identity, scanning, and evidence.

Phase 1: Inventory and Scope

Refresh scope documentation under Requirement 12.5. Build or update the cryptographic inventory for 12.3.3. Produce a full NHI inventory covering the CDE and all connected systems. Align the effort to the NIST Risk Management Framework so the artifacts serve more than one audit program.

Phase 2: Control Uplift

• Stand up authenticated scanning under 11.3.1.2, with properly governed scanner credentials
• Implement client-side script integrity controls on payment pages
• Roll out phishing-resistant MFA and enforce the 12-character minimum
• Close Requirement 8.6 gaps: hardcoded secrets removal, rotation schedules, owner assignment, interactive-use controls
• Write Targeted Risk Analyses for every control where PCI 4.0 lets you choose the frequency

Phase 3: Evidence and Continuous Assurance

Move from point-in-time reports to continuous evidence. Telemetry from scanners, IdPs, vaults, and NHI governance should feed a central control inventory that a QSA can query. Cross-reference that inventory to NIST CSF and 800-53 to avoid duplicate evidence collection across SOC 2, HITRUST, and sector audits. Use breach cost data from the IBM Cost of a Data Breach Report to set internal priorities on the controls that actually reduce blast radius.

Why PCI 4.0 Is Ultimately a Bet on Identity as the Control Plane

PCI 4.0 is a push toward continuous, evidence-backed security operations, with a clear emphasis on identity, testing rigor, and client-side risk. Among modern payment security standards, this version is the most specific about non-human identity governance the industry has ever produced.

The customized approach rewards mature teams and punishes improvisation. Requirement 8.6 finally treats application and system accounts as first-class identities. Client-side script controls make the payment page a testable surface, not a black box. Authenticated scanning closes a blind spot that has existed for years. The teams that win with PCI 4.0 will be the ones that stop treating compliance as an annual exercise and start treating identity as the control plane.