Are 3DS Authentication Values Sensitive Authentication Data Under PCI DSS?

When CAVV and AAV values flow through a 3DS authentication response, the natural question for a dev team is: do we need to treat these like card data? Do they need to be deleted after authorization? Do they trigger the same storage restrictions as a PAN or CVV? No. In March 2026, the PCI Security Standards Council published FAQ 1603 confirming that 3DS authentication values, including the CAVV (Cardholder Authentication Verification Value) and the AAV (Accountholder Authentication Value), are not sensitive authentication data under PCI DSS. PCI DSS does not prohibit storing them.

The confusion is understandable. These values are cryptographic, transaction-specific, and tied directly to the security of an authentication event. They look like the kind of data PCI DSS would restrict. But the standard defines sensitive authentication data with precision, and 3DS authentication values fall outside that definition by design.

For the full picture on how 3DS authentication works, read our Understanding the Essential 3DS Data Fields for Authorization Success article.

What PCI DSS Defines as Sensitive Authentication Data

PCI DSS sensitive authentication data covers three specific categories: full magnetic-stripe data, card verification codes and values (CVV, CVC), and PINs or PIN blocks. Requirement 3.3 prohibits storing any of these after authorization completes.

The restriction exists because these values can be used to initiate fraudulent transactions. Full track data can clone a card. A CVV enables card-not-present fraud. A PIN enables cash withdrawal. The common thread is that these are card credentials, reusable across transactions, and dangerous in the wrong hands.

The CAVV and AAV are different in kind. They are cryptographic outputs generated by the issuer's Access Control Server at the end of a specific authentication exchange. They confirm that authentication happened for that transaction and allow the issuer's authorization system to verify the result. They are bound to a single transaction. They cannot be replayed, cannot be used to clone a card, and cannot initiate a new transaction. That's why they sit outside the SAD definition, and why the PCI SSC was willing to say so explicitly in FAQ 1603.

Which Standard Does Apply

The CAVV and AAV are classified as sensitive data under the PCI 3DS Core Security Standard, specifically for entities operating 3DS infrastructure: 3DS Servers, Directory Servers, and Access Control Servers. This is a fundamentally different compliance regime from PCI DSS. Where PCI DSS governs how merchants and service providers handle card data, PCI 3DS Core governs the security of the authentication infrastructure itself: the systems that generate, transmit, and verify 3DS messages. The entities in scope are those building or operating that infrastructure, not those consuming the results it produces.

For a merchant or service provider receiving authentication results, the distinction matters practically. You are a consumer of 3DS output, not an operator of 3DS infrastructure. The obligations that apply to the Access Control Server generating the CAVV are not obligations that transfer downstream to the party receiving it.

FAQ 1603 is explicit that entities performing 3DS functions should confirm with the relevant card brands whether PCI 3DS Core certification is required for their specific role. If you're not operating a 3DS Server, Directory Server, or ACS, that question likely has a short answer.

What This Means in Practice

For merchants and service providers receiving CAVV or AAV values as part of a strong customer authentication flow, PCI DSS imposes no post-authorization deletion requirement on these values. You don't need to build a deletion routine into your post-auth flow. You don't need to exclude these values from your transaction records or treat them as restricted data in your storage layer.

There's a practical reason to retain them. CAVV and AAV are the evidence that authentication occurred. In a dispute or chargeback, the liability shift to the issuer depends on being able to demonstrate that a valid 3DS authentication took place. A merchant who retains the CAVV or AAV, along with the ECI code, has the documentation to support that claim. A merchant who discards them on the assumption they were restricted data is in a weaker position. Retention isn't just permissible. For any merchant relying on liability shift as part of their fraud strategy, it's the right default.

How long to retain them is a separate question, and not one PCI DSS answers for you. Data minimization principles, contractual terms with acquirers, and applicable privacy regulation all bear on that decision. The PCI DSS classification removes one constraint. It doesn't eliminate the others.

For teams using PCI Proxy as their 3DS provider, the practical picture is straightforward. PCI Proxy operates the 3DS infrastructure, managing the interaction with the Directory Server and the ACS on your behalf. The PCI 3DS Core obligations sit with PCI Proxy as the infrastructure operator. When authentication completes, PCI Proxy returns the result through its API: the ECI code, the CAVV or AAV, and the authentication status. Your systems receive the output without ever touching the infrastructure that generates it. That's the boundary that keeps PCI 3DS Core obligations upstream. Merchants and service providers using PCI Proxy can store those returned values without PCI DSS prohibiting it, and without inheriting the infrastructure compliance obligations that sit with PCI Proxy.