1

I am designing a system that uses a certain biometric vector as a secondary user identification step before authorizing a payment. My system does not handle payment card details, rather the payment card processor consumes my service to authenticate the user (as an additional step). In order to do this, my system needs to register a biometric vector of the user in its database, for comparison against subsequent authentication requests.

Following is a definition of what entities come under PCI scope.

The PCI DSS applies to all entities involved in payment card processing, including merchants, processors, acquirers, issuers and service providers. It also applies to all other entities that store, process or transmit cardholder data or sensitive authentication data.

Source: https://www.onespan.com/blog/multi-factor-authentication-comply-pci-dss-32

Since my system does not store or process card holder data AND it is located in a separate environment (a remote REST service), the only possibility of it coming under PCI scope would be if it is hosting sensitive authentication data (SAD).

By PCI's definition, SAD is:

Security-related information (including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions. Source: Pg 19 of https://www.pcisecuritystandards.org/documents/PCI_DSS_Glossary_v3-2.pdf

Sources such as this one indicate that SAD is data that is available on the card itself.

However, the PCI definition does not clearly indicate whether SAD is only considered as data available on the card itself or not.

Can anyone provide any direction or guidance on this matter? Would such biometric vectors be considered as SAD in the PCI scope?

Heshan Perera
  • 125
  • 4

2 Answers2

2

I'd say no. SAD is information relied on by the card issuer to authenticate a transaction. So PINs/PIN Blocks, full track data and CVC2 are all placed on the card by the issuer (OK, that is simplistic for PIN) and only used by the issuer to validate the card and the customer during the authorization process.

The table on P7 of v3.2.1 of PCI DSS is the authoritative reference, the glossary is not normative.

However, technically you are a service provider to the processor, and they may require you to comply with PCI DSS as a contractual measure because that what allows them to be comfortable about your security, whether or not it strictly applies from a card brand perspective.

withoutfire
  • 1,000
  • 4
  • 7
1

PCI/DSS states that SAD is:

Security-related information (...) used to authenticate cardholders ...

So from the definition in the PCI/DSS, I'd say yes.

The point about not storing the information after the authentication is, that when, for example, a merchants database is compromised, the information therein cannot be used to make a false authentication (for example in a replay attack). So, whether or not it is actually SAD might be perhaps a point of discussion, whether or not you would be allowed to store it should be clear (don't store).

In the EU, there are of course other reasons as well for not storing such data, for example the GDPR.

Ljm Dullaart
  • 1,897
  • 4
  • 11
  • Thanks for the feedback. What you are saying makes sense in terms it may coming under PCI compliance. However, I do not have an option when it comes to saving this data. It has to be saves as it is a vital component of the solution. – Heshan Perera Jul 29 '20 at 15:02