Account and authentication security

The PCI DSS 4.0 account and authentication security requirement means every person and system accessing cardholder data environment (CDE) systems must have a uniquely managed identity and strong authentication, with controls that prevent shared access, weak logins, and unmanaged accounts. To operationalize it quickly, inventory all in-scope accounts, enforce strong authentication (including MFA where required by your standard), and prove it with access governance evidence.

Key takeaways:

• Scope first: map “in-scope systems” and enumerate every human and non-human account touching them.
• Control the lifecycle: provisioning, changes, reviews, and deprovisioning must be standardized and evidenced.
• Audits are evidence-driven: assessors will ask for system configs, access lists, and proof your process runs consistently.

“Account and authentication security” is one of the fastest ways to fail a PCI assessment because gaps hide in plain sight: shared admin logins, stale vendor accounts, service accounts with interactive access, and identity controls that exist in policy but not in system configuration. The PCI DSS 4.0 requirement statement is short, but the operational surface area is large because it touches every in-scope system: operating systems, databases, hypervisors, network devices, applications, and the identity providers that front them.

For a Compliance Officer, CCO, or GRC lead, the job is to translate this into two things you can defend: (1) a repeatable control system that governs identities and authentication for CDE access, and (2) evidence that those controls operate over time, not just on assessment day. This page gives requirement-level implementation guidance you can hand to IAM, IT, and Security Operations, plus the artifacts you should collect for assessor questions. All references to the requirement align to the PCI DSS v4.0 source in the PCI SSC Document Library ¹.

Regulatory text

Excerpt (PCI-02): “Secure user identities and authentication for in-scope systems.” ¹

Plain-English interpretation

You must control who can access in-scope systems and make that access defensible. Practically, that means:

• Every access path ties back to a known identity (no anonymous access; no shared accounts for humans).
• Authentication is strong enough for the risk of the environment (especially administrative and remote access).
• Account creation, changes, and removal follow a defined process, and you can prove it happened.
• Access is limited to what people and systems need, and you re-check that periodically.

This is an assessor-friendly framing: “Can you show who has access, how they authenticate, and how you prevent and remove inappropriate access?” ¹

Who it applies to (entity and operational context)

Entities

• Merchants that store, process, or transmit payment card data. ¹
• Service providers that manage systems or services that touch cardholder data or connect into the CDE. ¹

Operational context (what is “in-scope”)

“In-scope systems” includes systems in the CDE and anything that can impact the security of the CDE, based on your PCI scoping decisions. Your identity controls must cover, at minimum:

• Workforce user accounts (employees, contractors, temporary staff).
• Privileged administrators (domain admins, system admins, DBAs, cloud admins).
• Third-party access paths (support portals, VPN, bastions, remote management tools).
• Non-human identities (service accounts, application identities, API keys) where they provide access into in-scope systems.

What you actually need to do (step-by-step)

1) Lock down scope and “systems of record”

1. Confirm your CDE scope diagram and in-scope system inventory are current.
2. Identify your identity “control points”: IdP (for example, SSO), directory, PAM tool, VPN, bastion hosts, and local OS authentication.
3. Decide the system of record for each account type (HR system for joiner/mover/leaver, ITSM for approvals, IdP for authentication enforcement).

Operator tip: If you cannot name the system of record for approvals and termination actions, you will struggle to produce evidence during assessment.

2) Enumerate all accounts with access to in-scope systems

Build an account inventory that answers: who/what is this account, where is it used, how is it authenticated, and who approves it?

• Pull lists from: IdP, directory, local server accounts, databases, network devices, cloud IAM, and application admin consoles.
• Tag each account: human vs non-human, privileged vs standard, interactive vs non-interactive, owner, last used, access method.
• Identify and remediate: shared human accounts, orphaned accounts, default accounts, and accounts without a clear owner.

3) Enforce strong authentication and remove weak paths

Implement enforcement at the control points, not just at the application layer. Minimum operational moves that are typically expected under “secure identities and authentication”:

• Require strong authentication for administrative access and remote access into in-scope systems ¹.
• Centralize authentication where possible (SSO/IdP) so policy is consistent and logs are consolidated.
• Disable direct authentication paths that bypass your controls (examples: local accounts used for routine admin work, app-level admin users outside SSO, vendor “break-glass” accounts left active).

Practical examples to standardize:

• Admins authenticate through a hardened path (VPN + bastion + MFA, or PAM broker).
• Service accounts cannot be used interactively and cannot log in via remote desktop or SSH unless documented and approved.
• Break-glass accounts exist, but they are tightly controlled (named owners, stored credentials, monitored use, periodic validation).

4) Put account lifecycle under change control (joiner/mover/leaver)

You need a workflow that produces evidence. Build it around:

• Provisioning: request, approval, creation, and assignment to groups/roles aligned to job function.
• Changes: group/role changes require ticketing and approval; privileged access requires higher scrutiny.
• Deprovisioning: terminate access promptly upon role change or exit, including third-party accounts.
• Exceptions: documented compensating controls for legacy systems that can’t meet your standard; track remediation.

Make it operational: Write a short standard operating procedure (SOP) that tells IT exactly what records must exist for each lifecycle event.

5) Implement periodic access reviews that actually find problems

Assessors look for proof that you detect and remove inappropriate access. For in-scope systems:

• Review privileged access separately from standard access.
• Include third-party accounts explicitly (support vendors are a common blind spot).
• Reconcile “effective access,” not just group membership. If a user is nested into multiple groups, you need to see the final permissions picture.
• Track findings to closure with tickets.

6) Log authentication and keep evidence accessible

Account and authentication security is not only prevention; it is also accountability.

• Ensure authentication events for in-scope systems are logged and attributable to unique identities.
• Ensure logs cover central identity systems (IdP/directory), privileged access tools, and remote access gateways.
• Make logs searchable for common assessor samples: specific user, timeframe, privileged event, and access to a named in-scope system.

Required evidence and artifacts to retain

Use this as an “assessment-ready packet” list. Keep it in a single control folder (GRC system or evidence repository).

Governance artifacts

• Account management policy/standard for in-scope systems ¹.
• IAM/PAM standard for privileged access and third-party access ¹.
• CDE scope diagram and in-scope system inventory.

Operating evidence (what assessors sample)

• Exported account lists for representative in-scope systems (directory groups, local admins, DB roles, cloud IAM roles).
• MFA and authentication policy configuration screenshots/exports from IdP/VPN/PAM.
• Joiner/mover/leaver tickets showing approvals and completion evidence.
• Access review records (attestations), including findings and closure tickets.
• Break-glass account register and access logs for use events.
• Third-party access register (who, purpose, method, approval, expiration).

Common exam/audit questions and hangups

Questions you should be ready for

• “Show me all accounts with administrative access to this in-scope system, and how you know they are authorized.”
• “How do you prevent shared accounts for administrators?”
• “How is third-party access granted, time-bounded, and removed?”
• “Demonstrate MFA enforcement for remote administrative access into the CDE.” ¹
• “Pick three terminated users: prove their access was removed from all in-scope systems.”

Hangups that slow assessments

• No single source of truth for privileged access; admins exist in local accounts, cloud IAM, and app consoles with inconsistent governance.
• Inconsistent scoping: the IAM team enforces controls for corporate apps, but the CDE has exceptions that were never tracked.
• Evidence mismatch: policy says one thing; configs show weaker settings; tickets are missing approvals.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Fix that works in practice
Shared admin accounts for “operations convenience”	No accountability; weak audit trail	Issue named admin accounts; require elevation through PAM or controlled groups
Third-party accounts left enabled after project end	Persistent unauthorized access path	Create third-party access with expiration; review monthly; disable on end date
Service accounts used interactively	Hard to attribute actions; credentials sprawl	Make service accounts non-interactive; document owners; rotate secrets via vault
Relying on policy without config proof	Assessors test systems, not intent	Export IdP/VPN/PAM policies; keep dated screenshots and configuration baselines
Access reviews performed but not reconciled	“Checkbox” reviews miss effective access	Review effective permissions and close findings with tickets

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific cases. Operationally, account and authentication failures tend to drive high-impact incidents because they turn one compromised credential into broad CDE access. Your assessment risk is also straightforward: if you cannot produce access lists, enforcement configurations, and lifecycle evidence on demand, assessors typically record control failures. ¹

A practical 30/60/90-day execution plan

First 30 days: establish scope, inventory, and quick wins

• Confirm in-scope systems list and access paths (VPN, bastion, IdP, local logins).
• Produce an initial account inventory for: privileged users, third-party users, and service accounts.
• Remove obvious high-risk items: shared human admin accounts, orphaned accounts, unowned third-party accounts.
• Capture baseline evidence: current auth policies, MFA enforcement points, and sample access lists.

Days 31–60: standardize lifecycle and privileged access controls

• Implement or tighten privileged access workflow: approvals, group-based access, separation of duties where applicable.
• Standardize joiner/mover/leaver tickets and required fields (system, role, approver, start/end date).
• Formalize third-party access process: request, justification, expiration, monitoring, and removal.
• Create a break-glass procedure and register; require approvals and logging for use events.

Days 61–90: operationalize reviews and audit-ready reporting

• Launch recurring access reviews for privileged access and third-party access to in-scope systems.
• Add reconciliation steps: compare HR roster to directory; compare directory privileged groups to system-level admins.
• Build an assessor packet: one folder with policies, configurations, exports, and completed tickets.
• If you use Daydream, map the requirement to owners, define evidence requests, and track review cadence so you can answer assessor samples quickly without last-minute scrambles.

Frequently Asked Questions

Do we have to use a central identity provider (SSO) to meet the account and authentication security requirement?

PCI DSS 4.0 doesn’t require a specific technology in the excerpt provided, but you must secure identities and authentication for in-scope systems ¹. Centralizing identity often makes enforcement and evidence collection easier.

How should we handle service accounts that need access to in-scope systems?

Treat service accounts as non-human identities with named owners, documented purpose, and controlled authentication. Prevent interactive use and manage credentials with a vault or equivalent secret-management process you can evidence.

Are third-party (vendor) accounts in scope?

Yes if the third party can access in-scope systems. You need documented authorization, a controlled access method, and a clear offboarding process tied to end dates or contract changes ¹.

What evidence is most likely to be sampled by an assessor?

Expect requests for access lists, MFA/authentication policy configurations, joiner/mover/leaver tickets, and access review records tied to specific in-scope systems ¹. Keep exports and screenshots dated and attributable.

We have legacy systems that can’t enforce our preferred authentication controls. What do we do?

Document the exception, define compensating controls (restricted network path, jump host, monitoring, reduced privileges), and track a remediation plan. The critical point is to show you still secure identity and authentication for that in-scope system ¹.

How do we prove accounts are unique and not shared?

Use named user accounts for humans, prohibit shared IDs in policy, and show system configuration and account exports where usernames map to individuals. For unavoidable shared functional accounts, document why they exist and wrap them with compensating controls and monitoring.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control management

Footnotes

1. PCI DSS v4.0