PCI DSS 8.2.7: Accounts used by third parties to access, support
PCI DSS v4.0.1 control 8.2.7: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 8.2.
Requirement 8: Identify Users and Authenticate Access to System Components › Section 8.2
Accounts used by third parties to access, support, or maintain system components via remote access are managed as follows:
- Enabled only during the time period needed and disabled when not in use.
- Use is monitored for unexpected activity.
Summary
Third-party remote access accounts stay disabled until they are needed, get switched off again afterwards, and their use is watched.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 8.2.7 | Interview personnel, examine documentation for managing accounts, and examine evidence to verify that accounts used by third parties for remote access are managed according to all elements specified in this requirement. |
Two bullets, and the first one is stronger than it looks: enabled only during the time period needed and disabled when not in use. That makes these accounts off by default, so a standing vendor account that is always enabled fails this control regardless of how well it is monitored. The second bullet says use is monitored for unexpected activity, which is a review obligation and not only a logging one: capturing the session and never looking at it does not meet it. This is the account-level counterpart to the relationship-level controls in 12.8.2 and 12.8.4, and the connection it uses should appear on the diagram required by 1.2.3.
What to prepare
- The list of third-party accounts with remote access, and who owns each relationship.
- The enable and disable process, with records showing the windows.
- The monitoring in place and evidence that someone reviews it.
- Recent examples: a support session enabled, used, disabled, reviewed.
How to implement it
1. Make enabling a request with an expiry. A time-bounded enable is easier to operate than a promise to disable afterwards, and the expiry is the evidence for the first bullet.
2. Give each vendor its own account. A shared support account cannot be enabled for the time one vendor needs it, and it makes the monitoring in the second bullet unattributable.
3. Review the sessions, and record that you did. Alerting on out-of-window use is the cheapest form of this, because the window is already defined by the first bullet.
4. Tie the account to the contract. When the relationship ends the account should end with it, and that only happens if someone owns the pairing.
Where this commonly fails
- A permanently enabled vendor account justified by the possibility of an urgent support need.
- Sessions recorded and never reviewed, which logs activity without monitoring for unexpected activity.
- One shared account across several vendors, so neither bullet can be met per party.
- Accounts left enabled after a project finished, because disabling was nobody's task.
Related controls
Others in section 8.2:
| Control | What it requires |
|---|---|
| 8.2.1 | All users are assigned a unique ID before access to system components or cardholder data… |
| 8.2.2 | Group, shared, or generic IDs, or other shared authentication credentials are only used… |
| 8.2.3 | Service providers with remote access to customer premises use unique authentication factors… |
| 8.2.4 | Addition, deletion, and modification of user IDs, authentication factors… |
| 8.2.5 | Access for terminated users is immediately revoked |
| 8.2.6 | Inactive user accounts are removed or disabled within 90 days of inactivity |
| 8.2.8 | If a user session has been idle for more than 15 minutes… |
← 8.2.6 · All controls · 8.2.8 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.