Document Comparison

SPoC_Technical_FAQs_v1.4.pdf SPoC_Technical_FAQs_v1.5.pdf
60% similar
12 → 13 Pages
3529 → 4287 Words
33 Content Changes

Content Changes

33 content changes. 19 administrative changes (dates, page numbers) hidden.

Added p. 6
An SPoC solution includes a Secure Card Reader

• PIN (SCRP), a PIN CVM application, the merchant’s COTS device, and back-end monitoring/attestation systems.

These elements work together to ensure the PIN, which has been accepted by a software application on the COTS device, is isolated within the COTS device from other sensitive account data. The back-end monitoring/attestation systems monitor the entire solution continuously for anomalous activity and to ensure that the solution has not deviated from the baseline due to tampering, rooting, or physical attacks. In other words, within an SPoC solution, the merchant-facing COTS device is only one element in the entire solution, whereas a Point of Interaction (POI) device is generally a single device.
Added p. 7
An SPoC solution consists of PCI-approved SCRPs, an optional standalone MSR device that meets the security and testing requirements detailed in Payment Card Industry (PCI) Software-based PIN Entry on COTS Magnetic Stripe Readers Annex, a PIN CVM application, optional libraries or APIs to allow third parties to interface the SPoC solution, merchant COTS devices, and back-end systems. The SPoC solution will be listed on the PCI SSC website.

Q 13 [June 2020] Can a SPoC solution provider compose a SPoC solution from third- party elements? A The SPoC Standard does not prohibit using a third-party service provider or elements developed by a third-party, as long as the SPoC solution in its entirety and as a whole solution is evaluated by the SPoC laboratory. Regardless of whether the SPoC solution, including a PIN CVM application, has been developed in-house or by a third-party, each SPoC solution provider is ultimately responsible for ensuring …
Added p. 12
Q 27 [June 2020] What is expected from a SPoC Lab when evaluating a SPoC solution that offers APIs or software libraries to allow third-party developers to interface with the SPoC solution? A The evaluation and validation of the APIs (together with the SPoC user guidance document described and defined in the SPoC Program Guide) by a SPoC Lab are required as part of each SPoC solution in which such libraries or APIs are provided. It is expected the SPoC Lab validates that third-party usage of the libraries or API cannot negatively impact the functionality, security or compliance with the SPoC Standard.

It is expected that the SPoC Lab evaluates the SPoC user guidance, provided by the SPoC solution provider, which describes how the API is used to interface the SPoC solution.

While reporting on the API’s validation, the SPoC Lab should follow the same process used for the reporting of PIN …
Added p. 12
The final laboratory evaluation reports must be received by PCI no later than sixty-day after the SPoC Standard and the associated SPoC Program Guide publication date.

Existing SPoC solutions are not affected and remain validated per the date on the listing on the PCI SSC website. However, SPoC solution provider may choose to engage a SPoC Lab to perform a delta or a full evaluation, as determined by the SPoC lab, to update a listed SPoC solution on the PCI SSC website.
Added p. 13
Q 30 [June 2020] Can a Delta change be submitted to update a listed SPoC solution between minor versions of the SPoC Standard? A Yes, the change is submitted to a SPoC Lab and it is up to the SPoC Lab to determine whether the extent of the change(s) can be validated via delta evaluation. If the changes are extensive or highly impactful to the SPoC security requirements, then the SPoC Lab may determine that a full evaluation is required. Note that all changes must be accompanied by current SPoC Attestation of Validation (AOV), and in accordance with SPoC Program Guide.

Please note that if a delta change is performed to update a listed SPoC solution between minor versions of SPoC Standard (e.g., from version 1.0 to version 1.1), the re-evaluation/expiry date does not change.

Q 31 [June 2020] Can an Administrative change be submitted to transition a listed SPoC solution from …
Removed p. 4
Q 1 [December 2019] What is a COTS Device? A A commercial-off-the-shelf (COTS) Device is a mobile device (smartphone, tablet, or wearable) that is designed for mass-market distribution.
Modified p. 4
Q 2 Are there any restrictions to specific form factors for COTS Devices and SCRPs that can be approved under the PCI SPoC Program? A No, the SPoC requirements do not dictate a specific form factor for the COTS Device, the SCRP, or the combination thereof for inclusion in an approved and validated SPoC Solution.
Q 1 Are there any restrictions to specific form factors for COTS devices and SCRPs that can be approved under the PCI SPoC Program? A No. The SPoC requirements do not dictate a specific form factor for the COTS device, the SCRP, or the combination thereof for inclusion in an approved and validated SPoC solution.
Modified p. 4
Q 3 Are contactless transactions allowed under the SPoC Standard? A Yes. The Standard supports both EMV-based and magnetic stripe mode contactless transactions.
Q 2 Are contactless transactions allowed under the SPoC Standard? A Yes. The Standard supports both EMV-based and magnetic stripe mode contactless transactions.
Modified p. 4
Q 4 In the SPoC Test Requirements (TRs), where the attack-costing thresholds are required, there is no minimum. When will the attack-costing threshold values be added, and how should labs evaluate the relative requirements in the interim? A The PCI SSC will work directly with the labs that are qualified to perform Solution assessments. Each assessment will be used to contribute relative attack-costing information using actual Solution validation data that will be factored into the development of appropriate attack-costing values. …
Q 3 In the SPoC Test Requirements (TRs), where the attack-costing thresholds are required, there is no minimum number of thresholds. When will the attack-costing threshold values be added, and how should labs evaluate the relative requirements in the interim? A The PCI SSC will work directly with the labs that are qualified to perform solution assessments. Each assessment will be used to contribute relative attack-costing information using actual solution validation data that will be factored into the development of …
Modified p. 5
Q 5 Please explain the difference between a “session” and a “transaction” within the context of the SPoC Standard? A A “session” is established when the PIN CVM Application initiates a payment. This session establishes secure channels with the Secure card reader

• PIN (SCRP) and with the Back-end Monitoring System. The session terminates when payment is complete or when any anomalous behavior is detected in The Solution at any point during the payment process.
Q 4 What is the difference between a “session” and a “transaction” within the context of the SPoC Standard? A A “session” is established when the PIN CVM application initiates a payment. This session establishes secure channels with the Secure Card Reader

• PIN (SCRP) and the back-end monitoring system. The session terminates when payment is complete or when any anomalous behavior is detected in the solution at any point during the payment process.
Modified p. 5
A “transaction” consists of the payment processing messages created and exchanged with the Back-end Payment Processing Systems to gain authorization for a customer.
A “transaction” consists of the payment-processing messages created and exchanged with the back-end payment processing systems to gain authorization for a customer.
Modified p. 5
Q 6 Regarding “Customer Data” and “Correlatable Data”, what is the scope of this data? A The scope applies to data that is entered into a PIN CVM Application on a COTS Device as part of the payment transaction process, or that is sent from the Back-end Monitoring System to the COTS Device. The scope is limited to data entered by the cardholder at the time of the transaction for purposes such as receipt transmission.
Q 5 Regarding “customer data” and “correlatable data,” what is the scope of this data? A The scope applies to data that either is entered into a PIN CVM application on a COTS device as part of the payment-transaction process or is sent from the back-end monitoring system to the COTS device. The scope is limited to data entered by the cardholder at the time of the transaction for purposes such as receipt transmission.
Modified p. 5
Q 7 What are the use cases for a SPoC Solution? A SPoC Solutions are intended for use in a face-to-face environment where the merchant hands the COTS Device to the customer. The customer then enters a PIN and hands the COTS Device back to the merchant.
Q 6 What are the use cases for an SPoC solution? A SPoC solutions are intended for use in a face-to-face environment where the merchant hands the COTS device to the customer. The customer then enters a PIN and returns the COTS device to the merchant.
Modified p. 5
Q 8 What is the intent of use of a SPoC Solution in an attended versus an unattended environment? A The SPoC Standard is intended for merchant COTS Devices in attended environments.
Q 7 What is the intent of use of an SPoC solution in an attended versus an unattended environment? A The SPoC Standard is intended for merchant COTS devices in attended environments.
Modified p. 5
Attended environments are when the COTS Device is made available to the customer by the merchant during a payment transaction. For example, the merchant hands the COTS Device to the customer. The customer enters a PIN and hands the COTS Device back to the merchant.
Attended environments are when the merchant makes the COTS device available to the customer during a payment transaction (for example, when the merchant hands the COTS device to the customer). The customer enters a PIN and returns the COTS device to the merchant.
Removed p. 6
A SPoC Solution includes an SCRP (Secure Card Reader

• PIN), a PIN CVM Application, the merchant’s COTS Device, and Back-end Monitoring/Attestation Systems. These elements work together to ensure the PIN, which has been accepted by a software application on the COTS Device, is isolated within the COTS Device from other sensitive Account data. The Back-end Monitoring/Attestation Systems continuously monitor the entire Solution for anomalous activity and to ensure The Solution has not deviated from the baseline because of tampering, rooting, or physical attacks. In other words, within a SPoC Solution, the merchant-facing COTS Device is only one element in the entire Solution, whereas a Point of Interaction (POI) device is generally a single device.

Contact magnetic stripe reads must only occur using a separate Magnetic Stripe Reader (MSR) Device that complies with the SPoC Annex, and the PIN CVM Application must prevent the entry of the PIN.

Q 11 Can a merchant …
Modified p. 6
Q 9 Is SPoC synonymous with PIN on Glass? A No. The SPoC Standard covers a software-based approach for accepting a PIN as the cardholder verification method on a merchant-owned COTS Device. The phrase “PIN on Glass” is often used to describe a variety of use cases, where a PIN is entered on a glass-based capture mechanism; that is, a touch screen.
Q 8 Is SPoC synonymous with PIN on Glass? A No. The SPoC Standard covers a software-based approach for accepting a PIN as the cardholder-verification method on a merchant-owned COTS device. The phrase “PIN on Glass” is often used to describe a variety of use cases where a PIN is entered on a glass-based capture mechanism (touch screen).
Modified p. 6
There are numerous PCI PIN Transaction Security (PTS) approved hardware-based POI devices that accept a PIN using a touch screen (PIN-on-Glass). These POI devices are built purposely for payment acceptance. Therefore, care must be taken when using the generic phrase “PIN-on-Glass”: for example, a PTS-approved POI device that accepts PIN-on-Glass is very different from a SPoC Solution that uses a merchant- facing COTS Device to accept a PIN.
There are numerous PCI PIN Transaction Security (PTS)-approved hardware-based POI devices that accept a PIN using a touch screen (PIN-on-Glass). These POI devices are built purposely for payment acceptance. Therefore, care must be taken when using the generic phrase “PIN-on-Glass.” For example, a PTS-approved POI device that accepts PIN-on-Glass is very different from an SPoC solution that uses a merchant- facing COTS device to accept a PIN.
Modified p. 6
Q 10 Are magnetic stripe-based transactions allowed by the SPoC Standard? A Yes. The Standard supports both EMV-based and magnetic-stripe mode-based contactless transactions. It also optionally supports the contact magnetic stripe reads.
Q 9 [June 2020] Are magnetic stripe-based transactions allowed by the SPoC Standard? A Yes. The Standard supports both EMV-based and magnetic-stripe mode-based contactless transactions. Solutions may optionally support magnetic-stripe readers that meet the security and testing requirements described in Payment Card Industry (PCI) Software-based PIN Entry on COTS Magnetic Stripe Readers Annex.
Removed p. 7
A SPoC Solution consists of PCI-approved SCRPs, an optional MSR that complies with the SPoC Annex, a PIN CVM Application, merchant COTS Devices, and Back-end Monitoring/Attestation Systems. The SPoC Solution will be listed on the PCI SSC Website with the individual elements.

Q 15 Is it possible to include an operating system (OS) version in the COTS System Baseline of the initial Solution evaluation that is not supported by the OS vendor at the time of evaluation? A No. Security Requirement 2.2.2 requires that PIN CVM Applications must be developed only for operating systems that are still supported by the operating system vendor. All new Solutions must operate only on supported platforms. The initial COTS System Baseline must not include any version of a COTS OS that is not supported by the OS vendor at the time of the initial evaluation.
Modified p. 7
Q 12 Can a merchant put together their own SPoC Solution by choosing an SCRP, PIN CVM Application, and Back-end Monitoring System? A No. Only complete SPoC Solutions will be approved and listed on the PCI SSC Website.
Q 11 Can merchants put together their own SPoC solution by choosing an SCRP, PIN CVM application, and back-end monitoring system? A No. Only complete SPoC solutions will be approved and listed on the PCI SSC website.
Modified p. 7
Q 13 What constitutes a SPoC Solution? Does the SPoC Standard cover separate elements or is it a single solution? A The SCRP will have a separate listing because it is evaluated and listed as part of the PTS POI Standard. However, all SCRPs associated with a SPoC Solution will be included as part of the SPoC Solution evaluation and listed as part of that SPoC Solution’s acceptance. It is also possible that an MSR evaluated as part of SPoC …
Q 12 [June 2020] What constitutes an SPoC solution? Does the SPoC Standard cover separate elements or is it a single solution? A The SCRP will have a separate listing because it is evaluated and listed as part of the PTS POI Standard. However, all SCRPs associated with an SPoC solution will be included as part of the SPoC solution evaluation and listed as part of that SPoC solution’s acceptance. It is also possible that an MSR evaluated as part …
Modified p. 7
Q 14 Is a SPoC Solution eligible for a Point-to-Point Encryption (P2PE) Solution approval? A No. The SPoC Standard and the P2PE Standard are separate PCI SSC standards that are intended for different use cases.
Q 14 Is an SPoC solution eligible for a Point-to-Point Encryption (P2PE) solution approval? A No. The SPoC Standard and the P2PE Standard are separate PCI SSC standards that are intended for different use cases.
Modified p. 8
Q 17 Security Requirement 2.2.5 states that where white-box cryptography is used, white-box keys must be unique for each PIN CVM Application instance, and that the reliance upon and use of common white-box keys must be minimized after the secure provisioning process. Does this requirement apply to all white-box keys as it relates to unique keys per PIN CVM Application, or just those used for encrypting a PIN? A The intent of the requirement is that where white-box cryptography is …
Q 17 Security Requirement 2.2.5 states that where white-box cryptography is used, white-box keys must be unique for each PIN CVM application instance, and that the reliance upon and use of common white-box keys must be minimized after the secure-provisioning process. Does this requirement apply to all white-box keys as it relates to unique keys per PIN CVM application, or just those used for encrypting a PIN? A The intent of the requirement is that where white-box cryptography is used, …
Modified p. 8
Q 18 Security Requirement 2.2.4 states that the PIN CVM Application must detect sensor activation and polling of sensor data. Does this requirement apply to all COTS Platforms? A The intent of the requirement is to protect the PIN entry process from manipulation or subversion. Because several attack vectors use COTS Platform sensors and hardware for side-channel attacks, detecting when these sensors are activated or used (i.e., polling sensor data) by untrusted applications can reduce the risk of PIN compromise.
Q 18 Security Requirement 2.4.2 states that the PIN CVM application must detect sensor activation and polling of sensor data. Does this requirement apply to all COTS platforms? A The intent of the requirement is to protect the PIN entry process from manipulation or subversion. Because several attack vectors use COTS platform sensors and hardware for side-channel attacks, detecting when these sensors are activated or used (i.e., polling sensor data) by untrusted applications can reduce the risk of PIN compromise.
Modified p. 8 → 10
Q 19 [December 2019] Security Requirement 3.2.13 states that for manual updates to the Attestation System, any deployment changes to the production environment require dual control. Is dual control necessary for Attestation System components associated with the PIN CVM Application recognizing that such applications are signed by the OS App Store and not under the control of the Solution Provider? A While it is acknowledged that the signing of a PIN CVM Application made available from the OS App Stores
Q 21 Security Requirement 3.2.13 states that for manual updates to the attestation system, any deployment changes to the production environment require dual control. Is dual control necessary for attestation system components associated with the PIN CVM application recognizing that such applications are signed by the OS app store and not under the control of the solution provider? A While it is acknowledged that the signing of a PIN CVM application made available from the OS app stores is not …
Removed p. 9
Q 20 SPoC Security Requirements 3.6.1 and 5.1.2 state that if the Back-end Monitoring System resides in the Cardholder Data Environment (CDE), then PCI DSS, Appendix A3 “Designated Entities Supplemental Validation (DESV)” will apply.

Q 21 If a version of the COTS OS initially listed in the Solution System Baseline reaches end-of-life such that it is no longer supported by the original OS vendor, does the SPoC Standard disallow transactions on affected COTS Devices until the OS on those devices is updated to a supported OS? A No. If an OS version has been assessed and is listed as part of the COTS System Baseline, (TR C1), and then the OS vendor ends support for that OS version, then per Security Requirement 4.3.7 and TR C4, the Solution Provider must provide evidence that the acceptance and use of such a platform that accepts PIN entry will not increase the risk of …
Modified p. 9 → 10
Does a SPoC Solution Provider have to be fully compliant with DESV when submitting a SPoC Solution for initial validation? A If the Solution Provider cannot meet DESV requirements at the point of an initial SPoC Solution validation, the Solution Provider must provide an action plan to the SPoC lab, demonstrating that work is in progress for requirements to be met at the first annual checkpoint. The action plan will be reviewed for sufficiency.
Q 22 SPoC Security Requirements 3.6.1 and 5.1.2 state that if the back-end monitoring system resides in the Cardholder Data Environment (CDE), PCI DSS, Appendix A3 “Designated Entities Supplemental Validation (DESV)” will apply. Does an SPoC solution provider have to be fully compliant with DESV when submitting an SPoC solution for initial validation? A If the solution provider cannot meet DESV requirements at the point of an initial SPoC solution validation, the solution provider must provide an action plan to …
Modified p. 9 → 10
SPoC Security Requirement 4.3
SPoC Security Requirement 3.6
Removed p. 10
Q 22 If an OS vender issues an update to a COTS OS that was initially listed in the Solution System Baseline, does the SPoC Standard disallow transactions on COTS Devices using the updated OS until the updated OS is evaluated? A No. If an updated version of an OS that is already listed in the COTS System Baseline is made available by the original OS vendor, then the Solution Provider may add that version to the COTS System Baseline and must provide evidence that the acceptance and use of such a platform as a part of the annual update of the risk-assessment policy and procedure. If such evidence is accepted at time of the review by PCI SSC after review of the laboratory evaluation report, then the new platform may continue to be used.

If such evidence is not provided or is not accepted by the PCI SSC, the SPoC …
Modified p. 10 → 11
Q 24 Test Requirement TB2.5 calls for the disabling of on-device sensors during PIN entry. Does this requirement apply to all COTS Platforms? A The SPoC Standard does not require disabling on-device sensors during PIN entry.
Q 24 Test Requirement TB2.5 calls for the disabling of on-device sensors during PIN entry. Does this requirement apply to all COTS platforms? A The SPoC Standard does not require on-device sensors to be disabled during PIN entry. This requirement applies only if the solution provider implemented programmatic methods, manual processes (for example, prompting the end-user to disable a sensor), or a combination of both to disable on-device sensors.
Removed p. 11
Q 26 [December 2019] What is required by SPoC Solution Providers and SPoC Labs regarding the note in section 4.1 Required Vendor Materials of the SPoC Program Guide? A In cases where a Vendor or SPoC Solution/SPoC Element cannot meet a specific requirement as stated, the Vendor must clearly explain why the requirement cannot be met as stated. The Vendor must also provide evidence to clearly show how the corresponding security objective is still being met or exceeded, and that the alternative controls or methods are employed to provide equivalent or greater assurance to that provided by the methods described in the requirement. Vendors should work with their SPoC Lab to determine the evidence required to satisfy a specific security objective or associated requirement. The SPoC Lab is responsible for evaluation of the alternative controls or methods, and must include in the evaluation report a description of the testing they …
Modified p. 11
Q 25 Can a SPoC Solution be associated with and communicate with multiple SCRPs, or MSRs concurrently? A Yes. A SPoC Solution is permitted to support the use of multiple SCRPs or MSRs (per the SpoC Annex). The use of multiple SCRPs or MSRs in the SPoC Solution is optional. The Back-end Monitoring System must be able to interact with each SCRP. All SCRPs supported by the SPoC Solution must act in accordance with all roles and responsibilities as detailed
Q 25 [June 2020] Can an SPoC solution be associated with and communicate with multiple SCRPs or MSRs concurrently? A Yes. An SPoC solution is permitted to support the use of multiple SCRPs or MSRs that meet the security and testing requirements described in the Payment Card Industry (PCI) Software-based PIN Entry on COTS Magnetic Stripe Readers Annex. The use of multiple SCRPs or MSRs in the SPoC solution is optional. The back-end monitoring system must be able to interact …