Access control and authentication implementation transforms the access governance framework of Requirements 7 and 8 into operational controls. This requires both technical implementation (IAM systems, MFA infrastructure, PAM tools) and process implementation (provisioning workflows, access reviews, offboarding procedures). Getting both right is essential — the best technical controls fail if the surrounding process allows unauthorized access to accumulate.
Role-Based Access Control Implementation
Defining CDE Roles
Start by documenting all job functions that require access to CDE systems or cardholder data. For each role, define: the specific systems the role needs access to (database, application server, firewall, monitoring system, etc.), the access level required (read, read/write, administrative), the business justification (why does this role need this access?), and the approving manager (who is responsible for this role?). This role catalog becomes the foundation for all access provisioning and all access reviews.
Common CDE roles include: Database Administrators (full access to production payment database), Network Engineers (access to firewall and network monitoring), System Administrators (access to OS configuration and patch management), Application Developers (access to application code, CI/CD pipelines, and staging databases), Security Team (access to security logs, monitoring systems, and incident response tools), and Auditors (read-only access to logs and configurations for audit purposes).
Access Provisioning Workflow
Implement a formal provisioning workflow: access request submitted (specifying role, systems, business justification, duration if temporary), manager approval (confirming the request is legitimate and the requestor has job responsibility for CDE access), security team review (confirming that request aligns with least-privilege model — the requestor should only have access to systems they actually need), provisioning by IT (implementing the access in the IAM system, adding the user to the appropriate groups, modifying firewall rules if necessary), and notification to user (confirming access is active). All steps must be documented — the ticket or approval record is the evidence for QSAs.
The entire workflow should be tracked in a change management system or ticketing system. Approval records should be digitally signed or at least timestamped and attributed to the approver. When the QSA asks "show me how you ensure only appropriate people get access to the payment database," you produce the access provisioning workflow documentation.
| Provisioning Step | Responsible Party | Documentation Required | QSA Evidence |
|---|---|---|---|
| Access request | Requestor | Ticket or form with role, systems, justification | Request record with timestamp |
| Manager approval | Requestor's manager | Signed approval in ticket/form | Approval record with approver ID and date |
| Security review | Security team | Confirmation that request aligns with least-privilege model | Review record |
| Provisioning | IT/IAM admin | Confirmation of access provisioned | Provisioning ticket, IAM audit log |
| User notification | IT/IAM admin | Email or notification to user | Email record or notification log |
MFA Implementation — Meeting v4.0 Requirements
MFA for All CDE Access
Under PCI DSS v4.0, every login to every CDE system requires MFA (multi-factor authentication). This means: all SSH connections to CDE servers must require MFA, all RDP connections to CDE Windows systems must require MFA, all web application logins for CDE systems must require MFA, all console access to CDE infrastructure (cloud provider management console, physical server console) must require MFA, and all VPN access to the CDE must require MFA. The only exception is direct physical console access to a system in a locked, guarded data center — even that may require MFA depending on the specific control interpretation.
MFA implementation requires identifying all access paths into the CDE, implementing MFA on each one, and then testing to ensure that no access paths bypass MFA. Common mistakes include implementing MFA for user login to a VPN but not for automated scripts that connect to the VPN, or implementing MFA for remote access but not for local console access to servers in the data center.
Selecting an MFA Solution
Common MFA implementations for CDE environments: Microsoft Azure AD MFA or Entra ID (supporting TOTP, FIDO2, Microsoft Authenticator app, phone call), Google Workspace MFA (TOTP, FIDO2), Duo Security (popular for its Privileged Access Management integration capabilities and detailed audit logs), RADIUS-based MFA (for network device and VPN access), and hardware tokens (YubiKey with FIDO2 — for highest-assurance environments where employees are provided with a physical device).
For most organizations, cloud-based MFA services (Azure AD, Google Workspace) integrated with identity provider systems are the most practical. For highly sensitive systems (payment processing, fraud detection), organizations sometimes deploy hardware tokens to ensure users cannot be socially engineered into bypassing MFA.
| KEY IDEA | The most common MFA implementation gap in PCI DSS v4.0 assessments is incomplete coverage. Organizations that implement MFA for VPN access but not for direct server access, or for external access but not for jump server to CDE server connections, still fail the MFA requirements. Every access path into the CDE must be enumerated and MFA applied to each one. This is often more extensive than organizations expect. |
Privileged Access Management (PAM)
Administrative and privileged access to CDE systems requires the most stringent controls. Implement a PAM solution (CyberArk, BeyondTrust, HashiCorp Boundary, AWS Systems Manager Session Manager, Google Cloud IAM Conditional Access) that: requires justification for each privileged session (why is the admin accessing this system now?), records all privileged sessions (video recording of the session, command logging showing every command executed), manages privileged credentials in a vault (just-in-time access — the admin does not have a permanent password, instead they request access for a session and the PAM system generates temporary credentials), and generates alerts for anomalous privileged activity (access from unusual locations or times, access to unusual files or databases).
PAM is particularly important for database administrator and network administrator access. A privileged user with unrestricted access to the production payment database could extract all cardholder data in minutes. With PAM in place, the database administrator can do their job, but every action is logged and can be reviewed or even prevented based on policy rules.
Service Account Management
Service accounts are system-to-system accounts — credentials used by applications, scheduled jobs, or integration processes to connect to other systems. A payment application that connects to the payment database uses a service account. A backup process that connects to backup servers uses a service account. Service accounts are often overlooked in access control discussions, but they are critical for security.
Create an inventory of all service accounts in the CDE. For each service account: document the function it performs (what is this account used for?), the access rights required (which databases/servers does it connect to, what operations does it perform?), the system(s) that use the account, the team responsible for the account, and the credential rotation schedule.
Automate credential rotation where possible using a secrets management solution (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, CyberArk). Automated rotation reduces the risk that credentials are shared, written down, or leaked. For systems that do not support automated rotation, establish a manual rotation process with quarterly rotation cycles and documented evidence of each rotation.
Access Review Implementation
Quarterly access reviews for CDE systems are a PCI DSS requirement. The review process: generate the current user access list from the IAM system (export a report of all users and their access to all CDE systems), distribute to responsible managers for review (ask them to confirm that each person still has job responsibility for CDE access), managers confirm each user's access is still appropriate (they sign off on the access list), inappropriate access is removed within a defined timeframe (users who left or changed roles have access revoked), and the review is documented with manager signatures and completion dates (the approval records are evidence).
Access reviews must be comprehensive. If a user left the company six months ago but their access was never revoked, that is a failed access review control. The review process should include not just active users, but confirmation that terminated users have been removed from the access list.
| IMPORTANT | Access reviews are one of the most commonly failed recurring controls in PCI DSS programs. The failure mode is usually not malicious — it is that the review process is cumbersome (manual spreadsheets, email chains requiring all managers to respond), so managers approve without actually reviewing, or reviews are delayed past the quarterly deadline. Invest in tooling that makes access reviews fast and easy — the easier the review, the more accurate it will be. |
Offboarding and Access Revocation
All access for departed personnel must be revoked on or before their last working day. For CDE systems, immediate revocation (on the day of departure) is the expectation. Implement an HR-IT integration that automatically triggers access revocation when a termination is processed in the HR system.
The offboarding process should include: last working day is documented, access to all CDE systems is suspended/revoked on that day, equipment (laptop, tokens, access cards) is recovered, and the employee no longer has any ability to access CDE systems. Some organizations disable accounts immediately, others disable on the last day — either approach is acceptable as long as the access is actually revoked before the employee leaves.
For employees changing roles within the company, access should be modified on the transition date. The employee should not retain access to their former role's systems while also gaining access to their new role's systems. This is sometimes overlooked when employees are promoted or move to different teams.
| Indonesian organizations with high staff turnover — particularly fintech companies with large engineering teams and competitive labor markets — face ongoing access revocation challenges. We recommend automating the offboarding trigger from the HR system to the IAM system, with automatic account suspension on the termination date, followed by manual review of access removal within 24 hours. Manual review catches edge cases (contractors who need extended access, employees working notice periods who still need some access) while ensuring that the default is immediate revocation. |
Evidence Package for Requirements 7 and 8
QSAs testing Requirements 7 and 8 require: role catalog (documenting all CDE roles and their access levels), access provisioning documentation (showing access requests, approvals, and provisioning records), current access lists (report of all users with CDE access), access review documentation (quarterly reviews with manager approval), MFA configuration documentation (systems protected with MFA, MFA solution deployment), MFA testing results (evidence that MFA is actually required), PAM configuration and logs (recording of privileged sessions), service account inventory (list of all service accounts, their purposes, and their access rights), service account credential rotation evidence (logs or tickets showing rotation activities), and offboarding procedures (documented process for revoking access when employees leave).
The most compelling evidence is actual audit logs from the IAM system showing access grants, removals, and reviews. Screenshots of the MFA system configuration showing MFA is required for all CDE access are essential. Actual provisioning tickets from the past year showing the full workflow (request, approval, provisioning, notification) are better evidence than generic policy documents.