Authentication
PCIComplianceHubLast updated
Proving that the account attempting access belongs to the person, device or process claiming it, by presenting one or more authentication factors: something known, something held, or something the claimant is. PCI DSS requires it for all user access to system components, and requires two or more factor types for all non-console access into the Cardholder Data Environment and for remote access from outside the entity's network that could reach or affect it. It answers who; authorisation, which follows it, answers what they may do.
Applies to. 8.3.1 applies it to all user access to system components, for users and administrators alike, and 8.3.2 requires the factors themselves to be rendered unreadable with strong cryptography during transmission and storage. 8.2.2 adds that the identity proven must be an individual's: group, shared or generic credentials are allowed only by documented, management-approved exception, for the time the exceptional circumstance lasts, with each person's identity confirmed before access and every action still attributable to one user. Where the access is non-console access into the CDE, or remote access from outside the entity's network that could access or impact the CDE, 8.4.2 and 8.4.3 require multi-factor authentication.
Example. A store manager logs in to the back-office system that holds the day's card transactions. Her user ID names the account; the password she types is the factor that proves the account is hers. When she connects to the same system from home over the company VPN, 8.4.3 means a second factor, a code from an authenticator app on her phone, is required before the session opens.
Limits. Authentication is neither identification nor authorisation. The user ID identifies which account is being claimed, authentication proves the claim, and authorisation, governed by the access control model in 7.2.1, decides what the proven identity may then do. Sensitive authentication data (SAD) is a different thing again: it is data received during a card transaction's authorisation, which 3.3.1 forbids storing once that authorisation completes, and it plays no part in logging a user in.