By NHI Mgmt Group Editorial TeamPublished 2023-11-10Domain: Governance & RiskSource: 1Kosmos

TL;DR: PCI DSS 4.0 shifts payment security toward continuous validation, stronger authentication, and tighter oversight of vendor and third-party accounts across the cardholder data environment, according to 1Kosmos. For IAM teams, the practical change is that card data protection now depends as much on identity lifecycle and access discipline as on perimeter controls.


At a glance

What this is: This is an analysis of PCI DSS 4.0 and its stronger authentication, monitoring, and access-control expectations for cardholder data environments.

Why it matters: It matters because payment environments expose the same identity governance weaknesses that affect NHI, privileged access, and third-party account control in broader enterprise IAM programmes.

By the numbers:

  • PCI DSS 4.0 was released on March 31, 2022, and the previous version remained active until March 31, 2024.
  • After a maximum of 10 unsuccessful login attempts, users must be locked out for at least 30 minutes or until they verify their identity through the service desk or other means.

👉 Read 1Kosmos’s analysis of PCI DSS 4.0 identity and authentication requirements


Context

PCI DSS 4.0 raises the bar on how organisations authenticate users, monitor access, and treat vendor and third-party accounts in environments that store, process, or transmit cardholder data. The central issue is not just compliance timing. It is whether identity controls are strong enough to reduce fraud, limit misuse, and keep access aligned to business need.

For IAM, PAM, and lifecycle teams, the useful lens is governance rather than payment processing. The standard reinforces patterns that already matter across human identity, NHI, and privileged access programmes: continuous verification, limited standing access, and stronger evidence that access is being used only when needed.


Key questions

Q: How should organisations apply PCI DSS 4.0 to third-party access?

A: Organisations should treat third-party access as a governed identity population with explicit ownership, expiry, and monitoring. Access should exist only for active business need, be reviewed continuously, and be removed when the relationship or task ends. In cardholder data environments, external accounts should never be allowed to drift into permanent standing access.

Q: Why do privileged accounts need stronger controls under PCI DSS 4.0?

A: Privileged accounts can change system state, expand exposure, and bypass ordinary business controls, so PCI DSS 4.0 requires stronger authentication and tighter oversight. In practice, that means enforcing MFA on administrative paths, limiting where privileged access is allowed, and ensuring the session is visible enough to review later.

Q: What breaks when access reviews are only periodic in a PCI environment?

A: Periodic reviews miss access that becomes risky between audit cycles, especially for vendors, administrators, and cloud-based accounts. The result is stale entitlement, hidden privilege creep, and control evidence that does not reflect current reality. PCI DSS 4.0 pushes organisations toward continuous validation because point-in-time approval is not enough.

Q: Who is accountable when a PCI DSS 4.0 access control fails?

A: Accountability usually sits with the control owner, the system owner, and the governance team that approved the access model. In regulated payment environments, teams should be able to show who owns each account type, who reviews it, and who can revoke it. Clear ownership is part of the control, not just an administrative detail.


Technical breakdown

Continuous security processes in PCI DSS 4.0

PCI DSS 4.0 moves away from a static, periodic compliance mindset and places more weight on continuous security processes. That means organisations are expected to maintain controls that are effective in day-to-day operations, not just at audit time. In practice, this changes how teams think about evidence, monitoring, and control durability. Security outcomes matter more than a single implementation pattern, so the same control objective may be met in different ways if the result is provable and sustained.

Practical implication: treat PCI access controls as live governance mechanisms, not annual certification tasks.

MFA, password rules, and privileged access in cardholder data environments

The standard strengthens authentication expectations by requiring MFA for remote access, non-console administrative access, and cloud-based access to the cardholder data environment. It also tightens password rules and account lockout behaviour to reduce brute-force and account takeover risk. The important point is that PCI DSS 4.0 treats privileged access as higher-risk access that needs stronger assurance, not merely stronger passwords. That aligns with broader PAM practice, where the identity, the session, and the activity all need to be controlled.

Practical implication: align privileged access policies with the specific access path, especially for remote and cloud-based administration.

Vendor and third-party account monitoring

PCI DSS 4.0 explicitly calls for vendor and third-party accounts to be used only when needed and continuously monitored for vulnerabilities and security risks. That is a governance statement as much as a security one. Third-party identities tend to outlive the business process that created them, which makes lifecycle oversight and usage review central to the control model. In other words, the standard is pushing organisations to prove that external access remains justified, active only when required, and visible enough to manage.

Practical implication: inventory third-party access, review usage continuously, and remove standing access that no longer has an active business need.


NHI Mgmt Group analysis

PCI DSS 4.0 is really a lifecycle governance standard in disguise. The language may be framed around payment security, but the operational burden falls on who can access card data, when that access is allowed, and how long external accounts remain active. That puts joiner-mover-leaver discipline, privileged session control, and evidence of ongoing need at the centre of compliance. For practitioners, the standard rewards programmes that can prove access is current, not merely authorised once.

Continuous validation matters more than one-time certification. PCI DSS 4.0 reflects a broader shift away from point-in-time attestation and toward sustained control performance. That is especially relevant for teams managing humans, service accounts, and delegated third-party access, because stale access patterns tend to hide between audit cycles. The implication is that identity governance must produce continuous evidence, not just periodic exceptions and remediations.

Vendor and third-party access is now a first-class identity problem. The requirement to use external accounts only when needed and monitor them continuously shows that payment environments no longer tolerate loosely governed delegated access. This is not just about perimeter trust or application security. It is about lifecycle ownership, entitlement scope, and session visibility for identities that sit outside the employee boundary. Practitioners should treat third-party access as a governed identity population, not as a procurement side effect.

Strong authentication controls only work when access scope is equally constrained. MFA, lockout rules, and password complexity reduce some takeover paths, but they do not compensate for excessive privilege or weak account lifecycle discipline. PCI DSS 4.0 implicitly connects authentication strength with entitlement hygiene, especially for privileged and cloud-based access. That means organisations should assess access scope and account persistence alongside authentication design, or they will protect the login while leaving the target surface exposed.

Named concept: continuous cardholder-data access governance. PCI DSS 4.0 is pushing organisations toward a model where access to cardholder data is governed as a living state rather than a static entitlement. That state must be continuously checked, especially for third-party and privileged accounts. For practitioners, the lesson is to align compliance evidence with real-time identity usage instead of relying on snapshot reviews.

From our research:

What this signals

Continuous cardholder-data governance: PCI DSS 4.0 rewards programmes that can prove access is active, justified, and monitored rather than simply approved. That same shift is visible across NHI and privileged access programmes, where lifecycle ownership and usage evidence increasingly matter more than static entitlement records.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, external access is already a governance blind spot. Payment teams should expect the same weak point to surface wherever vendor accounts, delegated access, and cloud identity overlap.

The next planning question is not whether MFA exists, but whether identity governance can continuously prove who has access, why they have it, and when it should end. That makes lifecycle controls, review evidence, and entitlement scope the practical measures that separate compliance theatre from operational control.


For practitioners

  • Map every identity that can reach cardholder data Build an inventory that includes employees, administrators, vendors, service accounts, and cloud-based access paths into the CDE. Separate active business need from inherited access and identify where permissions are broader than the payment function requires.
  • Tighten privileged access by path and use case Apply stronger authentication controls to remote, non-console, and cloud-based administrative access, then review whether the same controls are enforced consistently across all administrative paths. Do not let one access path become the weak exception.
  • Put third-party accounts on a usage clock Require explicit business need for vendor and third-party accounts, review them continuously, and remove access when the work ends. Use ownership and expiry metadata so dormant external accounts do not survive the engagement that justified them.
  • Align lockout and recovery controls with fraud risk Set lockout thresholds, recovery paths, and service-desk verification steps so they resist brute force without creating avoidable help-desk bypasses. Validate those settings for cardholder environments rather than inheriting generic enterprise defaults.

Key takeaways

  • PCI DSS 4.0 turns payment security into an identity governance problem by tightening authentication, access scope, and third-party oversight.
  • The standard’s emphasis on continuous validation means periodic review alone is no longer enough to demonstrate control over cardholder data access.
  • Practitioners should inventory all identities that can reach the CDE, constrain privileged paths, and remove external access as soon as the business need ends.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the technical controls, while PCI DSS v4.0 define the regulatory obligations.

FrameworkControl / ReferenceRelevance
PCI DSS v4.0The article centres on PCI DSS 4.0 authentication and access control changes.
NIST CSF 2.0PR.AC-4Access permissions and least privilege are central to the article’s governance theme.
NIST Zero Trust (SP 800-207)AC-4The article’s continuous verification and access-scope emphasis aligns with zero trust access controls.

Map cardholder-data access and third-party identity controls to PCI DSS 4.0 requirements and validate them continuously.


Key terms

  • Cardholder Data Environment: The cardholder data environment is the set of systems, networks, and processes that store, process, or transmit payment card data. In PCI programmes, it is the boundary that determines where stronger controls, tighter access rules, and clearer evidence of protection must be applied.
  • Third-Party Account: A third-party account is an identity used by a vendor, supplier, or external service provider to access an organisation’s systems. These accounts create governance risk when they outlive the work that justified them, especially if ownership, expiry, and monitoring are unclear.
  • Continuous Validation: Continuous validation is the practice of proving that access and security controls are still effective during normal operations, not just at audit time. For identity teams, it means checking usage, scope, and ownership often enough to catch drift before it becomes exposure.

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.

This post draws on content published by 1Kosmos: PCI DSS 4.0 identity and authentication requirements. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2023-11-10.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org