Take the lead in data protection best practices with our unified SIEM solution!
Disclaimer: This guide has been created with reference to official documents on the PCI DSS published by relevant government authorities. It is intended to provide a clear and comprehensive explanation of PCI DSS Requirement 8. The contents are for informational purposes only and should not be considered as legal advice. Organizations should consult with a qualified PCI DSS consultant to ensure compliance.
Requirement 8: Identify users and authenticate access to system components
This PCI DSS requirement is further divided into requirements 8.1, 8.2, 8.3, 8.4, 8.5 and 8.6. Let's explore these in detail.
PCI DSS Requirement 8.1: Processes and mechanisms for identifying users and authenticating access to system components are defined and understood.
This PCI DSS requirement is further divided into requirements 8.1.1, and 8.1.2. Let's dive deep into these.
PCI DSS Requirement 8.1.1 Manage security policies and procedures for user access
This requirement focuses on the effective management of security policies and operational procedures related to user access controls, as outlined in PCI DSS Requirement 8. It mandates that all such policies and procedures be:
- Documented: Clearly defined and documented in a written format.
- Kept up-to-date: Regularly reviewed and updated to reflect changes in your environment, threats, and regulations.
- In use: Actively implemented and enforced within your organization.
- Communicated: Made readily available and communicated to all affected personnel who need to be aware of these policies and procedures.
Definitions:
- Security policies: High-level documents that define your organization's overall security objectives and principles related to user access control.
- Operational procedures: Detailed instructions that describe how to perform specific activities related to user access control. These procedures should specify the controls, methods, and processes to be followed to achieve consistent and secure user access management.
Business implication:
- Reduced risk of data breaches: Effectively managing user access controls through documented, up-to-date, and enforced policies and procedures significantly reduces the risk of unauthorized access to sensitive CHD. This helps safeguard your business from potential financial losses, reputational damage, and regulatory penalties associated with data breaches.
Best practices to meet this requirement:
- Develop a documentation framework: Establish a system for documenting security policies and operational procedures related to user access control.
- Version control and updates: implement a version control system for your documentation to track changes and ensure everyone is using the latest version. update policies and procedures promptly to reflect changes in your environment or regulations.
- Communication and training: Communicate these policies and procedures to all affected personnel through training programs or readily accessible documentation repositories.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.1.1 | Examine documented security policies and operational procedures related to user access control (as outlined in Requirement 8).Interview relevant personnel to understand how these policies and procedures are used in practice. | The assessor will review the documented security policies and operational procedures to ensure they address all aspects of user access control as defined in Requirement 8.The assessor will also interview relevant personnel (e.g., IT security staff, department managers) to verify that these policies and procedures are actively used, understood, and enforced within the organization. |
PCI DSS Requirement 8.1.2: Define roles and responsibilities for user access controls
This requirement emphasizes the importance of clearly defining and assigning roles and responsibilities for implementing the user access control activities outlined in PCI DSS Requirement 8. It mandates that:
- Documented roles and responsibilities: A clear and documented description of the roles and responsibilities associated with each user access control activity within requirement 8 exists.
- Assigned responsibilities: These roles and responsibilities are effectively assigned to specific personnel within your organization.
- Understanding and accountability: The assigned personnel understand their roles and responsibilities, and are held accountable for their successful execution.
Definitions:
- Roles: Defined functions or duties assigned to individuals within your organization.
- Responsibilities: The specific tasks and activities associated with each assigned role.
Business implication:
- Reduced risk of data breaches: Clearly defined and assigned roles and responsibilities for user access control activities ensure that critical tasks are not overlooked or performed incorrectly. This helps minimize the risk of unauthorized access to sensitive CHD and potential data breaches.
Best practices to meet this requirement:
- Develop a RACI matrix: Consider using a responsibility assignment matrix to document roles and responsibilities. A RACI matrix defines who is responsible, accountable, consulted, and informed for each user access control activity.
- Role-based access control (RBAC): Implement an RBAC system that assigns access permissions based on predefined roles within your organization. This simplifies role assignment and clarifies responsibilities.
- Communication and training: Communicate these roles and responsibilities to all assigned personnel through training programs or readily accessible documentation.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.1.2.a | Examine documentation related to user access control activities (policies, procedures, RACI matrix).Verify the documentation describes roles and responsibilities for each activity outlined in Requirement 8. | The assessor will review the documented policies, procedures, or dedicated documents (e.g., RACI matrix) to ensure they clearly define the roles and responsibilities assigned to personnel for each user access control activity as defined in Requirement 8. |
| 8.1.2.b | Interview personnel assigned user access control responsibilities.Verify their understanding of their assigned roles and how they fulfill those responsibilities. | The assessor will interview personnel responsible for user access control activities. This may include IT security staff, department managers, or individuals responsible for user provisioning/deprovisioning. The assessor will verify their understanding of their assigned roles and responsibilities as documented, and how they perform the associated tasks. |
PCI DSS Requirement 8.2: User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle
This PCI DSS requirement is further divided into requirements 8.2.1, 8.2.2, 8.2.3, 8.2.4, 8.2.5, 8.2.6, 8.2.7 and 8.1.2. Let's dive deep into these.
PCI DSS Requirement 8.2.1: Assign Unique User IDs for Access
This core requirement mandates that all users within your organization who require access to system components or cardholder data (CHD) must be assigned a unique user ID. This unique identifier plays a crucial role in user accountability and audit trail integrity.
Definitions:
- Unique user ID: A distinct identifier assigned to each individual user that allows for clear attribution of actions performed within the system. Examples include usernames, employee IDs, or other unique identifiers.
Business implication:
- Enhanced accountability and security: Assigning unique user IDs allows you to track user activity within your systems. This facilitates identifying individuals responsible for specific actions, promoting accountability and deterring potential misuse of access privileges. Additionally, it enables faster and more targeted incident response in case of suspicious activity or security breaches.
Best practices to meet this requirement:
- Centralized user management: Implement a centralized user management system to assign and manage unique user IDs for all personnel requiring access to system components or CHD. This ensures consistency and simplifies administration.
- Unique and non-sharable credentials: Enforce the use of unique and non-sharable credentials (passwords, tokens) associated with each user ID. This prevents unauthorized access attempts by others using a shared login.
- Regular reviews: Conduct periodic reviews of user access to ensure user IDs remain assigned only to active personnel who require access. Deactivate or delete user IDs of employees who no longer require access.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.2.1.a | Interview personnel responsible for user provisioning (e.g., IT security staff, department managers).Verify their process for assigning unique user IDs to all personnel requiring access to system components or CHD. | The assessor will interview personnel responsible for user account management to understand their process for assigning user IDs. The interview will confirm that all users requiring access have a unique ID assigned. |
| 8.2.1.b | Examine audit logs from your systems.Verify that audit log entries contain unique user identifiers that can be traced back to individual users. | The assessor will review audit logs from your systems to ensure they capture user activity and that each entry includes a unique user ID. This verification demonstrates the ability to attribute actions to specific users. |
PCI DSS Requirement 8.2.2: Limit and Manage Shared Accounts
This requirement acknowledges that there may be rare instances where shared accounts (group, generic, or system accounts) are necessary. However, it emphasizes the critical need to strictly manage and limit the use of such accounts due to the inherent security risks associated with them. Here's a breakdown of the requirement:
- Limited use: Shared accounts should only be used as an exception and when absolutely necessary due to specific circumstances.
- Management controls: When used, shared accounts must be subject to stringent management controls:
- Documented justification: Clear business justification for using a shared account must be documented.
- Management approval: The use of a shared account requires explicit approval from management.
- Individual user verification: Before granting access to a shared account, individual user identity must be confirmed to ensure accountability.
- Action attribution: All actions taken using a shared account must be attributable to a specific individual user.
Definitions:
- Shared accounts: User accounts with login credentials (username and password) shared by multiple users. These include generic accounts (e.g., "admin"), system accounts, or group accounts.
Business implication:
- Reduced Risk of Data Breaches: Shared accounts pose a significant security risk as they lack individual accountability. A compromised shared account credential could grant unauthorized access to sensitive CHD for multiple users. Limiting and strictly managing shared accounts helps mitigate this risk.
Best practices to meet this requirement:
- Minimize shared account use: Whenever possible, avoid using shared accounts altogether. Favor individual user accounts with unique credentials for enhanced security and accountability.
- Strong authentication: If a shared account is unavoidable, implement strong authentication methods beyond a simple password. this could include multi-factor authentication (MFA) or requiring additional approval steps for access.
- Regular reviews: Conduct periodic reviews of all shared accounts to ensure they are still genuinely necessary and actively used. Deactivate or remove shared accounts that are no longer required.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.2.2.a | Examine user account lists on system components.Review relevant documentation (policies, procedures, justification logs).Verify that shared accounts are only used exceptionally and meet all the requirement criteria (documented justification, management approval, etc.). | The assessor will examine user account lists on your systems to identify shared accounts.They will then review relevant documentation, including policies, procedures, and justification logs, to ensure shared accounts are used exceptionally and in accordance with the defined controls. |
| 8.2.2.b | Review authentication policies and procedures.Verify the policies define processes for managing shared accounts as outlined in the requirement. | The assessor will review your authentication policies and procedures to ensure they address the management of shared accounts. This includes requiring justification, approval, individual user verification, and action attribution. |
| 8.2.2.c | Interview system administrators responsible for managing shared accounts.Verify their understanding and adherence to the controls outlined in the requirement for managing shared accounts. | The assessor will interview system administrators responsible for managing shared accounts. The interview will assess their understanding of the requirement and how they ensure shared accounts are used and managed according to the defined controls. |
PCI DSS Requirement 8.2.3: Unique Authentication for Service Providers (Remote Access)
This requirement applies specifically to service providers who require remote access to their customer's premises (e.g., to support POS systems or provide other remote services). It mandates the use of unique authentication factors for each customer location. This helps prevent a security breach at one customer from impacting other customers.
Definitions:
- Service provider: An organization that supplies services to another organization, such as managing point-of-sale systems.
- Remote access: Accessing a customer's computer system or network from a separate location over a communications link.
- Unique authentication factors: Credentials or methods used to verify a user's identity, different for each customer location. This could include passwords, tokens, or multi-factor authentication methods.
Business implication for service providers:
- Reduced risk of customer data breaches: Unique authentication for each customer location minimizes the potential for a compromised credential at one location to grant access to other customer systems. This safeguards customer data and protects your reputation as a service provider.
Best practices to meet this requirement:
- Implement MFA: Consider using MFA for remote access to customer premises. MFA requires additional verification beyond a simple password, such as a one-time code or biometric authentication. This significantly strengthens security.
- Unique credentials per customer: If not using MFA, ensure each customer location has unique login credentials (username and password) for remote access. Avoid using generic or shared credentials across multiple customer locations.
- Regular credential rotation: Enforce periodic rotation of authentication credentials for each customer location. This reduces the risk of compromised credentials being used for unauthorized access.
How to comply with this PCI DSS requirement (Service Providers Only):
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.2.3 | Examine authentication policies and procedures for remote access to customer premises.Interview personnel responsible for remote access to understand their practices.Verify that unique authentication factors are used for each customer location. | The assessor will review your authentication policies and procedures for remote access to customer premises. This review will confirm that the policy mandates the use of unique authentication factors for each location.The assessor will then interview personnel responsible for remote access to understand their practices and verify they adhere to the policy, using unique credentials for each customer location |
PCI DSS Requirement 8.2.4: Manage user account lifecycle with approval
This requirement emphasizes the importance of managing the entire lifecycle (creation, modification, deletion) of user IDs, authentication factors, and other identifier objects with proper authorization and control. This helps prevent unauthorized access attempts and privilege escalation.
Definitions:
- User ID: A unique identifier assigned to each user for access control purposes (e.g., username, employee ID).
- Authentication factors: Credentials or methods used to verify a user's identity, such as passwords, tokens, or biometrics.
- Identifier objects: Any data element used to identify and manage user access, including user IDs, authentication factors, and group memberships.
- Lifecycle management: The process of managing the creation, modification, and deletion of user accounts and associated access privileges throughout their existence.
- Authorization: Formal approval for performing specific actions related to user accounts.
Business implication:
- Reduced risk of unauthorized access: Properly controlled user account lifecycles with documented approvals minimize the risk of unauthorized account creation, privilege escalation, or unauthorized modifications. This safeguards your systems and sensitive CHD from potential breaches.
Best practices to meet this requirement:
- Defined approval process: Establish a clear and documented process for authorizing user account lifecycle actions (additions, modifications, deletions). This process should define who can grant approvals and for what types of accounts.
- Least privilege: Grant users only the minimum level of access privileges required to perform their job functions. Regularly review and adjust access privileges to ensure they remain appropriate.
- Segregation of duties: Implement segregation of duties to prevent a single individual from having complete control over the user account lifecycle. This helps mitigate the risk of unauthorized modifications or abuse.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.2.4 | Examine documented procedures for user account lifecycle management (additions, modifications, deletions).Review a sample of recent user account activity logs.Verify that all additions, modifications, and deletions were performed with documented authorization and reflect the privileges specified in the approval. | The assessor will review your documented procedures for managing user accounts throughout their lifecycle. This includes verifying that approvals are required for all lifecycle actions and that the approval process is clearly defined.The assessor will then review a sample of user account activity logs focusing on additions, modifications, and deletions. They will verify that these actions have documented authorization on file and that the implemented changes reflect the privileges specified in the approval. |
PCI DSS Requirement 8.2.5: Revoke access for terminated users
This requirement mandates the immediate revocation of access for all terminated users (employees, contractors, vendors) upon termination of their employment or contract. This ensures that former users no longer have access to your systems and sensitive CHD, minimizing the risk of unauthorized access or misuse.
Definitions:
- Terminated user: An employee, contractor, vendor, or any individual whose employment or contract has ended.
- Access revocation: Disabling a user's ability to access system components and CHD. This may involve deactivating user IDs, resetting passwords, and retrieving physical authentication factors.
Business implication:
- Reduced risk of data breaches: Promptly revoking access for terminated users eliminates the potential for them to access your systems and compromise CHD after their employment or contract ends. This protects sensitive data and reduces the risk of data breaches.
Best practices to meet this requirement:
- Automated processes: Implement automated processes to trigger user account deactivation upon termination events within your HR or identity management system. This ensures timely access revocation and minimizes manual intervention.
- Termination checklist: Develop a termination checklist that includes steps for revoking user access across all systems and applications. This ensures all access points are addressed during the termination process.
- Physical token retrieval: For users with physical authentication factors (tokens, smart cards), ensure a secure collection process upon termination. Consider deactivating the token or requiring its return before finalizing the termination process.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.2.5.a | Examine termination records or other sources to identify recently terminated users.Review current user access lists for both local and remote access systems.Verify that user IDs for terminated users have been deactivated or removed from the access lists. | The assessor will review your records to identify recently terminated employees, contractors, or vendors.They will then examine your user access lists for both local and remote access systems to ensure that the user IDs associated with these terminated users have been deactivated or completely removed from the lists. |
| 8.2.5.b | Interview personnel responsible for user account management.Verify their process for collecting or deactivating physical authentication factors (tokens, smart cards) upon user termination. | The assessor will interview personnel responsible for user account management to understand their process for handling physical authentication factors during the termination process. This interview will confirm that these factors are retrieved or deactivated to prevent unauthorized access by terminated users. |
PCI DSS Requirement 8.2.6: Disable or remove inactive user accounts
This requirement mandates that user accounts with no activity for a period of 90 days or more be disabled or removed. This helps mitigate the risk associated with inactive accounts, which are more vulnerable to attack due to potential lack of password changes or monitoring.
Definitions:
- Inactive user account: A user account that has not been used to access system components or CHD for a defined period (typically 90 days).
- Disable user account: Rendering a user account unusable by revoking access privileges without permanent deletion. This allows for potential future reactivation if needed.
- Remove user account: Permanently deleting a user account from the system.
Business implication:
- Reduced risk of data breaches: Disabling or removing inactive user accounts reduces the attack surface for potential attackers. By eliminating unused accounts, you minimize the risk of unauthorized access and compromise of sensitive CHD.
Best practices to meet this requirement:
- Automated user reviews: Implement automated processes to periodically review user activity and identify inactive accounts.
- Defined inactivity period: Establish a clear policy defining the timeframe for considering an account inactive (typically 90 days).
- Account reactivation process: Develop a process for securely reactivating user accounts if a previously inactive user requires access again. This may involve password resets and security awareness training.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.2.6 | Examine user account activity logs and define the timeframe considered "inactive" (usually 90 days).Verify that inactive user accounts have been disabled or removed within the defined timeframe. | The assessor will review user account activity logs to identify potentially inactive accounts based on your defined inactivity period (e.g., 90 days). They will then verify that these inactive accounts have been disabled or removed from the system within the specified timeframe. |
| 8.2.6 | Interview personnel responsible for user account management.Verify their understanding of the process for identifying and handling inactive user accounts. | The assessor will interview personnel responsible for user account management to understand their process for identifying inactive accounts and the actions taken (disabling or removing) to address them. |
PCI DSS Requirement 8.2.7: Manage Third-Party Remote Access Accounts
This requirement focuses on managing user accounts used by third-party vendors for remote access to your systems for support or maintenance purposes. It emphasizes the importance of strict controls to minimize the risk associated with such access.
Definitions:
- Third-party vendor: An external organization providing services such as system support or maintenance that require remote access to your systems.
- Remote access: Accessing a computer system or network from a separate location over a communications link.
- Unexpected activity: Any access attempt or action using a third-party account that falls outside the defined scope, authorized timeframe, or expected user behavior.
Business implication:
- Reduced risk of security breaches: Limiting the availability of third-party remote access accounts and monitoring their usage helps prevent unauthorized access attempts or misuse by malicious actors potentially present within the vendor's environment. This safeguards your systems and sensitive CHD from potential breaches.
Best practices to meet this requirement:
- Just-in-time (JIT) access: Implement JIT access for third-party vendors. Grant access only for the specific time period required for the support or maintenance task and disable it immediately upon completion.
- MFA: Consider requiring MFA for third-party remote access. This adds an extra layer of security beyond a simple password and helps prevent unauthorized access even if credentials are compromised.
- Activity monitoring: Monitor all third-party remote access activity for any suspicious or unexpected behavior. This allows for prompt detection and investigation of potential security incidents.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.2.7 | Interview personnel responsible for managing third-party vendor access.Review policies and procedures for handling third-party remote access.Examine documentation for authorization and access duration for each third-party vendor.Verify that access logs are monitored for unexpected activity related to third-party accounts. | The assessor will interview personnel responsible for managing third-party vendor access to understand their processes.They will review relevant policies and procedures to ensure they address the requirement's elements (limited access duration, monitoring).The assessor will examine documentation for each third-party vendor, verifying that access is authorized and limited to the specific timeframe required for their services.Finally, they will assess your monitoring practices to confirm that access logs are reviewed for any unexpected activity related to third-party accounts. |
PCI DSS Requirement 8.2.8: Enforce session timeout for idle users
This requirement mandates that user sessions become inactive and require re-authentication after a period of inactivity exceeding 15 minutes. This helps mitigate the risk of unauthorized access if a user leaves their workstation unattended with an active session.
Definitions:
- User session: A period of active interaction between a user and a system through a specific login.
- Idle session: An inactive user session where there has been no user interaction for a defined period (15 minutes or less).
- Re-authentication: The process of verifying a user's identity again before granting continued access to a session after a period of inactivity.
Business implication:
- Reduced risk of data breaches: Enforcing session timeouts for idle users minimizes the window of opportunity for unauthorized individuals to access sensitive CHD if a user forgets to log out or leaves their workstation unattended. This helps safeguard your data and reduces the risk of security breaches.
Best practices to meet this requirement:
- Automated session timeouts: Configure your systems and applications to automatically time out inactive user sessions after 15 minutes or less. This ensures consistent enforcement of the requirement.
- User awareness: Educate users about the importance of logging out when they step away from their workstations, even for short periods.
- MFA: Consider implementing MFA for user logins. This adds an extra layer of security beyond a simple password and makes it more difficult for unauthorized individuals to gain access even if a session times out but the user's credentials are compromised.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.2.8 | Examine system configuration settings for user session timeouts.Verify that the timeout is set to 15 minutes or less. | The assessor will review the configuration settings of your systems and applications to verify that session timeouts are enabled and set to the required timeframe (15 minutes or less) as per the PCI DSS requirement. |
PCI DSS Requirement: 8.3 Strong authentication for users and administrators is established and managed.
PCI DSS Requirement 8.3.1: Implement multi-factor authentication
This requirement mandates the use of multi-factor authentication (MFA) for all user access to system components, including both regular users and administrators. MFA adds an extra layer of security beyond a simple password or username by requiring at least one additional verification factor. This significantly reduces the risk of unauthorized access even if a single factor (e.g., password) is compromised.
Definitions:
- MFA: A security method that requires users to provide two or more verification factors to gain access to a system. Common factors include:
- Something you know (password, passphrase)
- Something you have (token device, smart card)
- Something you are (biometric element - fingerprint, facial recognition)
- User access: The ability for a user to interact with system components using their login credentials.
- System components: Any hardware, software, or firmware element within your IT infrastructure that stores, processes, or transmits cardholder data (CHD).
Business implication:
- Reduced risk of data breaches: MFA significantly strengthens user authentication and makes it much more difficult for unauthorized individuals to gain access to your systems and sensitive CHD, even if they manage to steal a user's password or login credentials. This helps safeguard your data and reduces the risk of costly data breaches.
Best practices to meet this requirement:
- MFA for All users: Implement MFA for all user access, regardless of user type (regular user or administrator). This ensures a consistent level of security across all access points.
- Strong authentication factors: Choose strong and reliable authentication factors for MFA. Consider factors beyond simple passwords, such as tokens, smart cards, or biometrics.
- User education: Educate users about the importance of MFA and how to use it effectively. This includes proper storage and protection of additional authentication factors like tokens or smart cards.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.3.1.a | Examine documentation outlining your authentication policies and procedures.Verify that the documentation mandates the use of MFA for all user access to system components. | The assessor will review your documentation related to user authentication, specifically focusing on whether it clearly states the requirement for MFA for all user access. |
| 8.3.1.b | Observe the login process for different user types (regular user, administrator) on various systems.Verify that at least two authentication factors are required for successful login. | The assessor will observe the login process for different user types on various systems within your environment. They will verify that the login process requires the use of at least two distinct authentication factors (e.g., password + token, password + fingerprint). |
PCI DSS Requirement 8.3.2: Protect authentication factors with strong cryptography
This requirement mandates the use of strong cryptography to protect all authentication factors throughout their lifecycle. This includes rendering them unreadable during transmission (across networks) and while stored on your systems. Strong cryptography safeguards authentication factors, making them useless even if intercepted by unauthorized individuals.
- Authentication factors: As defined previously, these are verification elements used for multi-factor authentication (MFA), including passwords, tokens, biometrics, etc.
- Strong cryptography: Encryption algorithms that meet industry standards and provide a high level of protection for sensitive data. Common examples include AES-256 and RSA.
- Transmission: The process of sending authentication factors across a network connection.
- Storage: The method of keeping authentication factors on a system component (database, file system).
This requirement applies to all authentication factors used for MFA, regardless of type (password, token, biometric).Password hashing is not considered strong cryptography for this requirement. Passwords should be stored using a one-way hashing function combined with a salt value for additional protection.
Business implication:
- Reduced risk of data breaches: Strong cryptographic protection for authentication factors significantly reduces the risk of unauthorized access to your systems and CHD. Even if attackers manage to intercept or steal authentication factors during transmission or storage, the encryption makes them unusable, preventing unauthorized login attempts.
Best practices to meet this requirement:
- Secure password storage: Hash and salt all user passwords before storing them on your systems. Hashing transforms passwords into a non-reversible format, and salting adds an extra layer of protection against brute-force attacks.
- HTTPS for data transmission: Ensure all communication channels transmitting authentication factors (e.g., login forms) use HTTPS with strong TLS encryption. This encrypts data in transit, making it unreadable even if intercepted.
- Secure token storage: For token-based MFA, choose tokens that store credentials securely using encryption. Avoid storing sensitive information such as PINs or passwords on the token itself in plain text.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.3.2.a | Examine vendor documentation for authentication factors (tokens, smart cards) to verify they use strong cryptography.Review system configuration settings to confirm encryption protocols used for data transmission (e.g., HTTPS with TLS). | The assessor will review documentation for your MFA solution and authentication factors to ensure they employ strong cryptographic algorithms.They will also examine your system configurations to verify that data transmission protocols like HTTPS with TLS are enabled for secure communication. |
| 8.3.2.b | For token-based MFA, assess how tokens store authentication factors.Verify that tokens do not store sensitive information (e.g., PINs, passwords) in plain text. | The assessor will review your token storage practices for token-based MFA. They will ensure that tokens themselves do not store sensitive credentials in an unencrypted format. |
| 8.3.2.c | (Optional) If feasible, capture network traffic during the login process to verify that authentication factors are not transmitted in plain text. | Analyzing network traffic is an optional assessment method. The assessor may attempt to capture login attempts to see if authentication factors are being transmitted in an encrypted format. However, this method might not always be practical due to security tools that might mask sensitive data in captured traffic. |
PCI DSS Requirement 8.3.3: Verify user identity before modifying authentication factors
This requirement mandates verifying a user's identity before processing any request to modify their authentication factors. This helps prevent unauthorized individuals from impersonating legitimate users and gaining access to the system by manipulating authentication factors (e.g., resetting passwords).
- Authentication factors: As defined previously, these are verification elements used for multi-factor authentication (MFA), including passwords, tokens, biometrics, etc.
- User identity verification: The process of confirming that the individual requesting a change to an authentication factor is indeed the authorized user.
This requirement applies to all situations where a user's authentication factors are being modified, such as password resets, provisioning new tokens, or generating new encryption keys.
Business implication:
- Reduced risk of account takeover: Verifying user identity before modifying authentication factors helps prevent social engineering attacks where malicious actors impersonate legitimate users to gain access. This safeguards your systems and CHD from unauthorized access.
Best practices to meet this requirement:
- Multi-Factor verification: Implement a multi-factor approach for verifying user identity when modifying authentication factors. This could involve a combination of methods like:
- Knowledge-based authentication (KBA): Asking pre-defined security questions only the user would know the answer to.
- Out-of-band verification: Sending a verification code to a trusted phone number or email address registered with the user account.
- Strong password reset procedures: Establish a strong password reset process that requires robust user identity verification before granting access to reset functionality.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.3.3 | Examine documented procedures for modifying authentication factors.Observe security personnel handling user requests to modify authentication factors.Verify that they implement a process to confirm user identity before proceeding with the modification. | The assessor will review your documented procedures for handling user requests to modify authentication factors (password resets, token provisioning).They will then observe your security personnel handling such requests to verify that they follow established procedures for user identity verification before modifying any authentication factors. |
PCI DSS Requirement 8.3.4: Limit login attempts to prevent brute-force attacks
This requirement mandates implementing account lockout mechanisms to limit the number of consecutive failed login attempts. This helps prevent unauthorized individuals from using brute-force attacks to guess valid passwords and gain access to your systems.
- Brute-force attack: A hacking technique that involves systematically trying a large number of possible passwords until a successful login is achieved.
- Account lockout: Disabling a user account for a specific period after exceeding a predefined number of failed login attempts.
- User ID: A unique identifier used by a user to access a system.
This requirement does not apply to user accounts on point-of-sale terminals with access to only a single card number for a single transaction (e.g., cashier IDs).
Business implication:
- Reduced risk of account takeover: Limiting login attempts and locking out accounts after a certain number of failed attempts significantly reduces the risk of successful brute-force attacks. This safeguards your systems and CHD from unauthorized access.
Best practices to meet this requirement:
- Strong password policies: Enforce strong password policies that require users to create complex passwords that are difficult to guess. This makes brute-force attacks less effective.
- Account lockout threshold: Configure account lockout to occur after no more than 10 invalid login attempts. This balances security with user experience by not locking out users for accidental typos.
- Lockout duration: Set the lockout duration to a minimum of 30 minutes. This delays attackers and increases the time required for a successful brute-force attempt.
- Identity verification for unlock: Implement a process to verify user identity before unlocking a locked account. This prevents attackers from exploiting a temporary lockout to gain access.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.3.4.a | Examine system configuration settings for password and login attempts.Verify that the settings limit login attempts to no more than 10 before locking out the user account. | The assessor will review your system configuration settings related to user login attempts. They will confirm that the settings are configured to lock out user accounts after a maximum of 10 consecutive failed login attempts. |
| 8.3.4.b | Examine system configuration settings for account lockout duration.Verify that the lockout duration is set to a minimum of 30 minutes or until administrator-confirmed user identity verification. | The assessor will review your system configuration settings for account lockout duration. They will confirm that the lockout period is set to at least 30 minutes or until an administrator verifies the user's identity before unlocking the account. |
PCI DSS Requirement 8.3.5: Enforce unique and mandatory password changes
This requirement applies specifically to scenarios where passwords or passphrases are used as authentication factors (as mandated by requirement 8.3.1). It focuses on ensuring the initial setup and subsequent resets of passwords are secure:
- Password/passphrase: A secret string of characters used for user authentication.
- Unique value: A password that is distinct and not reused for any other user or system.
- First-time use: The initial assignment of a password to a new user account.
- Reset: The process of changing an existing password due to security concerns, forgotten credentials, etc.
This requirement only applies if passwords or passphrases are your chosen method for meeting the multi-factor authentication requirement (8.3.1). If you utilize stronger authentication factors (tokens, biometrics), this requirement is not relevant for those specific factors.
Business implication:
- Reduced risk of credential compromise: Enforcing unique passwords for each user and mandatory changes after first use significantly reduces the risk of unauthorized access even if a password is compromised. This helps safeguard your systems and sensitive CHD from falling into the wrong hands.
Best practices to meet this requirement:
- Strong password policies: Implement strong password policies that enforce password complexity requirements (minimum length, character types). This makes passwords more difficult to guess or crack.
- Temporary passwords: For new user accounts, consider issuing temporary passwords that must be changed upon first login. This ensures users create their own unique passwords.
- Password reset procedures: Establish clear and secure procedures for password resets. This may involve multi-factor verification to confirm user identity before granting access to reset functionality.
- Password managers: Encourage the use of password managers by your users. These tools can help them create and store strong, unique passwords for different accounts.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.3.5 | Examine documented procedures for password setting and resetting.Observe security personnel handling new user account creation and password resets.Verify that they follow documented procedures to ensure passwords are unique and users are forced to change them upon first login. | The assessor will review your documented procedures for password management, focusing on aspects like initial assignment and resets.They will then observe your security personnel handling these processes to verify that:New user passwords are unique and temporary, requiring changes upon first login.Password resets are performed securely with user identity verification. |
PCI DSS Requirement 8.3.6: Enforce minimum password complexity (best practice until March 31, 2025)
This requirement outlines the minimum complexity standards for passwords if you choose them as an authentication factor (as required by 8.3.1). It focuses on password length and character types to make them more resistant to guessing attacks. However, it's important to note that this requirement is currently a best practice until March 31, 2025. After that date, it becomes a mandatory requirement for PCI DSS compliance.
- Password/passphrase: A secret string of characters used for user authentication.
- Complexity: A measure of how difficult a password is to guess or crack. More complex passwords involve a combination of different character types and lengths.
- Brute-force attack: A hacking technique that systematically tries a large number of possible passwords until a successful login is achieved.
This requirement does not apply to:
- User accounts on point-of-sale terminals with access to only one card number for a single transaction.
- Application or system accounts (governed by separate requirements in section 8.6 of PCI DSS).
Until March 31, 2025, this requirement remains a best practice. After that date, it becomes mandatory.
Business implication:
- Reduced risk of password guessing attacks: Enforcing strong password complexity significantly reduces the risk of unauthorized access through brute-force attacks, where attackers try to guess valid passwords. This helps safeguard your systems and sensitive CHD from falling into the wrong hands.
Best practices to meet this requirement:
- Strong password policies: Implement strong password policies that exceed the minimum requirements. This could involve enforcing longer password lengths (beyond 12 characters), requiring a combination of uppercase and lowercase letters, numbers, and special characters.
- Password rotation: Encourage users to change their passwords regularly (e.g., every 3 months) to further reduce the effectiveness of potential attacks even if a password is compromised.
- Password managers: Recommend the use of password managers by your users. These tools can help them create and store strong, complex passwords for different accounts.
How to comply with this PCI DSS requirement (Best Practice Assessment):
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.3.6 | Examine documented password policies to verify minimum password complexity requirements (length, character types).Review system configuration settings for password complexity parameters. | The assessor will review your documented password policies to ensure they enforce the minimum complexity requirements outlined in this standard (12 characters or 8 characters if systems don't support 12, and a combination of numeric and alphabetic characters).They will also examine your system configuration to verify that the settings are aligned with your documented policies. |
PCI DSS Requirement 8.3.7: Prevent password reuse
This requirement mandates preventing users from setting new passwords that are identical to any of their four most recently used passwords. This helps prevent attackers who might have compromised an old password from using it to regain access.
- Password/passphrase: A secret string of characters used for user authentication.
- Password history: A record of the past passwords used by a user for a particular account.
Note: This requirement does not apply to user accounts on point-of-sale terminals with access to only one card number for a single transaction.
Business implication:
- Reduced risk of password compromise: Enforcing password history prevents users from unintentionally or intentionally reusing compromised passwords. This strengthens your overall authentication posture and reduces the risk of unauthorized access.
Best practices to meet this requirement:
- Password rotation policies: Implement password rotation policies that require users to change their passwords periodically (e.g., every 3 months). This reduces the window of opportunity for attackers even if they manage to compromise an old password.
- Password complexity: Enforce strong password complexity requirements (as outlined in PCI DSS 8.3.6) in conjunction with password history. This creates a stronger barrier against brute-force attacks and password guessing.
- User education: Educate users about the importance of not reusing passwords across different accounts. Encourage them to create strong, unique passwords for each account they use.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.3.7 | Examine documented password policies to verify they prohibit password reuse for at least the last four passwords.Review system configuration settings for password history parameters. | The assessor will review your documented password policies to ensure they explicitly state that users cannot reuse their four most recent passwords.They will also examine your system configuration settings to verify that password history is enabled and stores at least the last four passwords. |
PCI DSS Requirement 8.3.8: Document and communicate authentication policies
This requirement mandates documenting and communicating clear authentication policies and procedures to all users. These policies should educate users on best practices for selecting strong authentication factors, protecting their credentials, and handling potential compromises.
- Authentication policies and procedures: A documented set of guidelines outlining user responsibilities for secure authentication practices.
- Authentication factors: Methods used for multi-factor authentication (MFA), including passwords, tokens, biometrics, etc.
Business implication:
- Reduced risk of social engineering and phishing attacks: Educated users are less susceptible to social engineering and phishing tactics where attackers try to trick users into revealing their credentials. This reduces the risk of unauthorized access attempts.
Best practices to meet this requirement:
- Comprehensive policies: Develop clear and concise policies covering various aspects of authentication security:
- Selecting strong passwords/passphrases (avoiding dictionary words, personal information).
- Protecting authentication factors (not writing them down, avoiding insecure storage).
- Password hygiene practices (not reusing passwords, changing them regularly).
- Reporting suspected compromises and requesting password resets.
- User awareness training: Conduct regular user awareness training sessions to educate employees on authentication best practices and potential threats.
- Readily available resources: Make authentication policies readily available to all users through an internal knowledge base or company portal for easy reference.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.3.8.a | Examine documented authentication policies and procedures.Interview security personnel responsible for distributing these policies to users. | The assessor will review your documented authentication policies to ensure they cover the elements outlined in this requirement (strong factor selection, credential protection, password hygiene, reporting compromises). They will then interview your security personnel to verify that these policies are distributed to all users (e.g., during onboarding, through internal communication channels). |
| 8.3.8.b | Review documented authentication policies and procedures. | The assessor will examine your documented policies to confirm they include specific guidance on:Selecting strong authentication factors.Protecting authentication factors from unauthorized access.Not reusing passwords and changing them if compromised.Reporting suspected compromises and requesting password resets. |
| 8.3.8.c | Conduct interviews with a representative sample of users from different departments. | The assessor will interview a selection of users from various departments to assess their awareness of the authentication policies.They will ask questions to gauge user understanding of best practices for selecting strong factors, protecting credentials, and handling potential compromises. |
PCI DSS Requirement 8.3.9: Enhance security for single-factor authentication with passwords
This requirement applies specifically to scenarios where passwords are the SOLE method used for user authentication (single-factor authentication). It mandates implementing additional security measures to compensate for the weaker security posture of single-factor authentication. There are two options for compliance:
- Regular password changes: Enforce mandatory password changes at least every 90 days.
- Dynamic access control: Implement a system that dynamically analyzes user access attempts and grants or denies access based on real-time security factors (e.g., location, device integrity).
Business implications:
- Reduced risk of long-term password compromise: regular password changes or dynamic access controls mitigate the risk associated with compromised passwords. by limiting the window of opportunity for attackers to exploit a compromised password, you safeguard your systems and CHD.
Best practices to meet this requirement:
- Strong password policies: Even if you choose to enforce regular password changes, it's crucial to have strong password policies in place. This includes enforcing password complexity requirements (length, character types) to make passwords more difficult to guess or crack.
- MFA: While not mandatory for single-factor scenarios in this requirement, consider implementing MFA whenever possible. MFA adds an extra layer of security by requiring a second verification factor (token, biometrics) beyond just a password.
- User education: Educate users on the importance of creating strong passwords and avoiding password reuse across different accounts.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.3.9 | If passwords are the only authentication factor, examine documented password policies and system configuration settings. Verify that either:Password changes are mandated at least every 90 days, OR,The system implements dynamic access controls that analyze user access attempts and grant/deny access based on real-time factors. | The assessor will review your documented password policies to confirm a mandatory password change requirement of at least every 90 days if passwords are the sole authentication method. They will then examine your system configuration settings to see if dynamic access controls are implemented for single-factor authentication scenarios. If dynamic controls are in place, the assessor may request additional documentation or conduct interviews with IT personnel to understand how these controls function. |
PCI DSS Requirement 8.3.10 and 8.3.10.1: Enhanced security for service provider customer password management (single-factor authentication)
Requirement 8.3.10 (current best practice):
- Requires service providers to provide customer users with guidance on:
- Periodically changing passwords.
- When and under what circumstances password changes are necessary.
Requirement 8.3.10.1 (future requirement - effective march 31, 2025):
- Mandates service providers to implement one of the following for customer passwords:
- Enforce password changes at least every 90 days.
- Implement dynamic access controls that analyze user access attempts and grant/deny access based on real-time factors.
Business implication:
- Reduced risk of long-term customer password compromise: Encouraging or enforcing regular password changes, or implementing dynamic access controls, helps mitigate the risk associated with compromised customer passwords. This safeguards your service and the cardholder data you manage.
Best practices to meet this requirement:
- Educate customers: Develop clear and concise guidance for your customers on creating strong passwords and the importance of changing them regularly. This can be included in onboarding materials, security awareness training, or knowledge base articles.
- Strong password policies (Even for 8.3.10): While not mandatory for 8.3.10, consider recommending strong password policies to your customers. This includes enforcing password complexity requirements (length, character types) to make passwords more difficult to guess or crack.
- Consider MFA: Whenever possible, encourage your customers to adopt MFA for accessing their accounts. MFA adds an extra layer of security beyond just a password.
How to comply with this PCI DSS requirement:
Requirement 8.3.10:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.3.10 | Review service provider documentation provided to customers regarding password management. | The assessor will examine your customer-facing documentation (website, onboarding materials) to verify it includes guidance on:Periodic password changes.When and why password changes might be necessary (e.g., suspected compromise). |
Requirement 8.3.10.1 - effective after march 31, 2025:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.3.10.1 | If passwords are the only authentication factor for customers, examine documented password policies and system configuration settings.Verify that either:Password changes are mandated at least every 90 days for customers, ORThe system implements dynamic access controls that analyze customer access attempts and grant/deny access based on real-time factors. | The assessor will review your documented password policies to confirm a mandatory password change requirement of at least every 90 days for customer accounts if passwords are the sole authentication method.They will then examine your system configuration settings to see if dynamic access controls are implemented for customer single-factor authentication scenarios.If dynamic controls are in place, the assessor may request additional documentation or conduct interviews with IT personnel to understand how these controls function. |
Note: Until March 31, 2025, service providers can choose to comply with either requirement 8.3.10 or 8.3.10.1. After that date, 8.3.10.1 becomes mandatory.
PCI DSS Requirement 8.3.11: Secure assignment and use of authentication factors
This requirement focuses on the secure management of authentication factors beyond passwords, including physical tokens, smart cards, and certificates. It mandates two key controls:
- Individual user assignment: Authentication factors must be assigned to a specific user and not shared among multiple users.
- Physical/logical controls: Implement controls to ensure that only the intended user can utilize their assigned factor to gain access. This might involve pins, biometrics, or passwords used in conjunction with the factor.
- Authentication factor: Any method used for user authentication besides passwords, such as tokens, smart cards, or certificates.
Business implication:
- Reduced risk of unauthorized access: Enforcing individual user assignment and additional access controls significantly reduces the risk of unauthorized access attempts. Even if an attacker acquires a stolen authentication factor, they wouldn't be able to use it without the additional control (PIN, biometrics) possessed by the legitimate user.
Best practices to meet this requirement:
- Documented policies: Develop clear policies outlining procedures for assigning, using, and safeguarding authentication factors. These policies should emphasize the importance of not sharing factors.
- Strong second factors: When using multi-factor authentication (MFA) with factors beyond passwords, choose strong second factors like hardware tokens or biometrics. These offer a higher level of security compared to software-based tokens.
- User training: Educate users on the proper use and security of their assigned authentication factors. This includes the importance of not sharing them and reporting any loss or suspected compromise.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.3.11.a | Review documented authentication policies and procedures. | The assessor will examine your documented policies to verify they explicitly state that authentication factors (tokens, smart cards, certificates) must be assigned to individual users and not shared. |
| 8.3.11.b | Interview security personnel responsible for managing authentication factors. | The assessor will interview security personnel to confirm that authentication factors are assigned to individual users and not distributed or shared among multiple users. |
| 8.3.11.c | Examine system configuration settings for multi-factor authentication and access controls. For physical tokens, observe physical security measures in place (e.g., secure storage). | The assessor will review your system configuration to verify that additional controls (PINs, biometrics) are required for using the assigned authentication factors.They will also examine physical security measures for tokens (e.g., locked storage cabinets) to ensure unauthorized access is prevented. |
PCI DSS Requirement 8.4 Multi-factor authentication (MFA) is implemented to secure access into the CDE.
PCI DSS Requirement 8.4.1: MFA for Administrative Access to CDE
This requirement mandates the use of multi-factor authentication (MFA) for all non-console access to the Cardholder Data Environment (CDE) by personnel with administrative privileges. MFA adds an extra layer of security by requiring at least two different verification factors beyond just a password.
- Multi-Factor Authentication (MFA): A security method that requires two or more independent verification factors for user authentication. These factors can include something the user knows (password), something the user has (token), or something the user is (biometrics).
- Non-Console Access: Access to a system or network through a logical connection (e.g., remote access software) as opposed to physically connecting to the device.
- Cardholder Data Environment (CDE): The environment that houses cardholder data or systems that process cardholder data.
Business implication:
- Reduced Risk of Account Takeover: MFA significantly reduces the risk of unauthorized access to the CDE by attackers. Even if an attacker steals a user's password, they wouldn't be able to gain access without the additional verification factor (token, biometrics) possessed by the legitimate user. This safeguards sensitive cardholder data.
Best practices to meet this requirement:
- Strong MFA Solutions: Implement robust MFA solutions that offer options beyond simple SMS verification codes. Consider hardware tokens, biometrics, or authenticator apps for a stronger security posture.
- User Training: Educate users with administrative access on the importance of MFA and proper use of their chosen verification factors. This includes best practices for securing their tokens and reporting any loss or compromise.
- MFA for All Remote Access: While not strictly required in this specific PCI DSS context, consider implementing MFA for all remote access attempts, not just for the CDE. This adds an extra layer of security for accessing any sensitive systems or data.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.4.1.a | Examine network and/or system configuration settings for the CDE. | The assessor will review your system configuration to verify that MFA is mandatory for all non-console access attempts to the CDE. This might involve reviewing settings for remote access software, VPNs, or other network access methods.They will specifically focus on access for users with administrative privileges. |
| 8.4.1.b | Observe a simulated or real administrator login attempt to the CDE. | The assessor may observe a simulated login process where an administrator with elevated privileges attempts to access the CDE through a non-console method.During this observation, the assessor will verify that the system prompts for at least two separate verification factors before granting access. |
PCI DSS Requirement 8.4.2: Multi-Factor Authentication (MFA) for ALL CDE Access
This requirement, effective March 31, 2025, mandates the use of multi-factor authentication (MFA) for ALL access attempts to the Cardholder Data Environment (CDE). This applies to both remote and non-console access methods. MFA adds an extra layer of security by requiring at least two different verification factors beyond just a password.
- Multi-Factor Authentication (MFA): A security method that requires two or more independent verification factors for user authentication. These factors can include something the user knows (password), something the user has (token), or something the user is (biometrics).
- Non-Console Access: Access to a system or network through a logical connection (e.g., remote access software) as opposed to physically connecting to the device.
- Cardholder Data Environment (CDE): The environment that houses cardholder data or systems that process cardholder data.
Business implication:
- Enhanced Security for ALL CDE Access: Enforcing MFA for all access points to the CDE significantly strengthens your security posture. By requiring multiple verification factors, it becomes much harder for attackers to gain unauthorized access, even if they steal a user's password. This safeguards sensitive cardholder data.
Best practices to meet this requirement:
- Robust MFA Solutions: Implement strong MFA solutions that offer options beyond simple SMS verification codes. Consider hardware tokens, biometrics, or authenticator apps for a stronger security posture.
- User Training: Educate all users with CDE access on the importance of MFA and proper use of their chosen verification factors. This includes best practices for securing their tokens and reporting any loss or compromise.
- MFA for Privileged Users: While not strictly a requirement here, prioritize enforcing MFA for privileged users (administrators) within the CDE. This adds an extra layer of protection for highly sensitive data and actions.
How to comply with this PCI DSS requirement (Effective March 31, 2025):
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.4.2.a | Examine network and/or system configuration settings for the CDE and all connected systems. | The assessor will review your system configuration to verify that MFA is mandatory for ALL access attempts to the CDE. This includes examining settings for remote access software, VPNs, web applications, and any other access points to the CDE environment. |
| 8.4.2.b | Observe personnel logging in to the CDE using various access methods (remote, web-based, etc.). | The assessor may observe simulated or real login processes where users attempt to access the CDE through different methods.During these observations, the assessor will verify that the system prompts for at least two separate verification factors before granting access, regardless of the access method used. |
PCI DSS Requirement 8.4.3: Multi-Factor Authentication (MFA) for Remote Network Access with Potential CDE Impact
This requirement mandates the use of multi-factor authentication (MFA) for ALL remote network access attempts originating from outside the organization's network that could potentially access or impact the Cardholder Data Environment (CDE). This applies to both personnel (users and administrators) and third-party/vendor access.
- Multi-Factor Authentication (MFA): A security method that requires two or more independent verification factors for user authentication. These factors can include something the user knows (password), something the user has (token), or something the user is (biometrics).
- Remote Network Access: Access to an organization's network through an external connection, often via the internet.
- Cardholder Data Environment (CDE): The environment that houses cardholder data or systems that process cardholder data.
Business implication:
- Reduced Risk of External Attacks: Enforcing MFA for remote access significantly strengthens your security posture against external attacks. By requiring multiple verification factors, it becomes much harder for attackers to gain unauthorized access to the CDE, even if they compromise a user's credentials through remote hacking attempts.
Best practices to meet this requirement:
- MFA for ALL Remote Access: Implement MFA for all remote access attempts, regardless of whether they seem directly connected to the CDE. This adds an extra layer of security for your entire network.
- Strong MFA Solutions: Choose robust MFA solutions that offer options beyond simple SMS verification codes. Consider hardware tokens, biometrics, or authenticator apps for a stronger security posture.
- Vendor Access Controls: In addition to MFA, implement additional access controls for third-party and vendor remote access. This might involve least privilege access principles and restrictions on what data or systems they can access remotely.
How to comply with this PCI DSS requirement:
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.4.3.a | Examine network and/or system configuration settings for remote access servers and systems (VPN, remote desktop software, etc.). | The assessor will review your configuration settings to verify that MFA is mandatory for ALL remote access attempts originating from outside your network.They will specifically focus on access methods that could potentially lead to accessing or impacting the CDE. |
| 8.4.3.b | Observe simulated or real remote access attempts by personnel (users and administrators) and third-party vendors. | The assessor may observe simulated scenarios where users from outside the network attempt to remotely access the network.During these observations, the assessor will verify that the system prompts for at least two separate verification factors before granting access.This observation may be extended to vendor access procedures as well. |
PCI DSS Requirement 8.5.1: Secure Multi-Factor Authentication (MFA) Implementation
This requirement, becoming mandatory after March 31, 2025, outlines specific controls for secure Multi-Factor Authentication (MFA) implementation within the Cardholder Data Environment (CDE). It focuses on four key aspects:
- MFA Resilience: The MFA system should be resistant to replay attacks, where an attacker captures and reuses a valid authentication attempt.
- MFA Bypass Prevention: MFA bypasses should be strictly controlled. Any exceptions for administrative overrides must be documented, authorized by management, and limited in time.
- MFA Factor Diversity: At least two different types of authentication factors must be used (e.g., password + token, password + biometrics). Using the same factor twice (e.g., two passwords) doesn't qualify.
- Strict MFA Enforcement: Access should only be granted after successful verification of ALL required authentication factors.
- Multi-Factor Authentication (MFA): A security method that requires two or more independent verification factors for user authentication. These factors can include something the user knows (password), something the user has (token), or something the user is (biometrics).
- Cardholder Data Environment (CDE): The environment that houses cardholder data or systems that process cardholder data.
Business implication:
- Enhanced MFA Security: This requirement ensures your MFA implementation offers robust protection against various attack methods. By requiring strong MFA controls, you significantly reduce the risk of unauthorized access to the CDE, safeguarding sensitive cardholder data.
Best practices to meet this requirement:
- MFA Selection: Choose a robust MFA solution that offers strong resistance to replay attacks and provides options for diverse authentication factors (tokens, biometrics, etc.).
- Documented Bypass Procedures: Establish clear procedures for requesting and authorizing any exceptions to bypass MFA. These exceptions should be rare, documented, have management approval, and have a strict time limit.
- User Training: Educate users on the importance of MFA security and proper use of their chosen authentication factors. This includes best practices for protecting their tokens and reporting any loss or compromise.
How to comply with this PCI DSS requirement (Effective March 31, 2025):
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.5.1.a | Examine vendor documentation for the MFA system to verify its resistance to replay attacks. | The assessor will review the documentation provided by your MFA vendor to ensure it outlines features and mechanisms that prevent replay attacks (e.g., time-based codes, challenge-response mechanisms). |
| 8.5.1.b | Examine system configuration settings for the MFA implementation. | The assessor will review your system configuration to verify it enforces all aspects of this requirement. This includes:No option to bypass MFA without proper authorization.Requirement for at least two different authentication factors.Access granted only after successful verification of all factors. |
| 8.5.1.c | Interview personnel responsible for managing MFA and observe their processes. | The assessor will interview relevant personnel to understand how exceptions to bypass MFA are handled.They will observe the process for requesting, documenting, and authorizing such exceptions, ensuring they are rare, documented, have management approval, and have a limited timeframe. |
| 8.5.1.d & 8.5.1.e | Observe simulated or real login attempts to the CDE (both local and remote). | The assessor will observe users attempting to access the CDE through various methods (local access, remote access).During these observations, the assessor will verify that the system prompts for and validates all required authentication factors before granting access. |
PCI DSS Requirement 8.6.1: Secure Management of System and Application Accounts
This requirement, becoming a mandatory control after March 31, 2025, focuses on the secure management of system and application accounts within the Cardholder Data Environment (CDE). It mandates strict controls when such accounts can be used for interactive login purposes.
- System/Application Accounts: Accounts used by systems or applications to run processes or tasks, typically not for individual user logins. These accounts often have elevated privileges.
- Interactive Login: The ability for a person to log in to a system or application account in the same way as a regular user account.
Business implication:
- Reduced Risk of Privilege Abuse: Enforcing strict controls on interactive logins for system/application accounts significantly reduces the risk of unauthorized access and privilege abuse. Attackers often target such accounts to gain access to sensitive data. By limiting interactive access, you minimize the potential for attackers to exploit these accounts.
Best practices to meet this requirement:
- Minimize Interactive Use: Configure system and application accounts to disallow interactive login whenever possible. This prevents unauthorized individuals from using these privileged accounts.
- Documented Justification: For any exceptional circumstances requiring interactive access, document a clear business justification outlining the specific need and timeframe.
- Management Approval: Require explicit management approval for any instances where interactive access with system/application accounts is necessary.
- Individual User Verification: Even in approved scenarios, implement controls to verify the identity of the individual using the system/application account before granting access.
- User Activity Attribution: Ensure all actions taken through these accounts are attributable to a specific individual user. This improves audit trails and accountability.
How to comply with this PCI DSS requirement (Effective March 31, 2025):
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.6.1.a | Examine system and application account configurations to identify those that allow interactive login. | The assessor will review your system configurations to identify accounts designated as system/application accounts that also have interactive login capabilities enabled. |
| 8.6.1.b | Interview administrative personnel responsible for managing these accounts. | The assessor will interview relevant personnel to understand the processes for handling interactive access requests with system/application accounts.This will involve verifying aspects like documented justification, management approval, individual user verification, and user activity attribution. |
PCI DSS Requirement 8.6.2: Secure Storage of Passwords for Interactive System/Application Accounts
This requirement, becoming mandatory after March 31, 2025, focuses on the secure storage of passwords or passphrases used by system and application accounts that can be used for interactive login purposes within the Cardholder Data Environment (CDE). It prohibits the practice of hardcoding these credentials in scripts, configuration files, or custom code.
- System/Application Accounts: Accounts used by systems or applications to run processes or tasks, typically not for individual user logins. These accounts often have elevated privileges.
- Interactive Login: The ability for a person to log in to a system or application account in the same way as a regular user account.
- Hardcoded Credentials: Embedding passwords or passphrases directly within scripts, configuration files, or custom code. This makes them easily accessible to anyone with access to those files.
Business implication:
- Reduced Risk of Credential Theft: By eliminating hardcoded credentials, you significantly reduce the risk of unauthorized individuals gaining access to privileged accounts. Exposed credentials in scripts or code can be easily exploited by attackers to gain access to sensitive data or systems.
Best practices to meet this requirement:
- Secure Password Management: Implement secure password management practices for system and application accounts. This could involve using password vaults, credential managers, or other secure storage solutions.
- Regular Credential Rotation: Rotate passwords for these accounts regularly to minimize the impact of any potential compromise.
- Code Review Processes: Integrate code review processes to identify and remove any instances of hardcoded credentials within scripts or custom code.
How to comply with this PCI DSS requirement (Effective March 31, 2025):
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.6.2.a | Interview personnel responsible for system and application development. | The assessor will interview relevant personnel to understand the established procedures for managing passwords/passphrases used by system/application accounts with interactive login capabilities.This interview will focus on verifying that these procedures explicitly prohibit hardcoding credentials in scripts, configuration files, or custom code. |
| 8.6.2.b | Examine scripts, configuration files, and custom code associated with system and application accounts that allow interactive login. | The assessor will review relevant code and configuration files to verify the absence of hardcoded passwords or passphrases for these accounts.This may involve code review tools or manual inspection of the codebase. |
PCI DSS Requirement 8.6.3 : Strong Password Management for System/Application Accounts
This requirement, becoming mandatory after March 31, 2025, focuses on strong password management practices for system and application accounts within the Cardholder Data Environment (CDE). It mandates regular password changes and enforces password complexity requirements based on your risk assessment.
- System/Application Accounts: Accounts used by systems or applications to run processes or tasks, typically not for individual user logins. These accounts often have elevated privileges.
- Password Complexity: The strength of a password determined by a combination of factors like length, character types (uppercase, lowercase, numbers, symbols), and special characters.
Business implication:
- Reduced Risk of Privilege Escalation: Enforcing strong password management for system/application accounts significantly reduces the risk of unauthorized access and privilege escalation. By requiring regular password changes and complex passwords, you make it much harder for attackers to compromise these accounts and gain access to sensitive systems or data.
Best practices to meet this requirement:
- Password Policy Definition: Develop a clear password policy that outlines the password complexity requirements and change frequency based on your risk assessment (performed according to PCI DSS Requirement 12.3.1).
- Password Complexity: Enforce strong password complexity requirements. Consider password length of at least 15 characters with a combination of uppercase, lowercase letters, numbers, and special characters.
- Regular Password Changes: Rotate passwords for system/application accounts at regular intervals as defined in your password policy. More frequent changes are recommended for less complex passwords.
- Secure Password Storage: Store passwords securely using password vaults or credential managers. Avoid storing passwords in plain text or within scripts or code.
How to comply with this PCI DSS requirement (Effective March 31, 2025):
| Requirement | Actions Required | How the Assessment is Done |
|---|---|---|
| 8.6.3.a | Examine password policies and procedures to verify they address protecting passwords for system/application accounts against misuse. | The assessor will review your documented password policies and procedures to ensure they cover:Regular password changes based on risk assessment.Password complexity requirements. |
| 8.6.3.b | Examine your targeted risk assessment for password change frequency and complexity for system/application accounts. | The assessor will review your risk assessment to verify it addresses:Frequency for periodic password changes for these accounts.Defined password complexity considering the change frequency.They will also ensure the risk assessment was performed according to PCI DSS Requirement 12.3.1. |
| 8.6.3.c | Interview personnel and examine system configurations. | The assessor will interview relevant personnel to understand how password changes are managed for system/application accounts.They will also examine system configurations to verify enforcement of password complexity requirements. |
