Anybody who has spent more than a few nanoseconds working on PCI compliance invariably has been confronted with the mystical challenges of scope. What is considered in-scope for PCI compliance? How do you limit scope? And what constitutes the Cardholder Data Environment, or CDE?
These can be tough questions to answer. First, we need to start with some important distinctions.
Many people conflate the CDE with the PCI Scope. In fact, the CDE and what is in-scope for compliance are not, necessarily, the same.
The CDE is where actual cardholder data is present. This could be a server that processes transactions, switches where CDE traffic is sent, and any other systems that are directly associated with the storage, transmission or processing of payment card data. The CDE needs to be isolated and segmented from the rest of your network. This is typically accomplished through ACLs on VLANs or, preferably, a firewall. Isolation of the CDE is a PCI requirement.
However, the scope of a PCI assessment often extends beyond the CDE. Any system that is “connected to the CDE” is also in scope for compliance. This statement, taken directly from the PCI Standard, is very important.
The operative words here are “connected to.” Any system that connects into the CDE is in scope for compliance and therefore must meet the relevant PCI requirements. That means servers that provide important management, administrative or monitoring functions are in-scope as well, even though they may reside outside the CDE. For example, if you have a server in the CDE, and it connects to an Active Directory server outside the CDE, that Active Directory server is also in scope for PCI compliance. It may not be inside the CDE and therefore warrant isolation, but it is still very much in-scope for compliance.
As such, any host that has a connection to the CDE (and your organization controls) is in-scope.
Connections can be anything, updates to a patch server, sending logs to a SIEM, anti-virus updates, management servers for file integrity monitoring. All of these examples would be in-scope for compliance, even if they were not inside the CDE.
One of the ways we analyze this is to look at the ACLs or firewall rules. If a device inside the CDE has a connection to a device inside your corporate LAN, then that device in the LAN is in-scope for compliance. It had better have anti-virus, log-management, patching, and all the other required host security controls for PCI.
There is one exception to this scoping rule, and that is any access to the CDE which uses two-factor authentication. If a host connects into the CDE, say for remote administration or to access a terminal server for example, and that access uses two-factor authentication, then the originating host is not in-scope. This is a very useful and powerful exception. It also is a very useful way to push hosts out of scope who need to access in-scope systems. And given how inexpensive two-factor authentication systems are, anybody dealing with PCI should pay close attention to this exception.
One other oddity, the PCI DSS does not require file integrity monitoring on hosts outside the CDE. If your CDE is properly isolated and segmented, then FIM is not necessary on hosts outside the CDE (that are still in-scope).
These nuances of PCI are what makes defining the scope of compliance extremely important. Many companies do not consider these connected devices in-scope. This can result in a rude awakening when a QSA lists those devices as in-scope for assessment.
This also underscores the need for documenting and diagramming your data flows. We see a lot of organizations that do not properly diagram how payment card data flows across the network. The PCI DSS requires organizations to document and diagram all payment card data flows, as well as the CDE and all connected systems.
If you are struggling with PCI scope issues, we suggest the following course of action:
- Diagram your data flows in Visio. Be able to explain exactly where payment card data enters your network, where it travels, and where it rests. You should be able to account for payment card data everywhere within your organization.
- Define your CDE. Be able to list the exact systems (that includes network infrastructure equipment) that are directly involved in handling cardholder data.
- Isolate the CDE with a firewall. All traffic into and out of the CDE should be extremely tightly controlled. You cannot have any discretionary access. Every rule should be defined down to a specific host or host range and port or port range. No “any” rules on the CDE firewall.
- Inventory every system that has any connection into or out of the CDE. Those devices are in-scope and need to have all the other PCI in-scope requirements met.
After completing these steps, you should have a pretty good idea of what your scope is. The next step is to start working on implementing the necessary host security controls for in-scope systems.
This includes:
- Antivirus scanning and logging
- Log monitoring
- Host hardening standards and configuration control
- Vulnerability management
- Patch management
- Unique accounts for all users and applications
- Password complexity and reset policies
- File integrity monitoring (for hosts in the CDE only)
- Intrusion detection/prevention
- Penetration testing
The good news here is that there are a lot of creative ways to limit the scope of your PCI compliance. However, be careful with “quick fix” solutions that promise easy compliance. Some of these solutions make grandiose claims with dubious results.
This was really valuable and a surprisingly easy read for a PCI article. Thanks.
That actually cleared up a couple of questions I had about remote computers. As always Andrew, insightful and timely. Thanks,
Ged
Great article! Thank you for such a clear and straightforward explanation!
I have 3 separate questions for you in regards to figuring out whether certain devices/servers are in CDE or “In-scope”:
1. A reverse proxy server is configured with SSL private keys and accepts HTTPS requests from the internet (card holder data is transferred), and forwards them (also HTTPS protocol) to an application server in the internal network. The way I understand this works: there are 2 distinct SSL connections established: browser to proxy server, and proxy server to application server. The proxy software internally is aware of the plain text cardholder data within the request. Does this fact make the proxy server belong to CDE?
2. Would an SSL load balancer appliance which processes requests for both card holder and non-cardholder web applications (back-end VLANs are isolated from each other) also be in CDE?
3. Another question is in regards to a database server. PCI requirement 3.4.1 seems to assume that the database server will handle cardholder data at some point in clear text because they mention 2 choices for database encryption: 1) file- or column-based and 2) disk encryption. However, if you have encryption completely offloaded from the database server, meaning that the database server only receives and stores binary data and has no way of knowing of figuring out what this binary data means, does this make the database server “In-scope” rather than in CDE?
Without an in-depth analysis of your situations, my initial answers would be:
1. The proxy server, since it is directly handling payment card data should be in the CDE. Moreover, since it is decrypting and re-encrypting the data, you would need to watch out for storage issues. If, for example, it is caching those requests, even for a few seconds – that is storage. And then the PAN storage requirements may apply.
2. Yes, that device is at least partially in the CDE and absolutely in-scope for compliance.
3. For the most part, it does not matter who does the encrypting, if a database stores PAN (which must be encrypted when stored, or “rendered unreadble”), its in-scope and should also be in the CDE. Now, if the data is tokenized – that is obfuscated or encrypted in a manner where you have absolutely no ability to decrypt it – then that’s a different story. Then you can push the database out of scope (potentially).
In scenario 2, does the load balancer bring the non-cardholder applications into scope?
A) Where will the scoping stop- If desktop A is able to take RDP of the systems in CDE. And desktop B can take RDP of desktop A. Will desktop B be in PCI assessment Scope ?
B) Can you please help clarify a bit more about the 2 factor authentication thing. In above example, if a user log in to desktop A with 2 factor auth, will this take it out of PCI scope or the user logs in to desktop A with normal username/ Password and then takes RDP of a system within CDE using 2 factor authentication, will this take desktop A out of PCI scope?
A) The scoping stops at direct connection to the CDE. So in your example, Desktop B would likely not be in-scope. However, other factors could alter that.
B) As long as a user is using two-factor authentication to connect to a CDE host, then the host they’re using can be out of scope. Its the connection that’s important. So, the example where the user logs on to the local desktop with two-factor does not work, because the connection would still be open. Better would be the user logons on to their desktop normally, then RDPs to a terminal server in the CDE with two-factor authentication for the connection. This is why UTMs with SSL-VPNs are so useful for PCI compliance. Because in one box you can solve a lot of issues.
Andrew your are simply great. I never saw any one with that good knowledge reply basic questions like these so honestly.
1. Can I consider all the management systems (patch, logging, AV etc) used for managing Desktop A as out-of-scope?
2. I have presumed that CDE systems (that process but do not store CHD) should have their own dedicated back up storage (X) and systems that are out scope should also have their own dedicated storage (Y). Where should I back up in scope systems like Desktop A (that not in the CDE but in scope)? Can I back-up Desktop A in storage (Y) without fear of putting those out-of-scope systems and my storage (Y) in scope. Afterall both the out-of-scope systems and storage (Y) have no direct access/connection to the CDE.
Hello Andrew,
Thanks for your clear answers – much appreciated. As a follow up to question (A) above – Desktop A is not in the CDE but has direct access to a system in the CDE on a/some port(s) and is therefore in scope. Understood.
1. Can I consider all the management systems (patch, logging, AV etc) used for managing Desktop A as out-of-scope?
2. I have presumed that CDE systems (that process but do not store CHD) should have their own dedicated back up storage (X) and systems that are out scope should also have their own dedicated storage (Y). Where should I back up in scope systems like Desktop A (that not in the CDE but in scope)? Can I back-up Desktop A in storage (Y) without fear of putting those out-of-scope systems and my storage (Y) in scope. Afterall both the out-of-scope systems and storage (Y) have no direct access/connection to the CDE.
1. I would. Anything that is directly connected to an in-scope system should probably be considered in-scope. Where you could fudge, is that if there were other desktops, in the same network as Desktop A, but they did not connect to the CDE, you could make a case for kicking them out of scope. But this would depend on the circumstances.
2. They don’t need their own backup, but it would be simpler. It would keep your primary backup system out of scope.
Does this mean internet access should be restricted from PCI CDE systems.
Absolutely! Neither in-scope nor CDE systems CANNOT access the Internet directly. They must go through some type of filtering.
Again informative.. Thanks
But still do you mean I can provide internet access from in-scope or CDE via Proxy and Proxy will become part of the PCI scope where as rest all(any internet website) are allowed.
That’s correct. The proxy will be in-scope.
I am getting confused with 10.1.1- Usrs must have unique ID including Administrators.
All desktops, servers have 1 generic admin account. What do we do with them ?
And for Unix systems you have to use the Root or SU account.
All users must have their own unique accounts, as well as application/services. Users cannot share accounts. That includes administrators. Each admin must have their own, unique account. They cannot share the Administrator or root account.
Totally agree with that Andrew, But the point here is what do I do to those Administrator IDs that exist by default and cannot be disabled, deleted from the system.
Thanks Andrew
My Firewall through which the CC data flows will be a part of CDE. If my Firewall which has IPS functionality is taking IPS signatures updates from the Firewall Vendor’s Server/Site. Does that mean Firewall Vendor’s Server/Site becomes in Scope or will it not be in scope as it is not managed by my Organization.
You have an intersting approach to PCI Scope. I am going to have to disagree with you a bit. Check out the PCI Glossary for CDE. It is clear that connected systems are considered part of the CDE
“Cardholder Data Environment:
The people, processes and technology that store, process or transmit cardholder data or sensitive authentication data, including any connected system components. ”
Also, the PCI DSS does not distinguish or give a pass for FIM for not in-scope systems (since the CDE and connected systems are one in the same)
Lastly, there is nothing in the PCI DSS that says “if you use two-factor” its out of scope. If the PCI Security Council’s website or the PCI DSS say something different I would love to see it.
The glossary refers to connected “system components.” Yes, anything directly connected to a CDE system, is in the CDE. But you can isolate the CDE. Then anything outside the CDE, but connects in, such as an update server, is not IN the CDE, but it is still in-scope for compliance.
As for two-factor, there is absolutely a requirement covering remote access. Read requirement 8.3.
You can leverage 8.3 to keep user workstations out of scope. If the user remotely accesses hosts inside the CDE and use two-factor authentication, then the user’s workstation is not in-scope. This is why remote access technologies, like Citrix are popular for large PCI environments.
Andrew – you need to clarify your point more. Please reference PCI SSC FAQ#5411. “remote access refers to network-level access originating from outside the company’s own network, either from the Internet or from an “untrusted” network or system such as an employee accessing the corporate network using his/her mobile computer. Internal company LAN-to-LAN access (e.g. between two offices via VPN) is not considered remote access for purposes of this requirement.”
In the comments here you hint that you meant 2Factor authentication to a virtual desktop such as Citrix. To clarify, if a remote user, regardless of level, establishes a direct connection to the CDE from an untrusted network using a SSL VPN with 2factor authentication are you going to call their workstation out of scope?
Finally, on FIM…you seem to be trying to isolate the label CDE to only systems that store, process or transmit cardholder data, which is incorrect by the council’s definition:
“Cardholder Data Environment:
The people, processes and technology that store, process or transmit cardholder data or sensitive authentication data, including any connected system components. ”
This is an area of interpretation where Anitian feels that the use of two-factor authentication is an adequate control for segmentation and isolation. In our opinion, if remote-access via two-factor pushes a external source out of scope, then internal access via two-factor should accomplish the same thing. You are correct that the PCI requirements do not mandate this. But, we see this as a reasonable method of isolation that protects the CDE and can limit scope.
And yes, it is our assessment that users accessing a remote desktop style environment, such as Citrix, using two-factor authentication pushes the end user’s workstation out of scope. Our reasoning is that the actual payment card transmission and capturing is taking place inside the remote desktop – not on the workstation. And the use of two-factor authentication (along with strict firewall / ACL controls) provides adequate segmentation as well as protection of the CDE.
Again, this is an area of interpretation. At Anitian, we interpret the CDE to be the directly connected environment. If it is not directly connected (such as on the other side of a firewall) but has access, then it is not inside the CDE, but still in-scope for compliance. Admittedly, we are splitting hairs here. However, in our assessment this is a reasonable interpretation that does not diminish the protection of the CDE or sensitive cardholder data, and provides clients with flexibility in their architecture.
I’m intrigued by your reasoning with the 2-factor, but I’m puzzled about your logic on other points. Would you also require 2-factor logon to the workstations that have Citrix access to the CDE? A Citrix server may require 2-factor access, but the workstation that accesses it need not ever be patched or have antivirus installed on it? I believe this flies in the spirit of the DSS. Authentication is not a panacea for all the other requirements.
It sounds like you differentiate between CDE system and in-scope systems outside of the CDE. From a compliance perspective, there shouldn’t be any difference between the two grous, right? If it’s in-scope, it has to comply with PCI-DSS. As the Glossary states, the CDE is composed of “connected systems”, and we have already agreed that the Active Directory server outside the CDE segment is in-scope. As such, wouldn’t the AD server also fall under the FIM requirement, since it is a “connected system” and in-scope?
Your argument that a workstation that uses Citrix or RDP to access the CDE is interesting, but I believe that the workstation still has access to cardholder data. I realize that the DSS is subject to a lot of different interpretation, but I find that it’s more prudent to err on the side of safety in these matters. 2-factor doesn’t prevent a user with CDE access from copying and pasting out of his Citrix session onto his desktop, either intentionally or unintentionally.
I will nitpick one point- there is no PCI-DSS requirement for segmentation, it just keeps the entire network from falling in-scope.
Wrong, there is a difference. The CDE is where cardholder date is present. And ideally it should be segmented and isolated from the rest of the corporate LAN. But there are systems that may connect into the CDE. Those systems are in-scope for compliance, but not inside the CDE. There are some small differences between the two, if you read the standard carefully and parse the language correctly.
Also, while the standard does not require segmentation, it is foolish not to do it. We have had customers try to put their entire network in-scope and we advise against it. The management overhead of doing such a thing is overwhelming, unless the company is very small, or has a very robust security operations team. In my experience, companies who try to put their entire network in-scope simply want to avoid doing the hard work of segmentation and network infrastructure work. Its a prime example of being penny-wise and pound-foolish.
Sorry to pile on like this, but after reviewing 8.3, I don’t see anything that would push a system out of scope by virtue of having 2-factor. The Requirement states that any remote connections from an untrusted network must use 2-factor auth, and nothing that says it falls out of scope. For example, for an admin using his home PC to VPN in, wouldn’t 1.4 apply?
Its an interpretation. At Anitian it is our position that if you use the combination of remote desktop (like Citrix) and two-factor authentication, then the originating workstation can be pushed out of scope. There is enough supporting text in the standard and FAQs and such to support such a design. However, its not without conditions and expectations. You can’t just put a Citrix server out there and setup some certificates. We have a set of requirements and expectations to meet that interpretation.
FIM is not required on connected to devices? I don’t think I have ever heard that one before from any QSA -definitely not a “common interpretation” at all and is totally inconsistent with both the PCI DSS and council communications.
FIM is required in the CDE. Outside the CDE, parse the language of 11.5, particularly the testing procedures:
Verify the use of file-integrity monitoring tools within the cardholder data environment by observing system settings and monitored files, as well as reviewing results from monitoring activities.
We interpret that to mean FIM is necessary inside the CDE, but not to merely connected systems.
Again, its an interpretation. This is what us QSAs do.
Interesting, but the CDE is defined at https://www.pcisecuritystandards.org/security_standards/glossary.php
Cardholder Data Environment: The people, processes and technology that store, process or transmit cardholder data or sensitive authentication data, including any connected system components.
I agree that it’s an interpretation, but I don’t see anything that supports that idea, not anything from the previous discussion about 2-factor taking connecting systems out of scope. I’ve maintained even before I earned my QSA credential that the DSS is far too nebulous and therefore, largely ineffective. Requirements like this should be a bright line.
I’ll give you an example as to why this no-FIM requirement is a bad idea: on a recent pentest we had a client that is using a Remote Desktop server for access into the CDE. The workstations that connect to the server use an RDP shortcut. We were able to gain Administrator access to the workstations and modify their RDP shortcuts to run a recent 0-day exploit upon login. FIM would have caught this.
I’m interested in anything that reduces scope, but I’m also interesting in being able to make defendable decisions.
Requirement 1.4 is focused on mobile and/or employee-owned computers, and this kind of technology should use two-factor authentication to connect to the CDE (Req 8.3).
Do you think thats is required to install a FIM, need centralized logging, need daily review of all those logs, enforce password policies, perform Penetration Test, etc., in a mobile and/or employee-owned computers? I don’t think so.
That’s the reason I think that the two-factor authentication allows you to de-scope systems using two-factor authentication. If this is not correct, maybe the standard should prohibit the use of mobile and/or employee-owned computers within the CDE.
I’m still interested in knowing where the DSS says that 2-factor allows for de-scoping of systems on the corporate network, or at least what the rationale is behind it. Again, I’m looking to make defensible decisions. I’ve asked other QSAs who feel similarly, and the best I can get out them is “it’s my interpretation”. Fine, that’s your interpretation, but how did you arrive at that interpretation?
2-factor is NOT a panacea that magically makes systems suddenly bulletproof. And attacker can still connect to shares and such without having to provide 2-factor credentials. Without revealing too many details (because it was a clever hack), on a recent pentest we did compromise a system that was in the client’s CDE that had 2-factor on it. All 2-FA did was force us to think a bit more creatively, and we decided to move around it.
As for employee-owned systems, absolutely I would include them in scope. It doesn’t matter who owns the system, if it is capable of connecting to the CDE, it is a potential vector for compromise and data loss and therefore the risk needs to be analyzed and mitigated. That is why the DSS exists.
I think there is a bit of confusion in the comments throughout that is clarified a bit in one of the earlier comments:
“At Anitian it is our position that if you use the combination of remote desktop (like Citrix) and two-factor authentication, then the originating workstation can be pushed out of scope….You can’t just put a Citrix server out there and setup some certificates. We have a set of requirements and expectations to meet that interpretation.”
I can agree with this position if the virtual desktop is properly configured to prevent the end client desktop from becoming a pivot point into the CDE and connections to the virtual desktop are secured (Ian’s example is an excellent reason for not losing focus on the client machines and connection profiles that are in use). However, if the use of a secured virtual desktop or jump server is not in use and the end client has a direct connection into the CDE then absolutely, those machines must have FIM, be included in centralized logging and review scheme are in scope for penetration test, etc. If you are interpreting this differently and still would not include machines that have a direct connection into the CDE as fully in scope just because the multifactor authentication is in place, I would like to understand how it is believed that authentication is protecting the organization from a compromised client machine that is now a pivot point for malicious access into the CDE?
I have a quick question for you…I hope this blog is still monitored.
If we have a web application running on a server outside of the internal network environment that a user can input card data into and then when they submit the data what is the traffic flow for that data to reach our database servers that hold this data?
I am not sure I understand how this data can ever reach the database servers and still have the database servers be in compliance if the database servers have to receive the data from a source outside of the CDE (i.e. the internet) ..I hope this question is clear.
Put the app server in one network, database in another (both would be considered in-scope). Use a firewall to control and route traffic accordingly.
Thanks for the quick reply.
The theoretical app server is off site and not part of the physical network were the CDE resides.
If I am reading the PCI compliance correctly, this app server can only make a connection into the internal network and touch a system that does not have direct access to the CDE server.
I would work with your PCI auditor to get an appropriate interpretation.
As a newcomer to PCI I found this very illuminating. If I use a company, such as Cybersource, to process all my card transactions, I assume that they are my defacto CDE. If the card data never touches any of my systems does this mean I have nothing in PCI scope?
Not necessarily. If the card data passes through any aspect of your infrastructure, even encrypted, then its in scope. You would need to do a full redirect to the Cybersource website. Your site cannot collect, gather, or handle the card data in any manner.
Hi, thanks for heads up on scope.
I have a confusion. Do all PCI requirements needs to be implemented on in scope systems as they do CDE. In my situation, my webserver (on internet) do a redirect to a SSL page (secure server on our DMZ). The user puts there card details on that SSL page which goes to the payment gateway (our bank handles the payment then). We are issued with a token which we save in our DB (internal network, which is segmented and segregated). Now I interpret my SSL page (meaning secure server ) as CDE and both webserver and internal DB server as inscope assets (as they connected with CDE). Now which PCI requirements will be considered for our inscope assests.
Thanks
No, not all the requirements apply to systems that are in-scope, but not in the CDE. The most obvious example is file integrity monitoring. This is only required for CDE systems, but not for systems that are in-scope, but not in the CDE.
As for which ones apply and which ones do not, you should work with your QSA to establish that.
Dear Andrew,
Thanks for your prompt response.
But is there any guidance or document which will help me in figuring out which clauses should apply on inscope systems. Thats for self learning only
Regards,
I would check the PCI Standards Council web site (https://www.pcisecuritystandards.org/). They have a lot of good content and guidance. They also have self-assessment and evaluation tools.
We are having an similar issue with PCI. We have two RDP servers and one DB server. One RDP server is CAT 1 in CDE and the second RDP server is CAT 2 not in the CDE they both have connection to the DB server which we class as CAT 2. The CAT1 RDP server has a ssl iframe access to sagepay for call center. The CAT2 server is for application only access to do pick and pack and reporting.
The question I have is are the users that are connecting to the CAT2 RDP Server in scope for PCI or are they out of scope?
Thanks in advance
They are technically both in-scope for compliance. As long as they have a connection into or out of the CDE, they are in-scope.
So as only RDP1 is sending out card data and not storing it on our network is there a way that we can keep users using RDP2 out of scope?
We cant really give packing stations user 2 form factor authentication?
Without a indepth analysis of your scope, its hard to say. But, based on what you wrote here, I’d say no. However, other QSAs may see it differently.
Thank you for this post. I realize it’s 2.5 years old, but it’s still one of the first posts that show up in a google search for PCI scope.
Version 3 clears up the definition of the CDE pretty dramatically to show that you were right (it’s not the same as scope), and it’s an important distinction when going through the requirements.
The 2-factor requirement, however, still seems to be an optimistic (and, imho, foolish) interpretation of the requirement. If it’s connected, it’s in scope. This “one degree of seperation’ rule is to protect not only the systems with the holy grail, but also anything that could directly compromise it through a security vulnerability.
The 8.3 requirement is that there must be 2-factor authentication for any user outside the network to connect to devices that are in-scope.
Although my comment here is coming 1.5 years later, I want to agree with Fred. In PCI DSS 3.1, two-factor authentication is only listed in regards to requirement 8.3, which talks about remote network access from outside the network. Two-factor authentication may also be used as (part or all of) a compensating control if it addresses the intent of the original control.
Hi Andrew, very interesting an helpful blog! I have a question and hope you can help me!
We are replacing our backup setup and implementing a new backup system – implementing two instances involves a significant cost. We need to backup some systems that are in the PCI scope, for example, database servers in the CDE containing encrypted card number tables as well as corporate servers e.g. development servers, that are outside the CDE. Our difficulty/question is where to put the backup server? if the backup server is connecting to the CDE and also the corporate servers will it automatically include the corporate in scope?
Many thanks!
No easy answer here. You might consider a lower-cost backup solution for CDE hosts. If you put it into the CDE, then everything that connects to it could be seen as in-scope. If you put it outside the CDE, the presence of card-data makes the whole environment in-scope.
You could always backup the card-data to a source inside the CDE. Then backup everything else to the central system. This would keep cardholder data off the backup system and allow you to put it outside the CDE.
I have a question re RDP also.
We have a POS application, that uses a USB card reader to expedite the entering of credit card holder information. I am considering setting up a server with RDP/SSL along with 2-factor authentication and running the POS software on the RDP server.
My understanding is that the CDE which in this case is the server and the network connection equipment is in scope, how does the USB card reader alter that since it is connected to a PC outside the CDE environment, or does that put the PC inside the CDE and totally in scope no matter where the POS software is running?
Thanks,
Yes, we would probably define that PC as in-scope as well.
I have a question about scoping ..
If a PCI compliant service provider hosts (i.e. configures servers, network etc) his technology for a third party service providers (client) with the third party having only web access to a portal (with viewing cardholder data permissions, can do debit credit etc.), does the client require to be PCI compliant? And is it the responsbility of the hosting service provider to make sure the client is compliant as required by 12.8.2?
Now if the client connects to the web portal with two- factor authentication, will that make him out of scope?