Skip to main content

PCI PIN On COTS - Changing The Paradigm For PIN Acceptance

Just this month (Jan 2018) PCI released the security requirements for their new standard – Software PIN on COTS. But what is this standard?  Does it affect you, or how you do business?  What exactly is a ‘COTS’ anyway?  In this blog post I will try to break down some of these questions, as well as some others that may be raised in light of this new standard.


The term ‘COTS’ stands for ‘Commercial Off The Shelf’, and is used to refer to devices and products which are designed for ‘mass market’ deployment, that have not been modified, designed specifically, or made bespoke. In the context of this new standard, it can be interpreted that ‘COTS’ means that the PIN entry process is not performed on a dedicated ‘PINPad’ that is specifically designed for that purpose.  Therefore, PIN on COTS is literally a standard for ‘PIN entry on devices which are not PINPads’; indeed, the examples given in the standard show merchants implementing this standard to allow for PIN entry on their own mobile phones.  This may seem a little strange, even fundamentally insecure, at first blush.  However, it is of course not quite that simple and although a dedicated PINPad is not used, there are methods and systems required within the PIN on COTS standard to provide security to the PIN entry process.

Before going into these, however, it’s important to consider that this new standard is not called PIN on Mobile, even though that seems to be the use case implied by the standard itself. This is an important, if subtle, distinction.  ‘Mobile’ is a use case, rather than a type of technology, and through the use of the term ‘COTS’ this standard does not appear to constrain itself to any specific use case: it is not a ‘mobile payment’ standard, although it will most likely be seen that way (at least initially).  It is a standard for replacing dedicated PINPads with non-dedicated devices, regardless of exactly how those non-dedicated devices are implemented in the field. 


One of the paradoxes of PIN security has always been the reliance on what is essentially just a four digit decimal number as a security and authentication feature. Of course, technically, a PIN can be anywhere from four to twelve digits in length (as defined in ISO9564), but most commonly it is implemented and used as a four digit number.  I can list out all of these numbers, from 0000 to 9999 … in fact, in the table below I have done just that.  If your PIN is four digits long, and it likely is, then your PIN is listed below (although to be fair it may be a bit small to see). 

I know your PIN.












Of course, this information provides me with no benefit unless I also know your card details.  Otherwise, your PIN remains ‘just’ a four digit number.  This is the fundamental idea that underlies the new PCI PIN on COTS standard – separating the customer card data from the customer PIN, so as to ‘devalue’ the PIN.  This is done through requiring the card data to be entered into a ‘SCRP’ – or Secure Card Reader: PIN – which is a new approval class under the existing PCI PTS program that outlines the incumbent requirements for PINPad devices.


Additionally, the requirements call for the PIN entry only to be accepted when the transaction is EMV (or ‘chip’) based. I won’t go into the details of how EMV works here (if you’re interested, we have lots of details here), but in summary the ‘chip’ in an EMV card contains secret cryptographic keys that are used to uniquely authenticate and identify EMV cards and transactions performed with that card. Unlike magnetic stripe cards, EMV cards cannot be easily cloned (I use the weasel word ‘easily’ here, as breaking things is kind of my job; very little is impossible, but it’s certainly hard enough that you’ll spend more than you make out of breaking any specific card). This, essentially, prevents card-present fraud with EMV. This reduction in fraud is backed up by statistics in countries which have gone through EMV deployment; it’s a fact.

This fact is the pivotal piece of information necessary to understand the concept of the new PCI PIN on COTS standard. Traditional PIN security programs have been about protecting the customer PIN, because the customer PIN is the only secret that secures the transaction; if I know your PIN and card data, I can create a cloned magnetic stripe card and use that to perform fraudulent transactions.  In this way, PINs can be seen as a solution to a magnetic stripe problem – and we are no longer in a magnetic stripe world.  We live in an EMV world, or at least a world rapidly reaching saturation of EMV deployment.  In this EMV world, the PIN is not the only secret anymore because we have the secret cryptographic keys on the customer card; even if you have a customer’s card data (as output from the EMV card during a transaction) and the associated customer PIN, you can’t perform an EMV transaction.

At UL, we’ve talked about similar issues before; about how the changing technology of EMV, phone-based Issuance (Apple Pay, Google Pay, etc), and advanced authentication methods are changing the way we pay, changing the way fraud is performed, and ultimately changing the need for PINs.  This new standard produced by PCI is essentially a stepping stone from a world dominated by PINs and magnetic stripe cards, to a world where different payment form factors and different authentication methods are used.


So how does this all work? The PIN on COTS standard calls for four main components for any solution, and those components must all work together in tandem to secure the overall transaction and PIN entry:

  1. The PIN on COTS application: This is the component that resides on the merchant COTS device (phone/tablet) that is used to accept the customer PIN.
  2. The ‘monitor’ system: This component is actually split between the merchants COTS device and a back-end system. The monitor is used as a mechanism to constantly check the ‘health’ and security of the COTS device that is being used. You can think of this as the software equivalent of the tamper detection mechanisms that normally reside in a PINPad, but instead of checking for physical tampering, the monitor constantly checks for ‘software tampering’ of the application or COTS device used.
  3. The Secure Card Reader: PIN (SCRP). As noted, this is a device that must be tested under the existing PCI PTS program, and it is used to accept and encrypt the customer card data before it is sent to the merchant COTS device. This is how the separation between the card data and the customer PIN is achieved.
  4. Payment and PIN processing backends: These areas are the ‘standard’ payment processing areas that would exist in any normal PIN based transactions.

These components are illustrated in the picture below, with the areas in scope of the new PCI PIN on COTS standard outlined in the brown boxes.

Flow Graphic 2

The transaction process is then performed as follows:

  1. The customer presents their card to the SCRP. As noted above, this card must be an EMV based ‘card’, but may be a contact or contactless chip card, mobile payment mechanism or other form factor.
  2. The card data is read and encrypted by the SCRP, which will also perform the EMV processing of this data.
  3. The customer enters their PIN into the PIN CVM application on the merchant COTS device. This PIN is encrypted on that COTS device, and sent to the SCRP; where it is either sent directly to the customer card for validation (if it is an ‘offline PIN’ transaction), or it is ‘translated’ to encryption under the cryptographic keys shared with the PIN processing backend.
  4. The transaction, including the encrypted online PIN as ‘translated’ by the SCRP (if it is an online PIN transaction), is sent to the payment processing backend.
  5. The transaction is authorised (or rejected) by the payment processing backend as per normal.

Throughout this process, the monitor system will also be constantly checking the security of the COTS device and merchant application.


An important item to note is that the transaction must be processed online.  The customer PIN cannot be accepted by the COTS application unless the merchants COTS device has connectivity through to the backend(s).  This does not forbid the use of ‘offline PINs’ however – in a somewhat confusing overloading of the term, in payments an ‘offline PIN’ transaction is where the customer PIN is authorised by the customer EMV card itself.  An offline PIN transaction may still be processed online. They're different.

Confusing, I know. Just remember – transactions must be processed with connectivity and transmission of the transaction data to the backend systems during the transaction, but this may be with either offline or online PIN.

It would also be possible for a PIN on COTS system to accept different authentication methods – signature, Consumer Device Cardholder Verification Method (CDCVM – such as biometrics on the cardholders phone), etc. PIN use is not mandated, but it is the focus of the security aspects of the new standard.


Now that you hopefully have some insight into the general ideas and process behind PIN on COTS, let’s move onto some specific questions that may come up:

I’m confused. Do I enter my PIN on my phone, or the merchant’s phone?

You enter your PIN on the merchants phone/tablet, etc. Not your own device.

Is this really secure?

Nothing is 100% secure, but the standard does go into a good level of detail about how security must be applied on the PIN CVM application, and through use of the monitoring system. These requirements are above and beyond what PCI PTS (the standard used for ‘traditional’ PINPads) are required to do for software security.

So, it’s online transactions only? Does that mean I can’t use my offline PIN?

Offline PINs are different from online transactions, and the requirement is just that transactions must be processed online (not that PINs must be processed online). It’s confusing, I know, but ultimately the answer is that a PIN on COTS system should accept your PIN regardless of if it is an online or offline PIN.

Does this mean that ‘traditional’ PTS PINPads are ‘dead’?

Not necessarily. The level of testing, sophistication, and security required for the monitor system can’t be easily overstated – this is not a ‘cheap way to accept PINs’.  In many use cases it will probably be the case that a ‘traditional’ PINPad remains a less expensive option all up when the cost of the maintenance and validation of the monitor system is considered.  PIN on COTS solutions will probably be most suitable for smaller merchants, but the cost of use for these systems is likely going to be too high for larger merchants.

I’m an Issuer, and I’m concerned about this standard. Can I ‘opt out’?

No – as far as Issuers are concerned there will be no real difference between a PIN on COTS transaction, and a ‘normal’ PIN transaction. So, it won’t be possible to opt out of accepting transactions that originate from PIN on COTS systems.

Can the card data be accepted through the NFC interface on the merchant phone? Do I really need to use an external SCRP?

The standard mandates the use of an external SCRP, to ensure that there is a strong separation between the customer PIN and the customer card data. So, no; card data cannot be accepted through the internal NFC interface of the merchant phone (indeed one of the security requirements dictates that such an interface must be disabled during the transaction to prevent ‘skimming’ of card details through this).

Can you still use magnetic stripe cards with a PIN on COTS solution?

No. The security provided by EMV based transactions is an important part of the overall security of the PIN on COTS solution, and therefore use of magnetic stripe cards is forbidden.  In fact, it is a requirement that the external SCRP cannot even have a physical mag-stripe reader, just to be sure that mag-stripe transactions are not accepted.

Can you use an OEM-pay (Apple/Google/Samsung/etc.) solution with PIN on COTS?

Yes, as long as the external SCRP accepts contactless cards, you can use an ‘OEM-pay’ solution with PIN on COTS acceptance. You can also use CDCVM, or other cardholder verification methods; PIN use is not mandated, just secured.

What happens when there’s a new vulnerability exposed in the merchant phone? Doesn’t that make this whole thing insecure?

Not necessarily. It is the job of the monitor system to constantly check the ‘health’ and security of the merchant phone, and to make sure it is not compromised or vulnerable.  When new vulnerabilities come out, the monitor system must be updated to check for such problems, and either mitigate against them being used to collect customer PINs, or block the use of vulnerable COTS systems (where the vulnerability cannot be otherwise mitigated).

Hang on; so this means the ‘monitor’ may disconnect me as a merchant at any time if it considers my phone to be ‘insecure’?

Yes, that’s the gist of the standard and one of the reasons why this standard does not necessarily ‘kill’ the traditional PINPad solutions. As the threat environment for COTS devices evolves it is expected that merchant phones that were considered ‘OK’ by the monitor system today will not be considered ‘OK’ tomorrow – and that may result in that phone being blocked from accepting PINs.

This monitor thing sounds cool! Where can I buy one?

It is expected that the monitor system will be developed bespoke by each PIN on COTS system developer – there is no single solution that may be purchased separately for this right now. It is likely that monitor solutions will leverage parts of existing technologies like Google SafetyNet, but at this time it is equally likely that existing systems like this will not meet all requirements for the monitor system without additional controls and security being added.

You mentioned that the SCRP must integrate the EMV kernel. Does this standard forbid the use of 'split' or 'cloud' based kernels?

At the moment, the standard appears silent on this issue and it is likely that a solution implementing a 'cloud' based kernel (where the EMV L2 kernel is at least partially located in a remote system to the SCRP) could meet the requirements. However, the kernel cannot be on the merchants COTS device as that would be a non-compliance to the requirements that enforce separation of the PIN and card data.

I’d like to know more about PIN on COTS – who can I talk to?

PCI are, of course, a good source to start with, but equally if you have any further questions I’d be happy to see if I can help answer them.

I'd like to know more about the SCRP requirements and approval - who can i talk to?

You'll want to contact a PCI PTS lab. Fortunately, UL is not just one of these; we've got four lab locations around the world, just send us an email and we can help you understand the requirements and testing process.