Authentication is the mechanism by which the access control model defined in Requirement 7 is enforced. Without strong authentication, access rights on paper mean nothing — an attacker who can impersonate a legitimate user bypasses all logical access controls. Requirement 8 mandates strong authentication for every human and non-human identity that accesses CDE systems.
Unique User IDs — The Foundation
Every user with access to CDE systems must have a unique individual user ID. Shared accounts are prohibited — even shared service accounts used by multiple individuals. The unique ID requirement ensures that all activity in the CDE can be attributed to a specific individual, which is essential for accountability, audit trails, and incident investigation.
| KEY IDEA | The prohibition on shared accounts is absolute in PCI DSS. A shared "admin" account used by multiple administrators, a shared service account credentials stored in a team spreadsheet, or a shared monitoring login all violate Requirement 8. Every human user must have their own uniquely identified account with their own credentials. |
Multi-Factor Authentication — The v4.0 Expansion
MFA requirements in v4.0 were significantly expanded from v3.2.1. The three contexts where MFA is now mandatory:
| Access Context | MFA Required | Notes |
|---|---|---|
| All remote network access from outside the CDE | Yes — required since v3.2.1 | VPN, remote desktop, SSH from external networks |
| All non-console administrative access to CDE systems | Yes — expanded in v4.0 | SSH, RDP, and any admin access not through a local console, even from internal network |
| All user access into the CDE | Yes — new in v4.0 | Any access to CDE systems, regardless of whether admin or general user, requires MFA |
| IMPORTANT | The v4.0 expansion of MFA to all CDE access (not just remote access) is the most impactful authentication change in the standard's history. An organization that previously required MFA only for VPN access now must require MFA for every login to every CDE system — from any location. This has significant infrastructure implications for organizations using on-premise CDE environments. |
What Constitutes Valid MFA
MFA requires authentication using two or more different authentication factors from these categories: something you know (password, PIN), something you have (authentication token, smart card, mobile authenticator app), something you are (biometric — fingerprint, facial recognition). TOTP (time-based one-time password) via an authenticator app is widely accepted. SMS OTP is acceptable but less preferred due to SIM-swap vulnerabilities.
Password Policy Requirements
Minimum password requirements under v4.0:
- Minimum length of 12 characters (increased from 7 in v3.2.1)
- At least one upper case and one lower case letter
- At least one number
- At least one special character
- Maximum age — passwords must be changed at least every 90 days (or justify a longer period via Targeted Risk Analysis)
- Password history — prevent reuse of the last 4 passwords
- Account lockout after maximum 10 failed attempts
- Lockout duration at least 30 minutes (or until unlocked by administrator)
Service Account and Non-Human Identity Management
Service accounts — accounts used by applications, automated processes, and systems — are a common security weakness. PCI DSS v4.0 explicitly addresses them. Service accounts must: have unique IDs (not shared), have passwords that meet policy requirements, have access limited to what the service function requires, and be inventoried and reviewed periodically.
| Service accounts are among the hardest authentication controls to manage in practice. Application teams often create service accounts during deployment and never revisit them. Default credentials, overly broad permissions, and credentials embedded in configuration files are all common service account failures in PCI DSS assessments. |
Application and System Accounts in the CDE
For application-level access (APIs, database connections, system integrations), the authentication requirements parallel human user requirements. API keys and service credentials must be protected, rotated regularly, not embedded in code, and managed through a secrets management system.
| Indonesian fintech organizations often use microservices architectures where service-to-service authentication uses API keys or tokens. PCI DSS v4.0 applies the same authentication rigor to these machine identities as to human users. Implementing a secrets management solution (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager) is increasingly the recommended approach for managing CDE service credentials. |