Requirements 7 and 8 form the access control foundation of PCI DSS. Requirement 7 governs who can access what (authorization). Requirement 8 governs how you prove someone is who they claim to be (authentication). Together, they determine whether your cardholder data environment has appropriate boundaries around sensitive data.
PCI DSS v4.0 made significant changes to both requirements. The MFA mandate expanded from remote access only to all CDE access. Password length requirements increased from 7 to 12 characters. Service account management got its own dedicated requirements. These changes reflect real-world attack patterns we see in every Active Directory penetration test.
Requirement 7: Restrict Access by Business Need to Know
Requirement 7 mandates a formal access control model based on least privilege. Access to system components and cardholder data must be limited to individuals whose job function requires it, with a default deny-all policy.
What your access control system must include
- Documented access control policy defining how access rights are granted, modified, and revoked based on job function
- Role-based access control (RBAC) or equivalent model that maps job functions to required access levels
- Default deny-all configuration where all access is blocked unless explicitly granted
- Access reviews at least every six months (Requirement 7.2.5) to verify that access rights remain appropriate
- Written approval by authorized personnel for all access grants, with specific privileges documented
Common failure: Many organizations implement RBAC but define roles too broadly. A "developer" role that grants access to production cardholder data, staging environments, CI/CD pipelines, and administrative interfaces does not satisfy least privilege. Roles must be granular enough that each person only accesses what their specific function requires.
Requirement 8: Identify Users and Authenticate Access
v3.2.1 vs v4.0 changes
| Control | v3.2.1 | v4.0 |
|---|---|---|
| Password length | Minimum 7 characters | Minimum 12 characters |
| MFA scope | Remote network access only | All access into the CDE |
| Password rotation | Every 90 days required | Every 90 days OR dynamic analysis approach |
| Service accounts | General requirements | Dedicated requirements for service accounts and application accounts (8.6) |
| Account lockout | Lock after 6 attempts for 30 minutes | Lock after 10 attempts for 30 minutes or until admin unlock |
| Session timeout | 15 minutes of inactivity | 15 minutes of inactivity (unchanged) |
MFA for All CDE Access
Requirement 8.4.2 is the most impactful change in v4.0 for many organizations. MFA is now required for all access into the CDE, not just remote access. This means internal employees sitting in the office must use MFA when accessing CDE systems.
The MFA implementation must use at least two of the three authentication factors: something you know (password), something you have (token, smart card, phone), or something you are (biometric). The factors must be independent; compromising one factor should not compromise another. SMS-based OTP is still technically allowed but is considered weak.
MFA exceptions that assessors scrutinize
- Service accounts and automated processes are not required to use MFA, but must be secured per Requirement 8.6
- Application-to-application communication using certificates or API keys does not require MFA
- Console access to systems in physically secured data centers may have alternative controls, but this requires documentation and assessor agreement
Service Account Management
PCI DSS v4.0 added Requirement 8.6 specifically for application and service accounts. These accounts are frequently the weakest link in access control. They often have broad privileges, never-rotated passwords, and no individual accountability.
- Service accounts must be assigned to only the applications or services that require them
- Interactive login capability must be disabled unless specifically needed for a documented business reason
- If interactive login is permitted, it must be managed with the same controls as user accounts (MFA, session management, accountability)
- Passwords for service accounts must be changed periodically based on risk assessment, and must be sufficiently complex
Common Access Control Failures
- Shared accounts. Multiple administrators using the same root or admin account. PCI DSS requires unique IDs for every user. Shared accounts eliminate individual accountability and make Requirement 10 logging meaningless
- Stale access. Former employees or role-changed employees retaining access to CDE systems. The six-month access review requirement exists specifically to catch this
- Over-privileged service accounts. Database service accounts with DBA-level permissions when they only need SELECT access to specific tables. Application service accounts with write access to directories they only need to read
- Weak MFA implementation. MFA configured only at the VPN level, not at the individual system level within the CDE. If an attacker bypasses the VPN through lateral movement, they have unauthenticated access to CDE systems
Need access control testing for PCI DSS?
Our penetration tests validate access controls in your CDE by testing authentication bypass, privilege escalation, and lateral movement. Reports are structured for QSA review.
