Windows XP Sunset Event Could Affect Your PCI Compliance

On April 8, 2014, Microsoft’s extended support for Windows XP will cease. Merchants running this operating system should start preparing now to upgrade to a supported operating system. But of course, in standard Shift4 style, we’re here to explain why and how these changes affect you so you can keep your business compliant and safe.

Why is this important?
Requirement 6.2 of the PCI Data Security Standard (PCI DSS) tells us to “ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches.”

The PCI Security Standards Council’s position on this subject is that if a vendor no longer supports a system component by issuing security patches, merchants running that component in their card data environment cannot check “In Place” on their next Self-Assessment Questionnaire. In case you weren’t aware, in order to be PCI DSS compliant, all in-scope requirements must be checked “In Place.”

If you are running an unsupported operating system, and it is accessible from the Internet, you will receive an automatic PCI failure on the next authorized scanning vendor (ASV) vulnerability scan and will immediately be deemed non-compliant with the PCI DSS. The ASVs are required to automatically fail a scan upon detecting an unsupported operating system.

What if my unsupported operating system does not process, store, or transmit cardholder data?
If the system resides in the card data environment and is not properly segmented from systems that process, store, or transmit card data, then it is in scope for PCI DSS requirement 6.2 (network segmentation is covered on page 11 of the PCI DSS manual).

What Should I do?
If you will be affected by this Microsoft sunset event you should immediately consult with your merchant services provider (MSP) or merchant bank and your ISA or QSA so they are aware and can provide guidance. If you already have a plan to upgrade, then congrats – you’re ahead of the game.

If you don’t have a plan or a budget allocation to upgrade to a supported operating system, you have one other possible option – use Compensating Controls (see PCI DSS Appendices B & C). This is not recommended, and should be discussed with your MSP/merchant bank and your ISA or QSA to determine your next steps.

As always, we’re here to help. Please contact Shift4 Support at 702.597.2480 (option 2) for more information on how to keep your card data environment PCI complaint through the upcoming changes.

Archived Comments

Carolyn Cogswell wrote on 01/07/14 2:36 PM

I am not a Retailer using Shift4 - but a Retail Pro (POS software) Business Partner Tech-that supports Retailers using Shift4 integrated with Retail Pro

Could you forward a link to the PCI/DSS
Is the Self-Assessment Questionnaire sent by Shift4?

"Who" is the authorized scanning vendor (ASV)--is that Shift4?
Assuming the answer is yes how does not happen?
I am assuming the Retailer has Shift4 of course?

What if the Retailer doesn't have the "latest" Shift4? Isn't that also a PCI DSS requirement?
Or is there some "allowance" back to "xxx" version.

Obviously the Retailer should not be required to get every single Update (other than Windows - I understand that) as soon as it is released

Nathan Casper wrote on 01/07/14 4:27 PM


Let’s take those one at a time:

Could you forward a link to the PCI/DSS
Is the Self-Assessment Questionnaire sent by Shift4?

Merchants can download the appropriate SAQ for their business (based on their transaction volume) by visiting:

"Who" is the authorized scanning vendor (ASV)--is that Shift4?

No, Shift4 is not an Approved Scanning Vendor. The ASV is a third-party organization that performs quarterly vulnerability scans of merchants’ (and service providers’) Internet-facing environments.

A full list of the 130+ ASVs approved by the PCI Council can be found here:

What if the Retailer doesn't have the "latest" Shift4? Is there some "allowance" back to "xxx" version.

PCI requires you to run a current and patched version of your operating system, but there is no such requirement for payment applications. So long as the application was listed and validated when you installed it, you are grandfathered into PCI compliance.

That being said, we do encourage our merchant customers to stay up-to-date with our most recently listed versions so as to take advantage of new features and enhanced security technologies that we provide at no additional cost with each new build.

Lee wrote on 01/08/14 6:34 AM

As a Choice Hotels property using Windows XP, we will be upgrading to Windows 7. Once this is done is there anything further we need to do regarding PCI compliance or with Shift4? Or will the upgrade itself be sufficient, i.e. no other transfer of information etc.?

Jason wrote on 01/08/14 9:36 AM

About six months ago, we were sold a Comtrol Lodging Link box running Windows XP Embedded to handle serial interfaces for our hotel Property Management System. Comtrol discontinued this product in favor of a new version of the product running Windows 7. I am attempting to negotiate a trade-in/buy-back arrangement with the PMS vendor and/or Comtrol as I consider a device's obsolescence so quickly after deployment as poor business practice.

However, it is possible both vendors will stand firm with the sale as-is, and we will be left to find a solution on our own. To that end, if a separate VLAN and subnet with its own WAN link were created for this device, would that be sufficient in satisfying PCI DSS requirements?

Nathan Casper wrote on 01/08/14 10:29 AM


No need to report the upgrade to us. As for PCI, we can't speak for them, so you'll have to check with your QSA to ensure that they still consider your environment compliant. (If nothing changes other than the OS, they should -- but PCI is crazy sometimes, so we still recommend you check with your QSA.)

Steve Ames, CISA, CISSP wrote on 01/08/14 10:47 AM


I can absolutely relate to your quandary, but at the end of the day you will be running a non-supported operating system.

Please speak with your ISA/QSA and/or bank about using compensating controls for PCI DSS Requirement 6.2. You should also search on “non-supported operating systems” in the PCI Security Standards FAQ web site. There is quite a bit of information available on this subject. You may even be “grandfathered” for existing deployments, but use caution as it appears the vendor has available a new version running Windows 7.

Beyond that, I recommend you include in your risk assessment the Comtrol Lodging Link story, to include compensating controls for Windows XP, and a migration plan for supported operating systems.

Carolyn Cogswell wrote on 01/16/14 9:36 AM

Why would Shift4 do recent new installs on XP WSs?
Would Shift4 have advised the client before the installs and the client would then choose to go forward anyway?

I personally know of 2 clients (1 new to Shift4/1 an existing Shift4 client) --recently had approx 20 separate WS installs of Shift4 on XP WSs (these all just happened to be IBM Sure1s).

Nathan Casper wrote on 01/16/14 1:36 PM


We feel your pain (we really do, we're actually in the process of updating about half of our workforce to get them off XP terminals). Please know that this regulation did not come from Shift4. It was a requirement set by PCI that we, like the rest of the world, now have to abide by. The guidance to avoid new installs of XP should have come from your QSA and we're sorry it didn't. We put this message out as a reminder to merchants that it's time to implement the changes their QSA should have recommended at the time of their last assessment. If your QSA didn't, it might be time to look for a more conscientious assessor.

On the bright side, if your new installation includes support for our 4Go solution and point-to-point encryption (P2PE), your QSA should deem your workstation out-of-scope for PCI, so the operating system running on it would be irrelevant.

Please let us know if we can help in any way!

Chris wrote on 02/07/14 12:32 PM

I have a number of clients who run hotel property management software which has Shift4 integrated into it. In most environments, there is a server which hosts the data base, is exposed to the internet through specific ports, and serves client software requests from machines on the local network.

If the server which does the processing for credit card transactions is running a compliant operating system, but some of the workstations running the client software had XP as an OS, whould Credit Card processing cease to operate for those workstations? Or is this purely a PCI compliance / failure to comply issue that would have no bearing on the actual operation of the software?

Am I correct to assume that only Shift4 and the 3rd party application would cease transactions due to the software compliance rather than the OS it is installed on? For example, Shift4 deciding to no longer support or allow it's software to be installed on say, Server 2003, due to support end of life, and subsequent PCI DSS non-compliance...

Or asked another way, has Shift4 coded in some sort of block of transactions from client software based on the PCI compliance status of the OS that client is running on, even though the actual processing is proxied through a supported and compliant server OS?

Nathan Casper wrote on 02/07/14 4:47 PM


As of April 8, 2014, merchants running Windows XP within their card data environment will no longer be able to attain PCI compliance (without implementing specific compensating controls that should be discussed in detail with your ISA/QSA).

At this time, Shift4 has no plans to deny access to customers who continue using Windows XP. We only hope to inform merchants of this lesser-known PCI regulation so that they can make an informed decision as to whether or not they want to allow their PCI compliance to lapse.

Dan wrote on 04/07/14 12:22 PM


I'd like to offer a little more clarification for you based upon my research. The key item is "card data environment". This would include any systems with access to the same physical or virtual network as your machines that process and/or store card data. So your server is the hub of that CDE. Even if you have clients that run the PMS for view only access/reports, these clients are a part of your CDE because they are on the same network as your server. That makes them subject to PCI compliance thus XP running on these machines means you cannot be "compliant" with 6.2 requirement. One of the top ways to reduce your risk and ease compliance is to segregate the CDE from all other systems. Best practice would be a separate physical network. So even though these XP machines are not "processing" the cards, they do have access to the card environment which makes them "in scope" for PCI.

Nathan Casper wrote on 04/07/14 1:31 PM


We agree with the following additions:

1) "The key item is "card data environment"."
PCI calls it "cardholder data environment" (CDE); semantics, but that's the term you'd want to reference.

2) "This would include any systems with access to the same physical or virtual network as your machines that process and/or store card data."
It's not just machines with access to the network where your CDE resides; it's also any machine that could in any way affect the CDE.

3) "One of the top ways to reduce your risk and ease compliance is to segregate the CDE from all other systems."
This should be done with firewalls.

4) "Best practice would be a separate physical network."
Yes, and that separation should be a literal air gap between the networks.

Sunil Kolar wrote on 04/24/14 3:58 AM

Does it apply only to OS or all unsupported products used by the Merchants?

Nathan Casper wrote on 04/24/14 9:20 AM

PCI requirement 6.2 says, “ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches.”

We understand that to mean any software running in your card data environment that is no longer receiving vendor patching would put you out of compliance. You should check with your QSA to confirm.