By PCIGuru

If you have a PCI question that is not related to anything I have posted, you are welcome to post them here.  I will do the best I can to respond to your questions.  If other readers wish to weigh in on questions posted here, their comments are also welcome.

To those of you that have issues with this page and it’s load time, blame WordPress. This is a “free” blog and to fix this issue would require a ‘Business’ subscription that would cost $300/year (2018) to access the necessary plugins to reorganize the comments to multiple pages. To afford that, I would have to charge a subscription fee to anyone reading the blog.

Remember though, I am a QSA and consultant.  So I am not going to “give away the store” as I am in the business of selling my expertise.

1900 Responses to “Miscellaneous Questions Page”

  1. 1 Marc Jones
    September 17, 2021 at 8:54 AM

    Would you accept a self-signed AOC where the SAQ-D was dated 3-months prior to the officer’s signature?

    • 2 Marc Jones
      September 17, 2021 at 8:54 AM

      Actually, it’s 4-months, not 3

      • September 17, 2021 at 12:29 PM

        Self-signed SAQs are always a concern, but given how the card brands treat them, they are legal representations by the person signing them that the organization is PCI compliant.

        As with any executive, documents get “lost” in their inbox and they do not get signed in a timely manner. If it is signed, it is a legal representation that the organization is PCI compliant and should be treated accordingly. That said, it is up to the receiving organization as to whether or not they accept that representation. If you are uncomfortable with that time frame, it is within your rights to reach out to the organization with your concerns and talk through those.

  2. 4 shane
    September 7, 2021 at 8:09 AM

    We recently changed vendors/applications for our front desk and now all CC transactions are run through a 3rd party. If the old servers are still on, but are no longer processing CCs (haven’t been for 3 months) are they still in scope for this years audit?

    • September 10, 2021 at 5:48 AM

      If they still have card data on them, yes they are until you properly decommission and wipe them.

      • 6 EDY NGAMKHAO
        September 10, 2021 at 6:27 AM

        HI. Would this also be true for HSM hardware? If MFK and all keys are removed, reset to factory? I recall something regarding the chain of custody upon initial possession of the HW but can not find anything upon retiring the devices and if the HW must be sent back to the MFG or can be recycled.

      • September 12, 2021 at 11:48 AM

        Most HSMs have a factory reset or similar utility that will securely decommision the device which would remove all sensitive information in the HSM. Provided it has that capability, it should not matter whether you recycle it or send it back to the manufacturer. That said though, I would probably lean towards sending the device back to the manufacturer regardless.

  3. 8 Brendan
    August 30, 2021 at 10:58 AM

    I work for a company that sells products. We pay a third party company to handle our credit card transactions (we don’t store numbers, we take them over the phone and put them straight into this vendor’s website). As such, we might need an SAQ C-VT. However, the employees who are taking the numbers work for another third party and so does the building they work in and all the equipment. So company A is a subcontractor of ours and they run the entire call center that takes the numbers. Thus, our direct employees and our direct equipment do not ever touch credit card numbers. My question is whether we need to fill out the SAQ, or company A does, or both?

    • August 30, 2021 at 3:49 PM

      The answer is going to depend on whose merchant identifier (Merchant ID) is being used to conduct the card transactions.

      If it is YOUR company’s merchant ID, then your company needs to fill out an SAQ A because everything is outsourced. However, for requirement 12.8, you will need PCI Attestation of Compliance (AOC) from your two outsourcers.

      If the outsourcers are running the transactions through their merchant IDs and just sending your company a check, you should have their AOCs on file to prove annually that they are compliant but your company does not need to fill anything out.

  4. 10 Erik
    August 16, 2021 at 4:56 AM


    I’ve encountered a strange practice from an Asian processor/acquirer, where half the card PIN code (first 2 digits) is sent as part of authorisation for e-commerce payments.

    They claim the half PIN code is not in scope for PCI DSS. As far as I know, there are no truncation rules for SAD. To make the PIN unreadable, you have to use cryptographic methods.

    Protecting the transmission isn’t a problem, but would the half PIN code “contaminate” systems it passes through with PCI DSS requirements? I’m inclined to say YES.

    How would you approach this?

    • August 16, 2021 at 9:48 AM

      I think you mean the card verification value (CVV) rather than the PIN. The PIN would only work in a card present transaction scenario and you are speaking about an eCommerce transaction.

      CVV is considered sensitive authentication data (SAD) and is required to be protected at all times and cannot be saved once a transaction has been either approved or declined. Splitting the CVV is not going to remove any intermediate systems from scope, so there is no scope reduction in my view.

      Besides, we are talking about a four digit number that can be easily guessed if you have half of it.

      • 12 Erik
        August 17, 2021 at 2:55 AM

        As far as I’ve been able to tell, it is actually the card PIN, not the CVV. I think it may be some kind of wierd effort to get better authentication of e-commerce transactions, without using proper 3DS.

        Thanks for your input! It confirms my view that SAD cannot be made unreadable by truncation.

      • August 18, 2021 at 7:27 AM

        If it is the PIN, how do they compare it to the PIN block? That is how the whole thing works. Without the card and the PIN block, the transaction fails. This sounds like some sort of scheme to obtain people’s PINs, not a security measure.

      • 14 Erik
        August 23, 2021 at 7:24 AM

        As far as I’ve found out, it appears to be a standard practice in Korea to require CVV and half the PIN code for e-commerce authorisations. I have no idea of how they actually use it.

        I’m still trying to verify if it is used for all cards, only for local non-branded cards, or just for cards issued by specific Korean issuers.

        The acquirer has now changed their mind, and say the half PIN is indeed in scope for PCI DSS.

        Strange case indeed…

        Thanks for your input!

      • August 23, 2021 at 12:40 PM

        I have a couple of clients in South Korea and neither uses half the PIN with eCommerce. I have also checked with some colleagues that have clients in SK and none of them have encountered it there either. Granted, all clients are subsidiaries of US-based retailers, so that might have something to do with it. But this is the first time we have ever encountered it.

      • August 25, 2021 at 7:52 AM

        So, I got more clarification from a QSA colleague. They think you are referring to the South Korean MyPIN or iPIN which is a personal identification number of 13 digits and has nothing to do with a payment card PIN. The MyPIN was introduced to reduce online fraud.

  5. 17 Nagu Sittampalam
    June 14, 2021 at 10:37 AM

    Hello PCIGuru

    I have question with regards to taking Credit Card Payments over the phone in the current corvid climate where people are asked to stay in. In a situation where you do not have a phone automated payment system are their any requirements to be compliant taking payment over the phone apart from the obvious once like not to write down Credit card numbers, do not repeat the number back etc..
    Regarding automated payment system are there any exceptions/catering for visually impaired people?

    • July 3, 2021 at 9:07 AM

      I think you have the basics down. Where telephony payments get into trouble is over voice over IP (VoIP) because the Council considers that no different than transmission of CHD/SAD as digital data. There is an Information Supplement on Telephony Security on the PCI SSC Website that you should read concerning VoIP.

    • July 3, 2021 at 9:08 AM

      In regards to visually impaired, I am not aware of any exceptions offered for solutions that cater to them.

  6. 20 Marc Jones
    April 21, 2021 at 8:17 AM

    Can you shed some light on what constitutes a “shared hosting provider” Requirement 2.6?
    For example, if I use AWS to host my web application for looking up credit bureau information, am I considered a shared hosting provider?

    • April 23, 2021 at 9:51 AM

      From the Guidance column of the PCI DSS v3.2.1.

      “This is intended for hosting providers that provide shared hosting environments for multiple clients on the same server. When all data is on the same server and under control of a single environment, often the settings on these shared servers are not manageable by individual clients. This allows clients to add insecure functions and scripts that impact the security of all other client environments; and thereby make it easy for a malicious individual to compromise one client’s data and thereby gain access to all other clients’ data. See Appendix A1 for details of requirements.”

      Under this definition, the best example of a shared hosting provider would be one that hosts a single instance of a Web-based eCommerce application that multiple organizations all use. Each organization’s data and users are segregated from one another, but they use the same application instance.

  7. 22 Deep Haria
    April 18, 2021 at 7:39 PM

    If the merchant is using Non-VoIP based PRI (Primary Rate Interface) to transmit and collect CHD, would this bring the telephony infrastructure (SBC, PBX, etc.) in scope for PCI? or Can they be NA as it is not VoIP based.

    • April 23, 2021 at 9:44 AM

      No. You cannot mark them as “NA” because they do process and transmit CHD/SAD. You must acknowledge the risk (msall as it is) and what you do to mitigate or remove those risks.

  8. 24 johnswk
    March 29, 2021 at 10:22 PM

    My organisation uses gmail using SSO to access their customer care call management software. The call management software is cloud hosted and they are PCI compliant. My question is whether using free gmail accounts to access the call management software prevents us from becoming PCI DSS compliant?

    • March 31, 2021 at 4:07 PM

      I think what you mean is that your personnel access your hosted Call Management solution using their GSuite SSO. If that is true, GMail (or any of the other GSuite apps) has nothing to do with anything other than the SSO solution grants access to all applications covered by the SSO solution.

  9. 26 Andrew Madejczyk
    March 29, 2021 at 12:10 PM


    quick question.

    Is there any value to having a QSA assist with completing a SAQ-D over just paying for the ROC? The cost difference not being much different. What I am asking is, do you see a benefit of doing one over the other?

    • March 31, 2021 at 4:15 PM

      IMCHO, an SAQ D is more like a auditing an education class versus actually attending the class to get a grade (i.e., ROC). Both however result in an Attestation Of Compliance (AOC) which is what you turn over to a customer if you are a service provider.

      The only difference would be with your acquiring bank who would likely prefer to see a ROC vs. an SAQ D, even when a QSA does an SAQ D. Sadly though, I know of firms that do not do much, if any, examination of evidence and just check the boxes, sign the AOC and move on. Which is why banks prefer the ROC over the SAQ.

  10. March 24, 2021 at 1:36 PM

    Regarding Bearer Tokens:
    One of my programmers recently asked me if there are any PCI DSS requirements regarding bearer tokens. Specifically, he is asking how often does PCI DSS recommends they be changed (rotated). I am unfamiliar with Bearer Tokens and have not been able to find any direct PCI DSS requirements that would influence the bearer tokens. I did find the RFC (, which has some recommendations regarding the rotation, but would like an expert’s opinion on how Bearer Tokens should be managed and secured in an environment that is within the scope of PCI DSS.

    • March 25, 2021 at 6:37 AM

      There is no guidance on this topic currently and I do not recall it being discussed in any of the v4 drafts, so I would expect no explicit guidance coming from the PCI DSS in the future. The Council may create an Information Supplement to discuss the topic, but that also is something for the future.

      That said, section 5 of the RFC has a great discussion on threats and mitigations to protecting the bearer tokens and I would use that as your reference.

      My guess would be you would want to rotate the token however often it makes sense based on the information being protected. General business information could have the token rotated annually or semi-annually. Payroll information might want a token rotated monthly.

  11. 30 Lloyd
    March 18, 2021 at 6:31 AM


    Thanks for the excellent site. Really useful.

    I have a question regarding devices from iZettle (and this probably refers to others such as Square).

    I understand that in this case, iZettle is the merchant, and therefore responsible for PCI DSS compliance. If I want to use these devices on a corporate LAN, where do I stand? Do I need to implement a segregated network, and complete a SAQ? Or do I just take iZettle’s statement at face value, and do nothing special?

    • March 19, 2021 at 4:01 PM

      Good questions.

      Unfortunately, we need more information to get you answers. I went out to the Zettle Web site and could not find any information on their POS solution. I assume it is end-to-end encrypted, but without explicit proof of that, I cannot say if you need to segment your network.

      Technically, Zettle is your acquiring bank, so they would be the ones requiring your organization to file an SAQ with them. If they are not requesting one, then you do not have to do one. That said though, I would recommend doing an SAQ B-IP for this solution just to make sure that you have all of those requirements covered.

      One other thing you need to do is to have an incident response plan in case the POS solution is tampered with or hacked. You will also need to have a procedure in place to examine the POS periodically to ensure that it has not been tampered with.

  12. 32 Pat
    March 5, 2021 at 5:14 PM

    Hi Guru,

    Our organization’s PCI program is maturing, and we are now expanding our requests for AoC’s beyond just those service providers who use our MIDs on our behalf. We’re now asking for AoCs from vendors who use their own MIDs, but may pose a risk to our “brand”.

    For example, an outsourced foodservice vendor with their own MID, POS system, employees, and network connectivity, but operating on our premises, and handling credit card data of our customers and employees.
    Because of the risk to our customers, employees, and our organization’s “brand” from a breach, we are requesting their AoC. In response to our request for an AoC, if a vendor asks “what does PCI AoC stand for?”, we believe we may have identified a credit card data risk that needs to be addressed.

    Q1: What are your thoughts on this?

    We asked the vendor whose name appears on the onsite vending machines (which accept credit card payments) for their AoC. They informed us that the vendor we contracted with for vending machine services actually subcontracted to them, and they in turn subcontracted to a third vendor. While we think we need an AoC from the party with whom we initially contracted, they would not be reasonably able to attest to what the 3rd subcontractor is doing.

    Q2: Can we accept an AoC from this “3rd vendor / 2nd subcontractor”?

    Q3: If this were an actual PCI-defined service provider, could we accept an AoC from a party we don’t directly contract with, or does that necessarily have to be attested to by the service provider we contracted with?

    –I really hope that made sense!

    And thanks, guru!


    • March 6, 2021 at 8:21 AM

      To your Q1, good luck with that. The vendor is technically correct in that it is whatever subcontractor that is responsible. That said, the vendor should have that AOC as part of their due diligence.

      As to Q2, that is up to you. There is nothing in the PCI DSS that says otherwise.

      For Q3, if you talk to your legal counsel, your organization has contracted through the legal process with the entity that is responsible. It is not direct, but all parties are legally bound, so technically there is accountability for compliance.

  13. 34 Frank
    February 16, 2021 at 7:53 AM

    Hello guru

    I have a question about searching credit card information on the Deepweb/Darkweb.
    I enter my credit card number in the system of a service provider and he regularly searches for this number in the darknet, in various forums.
    Do service providers who offer such services and store the credit card number in their systems have to be PCI-DSS certified and if so is a SAQ sufficient ?

    thank you

    • February 17, 2021 at 1:03 PM

      They should be PCI compliant, but I am guessing you are pointing out a gap in PCI compliance that flies under the radar.

      That said, an SAQ is fine as long as they do not handle more than 300K PANs. More than that and they should perform a Report On Compliance (ROC).

  14. 36 FRK
    January 7, 2021 at 5:44 AM

    Hi Guru,

    How can one provide evidence to the PCI auditor for requirement 4.1.c if the environment resides in AWS VPC and using wireshark is not possible?

    4.1.c Select and observe a sample of inbound and outbound transmissions as they occur (for example, by observing system processes or network traffic) to verify that all cardholder data is encrypted with strong cryptography during transit.


    • January 18, 2021 at 3:43 PM

      In this case you would have to rely on the configuration of the HTTPS and TLS certificate or whatever else is being used to encrypt the connection. You then say that you observed that HTTPS appeared in the browser or that you observed that the connection was encrypted.

      Serverless, virtual networks, etc. create a number of issues that are not easily addressed in the current PCI DSS because it was written before such technologies exist. Not that they cannot be addressed, you just much be creative in getting your evidence.

  15. 38 Lloyd
    December 3, 2020 at 4:41 AM


    I have a scenario where we have outsourced our online event ticketing to a compliant service provider. They handle all payment functions, using one of our merchant ids. My question is this. Where do we stand if we allow a member of the public to access the booking website to make their booking and pay for their tickets at one of our physical locations, using our PC, network etc.? I can’t decide if this will bring our network into scope or not.

    • December 8, 2020 at 5:39 PM

      If the payment is occurring on a device and network you own, yes, it will be in scope. That said, if you use a payment terminal (aka POI) that is a P2PE or E2EE device and you use tokenization, then only the POI is in scope.

  16. 40 Paul
    November 16, 2020 at 9:56 AM


    Question regarding segmentation and category 2/security impacting systems. Can you tell me, how is segmentation looked at from this perspective? More specifically, do these Cat 2 systems need to be in their own network segments and will the firewall rules that isolate them from the rest of the corporate network (not the CDE) also be in-scope for the firewall reviews? If for example a domain controller could connect both to the CDE and other non-CDE environments, would the assets in the non-CDE environment then be pulled into testing scope?

    Is there any guidance the council has put forth that speaks to this specific use case?

    • November 17, 2020 at 12:29 PM

      Easiest question first. See the Information Supplement ‘Guidance for PCI DSS Scoping and Segmentation’ for reference.

      As to your first question, you need firewalls to segment CDE, Connected To and not in scope network segments from one another. That does not necessarily mean separate firewalls (best approach), but separate network adapters on a single firewall with the appropriate rules. Connected To (Cat 2) systems are always in scope because they connect to systems that are directly in scope. Connected To systems are allowed to communicate to the CDE as well as out of scope systems but you must ensure that the out of scope systems cannot effect the security of Connected To systems that could then effect the security of the CDE.

  17. 42 gabbyndu
    October 23, 2020 at 4:24 AM

    How can organisations with their PCI-DSS assets in amazon cloud for example comply with requirement 1.1.7 that talks about firewall and router review every six months? knowing that they don’t have control over the firewall and routers

    • October 25, 2020 at 12:09 PM

      Pardon? This is a shared responsibility if you read the AWS responsibility matrix. AWS merely provides the capability, but your organization is responsible for establishing the firewall rules and network routes.

  18. 44 rlm
    October 22, 2020 at 12:21 PM

    Made an error in my last post..:

    Text contained in the major card brand program guides is somewhat confusing when it comes to deciphering franchisor/franchisee/TPSP PCI DSS accountability (think RACI model). American Express provides the clearest directive, as AMEX states that [remove all] “covered parties” are accountable for all entities associated with the entities’ Merchant Account.”

    • October 25, 2020 at 12:16 PM

      In most franchise arrangements, it is the franchisee that is on the hook for PCI DSS compliance. Where that can get messy though is with for example fast food where the franchisor may have connectivity into the franchisee’s systems for account, HR, inventory, ordering, monitoring, etc. In those cases, the Franchisor needs to be providing an AOC to the franchisee for those services they provide that could impact the security of CHD/SAD.

      A prime example of this arrangement is Exxon/Mobil Speedpass. That program is managed/maintained by Exxon/Mobile on behalf of their participating franchisees. Exxon/Mobil originally stored the CHD information and all transactions flow through them thus making Exxon/Mobil a service provider to their franchisees. It is my understanding now that Exxon/Mobil only stored tokens which gets the CHD out of their systems but they are still a service provider to their franchisees.

  19. 46 Stassi Hausen
    October 21, 2020 at 12:19 PM

    Do you happen to know if there are any limitations around reporting entities for ASV scans vs. SAQ’s? For example, if an entity reported via multiple SAQ’s, can they all rely on the same ASV scan providing that the appropriate hosts are included in the ASV scan or do they need to be separated to align with the SAQ’s?

    • October 22, 2020 at 11:22 AM

      I would have to ask why there are multiple SAQs with only one set of ASV scans. I would assume that the ASV is scanning everything used by the organization but for whatever reason there is an SAQ for each business unit for example. When that happens, you need to call out what infrastructure belongs to what BU for their individual SAQ.

      • 48 Robert
        October 25, 2020 at 4:13 AM

        I work for an acquiring bank and can confirm that there is no limitation in the Card Brand rules that prevents an entity from reporting their compliance using multiple SAQs and a single all-encompassing ASV. The primary reason an entity will attempt to report using multiple short-form SAQs is to align their acceptance channels in their CDE to the chosen SAQs. So long as the ASV scan tests all external IPs, it shouldn’t be a problem for the acquirer and Card Brands to accept. As PCIguru points out, you have to call out the infrastructure that belongs to the particular acceptance channel / SAQ.

        As an acquirer, we encourage merchants to aggregate multiple SAQs into one SAQ-D. They can validate using multiple SAQs if desired, but only one document should be submitted. This is easier for us, but moreover it ensures that the merchant has only one published compliance date in Section 3 of the AOC. Those merchants who report using multiple SAQs don’t always publish the same date on all SAQs making it more difficult for the acquirer to report compliance to the Card Brands.

  20. 49 Pete
    October 20, 2020 at 8:47 PM

    I’ve chased leads for over a year now, and have found statements supporting every side of the argument. I understand it can be complex, but the basic question should have a definitive answer available somewhere without all the circle talk.

    Scenario: I have a small office that takes card-present payments and is equipped with PCI-DSS approved P2PE hardware. The office is compliant and follows the P2PE requirements to a T.

    Twist: This office has begun taking phone payments over a VOIP system and entering the CHD on the P2PE keypads on behalf of the user.

    Question: Did this office’s SAQ qualification just change from a SAQ-P2PE to a SAQ-D by beginning to take phone payments over a VOIP system?

    Bonus Points: Does a possibility exist that would enable the office practices to proceed while still qualifying for P2PE? (Segmentation?)

    • October 22, 2020 at 11:29 AM

      Yes, your scope now includes the VoIP solution because people speak CHD/SAD over the phone. As a result, you are never going to be just P2PE once you added in VoIP.

      As to SAQ, yes you are probably going to have to use SAQ D to cover VoIP although a good portion will likely be marked as Not Applicable.

      One option is to outsource your VoIP and do end-to-end encryption (E2EE) between handsets and the call manager and other VoIP servers. That leave only handsets in scope which is not a heavy lift.

      Where organizations run into trouble is when they have softphones in use because softphones drag the workstations they run on into scope regardless of whether they discuss CHD/SAD via phone because they are directly connected to the CDE.

      You need to read the Information Supplement on Telephony from the PCI SSC Web site.

      • 51 Pete
        October 23, 2020 at 8:11 AM

        Thanks a bunch for your insight.
        After about 3 years on this project I still learn new things every day.

        Our VOIP implementation is already a hosted setup although, we are exploring DTMF masking in order to potentially de-scope the phone payments back out of the equation and get back to the P2PE qualification we desired. Hopefully DTMF masking can help us accomplish this.

        I have read the supplement you referenced, as well as every other resource I can possibly find regarding this subject. The answers are just not as clear as I would like. Your site has been one of the best resources of “plain talk” information I have found. Thanks a ton for that.

        In regards to your statement regarding “a good portion will likely be marked as Not Applicable”, I have one other hypothetical question to ask, as this too has produced conflicting information.

        Scenaro: If a company uses a flat network, but has two distinctively differing payment channels/processes, one meeting P2PE qualifications (branch office) and the other qualifying for SAQ-A (call center), I understand the proper way to accomplish this is by utilizing a SAQ-D to fulfill both channels.

        Question: If utilizing the SAQ-D form, can the company complete ONLY the requirements that are required either on the SAQ-A or the SAQ-P2PE form and mark EVERY OTHER requirement on the SAQ-D form as N/A, with the explanaition that it doesn’t apply to the SAQ-A and SAQ-P2PE qualifications, also fully explaining the intent and reasoning in the Executive Summary on the SAQ-D form.

        Thanks again for your insight. Your information provided at this site is awesome.

      • October 25, 2020 at 12:07 PM

        Whether or not DTMF masking reduces scope is dependent upon where it occurs. If it is before it hits the VoIP system, then it will reduce scope. If it occurs after (the most common implementation), the CHD is still going through the VoIP system and therefore it is not out of scope. It doesn’t matter that operators cannot hear the DTMF, its the fact that the call is still going through the VoIP call manager which is transmitting it to the DTMF masking solution.

        The short answer to your question is Yes. However, given my previous clarification, you may want to reconsider whether SAQ A is realistic for your call center.

  21. 53 Robert
    October 13, 2020 at 1:43 PM

    I have a question about MFA factors. Would a Kerberos token returned from a SAML call constitute a “Something you have” factor?

    • October 17, 2020 at 3:14 PM

      The Kerberos token is obtained by the user providing credentials. If the user’s credentials are compromised, anyone with those credentials can generate the Kerberos token so it is not MFA. The purpose of MFA is to not rely only on user credentials. You are relying on independent factors that cannot be derived from the other factors.

      • 55 Robert
        October 18, 2020 at 10:17 AM

        Thanks for those thoughts and I do agree with the position you’ve stated. The Kerberos token is obtained from a completely separate authentication environment from where the service is provided, and the user credentials which are associated with the service are validated in another separate authentication environment. So, the attacker would have to successfully compromise two disparate authentication environments to succeed with that attack. That situation does seem to fulfil the property of independence.

      • October 19, 2020 at 6:59 AM

        But is not the Kerberos token created as part of the authentication process using the user’s credentials to start the process? I would agree with you if the user must authenticate to LDAP for an example and then use different credentials to authenticate to Kerberos.

        However, in all of the Kerberos implementations I have seen, it is the user’s single set of credentials that authenticate as well as generate a Kerberos token behind the scenes. That is not MFA as defined by the PCI DSS nor NIST. You need two independent factors used to qualify as two factor authentication. Hence the something you know and something you have or something you are. One factor cannot generate the second or third factors.

      • 57 Robert
        October 20, 2020 at 7:09 PM

        The entity is trying to access a TPSP portal. The entity has implemented the following process. The entity has their auth system, a federated login based around AD. The TPSP has their own independant auth system, in no way related to the entity’s AD. An end user must have credentials on both systems and both access provisioning processes are separate. Having any one set of credentials does not guarantee portal access.

        The entity’s AD and federated login both need to be compromised to falsify a Kerberos token. The same assailant needs to compromise the TPSP’s AD to falsify the portal access. Both the entity’s token and the TPSP’s credentials are presented to the TPSP to get access. If access fails, it’s not possible to determine whether the token was bad or the TPSP credentials were bad.

      • October 22, 2020 at 11:31 AM

        I see two logons with different credentials. By definition that is NOT two factor authentication. See NIST SP800-63B for more information.

  22. 59 Rpm
    September 16, 2020 at 8:37 PM

    Hello Pciguru,

    What is the short term solution to resolve application hosted in PCF to connect directly with applications hosted in pci zone?

  23. 61 Deepa
    August 20, 2020 at 12:15 AM

    Hi PCI Guru, thanks for your support.
    I have a question on SAQ A.
    While SAQ A doesn’t not mandate customers using iframe on their website to have requirement 5 ( Antivirus ) and FIM solution and tea 10- logging , is it fine to go ahead with compliance without these basic important security requirements.
    The ecommerce guideline from PCI do recommend these in addition to SAQ A controls, but are these mandatory.
    Can we go ahead with certification without AV, FIM and logging for a website using iframe and eligible for a SAQ A.
    Thank you.

    • August 21, 2020 at 2:06 PM

      Remember, the Coucil always reminds people that the Information Supplements do NOT replace any requirements in the PCI DSS. They are written only to provide additional information on ways to approach compliance issues encountered when dealing with the PCI DSS.

      That said, I always explain to my clients that just because you are PCI compliant, does not mean you are secure. When that SAQ A compliant Web site gets compromised, it will NOT be the acquiring bank that is on the legal hook for that mistake. It will be you Ms. Client that is legally on the hook, so please act accordingly.

    • August 21, 2020 at 2:07 PM

      If it is NOT in SAQ A then to be PCI compliant, it is not needed.

    • 64 Deepa
      August 21, 2020 at 4:45 PM

      Thank you 👍

  24. 65 Deepa
    August 19, 2020 at 7:30 PM

    Hello Pci guru, thanks for all your insights.
    I have a question on call centers.
    If the call centers uses third party pci compliant call center soution that integrates with your calling soultion and makes uses of DTMF tones ( eg solutions from Secure co, semafone etc ) and thus call center agents do no see or hear card numbers or SAD, is the call center still is scope of pcidss.
    If yes what controls are to be validated in the call center. Thanks.

    • August 21, 2020 at 2:01 PM

      The problem with DTMF solutions is it all depends on how they are implemented. While call center operators cannot hear the tones, the call may still be processing through your Call Manager or telephone system which means it is still in scope. This is why you really need to follow the call flow to make sure that when DTMF is used, that VoIP flow is not still within your telephone system.

  25. 68 Joe H
    August 12, 2020 at 4:07 PM

    Hi PCIguru,

    Thank you for your work in maintaining this website. It has truly been informative and helpful.

    I have a query with regards to an organisation that has remediated their environment, and now meet the criteria for an SAQ-A and SAQ P2PE, BUT…. they believe they have CHD stored within legacy backup tapes in the form of email, files (e.g. Excel), etc. It is not a trivial task to restore all backups, search for CHD and securely delete them, as the backup of the environment is spanned across multiple tapes per backup run. Additionally, some legacy backup tapes exist but the system to restore them have been replaced with newer technology. The tapes are kept offsite in a secure facility and will eventually be disposed of in a few years time, when the data retention requirements have been exceeded.

    So, is there a way to ring fence these backup tapes, so that it does not contravene the SAQ requirement of legacy CHD Storage in the environment, and ultimately be assessed with an SAQ-A and SAQ P2PE.


    • August 13, 2020 at 7:40 AM

      Thank you for your question Joe.

      This is not as unusual a problem as you think. A lot of organizations get caught in this dilemma as they dig ever deeper into their processes and procedures. It’s a lot like cleaning an attic. I am assuming by your “remediation” comment that they have cleaned up their act going forward and are now dealing with their sins from the past.

      First thing they need to do is to determine secure methods of dealing with this situation. If there are tapes that cannot ever be used, those should be securely destroyed as soon as possible.
      I am assuming that the remaining tapes are not encrypted so they must be accurately tracked and secured. Assuming those tapes are in a facility like Iron Mountain, that physical security should be sufficient. Then you will need to make sure that any request for these tapes being brought back is approved by at least two people, one being an executive (i.e., CFO, CIO). If brought back, the tape must be secured when not in use such as being stored in a safe or locking secure cabinet and any access to use the tapes are logged. Once done with their use, they should immediately be securely returned to the offsite storage facility.

      Once you have those procedures documented and in place, the organization needs to talk to their acquiring bank about this situation and determine how the bank wishes to deal with it. The organization will explain their approach and get the bank’s approval to continue or will implement any changes.

      You will also want to discuss how the bank wishes you to report the fact that there is storage of CHD until it is purged with the last tape that contains CHD. That will be a $64K question. I have had banks say to report it on an SAQ D (most of which is NA) to just notate that it exists in the company’s file and the date the condition will no longer exist. I cannot give you any guidance as to how the bank will approach that situation.

      Good luck!

  26. 71 Jane L
    July 19, 2020 at 2:28 PM

    First, I thank you for your site and for your ask the PCI Dream Team web casts – they are a great resource! I would love to hear your thoughts on how much of SAQ A applies when the “redirect” is to a hosted form such as those offered by merchant payment gateways NelNet (QuikPay) and (Simple Checkout). Both of these large payment processors offer customized forms that are “linked” to via a custom URL. The merchant sets up a custom form on the payment gateway, then includes a custom URL on their web site that redirects the customer to the payment gateway/custom form to make the purchase. The US Treasury has something similar they offer on The URLs are also sometimes included on a printed form, or sent to the customer in an email. These custom forms are typically used for single purchases, like a electronic bill, vs. filling a shopping cart with items then making a payment. These methods fall under SAQ A, but is it SAQ A as a fully hosted eCommerce solution (where only SAQ A requirements under 9 and 12 would apply to the merchant), or SAQ A (where requirements under 2, 6,and 8) also would apply to the merchant)? For example, many universities use QuikPay (a simple google search on “commerce_manager/” will return many examples) and may have hundreds of such links on their Web sites (which may be hosted by many different internal and 3rd party organizations). These merchants are under the impression they have no PCI responsibilities under SAQ A other than 9 (if applicable) and 12, but SAQ A specifically states it applies “to e-commerce merchants that redirect customers from their website to a third party for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located.” Does this type of redirect (a link to a 3rd party payment processor) meet the definition of “redirect” in SAQ A? How is this any different than just redirecting the user to another eCommerce site altogether (e.g., to In one of your responses to a comment on you “of redirects and reposts-updated” article, you stated “Just because a Web site sends a user to another Web site and that Web site is an eCommerce site, does not mean that the original Web site needs to be PCI compliant. That would mean that the entire Internet would need to be PCI compliant and we all know that will never happen.” I would appreciate any thought you might have.

    • July 20, 2020 at 9:08 AM

      “but is it SAQ A as a fully hosted eCommerce solution (where only SAQ A requirements under 9 and 12 would apply to the merchant), or SAQ A (where requirements under 2, 6,and 8) also would apply to the merchant)?”

      I would refer you to the SAQ A criteria documented on page iii. I would also refer you to the PCI SSC FAQs with a search for ‘SAQ A’. All of this information can answer your question.

      “These merchants are under the impression they have no PCI responsibilities under SAQ A other than 9 (if applicable) and 12, but SAQ A specifically states it applies “to e-commerce merchants that redirect customers from their website to a third party for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located.” Does this type of redirect (a link to a 3rd party payment processor) meet the definition of “redirect” in SAQ A?”

      It all depends on how the redirect or iFrame are implemented. Again, some of the aforementioned FAQs on SAQ A address your question.

      Your merchants my be correct about their scope regarding SAQ A but this is all contingent on how the data does or does not flow through their Web site. That said, as I have pointed out many times, while an organization complies with SAQ A, that does not ensure they are secure. Should a bad actor change the redirect or iFrame invocation, that error will be on the merchant, NOT the service provider or their bank. So people need to look beyond just being compliant because that does NOT remove or mitigate their risks.

  27. 73 Wayne G
    June 22, 2020 at 4:20 PM

    Hey PCIGuru, first of thank you for this amazing page and thread. The info from your answers here are very helpful.
    We have a web application that we are adding credit card payment functionality to with a partner who handles the full CC transaction. We don’t store or process anything but use Checkout.js to tokenize the transaction with our payment partner. We are under SAQ-A-EP.

    I have a couple of questions regarding inactivity timeout (specifically 8.1.8) “If a session has been idle for more than 15 minutes, are users required to re-authenticate to re-activate the terminal or session”
    Given the industry and the way our application is used we are trying to come with a different solution. One idea is rather then log the user out of the system completely after 15min, would be to make them authenticate again when accessing the CC payment/management area then log them out of that portion of the application that deals with CC payments after 15min of inactivity. Would that be acceptable or is there an easier method like a cookie timeout?
    Second question, I’m a bit baffled that many SAAS admin consoles I use on a daily basis such as Office 365 and Atlassian don’t seem to log you out after 15min of inactivity, it made me question my interpretation and I was wondering how they get away with that?

    • June 23, 2020 at 8:20 AM

      Requirement 8.1.8 applies to people you control such as employees, contractors, third parties, etc. that have access to systems and devices in the CDE. Not consumers that are shopping on your site.

      That said, if someone was paying for something and got side tracked and did not complete payment, I would like to think you or your processor would step in and deactivate the consumer’s session after 15 minutes or less.

Leave a Reply

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

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

Google photo

You are commenting using your Google 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

October 2021


%d bloggers like this: