Document Comparison

Q 14 [March 2024] Can an MPoC evaluation exclude requirements which would normally be included in scope (such as payment acceptance methods, or connected devices)? A No. All requirements which are brought into scope due to the functionality of the MPoC Product must be included in the assessment. Any ‘N/A’ finding must be justified by the MPoC Laboratory as to why that requirement does not apply. For example, the assessment of an MPoC SDK or MPoC Application which supports use of an MSR cannot exclude MSR requirements.

Q 15 [March 2024] Can an MPoC Application to be listed as part of an MPoC Solution be developed by an entity other than the MPoC Solution provider? A Yes. The MPoC Solution provider is responsible for ensuring that any MPoC Application that is part of their listing meets all relevant MPoC requirements, including any BAU requirements. The MPoC Solution provider may act as …

Q 16 [March 2024] Is it required that a laboratory use more than one model/manufacturer of COTS device when evaluating a candidate MPoC Product? A Yes. Where an MPoC Product supports Platforms that may have different implementations or configurations of operating system or hardware, more than a single model/manufacturer of COTS device must be used during testing. Use of all possible configurations of device and operating system type is not required.

Q 10 [March 2024] Can the default random number generator of a COTS platform be used as the sole source of COTS-based entropy to seed a DRNG? A As per requirement 1A-2.3 a DRNG is required when a true random number generator is not used as the source of random numbers on the COTS device. As per

requirement 1A-2.5 a DRNG must use at least two sources of entropy as its seed

• one sourced externally and one sourced internally. As per requirement 1A-2.4 the internal entropy seeds must be trusted.

A trusted source of entropy is one where the entropy output has been validated through testing and there is a reasonable assurance that this testing is valid for all COTS platforms in the baseline.

Q 11 [March 2024] Does the MPoC SDK / MPoC Application need to prevent the use of weak cipher suites when using TLS to meet secure channel requirements? A Yes. An MPoC SDK / MPoC Application must ensure secure channels used to meet

section 1A-5 are equal or equivalent to the cryptographic requirements outlined in Appendix C: Minimum and Equivalent Key Sizes and Strengths for Approved Algorithms. Secure channels which do not meet these requirements must be rejected, or not relied upon to meet the MPoC requirements.

Q 2 [March 2024] Does an A&M system require a backend component? A Yes. An A&M system must implement a backend command and control system that collects and uses information gathered from many devices on which MPoC Applications are installed to make security decisions about any specific installed instance of the MPoC Application.

Q 2 [March 2024] If a COTS device has a physical keypad, can this be used for PIN entry in an MPoC SDK / MPoC Application? A No. An MPoC Software Product or MPoC Solution can support PIN entry only through use of the touch screen on the COTS platforms supported (in accordance with relevant MPoC requirements).

Q 3 [March 2024] Is it possible to implement per-transaction accessibility features for MPoC SDKs and/or MPoC Applications? A Yes. Accessibility features may be made available on a per-transaction basis, and must not be the default or sole PIN entry method offered. Accessibility features must not display the individual PIN digits themselves or provide feedback (audio, visual, or haptic) that is unique to individual PIN digits. ‘Zoom’ features to increase the size of keypad buttons may be provided, as long as individual PIN digits cannot be uniquely identified.

The MPoC Software and the A&M system …

Q 3 [March 2024] Can an MPoC Vendor provide tools to assist an MPoC Laboratory with the Domain 2 testing of an MPoC Application integrating that Vendor’s MPoC SDK? A Yes. An MPoC Vendor may provide tools to assist with laboratory evaluations, such as those performed under Domain 2A for MPoC Applications integrating an Isolating SDK. Such tools may include automated scanning processes to help confirm the correct and secure integration of that vendors Isolating SDK.

At all times, the MPoC Laboratory is responsible for the correctness and completeness of the testing process, and it is expected that an MPoC Laboratory will validate any such tooling prior to use.

Testing must be performed within the scope of the MPoC Laboratories validation under their MPoC Laboratory listing, including physical, logical, and procedural controls. MPoC Laboratories are not able to submit testing performed on their behalf by another entity, including the MPoC Vendor.