PCI DSS 8.3.3: User identity is verified before modifying any authentication factor
PCI DSS v4.0.1 control 8.3.3: the requirement in full, the 1 testing procedure 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
User identity is verified before modifying any authentication factor.
Summary
Before you change anyone's authentication factor, prove they are who they say they are.
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.3 | Examine procedures for modifying authentication factors and observe security personnel to verify that when a user requests a modification of an authentication factor, the user’s identity is verified before the authentication factor is modified. |
The help-desk control, and the one that social engineering aims at directly. The procedure observes security personnel handling a request, so it is demonstrated rather than described, and the demonstration is where a good written process meets what the desk actually does under pressure. "Any authentication factor" is the phrase that matters now: it covers re-enrolling multi-factor authentication, not just resetting a password. An attacker who can get a new device enrolled has defeated 8.4.1 through 8.4.3 without touching them, which is why the verification standard for an MFA reset should be at least as high as for a password.
What to prepare
- The verification procedure, naming what counts as proof of identity.
- The staff who perform it, available to be observed.
- Records of recent resets showing what verification was used.
- The escalation path for when verification fails.
How to implement it
1. Verify with something an attacker cannot research. Employee ID, date of birth, manager's name and address are all discoverable or breached. A callback to a number already on record, a manager confirmation through a separate channel, or an in-person check are not.
2. Hold MFA re-enrolment to the same bar as everything else. It is the higher-value request and it is frequently the one with the looser process, because it feels like helping someone locked out.
3. Give the desk permission to refuse. Verification only works if declining is an acceptable outcome, and staff need to know that in advance rather than deciding it during an urgent call.
4. Record what was used, not just that it happened. "Identity verified" in a ticket cannot be assessed. Naming the method can.
Where this commonly fails
- Verification questions answerable from a public profile or a past breach.
- MFA re-enrolment handled more loosely than a password reset, inverting the risk.
- An urgent caller claiming seniority, which is the scenario the observation in the procedure is designed to surface.
- Self-service reset flows that verify with an email address the attacker already controls.
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.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.2 · All controls · 8.3.4 →
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.