PCI DSS 2.2.2: Vendor default accounts
PCI DSS v4.0.1 control 2.2.2: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 2.2.
Requirement 2: Apply Secure Configurations to All System Components › Section 2.2
Vendor default accounts are managed as follows:
- If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6.
- If the vendor default account(s) will not be used, the account is removed or disabled.
Summary
Change the password on every vendor default account you intend to use, and remove or disable every one you do not.
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 | |
|---|---|
| 2.2.2.a | Examine system configuration standards to verify they include managing vendor default accounts in accordance with all elements specified in this requirement. |
| 2.2.2.b | Examine vendor documentation and observe a system administrator logging on using vendor default accounts to verify accounts are implemented in accordance with all elements specified in this requirement. |
| 2.2.2.c | Examine configuration files and interview personnel to verify that all vendor default accounts that will not be used are removed or disabled. |
The oldest control in the standard and still among the most commonly failed, because defaults arrive with things nobody installed on purpose: an appliance, a database image, a management interface bundled with a package, a device rebuilt from a vendor image last week. Three procedures: 2.2.2.a examines policies, 2.2.2.b examines system configurations, 2.2.2.c interviews and examines documentation to verify defaults were changed or the accounts removed. Note the split: if you use a default account, the password rule is 8.3.6; if you do not, the account has to go rather than merely be given a good password. The safer route is almost always removal.
What to prepare
- An inventory of system components with, for each, the vendor default accounts it shipped with and what happened to them.
- Evidence from configuration rather than from policy, showing accounts removed or disabled.
- The build process step that handles defaults on newly provisioned systems.
How to implement it
1. Enumerate defaults from the vendor documentation, not from memory. Most products ship with more accounts than the one people know about: a service account, a maintenance account and a read-only account are common, and only the admin one gets changed.
2. Prefer removal to rotation. An account you do not use is a permanent obligation if you keep it, and one fewer thing to evidence if you remove it. Disabling is acceptable where removal breaks the product.
3. Fold this into the build. A default handled by hand after provisioning is a default that returns the next time the image is rebuilt, which is what makes this control recur at every assessment.
4. Include the things that are not servers. Network appliances, printers with card-adjacent scanning, wireless controllers, hypervisors and out-of-band management cards all ship with defaults and are all system components.
Where this commonly fails
- Changing the interactive admin password and leaving a default service or maintenance account untouched.
- A default rotated once, then restored by a rebuild from the original image.
- Wireless and network appliance defaults treated as out of scope because the device does not process card data itself.
- Documentation asserting compliance that 2.2.2.b contradicts on the device.
Related controls
This control refers to 8.3.6.
Others in section 2.2:
| Control | What it requires |
|---|---|
| 2.2.1 | Configuration standards are developed, implemented, and maintained… |
| 2.2.3 | Primary functions requiring different security levels… |
| 2.2.4 | Only necessary services, protocols, daemons, and functions are enabled… |
| 2.2.5 | If any insecure services, protocols, or daemons are present… |
| 2.2.6 | System security parameters are configured to prevent misuse |
| 2.2.7 | All non-console administrative access is encrypted using strong cryptography |
← 2.2.1 · All controls · 2.2.3 →
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.