Document Comparison

MPoC-Technical-FAQs-v1-0.pdf MPoC-Technical-FAQs-v1-1.pdf
41% similar
5 → 11 Pages
816 → 3113 Words
8 Content Changes

Content Changes

8 content changes. 8 administrative changes (dates, page numbers) hidden.

Added p. 5
Q 4 [May 2023] Must an Isolated SDK protect itself, or its memory isolation properties, from compromise during the build process during MPoC Application release? A No. In assessing whether an SDK can be classified as Isolating, only attacks against the built MPoC Application need to be considered. Assessment of the on-going processes used to ensure the security of MPoC Application builds will be validated during the annual checkpoint process as part of the application vendors Secure SLC process.

Q 5 [May 2023] Is the execution of an MPoC SDK within a process separate to that of the MPoC Application sufficient to meet the definition of an Isolating SDK? A Many modern operating systems allow for a single application to launch multiple processes, and provide to these processes their own virtual memory space. This new memory space can be isolated from other processes, even if those processes are owned by the …
Added p. 6
Q 6 [May 2023] Is a COTS device permitted to use an NFC antenna which may be removed as part of the device casing or internal sub-component such as a battery? A Yes. MPoC requires that a COTS device is not intended for integration into another device, but use of a device which may be disassembled is acceptable if the removal of any required subcomponent renders the device inoperable or clearly in a state of disassembly (such as through the removal of an internal battery or external casing).

However, MPoC does not allow for use of external or third-party NFC antenna other than through use of a listed PCI PTS SCRP. Any removable antenna must be entirely passive, MPoC does not support the use of removable NFC subsystems which contain a digitizing element.

Q 7 [May 2023] Are there any restrictions to specific form factors for COTS devices and SCRPs that can …
Added p. 7
Moreover, as part of the annual checkpoint, the MPoC Laboratory must consider new risks, vulnerabilities/CVE, and attack techniques (such as new rooting or jailbreaking) and attempt to apply those techniques to ensure that attestation and monitoring systems are able to detect and respond to those attacks.

An example of requirements which should be considered during an annual checkpoint include (but may not be limited to) the list below. The MPoC Laboratory is expected to determine the exact scope for each annual checkpoint based on the MPoC Product under review, and the changes made to that MPoC Product during the year.

Domain 1: 1A-1.1, 1A-1.2, 1A-1.3, 1A-1.4, 1B-2.4 Domain 2: 2A-1.1, 2A-1.2, 2A-1.7, 2A-1.9 Domain 3: 3A-1.1, 3B-1.2, 3B-1.3, 3B-1.4, 3C-1.1, 3C-2.3, 3D-1.1, 3D-1.2, 3D-1.3 Domain 4: 4A-1.5, 4A-2.1, 4A-2.8, 4A-3.1, 4A-3.2 Domain 5: 5A-1.3, 5A-2.2, 5A-3.1, 5A-3.3 Each annual checkpoint submission must be made by an MPoC Laboratory and include the submission …
Added p. 10
Q 1 [May 2023] Requirement 1F-1.4 states that payment transactions may be accepted in offline mode for a maximum period of 48 hours. However, requirement 1F-2.4 states that the MPoC SDK must disable all payment acceptance after no more than 24 hours of no response from the A&M backend.

How do these two different times relate to one another? A The MPoC requirements separate the concept of ‘offline payment transactions’ from the concept of ‘disconnection from backend services’. For example, due to some issue with the backend payment processing environment (that does not similarly affect the A&M system), an MPoC SDK may be enabled to perform offline payment acceptance whilst still connected to the backend A&M system.

However, in all cases, if an MPoC SDK that supports offline payment processing is disconnected from the A&M backend, it will be required to cease payment processing after 24 hours. In circumstances where connection to …
Modified p. 5 → 9
MPoC Security Requirement 3D
MPoC Security Requirement 1C
Modified p. 5 → 11
Q 1 Requirements 3D-1.1 and 3D-1.2 outline the need for the security assessment of the A&M backend environment. Are these requirements the only options, and if so when do they apply? A A&M backend environments must be assessed to either Appendix A or to PCI DSS DESV. One of either 3D-1.1 or 3D-1.2 must be assessed as part of a compliant report.
Q 1 Requirements 3D-1.1 and 3D-1.2 outline the need for the security assessment of the A&M backend environment. Are these requirements the only options, and if so when do they apply? A A&M backend environments must be assessed to either Appendix A or to PCI DSS DESV. One of either 3D-1.1 or 3D-1.2 must be assessed as part of a compliant report. Assessment to Appendix A is only suitable if the A&M systems are sufficiently isolated from the payment processing …
Modified p. 5 → 11
Assessment to Appendix A is only suitable if the A&M systems are sufficiently isolated from the payment processing systems and Cardholder Data Environment. For details on what may be considered ‘sufficient isolation’ refer to the PCI DSS, and associated information supplements and FAQs.
For details on what may be considered ‘sufficient isolation’ refer to the PCI DSS, and associated information supplements and FAQs.
Modified p. 5 → 11
In all other cases, where sufficient isolation is not provided, the A&M environment must be compliant to the requirements of the PCI DSS, including Appendix A3: Designated Entities Supplemental Validation (DESV).
In all other cases, where sufficient isolation is not provided, the A&M environment must be compliant to the requirements of the PCI DSS, including Appendix A3: