Credit Card Terminals And PCI Compliance

Here is a point of confusion that even I do not completely understand.  Mainly because I do not understand why there is any confusion to begin with.  I am writing about this because the PCI SSC and the card brands need to provide guidance on what applies in regards to credit card terminals and PCI compliance.  The credit card terminal industry also needs to wake up and get on board with security before they end up in the PCI compliance dog house.

There seems to be a huge disconnect between the various standards and how they apply to credit card terminals.  In a thread on the SPSP Forum, there have been discussions regarding the fact that credit card terminals are required to meet the PCI DSS standard.  Yet I have seen terminals that store primary account numbers (PAN) unencrypted and violate other PCI DSS and PA-DSS requirements.  If you ask the terminal vendors, they claim that the only standard they need to worry about is the PCI PTS.  Hello?

Requirement 3.4 of the PCI DSS is the most troubling of the lot, the storing of PANs unencrypted.  I have seen numerous terminals that store PANs unencrypted.  Press the vendors on this issue and they come back with the following.

  • The PANs can only be displayed one at a time.
  • You have to be in administration mode to view the PANs.
  • The PANs cannot be printed out.
  • The PANs are stored in memory, not on a hard drive.
  • The PANs are cleared when the end-of-day (EOD) process is run.

In a couple of instances of which I am aware, the terminal vendor has told everyone that the terminals that are storing PANs will be fixed by August 2010, but not sooner.

Okay.  So you will rely on a compensating control to meet requirement 3.4.  In my opinion, none of those aforementioned bullets are sufficient to meet the requirements of a compensating control.  Big deal that the PANs can only be displayed one at a time.  The fact that you need to be in administrative mode is nothing, as most of these devices only have two modes, end user and administrative.  And to run EOD or do anything else, you need to be in administrative mode.  Storage is storage, memory or otherwise.  Logging of access to these devices is not available.  None of these conditions rise to going above and beyond, so a compensating control is not even possible.

Then there is compliance with the PA-DSS.  This is a really sore spot with terminal vendors.  They claim that the PA-DSS does not apply to them and point to the following on page vii of the PA-DSS standard.

“Hardware terminals with resident payment applications (also called dumb POS terminals or standalone POS terminals) do not need to undergo a PA-DSS review if all of the following are true:

  • The terminal has no connections to any of the merchant’s systems or networks;
  • The terminal connects only to the acquirer or processor;
  • The payment application vendor provides secure remote 1) updates, 2) troubleshooting, 3) access and 4) maintenance; and
  • The following are never stored after authorization: the full contents of any track from the magnetic stripe (that is on the back of a card, in a chip, or elsewhere), card-validation code or value (three- or four-digit number printed on front or back of payment card), PIN or encrypted PIN block.”

First, I do not believe there is such a thing as a “dumb” credit card terminal any more.  They all have memory and software and, in most cases, have complete software development kits for application development using languages such as Java, C++ and the like.  In some cases, these terminals are as powerful as a netbook.  Yet, somehow the PCI SSC and the card brands have missed this point.

Most of these devices have only one ‘secure’ account.  And that account is shared with every support person around.  Anyone remember PCI DSS requirement 8.5.8 regarding shared accounts?  Whoops!

Then there is that first bullet regarding the terminal having NO connection to any of the merchant’s systems or networks is where I run into the most problems.  We see a lot of these credit card terminals with serial or USB connections to POS solutions.  In most cases, the terminals are only retrieving the amount of the purchase from the POS solution and telling the POS solution that the transaction has been approved or declined.  But there are also a lot of instances where the data flows from the terminal through the POS to and from the processor.  That does not include the number of terminals that are connected to LANs for access to the processor.

The “rub” in all of this is that the software that drives these terminals is the same regardless of whether they connect to a POS solution or network.  Talk to any software engineer from any terminal vendor and they will tell you that the underlying software for each family of terminals is the same, regardless of the options used or installed.  So, if the terminals are not connected to a POS system we can ignore the fact that these terminals are not PA-DSS compliant.  But if the terminals are connected to the POS, then all of a sudden, they need to be PA-DSS complaint.  What kind of nonsense is that?  In my opinion, they need to comply with the PA-DSS regardless as this is cardholder data processing software.

So, where are we in all of this?

Is the software application in the terminal PA-DSS certified?  No!

Is it supposed to be certified?  Yes!

And the vendors’ responses?  You are misinterpreting the standard.

Pardon?  Exactly where have I misinterpreted the standard?

It’s BS like this that allow people to point at the PCI standards and say they are inconsistent and stupid.  Well, I hate to say it, but in this situation, it is inconsistent and a bit stupid.  All of you at the PCI SSC, the card brands and terminal vendors – get a clue before this becomes the next big exposure point.


10 Responses to “Credit Card Terminals And PCI Compliance”

  1. 1 Hina
    March 30, 2016 at 1:03 AM

    we have a client using our merchant solution on magstripe cards. They swipe the merchant card 300-500 times in a day and it’s getting damaged. They want us to provide the solution where the operator swipes the card once at the time of opening shift and doesn’t have to swipe it for every transaction after that. We can’t store the PAN on the POS due to PCI limitations. If we use tokenization, we will have to use the token to generate and verify PIN as well. Is there a better solution where we could store PAN or take input from the operator a part of the card number or something like that which could avoid them swiping card? Note that chip card is not an option at this point.

    • March 30, 2016 at 5:17 AM

      If I understand your question right and based on my experience with POS solutions, you are talking about a card with a magnetic stripe that is NOT a credit card. The card in question is just a card with a mag stripe that identifies the clerk that will be using the POS station. This card would NOT have a PAN on it and would therefore not need to be protected. Therefore, I have no reason to provide a solution for this situation. If this is not the case, please clarify your situation and question.

  2. June 10, 2015 at 12:55 PM

    MY question then is, does segmentation still apply to these standalone card terminals (VX520, VX570,etc), that are IP connected. How about firewalls, will each have their own firewall?

    • June 11, 2015 at 5:16 AM

      If they are on an IP network and there is no encryption from the card terminal or point of interaction (POI), then they are not segmented.

      Depending on how you segment will determine the number of logical/physical firewalls required.

  3. April 23, 2013 at 2:40 AM

    Thanks for finally talking about >Credit Card Terminals And
    PCI Compliance | PCI Guru <Liked it!

  4. 6 Martin
    January 12, 2011 at 2:24 PM

    My company wants to avoid PCI requirements on our network. We have a POS system at our sites that presently takes Credit Cards. If we move to stand alone terminals with no connection to our networks (dsl or even dial driven connections) I would think as long as the terminals and the “provider” are PCI compliant that all the work from a network and PC compliance standpoint for PCI compliance will not apply to “our stuff” I know there are other PCI compliance issues tied to processing Credit cards on a terminal, but those are operational to that device, correct?


  5. 8 Scott Spiker
    November 23, 2009 at 11:19 AM

    I have made the similar comments to MasterCard and Visa even prior to the formation of the PCI SSC. The real problem is that the PCI DSS is a set of best practices for Windows based POS systems, this its genesis. It has been tweaked here and there to try and be more generic, but at the core, it is the vulnerabilities of Windows that has caused the most concerns for the protection of CHD. The PA-DSS is the software subset to the PCI DSS. Again, primary target is for Windows based applications and systems. There are many areas of the PA-DSS that are difficult to meet in a stand alone payment terminal. My comments to the card brands and the PCI SSC is that a specific set of requirements for these type of devices is needed.

    In defense of the payment terminal vendor, these devices have been exclude from the CISP and SDP programs and the PCI DSS until recently. The are primarily used by level 4 merchants and only recently have these merchants been drug into the security of CHD. Data, by the way, that is impossible to protect since it starts our in the clear on the magnetic stripe of the card. But that is a different topic.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Welcome to the PCI Guru blog. The PCI Guru reserves the right to censor comments as they see fit. Sales people beware! This is not a place to push your goods and services.

November 2009

%d bloggers like this: