PCI DSS 8.3.2: Strong cryptography is used to render all authentication factors unreadable during transmission
PCI DSS v4.0.1 control 8.3.2: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 8.3.
Requirement 8: Identify Users and Authenticate Access to System Components › Section 8.3
Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.
Summary
Every authentication factor is unreadable in storage and in transit, everywhere it exists, using strong cryptography.
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.3.2.a | Examine vendor documentation and system configuration settings to verify that authentication factors are rendered unreadable with strong cryptography during transmission and storage. |
| 8.3.2.b | Examine repositories of authentication factors to verify that they are unreadable during storage. |
| 8.3.2.c | Examine data transmissions to verify that authentication factors are unreadable during transmission. |
Three procedures testing three different places, and they are examined directly rather than described. 8.3.2.a reads vendor documentation and configuration, 8.3.2.b examines the repositories where factors are stored, and 8.3.2.c examines data transmissions. So a claim that the platform handles it is not the evidence; the assessor looks at the store and at the traffic. Two words widen this beyond the obvious. All authentication factors means certificate private keys and token seed files as well as passwords. All system components means every place a factor comes to rest, which includes configuration backups, directory replicas, and the local password stores on network devices and appliances that nobody thinks of as identity systems.
What to prepare
- An inventory of every place authentication factors are stored, including appliances and network gear with local accounts.
- What protects each: the algorithm for stored factors, the transport for factors in flight.
- Vendor documentation for how each product stores factors, since 8.3.2.a asks for it.
- A capture or configuration evidence for the internal authentication traffic, not only the public login page.
How to implement it
1. Protect the internal hops, not just the front door. The browser to the load balancer is usually fine. LDAP binds, RADIUS, database connections and service-to-service authentication are where factors still travel unprotected, and 8.3.2.c examines transmissions rather than the login form.
2. Look inside the repository yourself first. 8.3.2.b is a direct examination, so open the store and see what is in it. Disk encryption underneath an application that can read the values back is not the same as the values being unreadable.
3. Include the certificate keys and token seeds. They are authentication factors and they are usually stored with less care than passwords, often in a file share or a build artefact.
4. Sweep the appliances. Firewalls, switches, printers and management controllers hold local credentials and are the components most often outside the identity review.
Where this commonly fails
- Stored factors protected only by full-disk encryption, which is not the same as unreadable in the repository.
- The public login protected and internal authentication protocols left in the clear.
- Certificate private keys exported without a passphrase and left where they were used.
- Legacy or embedded systems with local credential stores excluded because they were never in the identity inventory.
Related controls
Others in section 8.3:
| Control | What it requires |
|---|---|
| 8.3.1 | All user access to system components for users and administrators is authenticated via at least… |
| 8.3.3 | User identity is verified before modifying any authentication factor |
| 8.3.4 | Invalid authentication attempts are limited… |
| 8.3.5 | If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user… |
| 8.3.6 | If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity… |
| 8.3.7 | Individuals are not allowed to submit a new password/passphrase that is the same as any… |
| 8.3.8 | Authentication policies and procedures are documented and communicated to all users… |
| 8.3.9 | If passwords/passphrases are used as the only authentication factor for user access… |
| 8.3.10 | Service providers: If passwords/passphrases are used as the only authentication factor for customer user access to cardholder data (i.e., in any single-factor authentication implementation), then guidance is provided to customer users… |
| 8.3.10.1 | Service providers: If passwords/passphrases are used as the only authentication factor for customer user access (i.e., in any single-factor authentication implementation) then either… |
| 8.3.11 | Where authentication factors such as physical or logical security tokens, smart cards… |
← 8.3.1 · All controls · 8.3.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.