Frequently Asked Question
Are authentication values from a 3DS transaction considered sensitive authentication data for PCI DSS purposes?
No. PCI DSS sensitive authentication data (SAD) consists of full magnetic-stripe data, card verification codes or values, and PINs or PIN blocks. PCI DSS specifically prohibits storage of SAD after completion of the authorization process.
The 3-D Secure (3DS) authentication value is a cryptographic value generated by the 3DS Access Control Server that allows the authorization system to validate the integrity of the authentication result during authorization processing. This 3DS value is also referred to as the cardholder authentication value (CAVV) and the accountholder authentication value (AAV). The authentication value is one of the data elements identified as 3DS sensitive data in the PCI 3DS Data Matrix in Table 1: 3DSS, DS, and ACS Sensitive Data Elements. Data elements included in this table are subject to the requirements in the PCI 3DS Core Security Standard that apply to 3DS sensitive data.
3DS authentication values and other 3DS sensitive data are not considered to be SAD from a PCI DSS perspective and PCI DSS does not prohibit 3DS sensitive data from being stored after the authorization process is complete.
Entities performing or providing any of the following 3DS functions: 3DS Server, 3DS Directory Server, and/or 3DS Access Control Server should confirm with the payment brand(s) for which they perform these 3DS functions whether they are required to meet the requirements in the PCI 3DS Core Security Standard.
Related
-
Should entities with enterprise or internal service providers, used to provide internal services to other corporate entities, conduct separate PCI DSS assessments of these service providers or include them as part of each corporate entity’s PCI DSS assessment?
-
What is the impact if an entity uses a third-party service provider (TPSP) to meet a PCI DSS requirement(s), when that TPSP’s PCI DSS assessment completion date is close to a year ago, as documented in the TPSP’s Attestation of Compliance (AOC)?
Featured FAQ Articles
Featured
-
Do PCI DSS requirements for keyed cryptographic hashing apply to previously hashed PANs?
-
Is the PCI DSS Attestation of Compliance intended to be shared?
-
How does an entity report the results of a PCI DSS assessment for new requirements that are noted in PCI DSS as best practices until a future date?
-
Where do I direct questions about complying with PCI standards?
-
Can SAQ eligibility criteria be used as a guide for determining applicability of PCI DSS requirements for merchant assessments documented in a Report on Compliance?
Most Popular
-
Are authentication values from a 3DS transaction considered sensitive authentication data for PCI DSS purposes?
-
Should entities with enterprise or internal service providers, used to provide internal services to other corporate entities, conduct separate PCI DSS assessments of these service providers or include them as part of each corporate entity’s PCI DSS assessment?
-
What is the impact if an entity uses a third-party service provider (TPSP) to meet a PCI DSS requirement(s), when that TPSP’s PCI DSS assessment completion date is close to a year ago, as documented in the TPSP’s Attestation of Compliance (AOC)?
-
Are Approved Scanning Vendors and Qualified Security Assessors considered third-party service providers for PCI DSS Requirements 12.8 and 12.9?
-
What are the expectations for entities when assigning risk rankings to vulnerabilities and resolving or addressing those vulnerabilities?
Most Recently Updated
-
Are authentication values from a 3DS transaction considered sensitive authentication data for PCI DSS purposes?
-
Is sampling allowed in PCI DSS v4.x?
-
How does PCI DSS apply to payment terminals?
-
How does encrypted cardholder data impact PCI DSS scope?
-
How does encrypted cardholder data impact PCI DSS scope for third-party service providers?