We are a brick and mortar company... literally. We are brick masons. At our office we connect to the internet through our cable modem provided to us by Spectrum Business.

Our Treasurer uses a Verifone vx520 card reader to process credit card payments. It connects via ethernet. We don't store credit card data.

We got a vulnerability report stating that we were not PCI compliant.

They scanned our cable modem.

Part 2b-1. 38173 - SSL Certificate - Signature Verification Failed Vulnerability
Part 2b-6. 38628 - SSL/TLS Server supports TLSv1.0
Part 2b-7. 38601 - SSL/TLS use of weak RC4(Arcfour) cipher (CVE-2013-2566, CVE-2015-2808)

I don't understand what they mean. We don't have a server or an online store or anything. I was told they scanned our network and this is what they found. They told us to get with ISP to fix issue.

How is the ISP supposed to get an SSL certificate installed on a cable modem? I did call our ISP and he didn't know what to tell me.

We just use the card reader and it connects to our payment processor.

Am I supposed to do something here? Is any of this applicable to us?

  • 6
    Have you tried putting your public IP address into your web browser's address bar to see if it will connect to anything? Try with both "" and "" (note the S in the second URL).
    – Ghedipunk
    Aug 1, 2019 at 23:04
  • 6
    Also, since you are running credit cards that are physically located at your office, you do need to secure your network to be PCI compliant. This will probably just be configuring a firewall on your modem/router, though I'm putting off making an answer to this question depending on what you'd see from trying to bring up your IP address in your browser.
    – Ghedipunk
    Aug 1, 2019 at 23:08
  • 27
    @user3512967 that cert and user prompt is almost certainly to log in and control the modem itself. It really shouldn't be exposed to the Internet at large.
    – gowenfawr
    Aug 1, 2019 at 23:25
  • 12
    "Also, since you are running credit cards that are physically located at your office, you do need to secure your network to be PCI compliant." That depends on the card terminal, the good terminal providers works hard to keep the stores network out-of-scope for PCI.
    – Mattias
    Aug 2, 2019 at 8:43
  • 34
    From whom did you get this report? Were they trying to sell you something to fix it?
    – Kevin
    Aug 2, 2019 at 15:02

5 Answers 5


At our office with connect to the internet through our cable modem provided to us by Spectrum Business.

Our Treasurer uses a verifone vx520 card reader to process credit card payments. It connects via ethernet. We don't store credit card data.

It sounds like you fall under SAQ B-IP (and you will be amused that the mnemonic is that "SAQ B-for-Brick-and-Mortar"):

SAQ B-IP has been developed to address requirements applicable to merchants who process cardholder data only via standalone, PTS-approved point-of-interaction (POI) devices with an IP connection to the payment processor

It sounds like someone did an external ASV ("Approved Scanning Vendor") scan on your known IP address and found the cable modem was, unsurprisingly, not up to snuff.

Am I suppose to do something here? Is any of this applicable to us?

Yes, this is applicable to you, and many other things besides, all of which are outlined in the Self Assessment Questionnaire linked above. And if your other office systems - desktops, printers, whatever - are also sitting on the same network behind that cable modem, then the requirements of the SAQ apply to those as well. Things like patching and access controls.

For now, you will need to continue to work with your ISP. They either need to update the modem, upgrade it, or get it to stop accepting connections from the Internet at large.

To break down those error messages for you:

Part 2b-1. 38173 - SSL Certificate - Signature Verification Failed Vulnerability

There's likely a self-signed certificate on that device, common for things like cable modems that need TLS but don't care about being trusted by random users. (PCI cares, though, even when users don't).

Part 2b-6. 38628 - SSL/TLS Server supports TLSv1.0 

When you go to a secure web site today, the newest you'll see is TLSv1.3, however most websites only support up to TLSv1.2 or TLSv1.1. TLSv1.0 is old, relatively insecure, and PCI declared it unacceptable to use a few years ago.

Part 2b-7. 38601 - SSL/TLS use of weak RC4(Arcfour) cipher (CVE-2013-2566, CVE-2015-2808)

TLS gets to pick from multiple algorithms; over time, weaknesses are found and individual algorithms get retired because of it. RC4 got retired a few years ago.

  • 7
    If the verifone and processor were P2PE-certified, would that remove the whole store network from scope? I’m not very familiar with B, but my impression is that if the device is encrypting everything then there is no “card data environment”, so presumably most questions wouldn’t apply. But I have no idea if that’s how it actually works for a location like this.
    – Bobson
    Aug 2, 2019 at 0:48
  • 52
    RC4 may have been officially retired only a few years ago, but it was discovered to be broken literally hours after it was published in public, in the 90s. It's only through incompetence that it was used for so long.
    – forest
    Aug 2, 2019 at 6:15
  • 12
    RC4 should be called "poor man's plaintext" Aug 2, 2019 at 12:12
  • 3
    @Bobson you would have to do SAQ-P2PE instead, which has far fewer requirements than B-IP (and doesn't have the ASV scan, or really anything related to your network).
    – rbsec
    Aug 2, 2019 at 14:46
  • 3
    A note: "CVE" are the serial numbers we use for security weaknesses. So "CVE-2013-2566" was the 2566th security weakness filed in 2013.
    – lynn
    Aug 2, 2019 at 15:53

Since you are physically handling cards, and sending that card data across a network to your card processor, you do need to secure your network. Besides just being compliant in order to get auditors off your case, if someone sneaks a program into your network, it might be able to eavesdrop on the rest of the network and steal that card data.

Based on your question and comments, some computer in your network has a web server that is publicly responding to requests.

It is most likely the cable modem/router itself, and the web server is part of a remote management console -- It allows you or your ISP to change settings without needing to be inside of the network. It also allows anyone else in the world to change settings, as well, though.

The error message that you're getting is saying SSL/TLS Server supports TLSv1.0, (among a couple other errors) which means that the web server is using security settings that are several years old. This is what your card processor is complaining about -- That web server is just too old and there are several known vulnerabilities.

However, your most critical problem is that there is a remote management console that is available to the public. People can guess the login information at their leisure and gain access to your internal network. When you turn off remote management in your modem, your card processor should be able to scan your network and won't be able to see anything at all, and you'll be back in PCI compliance (assuming that you were in compliance before).

  • 1
    "it might be able to eavesdrop on the rest of the network and steal that card data" - card processing isn't my thing, but I assumed they would be robust to that threat.
    – Flexo
    Aug 4, 2019 at 1:43

TLDR: DON'T secure your network. Get a modern card terminal with P2PE (Point to Point Encryption) and acquirer who supports it - e.g. new-market products like Square or PayPal Here, which cost less than you think.

This transfers PCI-DSS responsibility away from you and to these billion dollar financial companies who are well equipped to handle it efficiently, at scale. Go encryption!

Complying with PCI-DSS is big work unless... (skip this)

PCI-DSS is serious business. Most small businesses do not have a breach. But if you do have a breach (which would most likely be crackers surveilling your credit card transactions for an extended period of time), you'll need to pay extremely painful penalties that have a (the figure I've heard is 90%) chance of bankrupting your small business.

What is in scope for PCI is

  • your card terminal
  • the network it's on
  • every PC, wait, device that can access that network
    • and the WiFi bridged to that network
    • including IoT: security cameras, Sense power monitor, and every silly WiFi-enabled gadget you bought on a lark and forgot all about
  • every network that can access that network, and
  • every PC, er, device on those networks.
  • guest WiFi must be correctly set up to not be on this network

... unless you dodge it altogether, with P2PE

P2PE = Point to Point Encryption - essentially a VPN tunnel between the card reader device and the acquirer.

Square's first card reader was a simple magnetic tape head. Obviously, the Square app handled card data in the tablet. That placed the app, phone/tablet, network etc. in scope for PCI-DSS.

PayPal Here put an encryption processor inside the scanner fob itself. The fob itself talks to PayPal servers, via P2PE. The PayPal app simply passes the data through and can't read it (and neither can anyone else).

This does not place the app, phone and network in-scope for PCI-DSS. If the acquirer guarantees the fob is secure, then all you have to do is make sure your fob has not been physically tampered with.

If all your credit card activity is via P2PE standalone devices, then you don't need to PCI-DSS your network.

P2PE is the only way to go.

But unfortunately, a lot of acquirers (particularly the kind with roving salesmen, you know the ones) have not gotten the memo. They force you to spend thousands securing your networks. Why?

Because they are super resistant to change (chip cards, heh) and P2PE requires a huge expense of back-end tech that they can get by without. And of course you, the retailer, needs to buy a new P2PE reader, which is a tough pill to swallow after just spending a bunch on chip readers.

And your acquirer sold you an obsolete jalopy; that reader dates from 2012, before P2PE became popular. See?

enter image description here

Look at modern payment processors like Square or PayPal Here. At first glance, they look terrible on percentage alone but there are no other fees, and that swings it back in your favor - no monthly fees, batch fees, trans fees, tiers, and the dozen or so little cuts that acquirers take. I've seen bills that claimed to be 1.4% but were actually 4.1% after all those fees/gotchas were accounted for. PayPal Here is 2.7%. Really.

Another benefit of modern acquirers is they work via Bluetooth to phones or tablets, using the tablet to ring up the sale and accept the finger-signature. This also means they can use the unbelievably cheap cellular data network access for tablets specifically ($100/year is readily available) rather than paying for commercial internet service.

And they work anywhere, so if you have roving salesmen they can swipe Visa-MC at the customer. Instead of writing down numbers for the treasurer (a whole 'nother PCI-DSS nightmare), to say nothing of declined charges!

Card Not Present (CNP) transactions

Use modern keypad P2PE devices such as PayPal Here's big reader for CNP transactions. Don't enter CNP transactions on any kind of tablet or PC or you place the PC, network, yadayada into PCI-DSS.

Alternately, minimize or outlaw CNP transactions, and convert them to billing out through PayPal etc. (which comes with PayPal Here obviously). That way the consumer is using his own device to interact with PayPal etc., and that makes PCI-DSS their problem.

  • This seems to be the simplest solution --- many card readers are simply just that (i.e., "readers!"), not necessarily doing any "encryption" on their end either!
    – ManRow
    Aug 3, 2019 at 22:40
  • 1
    This is 100% the answer. Hoping for a fix from an ISP who doesn't know how to fix obsolete, SSL errors on their equipment is a recipe for disaster. Disasters should be removed from the equation. :)
    – dannysauer
    Sep 27, 2019 at 15:18

In the big picture, the problem is that internet-connected devices face a lot of security threats. The other answers give good tips to address the specific issues that were detected this time.

On the other hand, if you'd prefer to stay out of that whole mess, you could downgrade to a standalone payment terminal that uses an analog phone line and doesn't touch the internet. It may not avoid all possible security problems, especially in the long term, but for now it will move you back from SAQ B-IP to SAQ B:

SAQ B: "...Standalone, dial-out terminals..."

SAQ B-IP: "...standalone...terminals with an IP connection..."

The advantages of moving to a dial-out terminal using an analog phone line are:

  • It takes your modem and other internet-connected devices out of the picture
  • You're less likely to be affected by new PCI security requirements
  • You're less likely to be affected by some future internet-based credit card security breach

The disadvantages are:

  • It might not be supported by your current payment processor (ask them)
  • It requires a regular analog phone line, not VOIP or anything like that

EDIT: After reading Harper's answer recommending P2PE, I now think it's a bad idea for any regular brick-and-mortar business to try to address its own SAQ B-IP issues as suggested by other answers. Trying to keep up with SAQ B-IP is simply too risky. A regular brick-and-mortar business should only use solutions under SAQ B (dial-out terminals) or SAQ P2PE-HW:

SAQ P2PE-HW: "...terminals...managed by a validated, PCI SSC-listed P2PE solution..."

  • 5
    Disadvantage three: unless you add a phone line just for that, you’ll have customers standing around waiting (or leaving in a huff) while you’re phone line is busy doing something else. (I once waited many minutes for a card transaction while someone else was trying to decide what to do at an ATM dialing out on the store’s only line!)
    – WGroleau
    Aug 2, 2019 at 14:16
  • @WGroleau the vendor would probably have to get a phone line (a physical wire) installed for him if he want to use an analog phone for dial-up these days. In some places it might not even be available. I doubt he will have trouble with a blocked phone line. Of course YMMV depending on your country and province. Aug 2, 2019 at 17:17
  • Indeed. My incident was less than three years ago.
    – WGroleau
    Aug 2, 2019 at 19:50
  • 3
    Where I'm from a lot of shops use mobile (GSM/3G/4G) payment terminals connected directly to the internet. In such cases I assume the vendor/manufacturer is responsible for PCI compliance. You do need to pay for a data plan for the sim card though.
    – slebetman
    Aug 3, 2019 at 3:14
  • 1
    @gowenfawr: The two are not equivalent, though. The whole point of Krubo's answer is that you don't have to care about "If you are sending card data over the public internet, PCI compliance is too hard for merchants to meet and maintain." when not using the internet for the connection.
    – Ben Voigt
    Aug 4, 2019 at 0:55

If user3512967's modem is like mine, then hardening the web interface's TLS settings is pointless. My Cisco EPC3212 has an interface that is accessible from within the LAN via HTTP only. It has login credentials that can be googled and cannot be changed. Even if it were served via TLS (weak or strong), my network would not be more secure. Public knowledge cannot be undisclosed.

So my question is: Does user3512967's modem's interface offer restriction-worthy control or confidential information that is not accessible via public knowledge? If it does not, then fixing it's TLS does not solve anything.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .