PCI DSS: what it asks of an account list

Vendor default accounts must be handled as follows: (a) where a vendor default account will be used, its default password is changed in line with Requirement 8.3.6; and (b) where it will stay unused, the account is disabled or deleted. Applicability: every vendor default account and password is covered, for example those of operating systems, security software, application and system accounts, POS terminals, payment applications and SNMP defaults; it also applies to components not installed in the entity's environment, such as CDE software and applications consumed through a cloud subscription. Objective under the customized approach: default passwords cannot be used to access system components.

All user accounts and their related access privileges, including third-party and vendor accounts, must be reviewed at least every six months. The review must confirm that accounts and access remain appropriate for each person's job function, any inappropriate access must be dealt with, and management must acknowledge that the remaining access is appropriate. The guidance notes the review is also a chance to catch terminated users and third parties whose access was missed. Applicability: covers every user account and related privilege, including accounts of personnel, of vendors and of other third parties and accounts used to reach third-party cloud services; application and system accounts are handled instead by Requirement 7.2.5 (and its sub-requirement) and by 8.6.1 to 8.6.3. Objective under the customized approach: management periodically verifies that account privilege assignments are correct and remediates nonconformities. Future-dated: treated as a best practice up to 31 March 2025 and mandatory since then.

Every application and system account and its related access privileges must be assigned and managed so that: privileges are the least needed for the system or application to operate; and access is limited to those systems, processes or applications that have a specific need for the account. The guidance explains that a compromised service account gives an attacker whatever the account can reach, and suggests entities may consider a baseline that keeps such accounts out of privileged groups such as domain or local administrators or root, restricts the machines and hours they can be used, and removes VPN or remote access. Objective under the customized approach: the rights given to system and application accounts are confined to what that application or system needs to operate. Future-dated: treated as a best practice up to 31 March 2025 and mandatory since then.

All access held by application and system accounts, together with their related privileges, must be reviewed periodically, at a frequency set by the entity's own targeted risk analysis carried out as Requirement 12.3.1 specifies. Each review must confirm that the account's access is still appropriate for the function it performs, address any inappropriate access, and record management's acknowledgement that the access remains appropriate. Objective under the customized approach: management periodically verifies that privilege assignments for application and system accounts are correct and remediates nonconformities. Future-dated: treated as a best practice up to 31 March 2025 and mandatory since then.

Each user must be given a unique ID before being permitted to reach any system component or cardholder data. The guidance explains that unique identification keeps actions traceable to one person, supports individual accountability and an effective audit trail, and helps resolve and contain misuse. Applicability: not intended for point-of-sale terminal user accounts that are limited to a single card number per transaction. Customized approach objective: every action by every user can be attributed to an individual.

Group, shared or generic IDs, and any other shared authentication credentials, may be used only where needed as an exception, and must be managed so that: use of the ID is blocked unless an exceptional circumstance calls for it; use lasts only as long as the exceptional circumstance requires; a business justification is documented; management explicitly approves the use; the identity of the individual is verified before the account is made available; and every action taken is attributable to one individual user. The guidance suggests password vaults or controls like sudo, and gives a break-glass emergency account as an example of an exception. Applicability: not intended for point-of-sale terminal user accounts that are limited to a single card number per transaction. Objective under the customized approach: all actions carried out with group, shared or generic IDs can be attributed to an individual person.

Any addition, deletion or modification of a user ID, an authentication factor or another identifier object must be: authorized with appropriate approval; and carried out with only the privileges stated on the documented approval. The guidance stresses detecting IDs created or changed outside the normal process, since attackers often escalate an existing account or create new IDs. Applicability: covers every user account, whether held by employees, contractors, consultants, temporary staff or third-party vendors. Objective under the customized approach: no lifecycle event affecting a user ID or authentication factor can occur without appropriate authorization.

Access for users who have been terminated must be revoked immediately. The testing procedures check both local and remote access lists for terminated IDs and confirm that any physical authentication factor, for example a token or smart card, has been deactivated or handed back. The guidance explains that a former employee or third party who keeps a working account, or an attacker who takes over an abandoned one, could reach cardholder data. Objective under the customized approach: accounts belonging to terminated users cannot be used.

A user account must be disabled or removed once it has gone unused for 90 days. The guidance explains that unused accounts are attractive targets because changes to them, such as a new password, tend to go unnoticed, and advises that where an extended absence such as a leave of absence is expected, the account be disabled when the absence begins rather than after 90 days. Objective under the customized approach: inactive user accounts cannot be used.

Where a third party reaches, supports or maintains system components remotely, the accounts it uses must be: switched on only for as long as needed and switched off when idle; and monitored for unexpected activity. The guidance advises that where round-the-clock access is genuinely needed it be recorded, justified, watched and linked to particular service needs, and suggests start and stop dates aligned with the service contract. Objective under the customized approach: remote access by third parties is unusable unless specifically authorized, and management oversees its use.

If user access relies on a password or passphrase alone (any single-factor implementation), one of these must hold: the password or passphrase is replaced no less often than every 90 days; or account security posture is assessed dynamically, with access to resources decided automatically and in real time from that assessment. The guidance notes that dynamic analysis may weigh data points such as device integrity, location, access times and resources requested. Applicability: does not apply to in-scope components where MFA is used; not intended for point-of-sale terminal user accounts that are limited to a single card number per transaction. Customer accounts of service providers are excluded, while accounts used by service provider staff are included. Objective under the customized approach: an undetected compromised password or passphrase cannot be used indefinitely.

Where a system or application account is capable of interactive login, it must be managed so that: interactive use is prevented unless an exceptional circumstance requires it; interactive use lasts no longer than the exceptional circumstance requires; the business justification is documented; management explicitly approves interactive use; the individual's identity is verified before the account is made available; and each action performed is attributable to one individual user. The guidance advises that, where possible, such accounts be configured to disallow interactive login and limited to specific machines and devices. Objective under the customized approach: whenever system or application accounts are used interactively, each action is authorized and traceable to one person. Future-dated: treated as a best practice up to 31 March 2025 and mandatory since then.

Passwords or passphrases belonging to any application or system account capable of interactive login must never be hard coded in scripts, in configuration or property files, or in bespoke or custom source code. The guidance suggests password vaults and other system-managed controls can help. Applicability: stored passwords must be encrypted in line with Requirement 8.3.2. Objective under the customized approach: unauthorized personnel are unable to use the passwords and passphrases of application and system accounts. Future-dated: treated as a best practice up to 31 March 2025 and mandatory since then.

Passwords or passphrases used by system and application accounts must be protected against misuse so that: they are changed periodically, at the frequency set by the entity's own targeted risk analysis performed per Requirement 12.3.1, and upon suspected or confirmed compromise; and they are built with enough complexity for how often the entity changes them. The guidance lists risk factors to weigh (how securely they are stored, such as in a vault; staff turnover; how many people can reach the factor; whether interactive login is possible; and whether dynamic posture analysis is used) and advises that complexity be stricter where changes are infrequent. Objective under the customized approach: passwords of application and system accounts cannot stay usable indefinitely and are built so that guessing and brute-force attacks fail. Future-dated: treated as a best practice up to 31 March 2025 and mandatory since then.