PCI Watch

Tracking changes across the Payment Card Industry

Document Comparison

MPoC-Technical-FAQs-v1_7.pdf → MPoC-Technical-FAQs-v1_8.pdf
65% similar
19 → 20 Pages
6208 → 6648 Words
8 Content Changes

Content Changes

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

Added p. 10
Q 18 [October 2025] Can an MPoC laboratory fill out and submit an MPoC Integration Report, even for an MPoC SDK that is not listed as suitable for Vendor Verification? A Yes. When an Integration Report is submitted by a lab, the MPoC SDK being integrated must be an isolating SDK. While this MPoC SDK does not need to be listed as suitable for Vendor Verification, it must still meet all applicable isolating requirements. In this case when filling out the Integration Report, the lab would leave the 5th and 7th checkboxes in Part 4a of the document unchecked.

Q 19 [October 2025] What is required for an MPoC Application that is to be listed as part of an MPoC Solution? A An MPoC Application that is to be listed as part of an MPoC Solution must be integrated into that MPoC Solution. This includes utilising the key management, merchant communications, …
Added p. 11
Q 20 [October 2025] Can a dual-screen device be used as a COTS-device in an MPoC implementation? Are there any limitations to this? A Yes. A dual-screen device may be used as a COTS-device in an MPoC implementation. However, the dual screen device must be a single, physically integrated device with internal physical connections for any cleartext account data communication methods.

Q 21 [October 2025] Is it required that the PCI DSS assessment is updated to include new systems used for A&M prior to submitting an MPoC evaluation report? A No. PCI DSS is intended as a point-in-time assessment, and it is expected that changes will occur in-between assessment events. Any changes or additions made to include the A&M systems are to be included within the scope of the entity’s PCIDSS change-management process. The next scheduled PCIDSS assessment is expected to include the A&M system in scope.

Q 22 [October 2025] Can …
Modified p. 4
Updates: Questions newly added or modified after the initial release of this Technical FAQ document (version 1.0), are highlighted in red for clarity.
Updates: Questions that have been newly added or revised since the previous release of this Technical FAQ document (version 1.7) are highlighted in red for ease of reference.
Modified p. 10 → 12
In all cases it is not permissible for the MPoC Application to disable any required secure channel, or configure the secure channel to accept insecure cipher-suites or protocol versions.
In all cases it is not permissible for the MPoC Application to disable any required secure channel or configure the secure channel to accept insecure cipher-suites or protocol versions.
Modified p. 13 → 14
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.
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.
Modified p. 13 → 14
Q 14 [May 2025] Requirement 1A-1.8 notes that COTS-based MPoC software must be able to provide the version number. Is this also a requirement for MPoC Applications which are not assessed through Domain 1? A Yes. All COTS-based MPoC software must provide a mechanism for the version number to be validated against the MPoC approval list.
Q 14 [May 2025] Requirement 1A-1.8 notes that COTS-based MPoC software must be able to provide the version number. Is this also a requirement for MPoC Applications which are not assessed through Domain 1? Yes. All COTS-based MPoC software must provide a mechanism for the version number to be validated against the MPoC approval list.
Modified p. 15 → 16
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 …
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 …
Modified p. 19 → 20
Examples may include communication through the MPoC Application directly, or through out of band communication methods established during merchant onboarding.
Examples may include communication through the MPoC Application directly, or through out-of-band communication methods established during merchant onboarding.