PCI DSS 8.3.11: Where authentication factors such as physical or logical security tokens, smart cards
PCI DSS v4.0.1 control 8.3.11: 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
Where authentication factors such as physical or logical security tokens, smart cards, or certificates are used:
- Factors are assigned to an individual user and not shared among multiple users.
- Physical and/or logical controls ensure only the intended user can use that factor to gain access.
Summary
Tokens, smart cards and certificates belong to one named person, and holding one must not be enough on its own to get in.
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.11.a | Examine authentication policies and procedures to verify that procedures for using authentication factors such as physical security tokens, smart cards, and certificates are defined and include all elements specified in this requirement. |
| 8.3.11.b | Interview security personnel to verify authentication factors are assigned to an individual user and not shared among multiple users. |
| 8.3.11.c | Examine system configuration settings and/or observe physical controls, as applicable, to verify that controls are implemented to ensure only the intended user can use that factor to gain access. |
The second bullet is the substance: physical and/or logical controls ensure only the intended user can use that factor. Possession alone is not supposed to be sufficient, which is why a smart card has a PIN and why a certificate should have a passphrase or live in hardware. A certificate that can be copied off a laptop makes whoever copied it the user, and it will still show as assigned to an individual in the register. The three procedures test the policy, then interview personnel about sharing, then examine configuration or observe the physical control, so the second bullet is checked against the mechanism rather than the intent. Note the scope: this covers factor types wherever they are used, not only the multi-factor implementations in 8.4.1 and its siblings, so a certificate used as a sole factor is in scope too.
What to prepare
- The register of issued factors, showing one named holder each.
- The policy covering issue, use and return, since 8.3.11.a examines it for both elements.
- The mechanism binding each factor to its user: PIN, biometric, passphrase, hardware storage.
- Configuration or a physical control to demonstrate, as 8.3.11.c requires.
How to implement it
1. Bind possession to something else. A PIN on the card, a passphrase on the certificate, or a key stored in a TPM or hardware token. Without it the factor authenticates whoever is holding it.
2. Make certificates non-exportable where the platform supports it. It is the practical form of the second bullet for software certificates, and it is a setting at issuance that cannot be applied retrospectively.
3. Keep the register per person, and reconcile it. Shared tokens usually appear where one was issued to a team, and the register is where that becomes visible.
4. Handle the return path. A factor assigned to someone who has left is neither returned nor deactivated, which fails here as well as in 8.2.5.
Where this commonly fails
- A drawer of shared tokens for a team or a shift, which fails the first bullet outright.
- Certificates issued as exportable and copied between machines, so possession is not tied to a person.
- A smart card with no PIN, which is a physical key rather than a bound factor.
- Certificates treated as configuration rather than as authentication factors, so they never enter the register at all.
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.2 | Strong cryptography is used to render all authentication factors unreadable during transmission… |
| 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.10.1 · All controls · 8.4.1 →
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.