Document Comparison

MPoC_Program_Guide_v1.0.pdf MPoC_Program_Guide_v1.1.pdf
36% similar
54 → 72 Pages
18049 → 23451 Words
292 Content Changes

Content Changes

292 content changes. 87 administrative changes (dates, page numbers) hidden.

Added p. 5
The MPoC Program allows two paths for Acceptance and Listing of candidate MPoC Products and modified MPoC Products, as applicable:

1. Evaluation and Validation of a candidate MPoC Product or modified MPoC Product by an MPoC Lab (see Section 3.2 Contracted Assessment (Lab Validation)); or

2. Evaluation and verification of an MPoC Product sub-element (MPoC Application or MPoC SDK, also known as COTS-based MPoC Software) through Vendor Verification where all of the following are true:

• Prior to Vendor Verification, the MPoC Vendor providing the listed isolated MPoC SDK to be integrated is recognized by PCI SSC to provide integration testing of that MPoC SDK being integrated (see Section 3.3 PCI-Recognized MPoC Vendor Recognition);

• Prior to Vendor Verification, the listed isolated MPoC SDK (to be integrated into a candidate COTS-based MPoC Software) is listed on an MPoC Product Listing;

• The candidate COTS-based MPoC Software that is integrating the listed isolated MPoC SDK is …
Added p. 6
• Upon PCI SSC acceptance of the Vendor Verification review, the candidate COTS-based MPoC Software that integrates the listed isolated MPoC SDK is subsequently Accepted by PCI SSC and added to an existing MPoC Product Listing as Vendor Verified.

Vendor Verification Overview Candidate COTS-based MPoC Software that integrate an isolated MPoC SDK from an existing Listing may undergo Vendor Verification and be submitted to PCI SSC for Acceptance and Listing as Vendor Verified, only as part of an existing MPoC Product Listing, by the MPoC Vendor of the MPoC SDK to be integrated.

In these cases, the MPoC Vendor of the MPoC SDK (to be integrated into the candidate COTS- based MPoC Software) is required to be recognized by PCI SSC to provide sufficient process and testing methods for the correct and secure integration of their MPoC SDK into candidate MPoC Applications or candidate MPoC SDKs (see definition of PCI-recognized MPoC Vendor …
Added p. 7
 MPoC Software  MPoC Service providing A&M operations (MPoC Service

• A&M)  MPoC Service providing both A&M and payment processing operations (MPoC Service

• A&M and Payment Processing)  MPoC Solution The MPoC Standard identifies each type of candidate MPoC Vendor responsible for each eligible MPoC Product type:

 MPoC Software Vendor  MPoC Service Provider  MPoC Solution Provider A candidate MPoC Product is recognized by PCI SSC as an MPoC Product (and is no longer considered a candidate) upon Acceptance by PCI SSC. This Acceptance denotes that the MPoC Product has been Validated by an MPoC Lab and is considered to have met all applicable requirements of the MPoC Standard and MPoC Program as of the date of such Acceptance.

Candidate COTS-based MPoC Software that integrate an MPoC SDK from an existing Listing

• and are validated through Vendor Verification

• are also required to be submitted to PCI SSC for Acceptance …
Added p. 11
Integration Report A document produced by an MPoC Vendor during Vendor Verification to confirm that a candidate MPoC Application or candidate MPoC SDK that integrates an isolated MPoC SDK from an existing Listing meets the applicable requirements of the MPoC Standard.

Lab Validation The process of Validation of a candidate MPoC Product to the MPoC Standard, through testing by an MPoC Laboratory. All new and modified MPoC Products are validated through the Lab Validation process. Also see Vendor Verification.

List (or Listing) (or Listed) (or Listable) The list on the Website of MPoC Products that have been Evaluated, Validated and Accepted.

MPoC Product An MPoC Solution, MPoC Software, or MPoC Service. All Listed MPoC Products have undergone and completed MPoC Lab Validation and PCI SSC Acceptance in accordance with the MPoC Program Requirements.

MPoC Program The PCI SSC managed program for:

• Recognition of MPoC Vendors for the Vendor Verification process, and

• Validation, Acceptance and …
Added p. 13
MSR (Magnetic-stripe reader) MSR is defined in the MPoC Standard.

Participating Payment Brand (or Payment Brand) A payment card brand that, as of the time in question, is then formally admitted as (or an affiliate of) a member of PCI SSC pursuant to its governing documents.

Note: At the time of this publication, Participating Payment Brands include PCI SSC’s Founding Members and Strategic Members.

PCI-recognized MPoC Vendors MPoC Vendors that have successfully undergone testing by an MPoC Lab to confirm they have processes in place to perform MPoC SDK Integration Assessments (Vendor Verification) on the integration of their specific isolated MPoC SDK into other candidate MPoC SDKs or candidate MPoC Applications and are subsequently recognized by PCI SSC as PCI-recognized MPoC Vendors.

Note: PCI-recognized MPoC Vendors are not qualified to perform Lab Validation.

See Vendor Verification. See Integration Report.

Portal The PCI SSC secure website through which documents are submitted to PCI SSC. The Portal is …
Added p. 18
The recognition process for MPoC Vendors recognized by PCI SSC to perform Vendor Verification is continuous and requires competencies to remain adequate to maintain this recognition. Validation of ongoing business as usual practices required to perform Vendor Verification is assessed by the MPoC Laboratory during the annual checkpoint process. See Section 4 on maintain good standing.

Recognition of suitability for Vendor Verification is applied per listed MPoC SDK. An MPoC Vendor may not be recognized to perform Vendor Verification on all of its listed MPoC SDKs. See Section 3.3 on PCI-Recognized Vendors.

Note: An MPoC Vendor may perform Vendor Verification on an MPoC Application using an MPoC SDK (that is listed as suitable for Vendor Verification as part of that MPoC Vendor’s Listing).
Added p. 19
• Submissions (including Evaluation Reports, change submissions, and annual checkpoints) are correct as required by the MPoC Standard, MPoC Program, and Laboratory General Requirements, including but not limited to adequately reporting the compliance of candidate MPoC Products in their associated submissions. PCI SSC reserves the right to review any submitted evidence for correctness and accuracy to the MPoC Standard, MPoC Program, and Laboratory General Requirements.

PCI SSC does reserve the right to review any submitted evidence for correctness and accuracy to the MPoC Standard and program.

Vendor Verification of candidate COTS-based MPoC Software, where the MPoC Vendor is both the entity performing the Vendor Verification and the entity that integrated the MPoC SDK that is part of an existing MPoC Listing, is permitted. See Figure 6.

9. If PCI SSC determines that the submission is ineligible for Acceptance under the MPoC Program, the Evaluation Report is rejected.
Added p. 22
1. MPoC Vendor negotiates fees and any associated confidentiality, non-disclosure and/or other agreements with the MPoC Lab.

2. MPoC Vendor provides the MPoC Lab with all access and materials required to perform the evaluation and validate the MPoC Vendor’s processes and procedures. The process for recognizing suitability for Vendor Verification may be performed during the course of a normal MPoC Product Evaluation. This validation process includes ensuring that the MPoC Vendor has sufficient quality assurance processes in place to produce a suitable Integration Report as required by the MPoC Program.

3. The MPoC Lab completes the relevant sections of the MPoC Lab Report Template and submits a copy of this completed template to PCI SSC.

4. PCI SSC issues an invoice to the MPoC Vendor for the applicable PCI-recognized MPoC Vendor fee. (See Programs Fee Schedule on the Website.)

5. After the MPoC Vendor pays the invoice, PCI SSC pre-screens the submission to ensure …
Added p. 23
7. If PCI SSC determines that the submission meets the applicable MPoC Program Requirements, PCI SSC countersigns the AOV signature page and returns it to the MPoC Vendor, notifying them that they have successfully completed the recognition process for the target MPoC SDK(s).

8. The date that PCI SSC countersigns the AOV is the initial date the MPoC Vendor is recognized to perform MPoC SDK Integration Assessments with respect to the target MPoC SDK(s); this date will not be used to determine any future MPoC Program 3-year lifecycle dates.

9. PCI SSC updates the MPoC Product Details Listing Fields on the Website, specific to the target MPoC SDK(s) for which they have achieved recognition to perform MPoC SDK Integration Assessments (Vendor Verification).

Note: PCI-recognized MPoC Vendor Recognition is per listed isolated MPoC SDK. If an MPoC Vendor has multiple SDKs the PCI SSC MPoC Vendor recognition process is completed for each listed isolated …
Added p. 23
Vendor Verification may only be performed by a PCI-recognized MPoC Vendor that is recognized as able to perform Vendor Verification on the target MPoC SDK that is to be integrated into the COTS- based MPoC Software. The vendor of this MPoC SDK is referred to as the Verifying MPoC Vendor below.

The Vendor Verification process is similar to the Lab Validation process above, except that the scope of the Evaluation is limited to the integration of the listed isolating MPoC SDK, and an Integration Report is created rather than an Evaluation Report. Vendor Verification cannot be used to create new MPoC Product Listings.

Note: Only isolated MPoC SDKs which are part of an existing Listing are suitable for integration into another candidate COTS-based MPoC Software (Vendor Verification). Only MPoC SDKs which are noted as suitable for Vendor Verification in their listing may be processed through Vendor Verification.

1. The Requesting MPoC Vendor and …
Added p. 24
The Requesting MPoC Vendor must deliver all completed MPoC Product Vendor Verification related materials to the Verifying MPoC Vendor, not to PCI SSC. The Verifying MPoC Vendor performs Vendor Verification of the MPoC Product.

3. The Verifying MPoC Vendor completes all steps required to perform Vendor Verification and finalize the Integration Report.

This includes any internal quality assurance steps to confirm the Integration Report correctly and sufficiently outlines the integration validation of the candidate COTS-based MPoC Software, and meets all applicable requirements of the MPoC Standard and MPoC Program. Where this cannot be confirmed, the Vendor Verification process is halted.

Where the Vendor Verification process is able to confirm the COTS-based MPoC Software meets all applicable requirements of the MPoC Standard and Program, the Verifying MPoC Vendor produces a signed AOV.

Submission to PCI SSC:

4. A current, signed, VRA is obtained from the Requesting MPoC Vendor by the Verifying MPoC Vendor performing the Vendor …
Added p. 25
12. PCI SCC adds the COTS-based MPoC Software to the relevant part of the existing MPoC Product Listing on the Website. Listing is the authoritative source of Acceptance status and ongoing approval of any MPoC Product, or component of an MPoC Product such as an MPoC SDK.

Note: MPoC Vendors, processed through the Vendor Verification process, that do not have an existing MPoC Product Listing may have their COTS-based MPoC Software added to the Listing details of another MPoC Product. PCI SSC must have on file the MPoC Vendor’s signed copy of the then-current version of the Vendor Release Agreement (VRA) available on the Website, and suitable confirmation from the MPoC Product Vendor accepting the inclusion of the COTS-based MPoC Software as part of their MPoC Product Listing.

Maintaining Acceptance and Listing:

13. Maintenance of “Good Standing” follows a 3-year (36 months) Listing lifecycle. Within the 3- year cycle, there are three continual …
Added p. 25
Each public release of a new instance or sub-element of an MPoC Product must use a unique version number.

The version number included on the Listing may use wildcards. Wildcards allow a single listed version number to validate against a range of released version numbers. Use of wildcards is subject to conditions detailed in the Wildcards section below.

Versioning Methodology Vendors must document and follow a software versioning methodology as part of their system development lifecycle. Additionally, Vendors must communicate the versioning methodology to their customers and integrators/resellers.

The format of the version number is set by the Vendor and may be comprised of several elements. The versioning methodology must fully describe the format of the version number including the following:
Added p. 26
 Number of elements;  Numbers of digits used for each element;  Format of separators used between elements;  Character set used for each element (consisting of alphabetic, numeric, and/or alphanumeric characters); The hierarchy of the elements;  Definition of what each element represents in the version scheme;  Type of change: major, minor, maintenance release, etc.

A wildcard element is a placeholder character that represents a range of possible characters in a version number. Use of a wildcard element in the versioning scheme is optional and is not required for the MPoC Product (and its sub-elements) to be Accepted and Listed. The use of wildcard elements is permitted subject to the following:

1. Wildcards may only be substituted for elements of the version number that represent no- impact changes.

2. Implementation changes must result in an update to a part of the listed version number which does not use a wildcard.

Multiple …
Added p. 27
Similarly, changes to the sub-elements of a listing, such as MPoC SDKs, may impact the listings of MPoC Applications which use these sub-elements.

It is incumbent on the vendors of any such dependencies to ensure they inform the vendors of any dependent products of potential impact to their own Listings.

To avoid early administrative Expiry (Section 4.2.1)

• starting on the date of initial Acceptance

• Any Vendor Verified COTS-based MPoC Software listed as part of an MPoC Product that achieved Revalidation must be processed through Vendor Verification prior to the first annual checkpoint of the revalidated MPoC Product.

Note: Vendor Verified status lasts for a maximum of 3-years, or the minimum remaining Listing time of the existing MPoC Product Listing on the Website, whichever happens first. Vendor Verified COTS-based MPoC Software continues to be listed as a sub-element of an MPoC Product that is going through Revalidation and must achieve Vendor Verification prior to …
Added p. 33
• Changing MPoC Labs requires a full Evaluation of the MPoC Product.
Added p. 44
• A&M or MPoC Service

• A&M and Payment Processing).

• A&M or MPoC Service A&M and Payment Processing), or the candidate MPoC Solution Provider may develop their own MPoC Service. Each MPoC Application may support:

• POI based PIN An MPoC Solution must have at least one MPoC Application(s) bound to the MPoC Solution. Each MPoC Application may support different platforms, operating system versions, payment acceptance channels, and cardholder verification methods. In all circumstances, the MPoC Solution Provider is responsible for integration required to comprise the candidate MPoC Solution, and for the candidate MPoC Solution as a whole.
Added p. 47
Part 3. Lab Validation

• Required Access & Materials As per the MPoC Standard, documentation and samples required for the Evaluation of the MPoC Product or candidate MPoC Product should be agreed upon between the MPoC Vendor or candidate MPoC Vendor and the MPoC Lab.

Part 7. Lab Validation

A delayed Listing may include other PCI Listed items which are currently part of a separate delayed Listing. For example, an MPoC Solution Listing that implements a PCI-approved PTS POI device which has its Listing already delayed may be requested to be part of a separate delayed Listing. At all times, the Acceptance date of an MPoC Product is the date used to determine any future dates, such as annual checkpoints and Revalidation, and a Listing cannot occur until all subordinate Listings are on the Website.
Added p. 52
Eligibility for Vendor Verification: See Figure 6.

Prior to Vendor Verification: See Section 1.2 MPoC Program Overview, and Figure 6.

Who can perform Vendor Verification: Vendor Verification must be performed by a PCI-recognized MPoC Vendor, only on MPoC SDKs which are listed a suitable for Vendor Verification, as described in Section 1.2.2 Vendor Verification Overview and Section 2.3 PCI-Recognized MPoC Vendors for Vendor Verification.

How to initiate Vendor Verification: MPoC Vendors initiate Vendor Verification, as described in Section 2.1 MPoC Vendors The Vendor Verification Process: Vendor Verification comprises an MPoC SDK Integration Assessment described in Section 3.4.

Vendor Verification - Required Access & Materials: See Section 3.4 MPoC SDK Integration Assessment (Vendor Verification).

The Vendor Verification Process and the 3-Year Listing Lifecycle (Revalidation): MPoC Program 3-year Listing lifecycle dates are determined by the initial Acceptance date of the MPoC Product (see Section 3.2 Contracted Assessment (Lab Validation)), and not by individual MPoC SDK or MPoC …
Added p. 56
Applicable to each MPoC Application Evaluated. When the Evaluation Entity is an MPoC Lab:

• MPoC Applications may be Evaluated by an MPoC Lab other than the MPoC Lab that Evaluates the MPoC Solution. When the Evaluation Entity is a PCI-recognized MPoC Vendor:

• The MPoC Application is Vendor Verified.

• Candidate MPoC Applications undergoing Vendor Verification must always be Evaluated by the MPoC Vendor of the MPoC SDK that is being integrated.
Added p. 57
Product(s) Supported This field indicates if the MPoC Solution Provider uses a monolithic or composite approach for their MPoC Solution. This field also indicates if the MPoC Solution Provider supports Non-PTS Approved MSR, PCI- approved PTS POI device(s). If an MPoC Solution contains only monolithic MPoC Applications, the MPoC Solution Provider uses a monolithic approach for their MPoC Solution. If an MPoC Solution contains both monolithic and composite MPoC Applications, the MPoC Solution Provider uses a composite approach for their MPoC Solution. See Figure 3 and Table 6.

Applicable to each MPoC Application Evaluated. Device(s) supported:

• If the MPoC Application supports PCI- approved PTS POI device(s), then the PTS Approval number, PCI-approved PTS POI firmware version, and PCI-approved PTS POI hardware version will be included in this field.

• If the MPoC Application supports Non-PTS Approved MSR, then a designator will be included in this field. Monolithic MPoC Application(s):

• All aspects of …
Added p. 57
• MPoC Services supported (indicated as MPoC A&M Service or MPoC A&M and Payment Processing)

• Vendor Verified MPoC Applications will reference the integrated isolated MPoC SDK (from either an MPoC Software or MPoC Service) in this field.

• If an MPoC Application dependency has more than one indicator, the most severe indicator will be inherited by the MPoC Application in MPoC Solution Details Listing.
Added p. 62
Identifies each MPoC Application / MPoC SDK Evaluated as part of the complete MPoC Software Evaluation, and each Vendor Verified MPoC Application / MPoC SDK. Identifies each MPoC Application / MPoC SDK Evaluated separately from the MPoC Software Evaluation and as part of the complete MPoC Software Evaluation. MPoC Application(s) / MPoC SDKs in MPoC Software Listings will inherit the indicator of any dependencies that are not in Good Standing with PCI SSC (i.e., an MPoC Application dependent on a PCI-approved PTS POI device that is not in Good Standing). If an MPoC Application / MPoC SDK dependency has more than one indicator, the most severe indicator will be inherited by the MPoC Application / MPoC SDK in MPoC Software Details Listing.

Applicable to each MPoC Application / MPoC SDK Evaluated. When the Evaluation Entity is an MPoC Lab:

• MPoC Applications / MPoC SDKs may be Evaluated by an MPoC Lab …
Added p. 64
• If the MPoC Application / MPoC SDK supports PCI-approved PTS POI device(s), then the PCI PTS Approval number, PCI-approved PTS POI firmware version, and PCI-approved PTS POI hardware version will be included in this field.

• If the MPoC Application supports Non-PTS Approved MSR, then a designator will be included in this field Monolithic MPoC Application(s) / MPoC SDK(s):

• All aspects of each MPoC Application / MPoC SDK are developed and integrated by the MPoC Software Vendor. Other MPoC Products are not integrated to comprise the MPoC Application/ MPoC SDK.

• Supported Service(s) is indicated as: monolithic Composite MPoC Application(s) / MPoC SDK(s):

• Other MPoC Products are integrated to comprise the MPoC Application/ MPoC SDK. Each MPoC Product name, version, and reference # will be denoted here. For example:

• Composite Vendor Verified MPoC Applications will reference the integrated isolated MPoC SDK (from either an MPoC Software or MPoC Service) in this …
Added p. 65
• MPoC Application(s) / MPoC SDKs in MPoC Software Listings will inherit the indicator of any dependencies to denote the MPoC Application / MPoC SDK supports dependencies that are not in Good Standing with PCI SSC (i.e., an MPoC Application dependent on an MPoC SDK that is not in Good Standing. Or MPoC SDK dependent on a PCI-approved PTS POI device not in Good Standing). If an MPoC Application / MPoC SDK dependency has more than one indicator, the most severe indicator will be inherited by the MPoC Application / MPoC SDK in the MPoC Software Details Listing.
Added p. 66
MPoC Service Type The type of MPoC Service provided (either A&M, or A&M and Payment Processing).

Two MPoC Services are supported, either an MPoC Service providing the operational aspects of an A&M implementation only, or an MPoC Service providing both A&M operations and payment processing operations. MPoC Service Details Details of the MPoC Service Evaluated.
Added p. 67
Each MPoC Application/MPoC SDK may support different account data entry methods. If the MPoC Service supports more than 1 platform and operating system version: This field does not denote that every platform supported under the MPoC Service will support every account data entry method in this field.

Revalidation applies if an MPoC Service Provider chooses to have their MPoC Service Evaluated to a newer version of the MPoC Standard during the 3-Year Listing lifecycle of the MPoC Service. An MPoC Service may be Evaluated to a different version of the MPoC Standard than any MPoC Solution it is security integrated into.

Table 13 describes the MPoC Services details Listing fields, descriptions, and notes. MPoC Services details Listings are presented on the Website to specify details of functionalities of each MPoC Service.

Table 13: MPoC Service Details Listing Fields on the Website Field Description Notes MPoC Application(s) and/or MPoC SDKs Evaluated MPoC Application / …
Added p. 70
• MPoC Applications / MPoC SDKs may be Evaluated by an MPoC Lab other than the MPoC Lab that Evaluates the MPoC Service. When the Evaluation Entity is a PCI- recognized MPoC Vendor:

• The MPoC Application / MPoC SDK is Vendor Verified.

• MPoC Applications / MPoC SDKs undergoing Vendor Verification must always be evaluated by the MPoC Vendor of the MPoC SDK that is being integrated. MPoC Applications / MPoC SDKs are not as themselves MPoC Products and are therefore not eligible under the MPoC Program for Listing independent of the MPoC Service. MPoC Applications / MPoC SDKs are a component of an MPoC Service, and all components of an MPoC Service are the responsibility of the MPoC Service Provider.

Vendor Verification Permitted? Yes / No Not applicable to non-Isolated MPoC SDKs and MPoC Applications.

Yes indicates this MPoC Service Provider is a PCI-recognized Vendor permitted to perform MPoC SDK Integration Assessments …
Added p. 71
An MPoC Service may support one or more Listed MPoC Software Products or may be Validated to Domain 1 of the MPoC Standard as part of the MPoC Service Validation, and not rely on any other MPoC Product Listing (See Figure 5). Device(s) supported:

• If the MPoC Application / MPoC SDK supports PCI-approved PTS POI device(s), then the PTS Approval number, PCI- approved PTS POI firmware version, and PCI-approved PTS POI hardware version will be included in this field.

• If the MPoC Application / MPoC SDK supports Non-PTS Approved MSR, then a designator will be included in this field. Monolithic MPoC Application(s) / MPoC SDK(s): An MPoC Service may be Validated to Domain 1 of the MPoC Standard as part of the MPoC Service Validation, and not rely on any other MPoC Product Listing. All aspects of each MPoC Application / MPoC SDK are developed and integrated by the MPoC …
Added p. 72
MPoC Application/MPoC SDK Revalidation Due Date This date is inherited from the MPoC Service Listing.

If MPoC Program Requirements for the MPoC Service are not met, any MPoC Application(s) / MPoC SDKs bound to the MPoC Service are not in Good Standing with PCI SSC and indicators are displayed on the Website to reflect the severity.
Removed p. 5
Only an MPoC Lab is permitted under the MPoC Program to Evaluate and Validate compliance of a candidate MPoC Product against the MPoC Standard and submit the Evaluation evidence to PCI SSC for Acceptance (if PCI SSC deems the submission eligible) and subsequent Listing. Candidate MPoC Vendors cannot submit evidence directly to PCI SSC and must enter a Contracted Assessment agreement with an MPoC Lab. Entities should reference the Website for MPoC Labs’ contact information.

Each MPoC Product type eligible for the MPoC Program is supported by, defined, and described in the MPoC Standard. Possible MPoC Products include each of the following types:
Modified p. 5
Note: Capitalized terms that appear in this document, but are not defined, have the meanings defined in or pursuant to Section 1.5 Terminology, as applicable.
Note: Capitalized terms that appear in this document but are not elsewhere defined herein have the meanings specified in or pursuant to Section 1.5 Terminology, as applicable.
Modified p. 5
This document, the Mobile Payments on Commercial off-the-shelf Program Guide provides an overview of the PCI SSC Mobile Payments on Commercial off-the-shelf (COTS) Standard (MPoC)™ Program operated and managed by PCI Security Standards Council, LLC (PCI SSC).
This MPoC Program Guide provides an overview of the MPoC Program operated and managed by the PCI Security Standards Council, LLC (PCI SSC).
Modified p. 5
The MPoC Program Guide describes MPoC Program Requirements for candidate and existing MPoC Product Evaluation and Validation against the MPoC Standard by a PCI Recognized Laboratory, subsequent Acceptance by PCI SSC, and Listing on the Website (https://www.pcisecuritystandards.org/).
The MPoC Program Guide describes MPoC Program Requirements for candidate and existing MPoC Product Evaluation and Validation to the MPoC Standard by a PCI-Recognized MPoC Laboratory, subsequent Acceptance by PCI SSC, and Listing on the Website.
Modified p. 5
A solution already Listed as Validated to the PCI SPoC or PCI CPoC programs may be presented as a candidate MPoC Product for Evaluation to the MPoC Program, and if Validated during a full Evaluation may be Accepted by PCI SSC and subsequently Listed as an MPoC Product.
A solution already Listed as Validated to the PCI SPoC or PCI CPoC Programs may be presented as a candidate MPoC Product for Evaluation to the MPoC Program, and if Validated during a full Evaluation may be Accepted by PCI SSC and subsequently Listed as an MPoC Product.
Modified p. 5 → 6
The decision to undergo Acceptance and Listing of a candidate MPoC Product is a business decision of the candidate MPoC Vendor. The process for achieving Acceptance and Listing can only be triggered if the candidate MPoC Vendor enters into an agreement with an MPoC Lab to perform an Evaluation of the candidate MPoC Product against the MPoC Standard (referred to in the VRA as a “Contracted Assessment”), under the conditions and scope contractually agreed upon between the candidate MPoC Vendor …
Lab Validation Overview The decision to undergo Acceptance and Listing of a new or modified candidate MPoC Product is a business decision of the candidate MPoC Vendor. The process for achieving Acceptance and Listing can only be initiated if the candidate MPoC Vendor enters into an agreement with an MPoC Lab to perform an Evaluation of the candidate MPoC Product to the MPoC Standard (referred to in the VRA as a “Contracted Assessment”), under the conditions and scope contractually agreed …
Removed p. 6
• MPoC Attestation and Monitoring Service (MPoC A&M Service).

• MPoC Solution (merchant-attended).

• MPoC Software Vendor.

• MPoC Attestation and Monitoring Service Provider (MPoC A&M Service Provider).

• MPoC Solution Provider.

A candidate MPoC Product becomes an officially recognized MPoC Product (and no longer a candidate) upon Acceptance by PCI SSC. This Acceptance denotes that the MPoC Product and MPoC Vendor have been successfully Validated by an MPoC Lab and are considered to have met all relevant requirements of the MPoC Standard and MPoC Program as of the date of such Acceptance.
Modified p. 6 → 7
Acceptance of an MPoC Product is accompanied by Listing of the MPoC Product on the Website. The List of Validated MPoC Products on the Website is the authoritative source for the Validation and Acceptance by PCI SSC for any MPoC Products. Any claims regarding the Acceptance of an MPoC Product can be verified by referencing the Listing on the Website.
Acceptance of an MPoC Product is accompanied by Listing of the MPoC Product on the Website. The List of Validated MPoC Products on the Website is the authoritative source for the Acceptance by PCI SSC for any Validated MPoC Products. Any claims regarding the Acceptance of an MPoC Product can be verified by referencing the Listing on the Website.
Modified p. 6 → 7
MPoC Product Listings have a 3-Year Listing lifecycle that starts on the date of initial Acceptance by PCI SSC. MPoC Vendors with MPoC Products Listed on the Website must continue to adhere to MPoC Program Requirements after initial Acceptance, including implementing robust-risk management practices as an integral part of their business as usual (BAU) operational process.
MPoC Product Listings have a 3-Year Listing lifecycle that starts on the date of initial PCI SSC Acceptance. MPoC Vendors with MPoC Products Listed on the Website must continue to adhere to MPoC Program Requirements after initial Acceptance, including implementing robust-risk management practices as an integral part of their business as usual (BAU) operational process as required by the MPoC Standard.
Modified p. 6 → 7
Maintenance of Good Standing under the MPoC Program is not a ‘point-in-time’ event. Per MPoC Program Requirements maintenance of Good Standing is an on-going process.
Maintenance of Good Standing under the MPoC Program is not a ‘point-in-time’ event. Per MPoC Program Requirements, maintenance of Good Standing is an ongoing process.
Modified p. 6 → 7
To maintain Good Standing, and thereby avoid early administrative Expiry (section 4.1.1), MPoC Vendors must follow MPoC Program Requirements for Maintaining Good Standing (section 4) during the entire 3-Year Listing lifecycle. Before the conclusion of the MPoC Products’ 3-Year Listing lifecycle, the MPoC Vendor should decide if they will pursue another 3-Year Listing lifecycle for their MPoC Product as per this Program Guide, or alternatively allow their MPoC Product to Expire (section 5).
To avoid early administrative Expiry (Section 4.2.1), MPoC Vendors must maintain compliance of their MPoC Product by following MPoC Program Requirements for Maintaining Good Standing (Section 4) during the entire 3-Year Listing lifecycle. Before expiry of the MPoC Products’ 3-Year Listing lifecycle, the MPoC Vendor should decide if they will pursue another 3- Year Listing lifecycle for their MPoC Product as per this Program Guide, or alternatively allow their MPoC Product to Expire (Section 5).
Removed p. 7
MPoC Product Attestation of Validation (AOV) The AOV is a form for MPoC Labs to use to attest to the results of an MPoC Product Evaluation.
Modified p. 7 → 8
Table 1: Related Publications Document Name Description Payment Card Industry (PCI) Mobile Payments on COTS Security and Test Requirements (MPoC Security & Test Requirements, or MPoC Standard) Defines security requirements, test requirements, and guidance for entities involved in the development, deployment, and operation of the mobile payment acceptance products (MPoC Products) that use COTS devices. Provides details of the testing processes performed by the PCI Recognized Laboratory (MPoC Lab) that perform the Validation testing (Evaluation) of the MPoC Product(s).
Table 1: Related Publications Document Name Description Payment Card Industry (PCI) Mobile Payments on COTS Security and Test Requirements Version 1.x (MPoC Security & Test Requirements, or MPoC Standard) Defines security requirements, test requirements, and guidance for entities involved in the development, deployment, and operation of the mobile payment acceptance products (MPoC Products) that use COTS devices. Provides details of the testing processes performed by the PCI- Recognized Laboratory (MPoC Lab) that perform the Validation testing (Evaluation) of the MPoC …
Removed p. 8
See 1.3 Related Publications.

Good Standing Good Standing that the applicable MPoC Vendor and MPoC Product are in compliance with all applicable MPoC Program Requirements, including but not limited to requirements for initial Acceptance. See MPoC Program Requirements.
Modified p. 8 → 10
Table 2: MPoC Program Terminology Term Definition Accepted / Acceptance / Accept Acceptance is the action of being accepted for Listing by PCI SSC, as outlined in Section 3 of this document. See Website. See Vendor Release Agreement (or VRA). See List (or Listing).
Table 2: MPoC Program Terminology Term Definition Accepted / Acceptance / Accept Acceptance is the action of being accepted for Listing by PCI SSC, as outlined in Section 3 of this document. Also see Website. Also see Vendor Release Agreement (or VRA). Also see List (or Listing).
Modified p. 8 → 10
AOV Acronym for Attestation of Validation. As applicable to the MPoC Program, the AOV is a form for MPoC Labs and MPoC Vendors to attest to the results of an MPoC Evaluation, declaring the MPoC Product’s Validation status against the MPoC Standard. See Validation.
AOV Acronym for Attestation of Validation. As applicable to the MPoC Program, AOV means the then current (or successor) version of the form of MPoC Solution, AOV, MPoC Software AOV, or MPoC Service AOV available on the Website for MPoC Labs and MPoC Vendors to attest to the results of an MPoC Evaluation, declaring the MPoC Product’s Validation status to the MPoC Standard. Also see Validation.
Modified p. 8 → 10
Change Any variation to an MPoC Product after initial Acceptance and before the Re- Validation date. Changes are classified in the MPoC Program as no impact Change, administrative Change, or implementation Change. See Section 4.2 for more details on types of Changes.
Change Any variation to an MPoC Product after initial Acceptance and before the Revalidation date. Changes are classified in the MPoC Program as no- impact Change, administrative Change, or implementation Change. See Section 4.3 for more details on types of Changes.
Modified p. 8 → 10
Evaluation / Evaluated / Evaluate Evaluation is an in-depth examination of an (existing) MPoC Product or candidate (new) MPoC Product against the MPoC Standard as per Program Requirements.
Evaluation / Evaluated / Evaluate An in-depth examination of an (existing) MPoC Product or candidate (new) MPoC Product to the MPoC Standard as per Program Requirements.
Modified p. 8 → 10
Evaluation Report (or MPoC Product Evaluation Report) (or Reports on Validation (ROV)) Also referred to as “Assessment Report” in the VRA. The Evaluation Report contains the Evaluation and Validation or Re-Validation results for all test requirements in the MPoC Standard as determined by the MPoC Lab during the Evaluation.
Evaluation Report (or MPoC Product Evaluation Report) (or Reports on Validation (ROV)) The Evaluation Report contains the Evaluation and Validation or Revalidation results for all test requirements in the MPoC Standard as determined by the MPoC Lab during the Evaluation. Also referred to as “Assessment Report” in the VRA.
Modified p. 8 → 10
Expired (Expiry / Expire) Expired MPoC Products are no longer Accepted by PCI SSC. Expired means on- going Acceptance (approval) by PCI SSC of the former MPoC Product stopped at a point-in-time.
Expired (Expiry / Expire) Expired MPoC Products are no longer Accepted by PCI SSC. Expired means on-going Acceptance (approval) by PCI SSC of the former MPoC Product stopped at a point in time.
Modified p. 8 → 10
FAQ / FAQs Acronym for Frequently Asked Question(s).
FAQ / FAQs Acronym for Frequently Asked Question(s). Also see “Technical FAQs” referenced in 1.3 Related Publications.
Removed p. 9
Merchant-attended Merchant-attended is defined in the MPoC Standard.

MSR (Magnetic Stripe Reader) MSR is defined in the MPoC Standard.

MPoC A&M Service (MPoC Attestation and Monitoring Service) A type of MPoC Product that is a service offering. The MPoC A&M Service operates the attestation and monitoring functionality of Listed MPoC Software Product(s). The MPoC A&M Service is provided by an MPoC A&M Service Provider and is supported by the MPoC Standard for standalone Evaluation, Validation, Acceptance and Listing on the Website. Also see MPoC A&M Service Provider.

MPoC A&M Service Provider MPoC A&M Service Provider is defined in the MPoC Standard.

MPoC Product Product as defined in the VRA and applicable for the MPoC Program means a complete MPoC Solution (Product), MPoC Software (Product), or MPoC A&M Service (Product), development process or combination of any of the foregoing with respect to which Validation or Acceptance may be sought on a standalone basis as part …
Modified p. 9 → 11
MPoC Lab MPoC Labs are PCI Recognized Laboratories qualified by PCI SSC to perform Evaluations of candidate MPoC Products and existing MPoC Products against the MPoC Standard. MPoC Labs are also qualified by PCI SSC to perform Evaluations of optional non-PTS approved MSRs for MPoC Program purposes. See PCI Recognized Laboratory.
MPoC Laboratory (or MPoC Lab) (or Lab) PCI-Recognized Laboratories qualified by PCI SSC to perform Evaluations of candidate MPoC Products and existing MPoC Products to the MPoC Standard and Program. MPoC Labs are also qualified by PCI SSC to perform Evaluations of optional Non-PTS approved MSRs for MPoC Program purposes. Also see PCI-Recognized Laboratory.
Modified p. 9 → 11
MPoC Product Expired List Refers to the grouping of and inclusion of all Expired (former) MPoC Product Listings on the Website. Also see Expired Also see List.
MPoC Product Expired List The list of Expired MPoC Products on the Website. Also see Expired Also see List.
Modified p. 9 → 11
MPoC Program PCI SSC’s MPoC Program Requirements for qualification of MPoC Labs and applicable employees thereof. See MPoC Program Requirements.
• Qualification of MPoC Labs and applicable employees thereof,
Removed p. 10
MPoC Vendor An MPoC Solution Provider, or MPoC Software Vendor, or MPoC A&M Service Provider. Vendors with candidate MPoC Products pursuing Evaluation, Validation, Acceptance and Listing may be referred to as candidate MPoC Vendors if they do not have other Listed MPoC Products. A candidate MPoC Vendor becomes an MPoC Vendor upon initial Acceptance of a candidate MPoC Product by PCI SSC. Also see Acceptance.

Participating Payment Brand (or Payment Brand) A global payment card brand or scheme that is also a limited liability company member of PCI SSC (or affiliate thereof).

Portal The MPoC Lab (on behalf of the MPoC Vendor) must submit all MPoC Product Validation-related documents to PCI SSC through PCI SSC’s secure Website (Portal).
Modified p. 10 → 12
MPoC Solution (also Mobile Payments on COTS (MPoC) Solution) MPoC Solution is defined in the MPoC Standard. Also see MPoC Product.
MPoC Solution (or Mobile Payments on COTS (MPoC) Solution) MPoC Solution is defined in the MPoC Standard. Also see MPoC Product.
Modified p. 10 → 13
PCI PTS Approved Device list The list of PCI PTS-approved PIN transaction security devices made available on the Website.
PCI PTS Approved Device list The list of PCI PTS-approved devices made available on the Website.
Modified p. 10 → 13
PCI Recognized Laboratory A laboratory qualified by PCI SSC to perform evaluations of devices and solutions against the requirements of applicable PCI SSC Standards. Also see MPoC Lab.
PCI-Recognized Laboratory A laboratory qualified by PCI SSC to perform evaluations of devices and solutions to the requirements of applicable PCI SSC Standards. Also see MPoC Lab.
Modified p. 10 → 13
PCI SSC Acronym for Payment Card Industry Security Standards Council, LLC.
PCI SSC (or the Council) Acronym for Payment Card Industry Security Standards Council, LLC.
Removed p. 11
SCRP (Secure Card Reader

• PIN.) SCRP is defined in the MPoC Standard.
Modified p. 11 → 14
Re-Validation Date The Expiry date of an MPoC Product that is in Good Standing.
Revalidation Date The Expiry date of an MPoC Product that is in Good Standing.
Modified p. 11 → 14
Re-Validation (or Re-Validate) A full Evaluation where the MPoC Lab re-confirms Validation of an existing MPoC Product against the MPoC Standard. Re-Validation is not applicable to Expired (former) MPoC Products. See Section 4 Maintaining Good Standing. See Section 6 MPoC Program Fees.
Revalidation (or Revalidate) A full Evaluation where the MPoC Lab re-confirms Validation of an existing MPoC Product to the MPoC Standard. Revalidation is not applicable to Expired (former) MPoC Products. See Section 4 Maintaining Good Standing. See Section 6 MPoC Program Fees.
Modified p. 11 → 14
Third Party Rider See Third Party Product Provider Third Party Product (TPP) A component (device, application, code, product) or service that is incorporated into and / or referenced by the applicable MPoC Product. See VRA Section 1.1 Third Party Product Provider (TPP Provider) A device, application, product, or service (whether or not eligible for Validation or Acceptance on a standalone basis as part of a Program) that is incorporated into and / or referenced by any MPoC Product. See VRA …
Third Party Product (TPP) A component (device, application, code, product) or service that is incorporated into and / or referenced by the applicable MPoC Product. See VRA Third Party Product Provider (TPP Provider) A device, application, product, or service (whether or not eligible for Validation or Acceptance on a standalone basis as part of a Program) that is incorporated into and / or referenced by any MPoC Product. See VRA Unattended Unattended is defined in the MPoC Standard.
Modified p. 11 → 14
Validation (or Validate, or Validated) The MPoC Lab’s determination of compliance with the applicable MPoC Standard and Test Requirements. Validation is attested by the MPoC Lab and documented in the AOV. See AOV.
Validation (or Validate, or Validated) The MPoC Lab’s determination of compliance with the applicable MPoC Standard and Program Requirements. Validation is attested by the MPoC Lab and documented in the AOV. Also see AOV.
Removed p. 12
• Submitting their candidate MPoC Products and supporting documentation to the MPoC Lab for Evaluation and authorizing the same MPoC Lab to submit resulting Evaluation Reports (Reports on Validation) and related information (such as the VRA) to PCI SSC upon successful Validation of the candidate MPoC Product.
Modified p. 12 → 16
Ensuring compliance with all applicable laws, statutes, regulations, and rules (including privacy laws without limitation) that apply to their activities as MPoC Vendors and their MPoC Products, and any related services or products.
Ensuring compliance with all applicable laws, statutes, regulations, and rules (including privacy laws without limitation) that apply to their activities as MPoC Vendors and their MPoC Products, and any related services or products.
Modified p. 12 → 16
Creating MPoC Products compliant with the MPoC Standard.
Creating MPoC Products compliant with the MPoC Standard.
Modified p. 12 → 16
Contracting with an MPoC Lab as per MPoC Program Requirements.
Contracting with an MPoC Lab for Evaluation and Validation (Lab Validation) of candidate or modified MPoC Products as per MPoC Program Requirements.
Modified p. 12 → 16
The determination that they themselves (the candidate MPoC Vendor), and their candidate MPoC Product satisfy all applicable requirements of the MPoC Standard and MPoC Program prior to submission for Evaluation, Validation by an MPoC Lab and subsequent Acceptance and Listing by PCI SSC under the MPoC Program.
The determination that they themselves (the candidate MPoC Vendor), and their candidate product (MPoC Product or COTS-based MPoC Software) satisfy all applicable requirements of the MPoC Standard and MPoC Program prior to submission for Evaluation or Vendor Verification.
Modified p. 12 → 16
Implementing a robust risk-management practice as an integral part of their BAU operational process to support MPoC Program Requirements for maintenance of Acceptance, following initial Acceptance by PCI SSC.
Implementing a robust risk-management practice as an integral part of their BAU operational process to support MPoC Program Requirements for maintenance of Acceptance, following initial Acceptance by PCI SSC.
Modified p. 12 → 16
Maintaining compliance of their MPoC Product with the MPoC Standard and MPoC Program Guide version(s) used during the initial Evaluation, and any FAQ or MPoC Program updates, or any other updates which may be applicable while the applicable MPoC Product is on the List of Validated MPoC Products.
Maintaining compliance of their product (MPoC Product or COTS-based MPoC Software) with the MPoC Standard and MPoC Program Guide version(s) used during the initial Evaluation, and any FAQ or MPoC Program updates, or any other updates which may be applicable while the applicable product (MPoC Product or COTS-based MPoC Software) is on the List of Validated MPoC Products.
Modified p. 12 → 16
Maintaining Good Standing and adherence to the 3-Year Listing lifecycle of the MPoC Program as described in Section 4 Maintaining Good Standing.
Maintaining Good Standing and adherence to the 3-Year Listing lifecycle of the MPoC Program as described in Section 4 Maintaining Good Standing.
Modified p. 12 → 16
Complying with the VRA including Appendix B for any Third Party Product Providers.
Complying with the VRA including Appendix B for any Third Party Product Providers.
Modified p. 12 → 16
Ensuring that any Third Party Products are integrated into the overall MPoC Product correctly and securely.
Ensuring that any Third Party Products are integrated into the overall MPoC Product correctly and securely.
Modified p. 12 → 16
Creating implementation guidance in accordance with the requirements of the MPoC Standard.
Creating implementation guidance in accordance with the requirements of the MPoC Standard.
Modified p. 12 → 16
Providing their MPoC Product customers with a copy of the applicable implementation guidance.
Providing the customers of their product (MPoC Product or COTS-based MPoC Software) with a copy of the applicable implementation guidance.
Modified p. 12 → 16
Paying all invoices from PCI SSC for MPoC Program fees in a timely fashion.
Paying all invoices from PCI SSC for MPoC Program fees in a timely fashion.
Modified p. 12 → 16
Staying up to date with MPoC Standard and MPoC Program documents, statements, and guidance on the Website as well as industry trends and best practices.
Staying up to date with MPoC Standard and MPoC Program documents, statements, and guidance on the Website as well as industry trends and best practices.
Removed p. 13
• Have the function(s) (i.e. software, functions, services) reviewed during the Evaluation of each candidate MPoC Product.

PCI PTS POI devices with an approval class of SCRP (PCI PTS POI SCRP), as well as Non- PTS approved MSR hardware are eligible for secure integration into an MPoC Solution or MPoC Software, as described in the MPoC Standard.
Modified p. 13 → 17
There are two options for TPP Providers developing software, performing functions on behalf of, or providing services to the MPoC Solution provider to Validate compliance against the MPoC Standard:
There are two options for TPP Providers developing software, performing functions on behalf of, or providing services to the MPoC Solution provider to Validate compliance to the MPoC Standard:
Modified p. 13 → 17
Solution components that fit into the MPoC Product types of either an MPoC Software product or MPoC A&M Service may be separately Evaluated against the MPoC Standard by an MPoC Lab and (if found compliant to all applicable requirements), Validated, Accepted, and Listed on the PCI SSC website. Or:
Solution components that fit into the MPoC Product types of either an MPoC Software product or MPoC Service may be separately Evaluated to the MPoC Standard by an MPoC Lab and (if found compliant to all applicable requirements), Validated, Accepted, and Listed on the PCI SSC website; or  Have the function(s) (i.e., software, functions, services) reviewed during the Evaluation of each candidate MPoC Product.
Modified p. 13 → 17
PCI PTS POI SCRPs are listed in the PCI PTS Approved Device list on the Website.
PCI-approved PTS POI devices are listed in the PCI PTS Approved Device list on the Website.
Modified p. 13 → 17
Note: MPoC Labs are qualified by PCI SSC to perform Evaluations of optional non-PTS approved MSRs for MPoC Program purposes.
Note: Only PTS Labs are qualified by PCI SSC to perform Evaluations on PCI-approved PTS POI devices. PTS Labs and MPoC Labs are qualified by PCI SSC to perform Evaluations of optional Non-PTS approved MSRs for MPoC Program purposes.
Modified p. 13 → 17
MPoC Labs are PCI Recognized Laboratories qualified by PCI SSC to perform Evaluations of candidate MPoC Products for Acceptance and Listing on the Website. MPoC Labs are also qualified by PCI SSC to Evaluate existing MPoC Products as part of the MPoC Program’s Requirements for maintaining Good Standing (see Sections 3 Acceptance Process and 4 Maintaining Good Standing).
MPoC Labs are PCI-Recognized Laboratories qualified by PCI SSC to perform Evaluations of candidate MPoC Products for Acceptance and Listing on the Website. MPoC Labs are also qualified by PCI SSC to Evaluate existing MPoC Products as part of the MPoC Program Requirements for maintaining Good Standing (see Sections 3 Acceptance Process and 4 Maintaining Good Standing).
Modified p. 13 → 17
Meeting and maintaining the required MPoC Program requirements applicable to MPoC Labs, including but not limited to any associated fees, physical / logical / procedural controls, equipment, skills, and experience necessary to execute all test activities.
Meeting and maintaining the required MPoC Program requirements applicable to MPoC Labs, including but not limited to any associated fees, physical / logical / procedural controls, equipment, skills, and experience necessary to execute all test activities.
Modified p. 13 → 17
Evaluating candidate or existing MPoC Products in accordance with the MPoC Standard and the MPoC Program Guide.
Evaluating candidate or existing MPoC Products in accordance with the MPoC Standard, the MPoC Program Guide, and the Laboratory General Requirements.
Modified p. 13 → 17
Providing a determination regarding whether the candidate or existing MPoC Product meets the MPoC Standard test requirements.
Providing a determination regarding whether the candidate or existing MPoC Product meets the MPoC Standard test requirements.
Modified p. 13 → 18
Providing adequate documentation within the applicable reporting template to demonstrate the candidate or existing MPoC Product meets the MPoC Standard test requirements.
Providing adequate documentation within the applicable reporting template to demonstrate the candidate or existing MPoC Product meets the MPoC Standard test requirements.
Modified p. 13 → 18
Uploading all Evaluation submission requirements to PCI SSC per Appendix A - Part 7. Submission to PCI SSC
Uploading all Evaluation submission requirements to PCI SSC per Appendix A - Part 7. Lab Validation
Removed p. 14
• Submissions adequately report the compliance of candidate MPoC Products in their associated submissions.
Modified p. 14 → 18
Determine the type of Evaluation required for any implementation Change as per Section 4.2.3 Implementation Change.
Determine the type of Evaluation required for any implementation Change as per Section 4.3.3 Implementation Change.
Modified p. 14 → 18
Uploading any Change submission requirements to PCI SSC as per Appendix A
Uploading any Change submission requirements to PCI SSC as per Appendix A • Part 10. Change Documentation.
Modified p. 14 → 18
Maintaining an internal quality assurance process for their MPoC Product Evaluation efforts.
Maintaining an internal quality assurance process for their MPoC Product Evaluation efforts.
Modified p. 14 → 18
Staying up to date with PCI SSC statements and guidance, industry trends and best practices.
Staying up to date with PCI SSC statements and guidance, industry trends and best practices.
Modified p. 14 → 18
Satisfying all applicable MPoC Program Requirements at all times.
Satisfying all applicable MPoC Program Requirements at all times.
Modified p. 14 → 19
Maintains and updates the MPoC Standard.
Maintains and updates the MPoC Standard.
Modified p. 14 → 19
Qualifies MPoC Labs to Evaluate and Validate MPoC Products for compliance with the MPoC Standard.
Qualifies MPoC Labs to Evaluate and Validate MPoC Products for compliance with the MPoC Standard.
Modified p. 14 → 19
Hosts the List including Validated MPoC Products on the Website.
Hosts the List including Validated MPoC Products on the Website.
Modified p. 14 → 19
Hosts the List including Expired MPoC Products on the Website.
Hosts the List including Expired MPoC Products on the Website.
Modified p. 14 → 19
Reviews all MPoC Product Evaluation Reports and related Change submissions from MPoC Laboratories to PCI SSC for quality assurance and compliance with baseline quality standards and confirms that:
Reviews all MPoC Product Evaluation Reports and related Change submissions from MPoC Laboratories to PCI SSC for quality assurance and compliance with the Laboratory General Requirements, including but not limited to confirming that:
Modified p. 14 → 19
• Detail provided in such submissions meets PCI SSC’s reporting, documentation, and evidence requirements (i.e. Evaluation Report Template, AOV, VRA).
• Detail provided in such submissions meets PCI SSC’s reporting, documentation, and evidence requirements (e.g., Evaluation Report Template, AOV, VRA).
Modified p. 14 → 19
• MPoC Product Evaluation is performed against the MPoC Standard in accordance with MPoC Program Requirements.
• MPoC Product Evaluation is performed to the MPoC Standard in accordance with MPoC Program Requirements.
Modified p. 14 → 19
Note: Compliance of a given MPoC Product with the MPoC Standard is determined solely by the applicable MPoC Lab based upon that MPoC Lab’s Evaluation of the MPoC Product, as documented in corresponding evidence requirements prepared by that MPoC Lab and submitted to PCI SSC.
Note: Compliance of a given MPoC Product with the MPoC Standard is determined solely by the applicable MPoC Lab based upon that MPoC Lab’s Evaluation of the MPoC Product, as documented in corresponding evidence requirements prepared by that MPoC Lab and submitted to PCI SSC. This does not include sub-elements of an MPoC Product, such as COTS-based MPoC Software, which has been listed through the Vendor Verification process.
Modified p. 15 → 20
PCI SSC does not independently confirm the determinations for Acceptance, findings or information contained in submissions to PCI SSC and does not perform any testing or analysis of the corresponding MPoC Products, or related functionality, performance, suitability, or compliance with the MPoC Standard.
PCI SSC does not independently confirm the determinations, findings or information contained in submissions to PCI SSC and does not perform any testing or analysis of the corresponding MPoC Products, or related functionality, performance, suitability, or compliance with the MPoC Standard.
Modified p. 15 → 20
Listing is the authoritative source of Acceptance and ongoing approval Acceptance of any MPoC Product.
Listing is the authoritative source of Acceptance of Validated MPoC Products.
Modified p. 15 → 20
1. The candidate MPoC Vendor contracts with an MPoC Lab to have the MPoC Lab Evaluate the candidate MPoC Product against the MPoC Standard. The candidate MPoC Vendor negotiates the fees and any associated confidentiality and non-disclosure agreements with the MPoC Lab. Each new Validation or Re-Validation requires Evaluation against the then-current version(s) of the MPoC Standard.
1. The candidate MPoC Vendor contracts with an MPoC Lab to have the MPoC Lab Evaluate the candidate MPoC Product to the MPoC Standard. The candidate MPoC Vendor negotiates the fees and any associated confidentiality and non-disclosure agreements with the MPoC Lab. Each new Validation or Revalidation requires Evaluation to the then-current version(s) of the MPoC Standard.
Modified p. 15 → 20
Evaluation conclusions fall into four categories: Validated, Re-Validated, not-Validated, not-Re- Validated.
Evaluation conclusions fall into four categories: Validated, Revalidated, not Validated, not Revalidated.
Removed p. 16
11. If it is determined that the candidate MPoC Product is eligible for Validation under the MPoC Program, PCI SSC conducts a complete review of the Evaluation Report and supporting documentation provided or subsequently requested by PCI SSC. PCI SSC identifies issues or questions for resolution by the MPoC Lab. Subsequent MPoC Lab responses and information are reviewed, and the cycle repeats until satisfactory responses have been received, or the submission is rejected or withdrawn. The MPoC Lab should address all comments and feedback in a timely manner.
Modified p. 16 → 21
2. The MPoC Vendor provides the MPoC Lab with access and documentation as defined in Appendix A Part 3. Evaluation - Required Access & Materials. The MPoC Lab performs an Evaluation of the MPoC Product.
2. The MPoC Vendor provides the MPoC Lab with access and documentation as defined in Appendix A Part 3. Lab Validation

Required Access & Materials. The MPoC Lab performs an Evaluation of the MPoC Product.
Modified p. 16 → 21
Validation or Re-Validation:
Validation or Revalidation:
Modified p. 16 → 21
3. Validation or Re-Validation is achieved if the MPoC Lab determines that the candidate MPoC Product or existing MPoC Product complies with the MPoC Standard. The MPoC Lab completes all steps required to finalize the Evaluation Report, including any internal quality assurance steps to confirm the Evaluation Report correctly and sufficiently outlines the Validation of the MPoC Product, and meets all requirements of the MPoC Program and MPoC Lab quality requirements. The MPoC Lab requests a signed AOV from the …
3. Validation or Revalidation is achieved if the MPoC Lab determines that the candidate MPoC Product or existing MPoC Product complies with the MPoC Standard. The MPoC Lab completes all steps required to finalize the Evaluation Report, including any internal quality assurance steps to confirm the Evaluation Report correctly and sufficiently outlines the Validation of the MPoC Product, and meets all requirements of the MPoC Program and MPoC Lab quality requirements.
Modified p. 16 → 21
8. If the submission is complete, then PCI SSC completes a full review to confirm that the submission meets the MPoC Program eligibility requirements.
8. If the submission is complete, then PCI SSC completes a full review to confirm that the submission meets the MPoC Program eligibility requirements. PCI SSC identifies issues or questions for resolution by the MPoC Lab. Subsequent MPoC Lab responses and information are reviewed, and the cycle repeats until satisfactory responses have been received, or the submission is rejected or withdrawn. The MPoC Lab should address all comments and feedback in a timely manner.
Modified p. 16 → 21
9. The Portal is used by PCI SSC and the MPoC Lab to track communications related to a submission, including eligibility questions.
The Portal is used by PCI SSC and the MPoC Lab to track communications related to submissions, including eligibility questions.
Modified p. 16 → 21
10. If it is determined that the candidate MPoC Product is ineligible for Validation under the MPoC Program, the Evaluation Report is rejected. For subsequent reviews, if an Evaluation Report requires multiple iterations before PCI SSC accepts the report, each report that the MPoC Lab submits must be redlined to show differences from the original submission and each iteration.
10. If an Evaluation Report requires multiple iterations before PCI SSC accepts the report, each report that the MPoC Lab submits must be redlined to show differences from the original submission and each iteration.
Modified p. 16 → 22
12. Once PCI SSC has confirmed that the submission meets the MPoC Program Requirements, PCI SSC notifies the MPoC Lab and MPoC Vendor that the MPoC Product has successfully completed the submission process.
11. Once PCI SSC has confirmed that the submission meets the MPoC Program Requirements, PCI SSC notifies the MPoC Lab and MPoC Vendor that the MPoC Product has successfully completed the submission process.
Modified p. 17 → 22
13. PCI SSC countersigns the AOV and sends a copy to the MPoC Vendor and the MPoC Lab. The date that PCI SSC countersigns the AOV is the initial date of Acceptance, and this date is used to determine any future MPoC Program lifecycle dates, such as annual checkpoints and Re- Validation.
12. PCI SSC countersigns the AOV and sends a copy to the MPoC Vendor and the MPoC Lab. The date that PCI SSC countersigns the AOV is the initial date of Acceptance, and this date is used to determine any future MPoC Program lifecycle dates, such as annual checkpoints and Revalidation.
Modified p. 17 → 22
14. PCI SCC adds the MPoC Product to the List of Validated MPoC Products on the Website. Listing is the authoritative source of Acceptance status and ongoing approval of any MPoC Product.
13. PCI SCC adds the MPoC Product to the List of Validated MPoC Products on the Website. Listing is the authoritative source of Acceptance status and ongoing approval of any MPoC Product.
Modified p. 17 → 22
15. Maintenance of Good Standing follows a three-year (36 months) Listing lifecycle. Within the three-year cycle, there are three continual and on-going categories of maintenance activities required of MPoC Vendors to maintain Good Standing status. It is the sole responsibility of the MPoC Vendor to maintain compliance of their MPoC Product.
14. Maintenance of Good Standing follows a 3-year (36-month) Listing lifecycle. Within the 3-year cycle, there are three continual and on-going categories of maintenance activities required of MPoC Vendors to maintain Good Standing status. It is the sole responsibility of the MPoC Vendor to maintain compliance of their MPoC Product.
Removed p. 18
MPoC Program 3-Year Listing Lifecycle (Section 4.1).

Changes to MPoC Products and Listings (Section 4.2).

VRA Obligations for (Section 4.3).
Modified p. 18 → 27
Note: For Expired (or Expiring) Listings, see Section 5 Renewing Expiring Listings and Section 4.1.1 Early Administrative Expiry.
Note: For Expired (or Expiring) Listings, see Section 5 Renewing Expiring Listings and Section 4.2.1 Early Administrative Expiry.
Modified p. 18 → 27
Upon initial Acceptance, the candidate MPoC Product becomes an MPoC Product (see Section 3 Acceptance Process). It is the sole responsibility of the MPoC Vendor to maintain compliance of their MPoC Product with the MPoC Standard version used for the Evaluation, submission, and initial Acceptance. Failure to do so subjects the Listing to early administrative Expiration. Maintaining Good Standing and adherence to the 3-Year Listing lifecycle is the sole responsibility of the MPoC Vendor.
Upon initial Acceptance, the candidate MPoC Product becomes an MPoC Product (see Section 3 Acceptance Process). It is the sole responsibility of the MPoC Vendor to maintain compliance of their MPoC Product with the same major version of the MPoC Standard used for the Evaluation, submission, and initial Acceptance. Failure to do so subjects the Listing to early administrative Expiration. Maintaining Good Standing and adherence to the 3-year Listing lifecycle is the sole responsibility of the MPoC Vendor.
Modified p. 18 → 27
Maintenance of Good Standing status follows a three-year Listing lifecycle beginning on the date of initial Acceptance. Within the three-year Listing lifecycle, there are three continual and on-going categories of maintenance activities required of MPoC Vendors to maintain Good Standing status as shown in Table 3.
Maintenance of Good Standing status follows a 3-year Listing lifecycle beginning on the date of initial Acceptance. Within the 3-year Listing lifecycle, there are three continual and on-going categories of maintenance activities required of MPoC Vendors to maintain Good Standing status as shown in Table 3.
Modified p. 18 → 27
Note: As described in the VRA, PCI SSC may delist, suspend, withdraw, revoke, cancel or place conditions upon (including without limitation, compliance with remediation requirements) Acceptance and subsequent Listing of any MPoC Product in accordance with applicable MPoC Program Requirements.
Note: As described in the VRA, PCI SSC may suspend, withdraw, revoke, cancel or place conditions upon (including without limitation, compliance with remediation requirements) Acceptance and subsequent Listing of any MPoC Product in accordance with applicable MPoC Program Requirements.
Modified p. 18 → 28
Where a different MPoC Lab is to be used for Validation of any on-going BAU practices (annual checkpoints), Re-Validation is required.
Where a different MPoC Lab is to be used for Validation of any on-going BAU practices (annual checkpoints), Revalidation is required.
Modified p. 18 → 28
Note: As described in Appendix A Part 9. Listing Delay. At all times, the Acceptance date of an MPoC Product is the date used to determine any future dates, such as annual checkpoints, and a Listing cannot occur until all subordinate Listings are on the Website.
Note: As described in Appendix A Part 9. Lab Validation

Listing Delay, at all times, the Acceptance date of an MPoC Product is the date used to determine any future dates, such as annual checkpoints, and a Listing cannot occur until all subordinate Listings are on the Website.
Modified p. 18 → 28
Table 4 (on next page) describes the MPoC Program’s 3-year Listing lifecycle for MPoC Vendors:
Table 4 describes the MPoC Program’s 3-year Listing lifecycle for MPoC Vendors.
Modified p. 19 → 28
Table 4: MPoC Program 3-Year Listing Lifecycle During Year 1 of 3 MPoC Vendors should prepare for Annual Checkpoint #1:
Table 4: MPoC Program 3-Year Listing Lifecycle During Year 1 and 2 of 3 MPoC Vendors should prepare for annual checkpoints #1 and #2:
Modified p. 19 → 28
To avoid early administrative Expiry (Section 4.1.1) - Starting on Day 1 (the date of initial Acceptance)

• up to 12 Months after initial Acceptance: The MPoC Vendor adopts the MPoC Standard requirements applicable to their MPoC Product as BAU to ensure their MPoC Product remains in compliance with the MPoC Standard. Compliance of the MPoC Vendor and their MPoC Product with the MPoC Standard is BAU and directly aligned with security requirement timeframes as defined in Table 2. Security Requirement …
• up to 12 months after initial Acceptance or the 1st annual checkpoint: The MPoC Vendor adopts the MPoC Standard requirements applicable to their MPoC Product as BAU to ensure their MPoC Product remains in compliance with the MPoC Standard. Compliance of the MPoC Vendor and their MPoC Product with the MPoC Standard is BAU and directly aligned with security requirement timeframes as defined in Table 3. Security Requirement Timeframes of the MPoC Standard.
Modified p. 19 → 28
No impact Changes are BAU and have supporting evidence as per the MPoC Standard. No impact Changes are not reported to the MPoC Lab until the following year (Annual Checkpoint #1).
No-impact Changes are BAU and have supporting evidence as per the MPoC Standard. No-impact Changes are not reported to the MPoC Lab until the following year.
Modified p. 19 → 28
• Any implementation Changes that result in previously not-applicable requirements of the MPoC Standard becoming applicable after the Change, are adopted as per the MPoC Standard. Compliance with the VRA is BAU.
• Any implementation Changes that result in previously not-applicable requirements of the MPoC Standard becoming applicable after the Change, are adopted as per the MPoC Standard.
Removed p. 20
• Confirmation any implementation Changes from 0-12 Months after initial Acceptance were already submitted to PCI SSC by the same MPoC Lab that Validated the MPoC Product. Any previously un- reported implementation Changes that occurred from 0 to 12 months after initial Acceptance are reported to the MPoC Lab. The MPoC Vendor will permit the MPoC Lab to perform Live Testing of the MPoC Product to ensure that the MPoC Product complies with the MPoC Standard. The MPoC Lab must submit to PCI SSC via the Portal on or up to 90 days before the start of Year 2:
Modified p. 20 → 29
To avoid early administrative Expiry (Section 4.1.1) - Annual Checkpoint #1 is due on or up to 90 days before the 12 Month anniversary of initial Acceptance. The previous year’s (Year 1) BAU compliance of the MPoC Vendor and their MPoC Product with the MPoC Standard must be Evaluated by the same MPoC Lab that Validated the MPoC Product for initial Acceptance (or else a full Evaluation is required). The MPoC Vendor must attest and provide to the MPoC Lab …
To avoid early administrative Expiry (Section 4.2.1)

• annual checkpoint
#1 is due on or up to 90 calendar days before the 12 month anniversary of initial Acceptance, or the 12 month anniversary of annual checkpoint #1. The BAU compliance of the MPoC Vendor and their MPoC Product with the MPoC Standard must be Evaluated by the same MPoC Lab that Validated the MPoC Product for initial Acceptance (or else a full Evaluation is required). The MPoC Vendor must attest and …
Modified p. 20 → 29
• Confirmation of all No impact Changes that occurred 0-12 Months after initial Acceptance. All No impact Changes are reported to the MPoC Lab.
• Confirmation of all No-impact Changes that occurred in the last 12 months. All No-impact Changes are reported to the MPoC Lab.
Modified p. 20 → 29
• Confirmation any administration Changes from 0-12 Months after Initial Acceptance were already submitted to PCI SSC by the same MPoC Lab that Validated the MPoC Product. Any previously un- reported administration Changes that occurred from 0 to 12 months after initial Acceptance are reported to the MPoC Lab.
• Confirmation that all administration Changes during the last 12 months were already submitted to PCI SSC by the same MPoC Lab that Validated the MPoC Product.
Modified p. 20 → 29
• VRA: A copy of the duly executed VRA. The VRA must include Appendix B of the VRA and the VRA must be current and updated to include any Third Party Riders where applicable.
• VRA: A copy of the MPoC Vendor’s duly executed VRA. The VRA must include Appendix B of the VRA and the VRA must be current and updated to include any Third Party Riders where applicable.
Modified p. 20 → 29
• Evaluation Report and any supporting documentation and evidence as per the MPoC Evaluation Report Template. The Evaluation Report must be Red-lined to clearly indicate any iterations / updates / modifications from the original Evaluation Report that was submitted and resulted in initial Acceptance. PCI SSC has to review and Accept annual checkpoint submissions. PCI SSC does the following:
• Evaluation Report and any supporting documentation and evidence as per the MPoC Evaluation Report Template. The Evaluation Report must be Redlined to clearly indicate any iterations / updates / modifications from the original Evaluation Report that was submitted and resulted in initial Acceptance. PCI SSC reviews annual checkpoint submissions per the following:
Modified p. 20 → 29
• When completeness is established, PCI SSC signs and returns a copy of the updated AOV to the MPoC Vendor and MPoC Lab.
• When completeness is established, PCI SSC accepts the submission, and signs and returns a copy of the updated AOV to the MPoC Vendor and MPoC Lab.
Removed p. 21
• Administrative or implementation changes are reported to the MPoC Lab as follows:

• Any Administrative Changes are submitted to PCI SSC by the same MPoC Lab that Validated the MPoC Product.

• Any Implementation Changes are submitted to PCI SSC by the same MPoC Lab that Validated the MPoC Product.

• Any implementation Changes that result in previously not-applicable requirements of the MPoC Standard becoming applicable after the Change, are adopted as per the MPoC Standard. Compliance with the VRA is BAU.
Modified p. 21 → 30
To avoid early administrative Expiry (Section 4.1.1) starting on the 12-month anniversary of initial Acceptance - up to 24 Months after initial Acceptance
To avoid early administrative Expiry (Section 4.2.1)
Modified p. 21 → 30
the following applies: Compliance of the MPoC Vendor and their MPoC Product with the MPoC Standard is BAU and directly aligned with security requirement timeframes as defined in Table 2. Security Requirement Timeframes of the MPoC Standard.
up to 36 months after initial Acceptance: Compliance of the MPoC Vendor and their MPoC Product with the MPoC Standard is BAU and directly aligned with security requirement timeframes as defined in Table 3. Security Requirement Timeframes of the MPoC Standard.
Modified p. 21 → 30
No impact Changes are BAU and have supporting evidence as per the MPoC Standard. No impact Changes are not reported to the MPoC Lab until the following year (Annual Checkpoint #2).
No-impact Changes are BAU and have supporting evidence as per the MPoC Standard. No-impact Changes are not reported to the MPoC Lab until the following year and only if the MPoC Vendor chooses to Revalidate (Revalidation).
Removed p. 22
To avoid early administrative Expiry (Section 4.1.1) - Annual Checkpoint #2: is due on or up to 90 days before the 24th Month anniversary of initial Acceptance. The previous year’s (Year 2) BAU compliance of the MPoC Vendor and their MPoC Product with the MPoC Standard must be Evaluated for by the same MPoC Lab that Validated the MPoC Product for initial Acceptance (or else a full Evaluation is required).

• The MPoC Vendor must attest and provide to the MPoC Lab for review:

• Confirmation of all No impact Changes that occurred 12 to 24 Months after initial Acceptance. All No impact Changes are reported to the MPoC Lab.

• Confirmation any Administration Changes from 12 to 24 Months after Initial Acceptance were already submitted to PCI SSC by the same MPoC Lab that Validated the MPoC Product. Any previously un-reported Administration Changes that occurred from 0 to 12 months after initial …
Removed p. 23
To avoid early administrative Expiry (Section 4.1.1) starting on the 24 month anniversary of initial Acceptance - up to 36 Months after initial Acceptance

• the following applies: Compliance of the MPoC Vendor and their MPoC Product with the MPoC Standard is BAU and directly aligned with security requirement timeframes as defined in Table 2. Security Requirement Timeframes of the MPoC Standard.

• No impact Changes are BAU and have supporting evidence as per the MPoC Standard. No impact Changes are not reported to the MPoC Lab until the following year and only if the MPoC Vendor chooses to Re-Validate (Re-Validation).
Modified p. 23 → 30
Note: The MPoC Vendor should begin to plan their business decision to either pursue another 3-Year MPoC Product Acceptance and Listing with PCI SSC (Re-Validation) or permit their MPoC Product to Expire at the end of the 3-Year Listing lifecycle and be moved to PCI SSC’s MPoC Product Expired List after at least 180 days past Expiry.
Note: The MPoC Vendor should begin to plan their business decision to either pursue another 3-year MPoC Product Acceptance and Listing with PCI SSC (Revalidation) or permit their MPoC Product to Expire at the end of the 3-year Listing lifecycle and be moved to PCI SSC’s MPoC Product Expired List after at least 180 calendar days past Expiry.
Modified p. 23 → 30
Re-Validation MPoC Vendors should begin Re-Validation before the end of Year 3 of 3:
Revalidation MPoC Vendors should begin Revalidation before the end of year 3 of 3:
Modified p. 23 → 30
To avoid Expiry, before the 36 month anniversary date since initial Acceptance, a full Evaluation on the existing MPoC Product (Re-Validation) is required to Re-Validate the existing MPoC Product’s compliance with the MPoC Standard. Refer to Section 5 Renewing Expiring Listings.
To avoid Expiry, before the 36-month anniversary date since initial Acceptance, a full Evaluation on the existing MPoC Product (Revalidation) is required to Revalidate the existing MPoC Product’s compliance with the MPoC Standard. See Section 5 Renewing Expiring Listings.
Modified p. 24 → 31
The Early expiry indicator remains for up to 90-calendar days past the annual checkpoint date after which a more severe secondary Expiry indicator is applied to the corresponding Listings annual checkpoint date and any corresponding dependent Listings for another 90 calendar-days.
The Early expiry indicator remains for up to 90 calendar days past the annual checkpoint date after which a secondary Expiry indicator is applied to the corresponding Listings’ annual checkpoint date and any corresponding dependent Listings for another 90 calendar days.
Modified p. 24 → 31
After 180 days past the annual checkpoint date, the MPoC Product is no-longer considered an MPoC Product and is indicated as Expired on the Website.
After 180 calendar days past the annual checkpoint date, the MPoC Product is no longer considered an MPoC Product and is indicated as Expired on the Website.
Modified p. 24 → 31
If the annual checkpoint documentation (described in Table 4) is submitted by an MPoC Lab to PCI SSC within 180 days past the annual checkpoint date, PCI SSC does the following:
If the annual checkpoint documentation (described in Table 4) is submitted by an MPoC Lab to PCI SSC within 180 calendar days past the annual checkpoint date, PCI SSC does the following:
Modified p. 24 → 31
Reviews the submission for completeness.
Reviews the submission for completeness.
Modified p. 24 → 31
When completeness is established, PCI SSC signs and returns a copy of the updated AOV to the MPoC Vendor and MPoC Lab.
When completeness is established, PCI SSC signs and returns a copy of the updated AOV to the MPoC Vendor and MPoC Lab.
Modified p. 24 → 31
Removes the indicator(s) from the Listing and any dependent Listings.
Removes the indicator(s) from the Listing and any dependent Listings.
Modified p. 24 → 31
Updates the annual checkpoint date on the Website.
Updates the annual checkpoint date on the Website.
Modified p. 24 → 31
If the annual checkpoint documentation (described in Table 4) is not submitted by an MPoC Lab to PCI SSC within 180 days past the annual checkpoint date, PCI SSC does the following:
If the annual checkpoint documentation (described in Table 4) is not submitted by an MPoC Lab to PCI SSC within 180 calendar days past the annual checkpoint date, PCI SSC does the following:
Removed p. 25
Sometimes there is no impact, and no change to the MPoC Product at all, and instead there is a requested administrative update to the Listing details on the Website. The MPoC Program considers the objective nature of the MPoC Standard and the various types of Changes and impact of Changes to the compliance of the MPoC Product and dependencies with MPoC Standard.
Modified p. 25 → 32
MPoC Vendors may Change Listed MPoC Products for various reasons: Changes do not impact the initial Acceptance date of the MPoC Product or any dependent MPoC Products.
MPoC Vendors may change Listed MPoC Products for various reasons: Changes do not impact the initial Acceptance date of the MPoC Product or any dependent MPoC Products.
Modified p. 25 → 32
As per the VRA (A.11) the MPoC Vendor shall promptly notify PCI SSC of change(s) to an MPoC Product in accordance with this MPoC Program (see Table 5 below for changes that require notification). As defined in Table 2 of the MPoC Standard, significant changes are changes that have potential impacts on the security of the solution. Significant changes as described in the MPoC Standard are considered implementation Changes under the MPoC Program.
As per the VRA (A.11) the MPoC Vendor shall promptly notify PCI SSC of change(s) to an MPoC Product in accordance with this MPoC Program (see Table 5 below for changes that require notification). As defined in Table 23 of the MPoC Standard, significant changes are changes that have potential impacts on the security of the solution. Significant changes as described in the MPoC Standard are considered implementation Changes under the MPoC Program.
Modified p. 25 → 32
Table 5 (on next page) describes the MPoC Product and Listing Change types.
Table 5 describes the MPoC Product and Listing Change types.
Modified p. 26 → 32
Table 5: Changes to MPoC Products and Listings Change Type Description Action by the MPoC Vendor Action by the No Impact Change
Table 5: Changes to MPoC Products and Listings Change Type Description Action by the MPoC Vendor Action by the No-impact Change
Modified p. 26 → 32
Does not impact the corresponding Listing. Examples of no impact Changes include, but are not limited to, maintenance patches which do not change functionality, or routine key rotation. For details, see Section 4.2.1 No Impact Change.
• Examples of no-impact Changes include, but are not limited to, maintenance patches which do not change functionality, or routine key rotation. For details, see Section 4.3.1 No-impact Change.
Modified p. 26 → 32
The MPoC Lab reviews no impact Change(s) as part of each annual Checkpoint described in Section 4 Maintaining Good Standing.
The MPoC Lab reviews no-impact Change(s) as part of each annual checkpoint described in Section 4 Maintaining Good Standing.
Modified p. 26 → 33
• Impacts only ‘administrative information’ associated with the MPoC Product as documented in the corresponding MPoC Product Listing on the Website. For details, see Section 4.2.2 Administrative Change.
• Impacts only ‘administrative information’ associated with the MPoC Product as documented in the corresponding MPoC Product Listing on the Website. For details, see Section 4.3.2 Administrative Change.
Modified p. 26 → 33
• The MPoC Vendor contacts the MPoC Lab that performed the last complete and full MPoC Product Evaluation and reports the administrative Change (as soon as possible) to the MPoC Lab per Section 4.2.2 Administrative Change.
• The MPoC Vendor contacts the MPoC Lab that performed the last complete and full MPoC Product Evaluation and reports the administrative Change (as soon as possible) to the MPoC Lab per Section 4.3.2 Administrative Change.
Modified p. 26 → 33
The MPoC Lab reviews the administrative Change. If the MPoC Lab agrees that the Change is administrative, then the Lab submits the Change to PCI SSC per Section 4.2.2 Administrative Change.
The MPoC Lab reviews the administrative Change. If the MPoC Lab agrees that the Change is administrative, then the Lab submits the Change to PCI SSC per Section 4.3.2 Administrative Change.
Modified p. 26 → 33
Implementation Change An implementation Change:
Implementation Change
Modified p. 26 → 33
• Impacts the MPoC Product’s Listing details and is not a ‘no impact Change’ or an ‘administrative Change’, or
• Impacts the MPoC Product’s Listing details and is not a ‘no- impact Change’ or an ‘administrative Change’, or
Modified p. 26 → 33
• Impacts the MPoC Product’s compliance with the MPoC Standard or the security of the MPoC Product by making alterations to the intended function of the MPoC Product. This may be the case even if the impact does not require any Change to the MPoC Product Listing’s details. For details, see Section 4.2.3 Implementation Change.
• Impacts the MPoC Product’s compliance with the MPoC Standard or the security of the MPoC Product by making alterations to the intended function of the MPoC Product. This may be the case even if the impact does not require any Change to the MPoC Product Listing’s details. For details, see Section 4.3.3 Implementation Change.
Modified p. 26 → 33
The MPoC Vendor contacts the MPoC Lab that performed the last full MPoC Product Evaluation and requests an Evaluation (case-by- case) of the implementation Change as per Section 4.2.3 Implementation Change. Changing MPoC Labs requires a full Evaluation of the MPoC Product.
The MPoC Vendor contacts the MPoC Lab that performed the last full MPoC Product Evaluation and requests an Evaluation (case-by-case) of the implementation Change as per Section 4.3.3 Implementation Change.
Modified p. 26 → 33
On a case-to-case basis, the MPoC Lab works with the MPoC Vendor to determine the impact that the Change has before determining the type of Evaluation required. There are two types of Evaluations that apply to MPoC Product implementation Changes per Section 4.2.3 Implementation Change.
On a per-case basis, the MPoC Lab works with the MPoC Vendor to determine the impact that the Change has before determining the type of Evaluation required. There are two types of Evaluations that apply to MPoC Product implementation Changes per Section 4.3.3 Implementation Change.
Removed p. 27
Any no impact Changes made must be recorded so that they can be reviewed and Validated during the next Annual Checkpoint or Re-Validation.
Modified p. 27 → 34
Examples of this type of Changes include activities to maintain MPoC Product security and/or rectify errors and faults in software (without modifying functionality), such as addressing vulnerabilities and penetration testing findings, or cryptographic key rotation when the end of the cryptoperiod is reached.
Examples of this type of change include activities to maintain MPoC Product security and/or rectify errors and faults in software (without impacting aspects of the implementation or functionality which may affect Validation to the MPoC Standard), such as addressing vulnerabilities and penetration testing findings, or cryptographic key rotation when the end of the cryptoperiod is reached.
Modified p. 27 → 34
It is important to note that no impact Changes do not override VRA obligations for reporting (4.3). For example, in the MPoC Standard Table 2. Security Requirement Timeframes, any Timeframes with “Immediately” or “Promptly”.
It is important to note that no-impact Changes do not override VRA obligations for reporting (4.3). For example, in the MPoC Standard Table 3, Security Requirement Timeframes, any Timeframes with “Immediately” or “Promptly.” Any no-impact Changes made must be recorded so that they can be reviewed and Validated during the next annual checkpoint or Revalidation.
Modified p. 27 → 34
Administrative Change Administrative Changes are limited to updates where no Changes to a Listed MPoC Product have occurred, but the MPoC Vendor requests a Change to the way that the MPoC Product is Listed on the Website. Examples of administrative Changes include, but are not limited to:
Administrative Change Administrative Changes are limited to updates where no changes to a Listed MPoC Product have occurred, but the MPoC Vendor requests a change to the way that the MPoC Product is Listed on the Website. Examples of administrative Changes include, but are not limited to:
Modified p. 27 → 34
Corporate identity changes.
Corporate identity changes.
Modified p. 27 → 34
• Changes to Listing details that are not changes to the underlying MPoC Product, or components, or elements as described in Part 1. MPoC Program Eligibility For details about the content of the Change analysis, see Part 10. Change Documentation.
Listing details that are not changes to the underlying MPoC Product, or components, or elements as described in Part 1. Lab Validation - MPoC Program Eligibility.
Modified p. 27 → 34
The MPoC Vendor prepares a Change analysis using the Change Impact Template (available on the Website) and submits it to the MPoC Lab for review.
The MPoC Vendor prepares a change analysis and submits it to the MPoC Lab for review.
Modified p. 27 → 34
Note: The MPoC Vendor should submit the Change analysis to the same MPoC Lab that performed the original MPoC Product Evaluation - changing MPoC Labs requires a full Evaluation of the MPoC Product.
Note: The MPoC Vendor should submit the change analysis to the same MPoC Lab that performed the original MPoC Product Evaluation - changing MPoC Labs requires a full Evaluation of the MPoC Product.
Modified p. 27 → 34
If the MPoC Lab does not agree that the Change is eligible as an administrative Change, the MPoC Lab works with the MPoC Vendor to resolve the disagreement.
If the MPoC Lab does not agree that the change is eligible as an administrative Change, the MPoC Lab works with the MPoC Vendor to resolve the disagreement.
Modified p. 27 → 34
If the MPoC Lab agrees that the Change is eligible as an administrative Change. The MPoC Lab notifies the MPoC Vendor that the Change is eligible.
If the MPoC Lab agrees that the change is eligible as an administrative Change. The MPoC Lab notifies the MPoC Vendor that the change is eligible.
Modified p. 27 → 34
The MPoC Vendor prepares the Change documentation (Part 10. Change Documentation), signs the corresponding AOV, and sends the documentation to the MPoC Lab.
The MPoC Vendor prepares the change documentation (Part 10. Change Documentation), signs the corresponding AOV, and sends the documentation to the MPoC Lab.
Modified p. 28 → 35
Updates the corresponding List of Validated MPoC Products on the Website accordingly with the new information.
Updates the corresponding List of Validated MPoC Products on the Website accordingly with the new information.
Modified p. 28 → 35
Signs and returns a copy of the corresponding AOV to the MPoC Vendor and the MPoC Lab. The Re-Validation date of the updated Listing remains the same.
Signs and returns a copy of the corresponding AOV to the MPoC Vendor and the MPoC Lab. The Revalidation date of the updated Listing remains the same.
Modified p. 28 → 35
Implementation Change An implementation Change is any variation to a MPoC Product or MPoC Product Listing that is not an administrative Change or a no impact Change. On a case-by-case basis, the MPoC Lab determines the type of Evaluation required for the implementation Change.
Implementation Change An implementation Change is any variation to an MPoC Product or MPoC Product Listing that is not an administrative Change or a no-impact Change. On a per-case basis, the MPoC Lab determines the type of Evaluation required for the implementation Change.
Modified p. 28 → 35
MPoC Vendors should contact the MPoC Lab that performed the last full MPoC Product Evaluation for guidance. The MPoC Lab engaged by the MPoC Vendor for this purpose then determines whether a partial Evaluation or full Evaluation is required to maintain Good Standing and Listing of the MPoC Product eligible for the implementation Change. Since the number of possible implementation Changes and their impact cannot be determined in advance, the type of Evaluation must be considered on a case-by-case basis.
MPoC Vendors should contact the MPoC Lab that performed the last full MPoC Product Evaluation for guidance. The MPoC Lab engaged by the MPoC Vendor for this purpose then determines whether a partial Evaluation or full Evaluation is required to maintain Good Standing and Listing of the MPoC Product eligible for the implementation Change. Since the number of possible implementation Changes and their impact cannot be determined in advance, the type of Evaluation must be considered on a per-case
Modified p. 28 → 35
Any implementation Change that requires a full Evaluation does not classify the changed MPoC Product as a new MPoC Product or new Listing, and therefore, does not reset the annual checkpoint dates or Re-Validation date (see Section 4 Maintaining Good Standing).
Any implementation Change that requires a full Evaluation does not classify the changed MPoC Product as a new MPoC Product or new Listing, and therefore, does not reset the annual checkpoint dates or Revalidation date (see Section 4 Maintaining Good Standing).
Modified p. 28 → 35
The MPoC Vendor prepares a Change analysis using the Change Impact Template (available on the Website) and submits it to the MPoC Lab for review. For details about the content of the Change analysis, see Part 10. Change Documentation.
The MPoC Vendor prepares a change analysis and submits it to the MPoC Lab for review. For details about the content of the Change analysis, see Part 10. Change Documentation.
Modified p. 28 → 35
A full (complete) MPoC Product Evaluation is required when:
A full MPoC Product Evaluation is required when:
Modified p. 28 → 35
• Compliance of the Changed MPoC Product against the MPoC Standard can only be proven by a full MPoC Product Evaluation as determined by the MPoC Lab (See Appendix A
• Compliance of the changed MPoC Product to the MPoC Standard can only be proven by a full MPoC Product Evaluation as determined by the MPoC Lab (see Appendix A
Modified p. 28 → 35
A partial MPoC Product Evaluation is allowed when:
A partial MPoC Product Evaluation is allowed when:
Modified p. 28 → 35
• Compliance of the Changed MPoC Product against the MPoC Standard can be proven by a partial MPoC Product Evaluation as determined by the MPoC Lab (See Appendix A
• Compliance of the changed MPoC Product to the MPoC Standard can be proven by a partial MPoC Product Evaluation as determined by the MPoC Lab (see Appendix A
Modified p. 29 → 36
Updates the corresponding List of Validated MPoC Products on the Website accordingly with the new information.
Updates the corresponding List of Validated MPoC Products on the Website accordingly with the new information.
Modified p. 29 → 36
Signs and returns a copy of the corresponding AOV to the MPoC Vendor and the MPoC Lab. The Re-Validation date of the updated Listing remains the same.
Signs and returns a copy of the corresponding AOV to the MPoC Vendor and the MPoC Lab. The Revalidation date of the updated Listing remains the same.
Modified p. 30 → 37
Figure 2: Expiry As an MPoC Product Listing approaches its Re-Validation date (Expiry date), two options are available to the MPoC Vendor:
Figure 2: Expiry As an MPoC Product Listing approaches its Revalidation date (Expiry date), two options are available to the MPoC Vendor:
Modified p. 30 → 37
• Re-Validation: If the MPoC Vendor wants the MPoC Product to remain in Good Standing all of the following must be completed before the Re-Validation date:
 Revalidation: If the MPoC Vendor wants the MPoC Product to remain in Good Standing all of the following must be completed before the Revalidation date:
Modified p. 30 → 37
The MPoC Vendor must engage an MPoC Lab to perform Re-Validation.
The MPoC Vendor must engage an MPoC Lab to perform Revalidation.
Modified p. 30 → 37
The MPoC Lab Evaluates the MPoC Product against the current MPoC Standard, and if Re-Validation is achieved, submits results to PCI SSC for Acceptance.
The MPoC Lab Evaluates the MPoC Product to the current MPoC Standard, and if Revalidation is achieved, submits results to PCI SSC for Acceptance.
Modified p. 30 → 37
PCI SSC reviews and Accepts the Evaluation Report and Lists the MPoC Product on the Website.
PCI SSC reviews and Accepts the Evaluation Report and Lists the MPoC Product on the Website.
Modified p. 30 → 37
Subject to the successful and timely completion of the above process, the resulting MPoC Product Listing has a new initial Acceptance date. Re-Validation requires a full Evaluation and follows the same process as the original MPoC Product Evaluation. (Refer to Section to Section 3 Acceptance Process). Where a new reference number is applied, any dependent Listings are also updated to reflect the new reference number.
Subject to the successful and timely completion of the above process, the resulting MPoC Product Listing has a new initial Acceptance date. Revalidation requires a full Evaluation and follows the same process as the original MPoC Product Evaluation. (See Section 3 Acceptance Process). Where a new reference number is applied, any dependent Listings are also updated to reflect the new reference number.
Modified p. 30 → 37
Expiry: An MPoC Product Listing for which Re-Validation and subsequent Acceptance by PCI SSC has not occurred on or before the Re-Validation date, will have an Expiry indicator applied to the Listing on the Website, and an indicator will also be applied to any dependent Listings for the first 90 days past expiry. The Expiry indicator remains for up to 90-calendar days past the Re-Validation date after which a more severe secondary Expiry indicator is applied to the corresponding …
Expiry: An MPoC Product Listing for which Revalidation and subsequent Acceptance by PCI SSC has not occurred on or before the Revalidation date, will have an Expiry indicator applied to the Listing on the Website, and an indicator will also be applied to any dependent Listings for the first 90 calendar days past expiry. The Expiry indicator remains for up to 90 calendar days past the Revalidation date after which a secondary Expiry indicator is applied to the corresponding …
Modified p. 30 → 37
The Expired indicator will denote the MPoC Product’s Re-Validation requirements as per MPoC Program Requirements is less than 180 days past the Re-Validation date. Any dependent MPoC Product Listings will also have an indicator to denote the dependent MPoC Product(s) integrate an MPoC Product that is a TPP (Third Party Product), and the TPP is less than 180 days past Expiry. (Refer to Section 2.1.1 Use of Third Party Product Providers)
The Expired indicator will denote the MPoC Product’s Revalidation requirements as per MPoC Program Requirements is less than 180 calendar days past the Revalidation date. Any dependent MPoC Product Listings will also have an indicator to denote the dependent MPoC Product(s) integrate an MPoC Product that is a TPP (Third Party Product), and the TPP is less than 180 calendar days past Expiry. (See Section 2.1.1 Use of Third Party Product Providers.)
Modified p. 30 → 37
• If the MPoC Product undergoes Re-Validation and the submittal is received and Accepted by PCI SSC within 180-days past the Re-Validate date, a new initial Acceptance date applies to the MPoC Product, the 3-Year Listing lifecycle is reset, and the Expiry indicator is removed from the MPoC Product Listing. Dependent Listings are also updated.
• If the MPoC Product undergoes Revalidation and the submittal is received and Accepted by PCI SSC within 180 calendar days past the Revalidate date, a new initial Acceptance date applies to the MPoC Product, the 3-year Listing lifecycle is reset, and the Expiry indicator is removed from the MPoC Product Listing. Dependent Listings are also updated.
Modified p. 31 → 38
• If the MPoC Product is not Re-Validated within 180-days past the Expiry date and submitted to PCI SSC within 180 days past the Expiry date, the corresponding Listing is indicated as Expired on the Website, also known as the MPoC Product Expired List, and any dependent Listings are updated to reflect their MPoC Product’s dependency on an Expired MPoC Product. (In some cases, if a dependent MPoC Product solely relies on an Expired MPoC Product, then it may affect …
• If the MPoC Product is not Revalidated within 180 calendar days past the Expiry date and submitted to PCI SSC within 180 calendar days past the Expiry date, the corresponding Listing is indicated as Expired on the Website (also known as the MPoC Product Expired List), and any dependent Listings are updated to reflect their MPoC Product’s dependency on an Expired MPoC Product. (In some cases, if a dependent MPoC Product solely relies on an Expired MPoC Product, then …
Removed p. 32
All MPoC Program fees are non-refundable and are subject to change upon posting of revised fees on the Website.
Modified p. 33 → 40
Part 1. MPoC Program Eligibility This section covers the factors affecting the eligibility and processes involved for different types of candidate MPoC Products.
Part 1. Lab Validation - MPoC Program Eligibility This Section covers the factors affecting the eligibility and processes involved for different types of candidate MPoC Products.
Modified p. 35 → 43
Figure 5 provides high-level eligibility considerations for candidate MPoC A&M Service Providers that pursue development of MPoC A&M Service offerings.
Figure 5 provides high-level eligibility considerations for candidate MPoC Service Providers that pursue development of MPoC Service offerings.
Removed p. 36
• CDCVM. An MPoC Solution must have at least one MPoC Application(s) bound to the MPoC Solution. Each MPoC Application may support different platforms, operating system versions, payment acceptance channels, and cardholder verification methods. In all circumstances, the MPoC Solution Provider is responsible for integration required to comprise the candidate MPoC Solution, and for the candidate MPoC Solution as a whole.
Modified p. 36 → 44
Table 6: MPoC Program Eligibility MPoC Product Eligibility MPoC Solution Each MPoC Solution must be merchant-attended. Unattended MPoC Solutions are not eligible for the MPoC Program. Each MPoC Solution must have at least one merchant-facing MPoC Application bound to (Evaluated as part of) the MPoC Solution. Each MPoC Application may be developed as monolithic or composite-based:
Table 6: MPoC Program Eligibility MPoC Product Eligibility MPoC Solution Each MPoC Solution must have at least one merchant-facing MPoC Application bound to (Evaluated as part of) the MPoC Solution. Each MPoC Application may be developed as monolithic or composite-based:
Modified p. 36 → 44
• Each MPoC Application must be developed without integration of a Listed MPoC Software Product and without integration of a Listed MPoC A&M Service.
• Each MPoC Application must be developed without integration of a Listed MPoC Software Product and without integration of a Listed MPoC Service (i.e., MPoC Service
Modified p. 36 → 44
• Monolithic MPoC Applications that integrate MPoC A&M Services are not eligible for the MPoC Program.
• Monolithic MPoC Applications that integrate MPoC Services are not eligible for the MPoC Program.
Modified p. 36 → 44
• Composite Development: The MPoC Application is developed via integration of a Listed MPoC Software Product and integration of either a Listed MPoC A&M Service, or the candidate MPoC Solution Provider may develop their own A&M Service. Each MPoC Application may support:
• Composite Development: The MPoC Application is developed via integration of a Listed MPoC Software Product and integration of either a Listed MPoC Service (i.e., MPoC Service
Modified p. 36 → 44
PCI PTS POI SCRP devices for chip-based contact, contactless, and MSR-based transactions,
PCI-approved PTS POI devices for chip-based contact, contactless, and MSR-based transactions,
Modified p. 37 → 45
• An MPoC Application.
• An MPoC Application
Modified p. 37 → 45
• One or more MPoC SDK’s, each isolated or non-isolated.
• One or more MPoC SDKs, each isolated or non-isolated
Modified p. 37 → 45
• One or more MPoC Applications, and each MPoC Application comprised of maximum two MPoC SDK’s (the MPoC SDK’s must be developed by the same MPoC Software Vendor and cannot be MPoC SDK’s Listed by a different MPoC Software Vendor). Each MPoC Software Product may support:
• One or more MPoC Applications, and each MPoC Application comprised of maximum two MPoC SDKs Each MPoC Software Product may support:
Modified p. 37 → 45
• Offline payment transactions.
• Offline payment transactions
Modified p. 37 → 45
• Multiple platforms and operating system versions.
• Multiple platforms and operating system versions
Modified p. 37 → 45
• COTS-native contactless interface,
• COTS-native contactless interface
Modified p. 37 → 45
PCI PTS POI SCRP devices for chip-based contact, contactless, and MSR-based transactions,
PCI-approved PTS POI devices for chip-based contact, contactless, and MSR-based transactions
Modified p. 37 → 45
• MSR devices Validated through the MSR appendix of the MPoC Standard. And cardholder verification methods:
• MSR devices Validated through the MSR appendix of the MPoC Standard And cardholder verification methods:
Modified p. 37 → 45
• COTS-native PIN entry,
• COTS-native PIN entry
Modified p. 37 → 45
CDCVM. In all circumstances, the MPoC Software Vendor is responsible for integration required to comprise the candidate MPoC Software, and for the candidate MPoC Software Product as a whole. The MPoC Software Vendor is accountable as a Third Party Product Provider to any MPoC Solution Provider(s) and / or any MPoC A&M Service Provider(s) that integrate their MPoC Software Product(s).
POI based PIN In all circumstances, the MPoC Software Vendor is responsible for integration required to comprise the candidate MPoC Software, and for the candidate MPoC Software Product as a whole. The MPoC Software Vendor is accountable as a Third Party Product Provider to any MPoC Solution Provider(s) and / or any MPoC Service Provider(s) that integrate their MPoC Software Product(s).
Removed p. 39
Part 3. Evaluation - Required Access & Materials As per the MPoC Standard, documentation and samples required for the Evaluation of the MPoC Product or candidate MPoC Product should be agreed upon between the MPoC Vendor or candidate MPoC Vendor and the MPoC Lab.
Modified p. 39 → 47
The MPoC Vendor must provide sufficient evidence to enable an MPoC Lab to Validate the MPoC Product against the MPoC Standard.
The MPoC Vendor must provide sufficient evidence to enable an MPoC Lab to Validate the MPoC Product to the MPoC Standard.
Modified p. 40 → 48
The number and types of gaps that the candidate MPoC Product has with the MPoC Standard, as determined by the MPoC Lab during the Evaluation. See Part 2 Evaluation
The number and types of gaps that the candidate MPoC Product has with the MPoC Standard, as determined by the MPoC Lab during the Evaluation. See Part 2. Lab Validation

• Preparation & Guidance.
Modified p. 40 → 48
Prompt and comprehensive submission of all Validation artifacts to the MPoC Lab.
Prompt and comprehensive submission of all Validation artifacts to the MPoC Lab.
Modified p. 40 → 48
Prompt payment of fees to PCI SSC upon submission. See Section 6 Program Fees.
Prompt payment of fees to PCI SSC upon submission. See Section 6 Program Fees.
Modified p. 40 → 48
Appropriate agreements are in place with any MPoC Vendors or other TPP Providers of the candidate MPoC Solution or Product to ensure proper information disclosure, if required under the VRA. See Section 2 Roles and Responsibilities).
Appropriate agreements are in place with any MPoC Vendors or other TPP Providers of the candidate MPoC Solution or Product to ensure proper information disclosure, if required under the VRA. See Section 2 Roles and Responsibilities).
Modified p. 40 → 48
Quality of the required documentation provided by the candidate MPoC Vendor to the MPoC Lab. See Part 3. Evaluation - Required Access & Materials.
Quality of the required documentation provided by the candidate MPoC Vendor to the MPoC Lab. See Part 3. Lab Validation

Required Access & Materials.
Modified p. 40 → 48
During the Evaluation, questions from the MPoC Lab that need to be addressed by the MPoC Vendor. See Part 5. Technical Support Throughout Evaluation and Review.
During the Evaluation, questions from the MPoC Lab that need to be addressed by the MPoC Vendor. See Part 5. Lab Validation

Technical Support and Review.
Modified p. 40 → 48
Quality of the submission by the MPoC Lab to PCI SSC. See Part 7. Submission to PCI SSC
Quality of the submission by the MPoC Lab to PCI SSC. See Part 7. Lab Validation
Modified p. 40 → 48
Part 5. Technical Support Throughout Evaluation and Review It is the responsibility of the MPoC Vendor to contact a MPoC Lab and enter into a contractual agreement with the MPoC Lab to Evaluate the candidate MPoC Product (see Section 2 Roles and Responsibilities). The contractual agreement should address any potential support needs required by the MPoC Lab from the MPoC Vendor, including but not limited to:
Part 5. Lab Validation

Technical Support and Review It is the responsibility of the MPoC Vendor to contact an MPoC Lab and enter into a contractual agreement with the MPoC Lab to Evaluate the candidate MPoC Product (see Section 2 Roles and Responsibilities). The contractual agreement should address any potential support needs required by the MPoC Lab from the MPoC Vendor, including but not limited to:
Modified p. 40 → 48
During the Evaluation, questions may arise from the MPoC Lab that need to be addressed by the MPoC Vendor. It is recommended that the contractual agreement between the MPoC Lab and the MPoC Vendor include availability of an MPoC Vendor technical representative to discuss and respond to questions from the MPoC Lab in a timely manner. See Part 4. Evaluation and Review Time Considerations.
During the Evaluation, questions may arise from the MPoC Lab that need to be addressed by the MPoC Vendor. It is recommended that the contractual agreement between the MPoC Lab and the MPoC Vendor include availability of an MPoC Vendor technical representative to discuss and respond to questions from the MPoC Lab in a timely manner. See Part 4. Lab Validation and Review Time Considerations.
Modified p. 40 → 48
After submission to PCI SSC for review, questions may arise from PCI SSC that need to be addressed by the MPoC Lab on behalf of the MPoC Vendor. It is recommended the contractual agreement between the MPoC Lab and the MPoC Vendor include availability of a MPoC Vendor technical representative to discuss and respond to questions from PCI SSC directed to the MPoC Lab. See Part 4. Evaluation and Review Time Considerations.
After submission to PCI SSC for review, questions may arise from PCI SSC that need to be addressed by the MPoC Lab on behalf of the MPoC Vendor. It is recommended the contractual agreement between the MPoC Lab and the MPoC Vendor include availability of an MPoC Vendor technical representative to discuss and respond to questions from PCI SSC directed to the MPoC Lab. See Part 4. Lab Validation and Review Time Considerations.
Modified p. 41 → 49
Covers confidentiality issues.
Covers confidentiality issues.
Modified p. 41 → 49
Covers the candidate MPoC Vendor’s agreement to the MPoC Program Requirements, policies, and procedures.
Covers the candidate MPoC Vendor’s agreement to the MPoC Program Requirements, policies, and procedures.
Modified p. 41 → 49
Gives permission to the MPoC Lab to release Evaluation Reports and other related materials to PCI SSC for review.
Gives permission to the MPoC Lab to release Evaluation Reports and other related materials to PCI SSC for review.
Modified p. 41 → 49
Requires MPoC Vendors to adopt and comply with industry-standard vulnerability handling policies.
Requires MPoC Vendors to adopt and comply with industry-standard vulnerability handling policies.
Modified p. 41 → 49
Ensures MPoC Vendors have all necessary rights and permissions to disclose information regarding TPP Providers.
Ensures MPoC Vendors have all necessary rights and permissions to disclose information regarding TPP Providers.
Modified p. 41 → 49
If PCI SSC does not already have the MPoC Vendor’s signed copy of the then-current VRA, the MPoC Lab must provide the MPoC Vendor’s signed copy of the then-current VRA to PCI SSC with the Evaluation Report.
If PCI SSC does not already have the MPoC Vendor’s signed copy of the then-current VRA, the MPoC Lab must provide the MPoC Vendor’s signed copy of the then-current VRA to PCI SSC with the Evaluation Report.
Modified p. 41 → 49
If PCI SSC has the MPoC Vendor’s signed copy of the then-current VRA, the MPoC Lab is not required to re-submit the same VRA to PCI SSC at that time.
If PCI SSC has the MPoC Vendor’s signed copy of the then-current VRA, the MPoC Lab is not required to re-submit the same VRA to PCI SSC at that time.
Modified p. 41 → 49
Part 7. Submission to PCI SSC

• Required Documentation Following an Evaluation or Re-Validation, the MPoC Lab uploads the submission to the Portal (see Section 3 Acceptance Process).
• Required Documentation Following an Evaluation or Revalidation, the MPoC Lab uploads the submission to the Portal (see Section 3 Acceptance Process).
Modified p. 41 → 49
VRA: A copy of the duly executed then current VRA from the Website. The VRA must include Appendix B of the VRA and the VRA must be current and updated to include any Third Party Riders where applicable.
VRA: A copy of the duly executed then current VRA from the Website. The VRA must include Appendix B of the VRA and the VRA must be current and updated to include any Third Party Riders where applicable.
Modified p. 41 → 49
AOV: Updated AOV including any new Third Party Riders, duly executed by both the MPoC Vendor and MPoC Lab.
AOV: Updated AOV including any new Third Party Riders, duly executed by both the MPoC Vendor and MPoC Lab.
Modified p. 41 → 49
Evaluation Report and any supporting documentation and evidence as per the MPoC Evaluation Report Template. The Evaluation Report must be Red-lined to clearly indicate any iterations / updates / modifications based on questions from the report reviewers.
Evaluation Report and any supporting documentation and evidence as per the MPoC Evaluation Report Template. The Evaluation Report must be Redlined to clearly indicate any iterations / updates / modifications based on questions from the report reviewers.
Removed p. 42
A delayed Listing may include other PCI Listed items which are currently part of a separate delayed Listing. For example, an MPoC Solution Listing that implements an PCI PTS POI SCRP which has its Listing already delayed may be requested to be part of a separate delayed Listing. At all times, the Acceptance date of an MPoC Product is the date used to determine any future dates, such as annual checkpoints and Re-Validation, and a Listing cannot occur until all subordinate Listings are on the Website.
Modified p. 42 → 50
No MPoC Vendor or Third Party Product Provider may refer to an MPoC Product as “PCI Approved,” “PCI SSC Approved”, or otherwise state or imply that PCI SSC has, in whole or part, approved any aspect of an MPoC Vendor or its MPoC Solution, MPoC Software Product, or MPoC A&M Service, except to the extent and subject to the terms and restrictions expressly set forth in the VRA, or in a countersigned AOV provided by PCI SSC. All other references …
No MPoC Vendor or Third Party Product Provider may See an MPoC Product as “PCI Approved,” “PCI SSC Approved”, or otherwise state or imply that PCI SSC has, in whole or part, approved any aspect of an MPoC Vendor or its MPoC Solution, MPoC Software Product, or MPoC Service, except to the extent and subject to the terms and restrictions expressly set forth in the VRA, or in a countersigned AOV provided by PCI SSC. All other references to PCI …
Modified p. 42 → 50
When granted, PCI SSC Acceptance is provided to ensure certain security and operational characteristics important to the achievement of PCI SSC’s goals. However, such Acceptance does not under any circumstances include or imply any endorsement or warranty regarding the applicable MPoC Vendor or the functionality, quality, or performance of the MPoC Product or any other product or service. PCI SSC does not warrant any products or services provided by Third Party Product Providers. PCI SSC Acceptance does not, under any …
When granted, PCI SSC Acceptance is provided to ensure certain security and operational characteristics important to the achievement of PCI SSC’s goals. However, such Acceptance does not under any circumstances include or imply any endorsement or warranty regarding the applicable MPoC Vendor or the functionality, quality, or performance of the MPoC Product or any other product or service. PCI SSC does not warrant any products or services provided by Third Party Product Providers. PCI SSC Acceptance does not, under any …
Modified p. 42 → 50
Part 9. Listing Delay Vendors may choose to delay Listing a newly Accepted MPoC Product for up to a maximum of six months. Written notification to PCI SSC must be submitted through the MPoC Lab along with the Evaluation Report. In addition, the MPoC Lab must provide details as part of the submission indicating the duration of time that the MPoC Product Listing should be withheld.
Part 9. Lab Validation

Listing Delay Vendors may choose to delay Listing a newly Accepted MPoC Product for up to a maximum of six months. Written notification to PCI SSC must be submitted through the MPoC Lab along with the Evaluation Report. In addition, the MPoC Lab must provide details as part of the submission indicating the duration of time that the MPoC Product Listing should be withheld.
Removed p. 43
• Reported as part of the MPoC Program Annual Requirements. See Section 4.1 MPoC Program
Modified p. 43 → 51
Table 7: Change Documentation No Impact Changes Administrative Changes Implementation Changes
Table 7: Change Documentation No-Impact Changes Administrative Changes Implementation Changes Reported as part of the MPoC Program Annual Requirements. See Section 4.1 MPoC Product Dependencies.
Modified p. 43 → 51
• Change Impact document 1
• Change analysis documentation 2
Modified p. 43 → 51
• Change Impact document 3

Evidence of 3.1 as per the MPoC Standard and A.1.3.2 as per the MPoC Standard: The documented risk-assessment process is performed at least annually and upon significant changes and must address why partial Evaluation or Re-Validation is sufficient.
• Change analysis documentation 2 Evidence and documentation must address why partial Evaluation or Revalidation is sufficient.
Modified p. 43 → 51
• Evaluation Report and any supporting documentation and evidence as per the MPoC Evaluation Report Template. The Evaluation Report must be Red- lined to clearly indicate any iterations / updates / modifications from the original Evaluation Report that was submitted and resulted in initial Acceptance.
• Evaluation Report and any supporting documentation and evidence as per the MPoC Evaluation Report Template. The Evaluation Report must be Redlined to clearly indicate any iterations / updates / modifications from the original Evaluation Report that was submitted and resulted in initial Acceptance.
Modified p. 44 → 54
Table 8: MPoC Solution Listing fields on the Website.
Table 8: MPoC Solution Listing Fields on the Website Field Description Notes MPoC Solution Provider The MPoC Solution Provider’s company name.
Modified p. 44 → 54
Every MPoC Solution will have at least 1 MPoC Application denoted under Solution Details. MPoC Solution Listings will inherit the indicator of any PCI SSC Listed dependencies or MPoC Applications to denote the MPoC Solution is dependent on MPoC Product, MPoC Application, or PCI PTS POI SCRP that is not in Good Standing with PCI SSC. If an MPoC Solution dependency has more than one indicator, the most severe indicator will be inherited by the MPoC Solution Listing.
Every MPoC Solution will have at least 1 MPoC Application denoted under Solution Details. MPoC Solution Listings will inherit the indicator of any PCI SSC Listed dependencies or MPoC Applications to denote the MPoC Solution is dependent on MPoC Product, MPoC Application, or PCI-approved PTS POI device that is not in Good Standing with PCI SSC. If an MPoC Solution dependency has more than one indicator, the most severe indicator will be inherited by the MPoC Solution Listing.
Modified p. 44 → 54
This reference number is unique per MPoC Solution Provider and MPoC Solution and remains the same for the life of the Listing. A MPoC Solution Provider may have multiple Listed MPoC Products, each of which will have a unique Reference number.
This reference number is unique per MPoC Solution Provider and MPoC Solution and remains the same for the life of the Listing. An MPoC Solution Provider may have multiple Listed MPoC Products, each of which will have a unique Reference number.
Modified p. 45 → 55
Re-Validation applies if an MPoC Solution Provider chooses to have their MPoC Solution Evaluated against a newer version of the MPoC Standard during the 3-Year Listing lifecycle of the MPoC Solution.
Revalidation applies if an MPoC Solution Provider chooses to have their MPoC Solution Evaluated to a newer version of the MPoC Standard during the 3-Year Listing lifecycle of the MPoC Solution.
Modified p. 45 → 55
Re-Validation Due Date Date Format: DD MMM YYYY If MPoC Program Requirements are not met, this MPoC Solution is not in Good Standing with PCI SSC and indicators are displayed on the Website to reflect the severity.
Revalidation Due Date Date Format: DD MMM YYYY If MPoC Program Requirements are not met, this MPoC Solution is not in Good Standing with PCI SSC and indicators are displayed on the Website to reflect the severity.
Removed p. 46
Table 9: MPoC Solution Details Listing fields on the Website.

Applicable to each MPoC Application Evaluated. MPoC Applications may be Evaluated by an MPoC Lab different from the MPoC Lab that Evaluates the MPoC Solution. MPoC Applications are not as themselves MPoC Products and are therefore not eligible under the MPoC Program for Listing independent of the MPoC Solution. MPoC Applications are a component of an MPoC Solution, and all components of an MPoC Solution are the responsibility of the MPoC Solution Provider. When a candidate MPoC Solution is submitted to PCI SSC, the submission must include Evaluation and Validation of the MPoC Application(s) regardless of if the MPoC Application(s) were Evaluated by a different MPoC Lab than the MPoC Solution.
Modified p. 46 → 56
Field Description Notes MPoC Application(s) Evaluated MPoC Application Name, MPoC Application Version, OS: Operating system(s) on which the MPoC Application was tested and Validated, OS Version(s): Major version(s) of the operating system on which the MPoC Application was tested and is supported.
Table 9: MPoC Solution Details Listing Fields on the Website Field Description Notes MPoC Application(s) Evaluated MPoC Application Name, MPoC Application Version, OS: Operating system(s) on which the MPoC Application was tested and Validated, OS Version(s): Major version(s) of the operating system on which the MPoC Application was tested and is supported.
Modified p. 46 → 56
Identifies each MPoC Application Evaluated as part of the complete MPoC Solution Evaluation. Identifies each MPoC Application Evaluated separately from the MPoC Solution Evaluation and as part of the complete MPoC Solution Evaluation. MPoC Application(s) in MPoC Solution Listings will inherit the indicator of any dependencies to denote the MPoC Application supports dependencies that are not in Good Standing with PCI SSC (i.e., an MPoC Application dependent on an MPoC Software Product that is not in Good Standing). If an …
Identifies each MPoC Application Evaluated as part of the complete MPoC Solution Evaluation, and each Vendor Verified MPoC Application. Identifies each MPoC Application Evaluated separately from the MPoC Solution Evaluation and as part of the complete MPoC Solution Evaluation. MPoC Application(s) in MPoC Solution Listings will inherit the indicator of any dependencies to denote the MPoC Application supports dependencies that are not in Good Standing with PCI SSC (i.e., an MPoC Application dependent on an MPoC Product that is not …
Modified p. 46 → 56
Each MPoC Application is not permitted to have or support only PIN Entry. Each MPoC Application is not permitted to have or support only PIN and magnetic stripe based transactions. Each MPoC Application must also support at least one form of chip-based cardholder data entry.
Each MPoC Application is not permitted to have or support only PIN Entry. Each MPoC Application must also support at least one form of chip-based cardholder data entry.
Modified p. 46 → 56
Evaluation Lab The name of the MPoC Lab that Evaluated and Validated the MPoC Application.
Evaluation Entity The name of the MPoC Lab that performed the Evaluation and Validation or PCI-recognized MPoC Vendor that performed the Vendor Verification (as applicable).
Modified p. 46 → 57
Applicable to each MPoC Application Evaluated. The MPoC Application may be Evaluated against a different version of the MPoC Standard than the MPoC Solution.
Applicable to each MPoC Application Evaluated. The MPoC Application may be Evaluated to a different version of the MPoC Standard than the MPoC Solution.
Modified p. 47 → 57
Applicable to each MPoC Application Evaluated. If the MPoC Application is monolithic and the MPoC Application supports PCI PTS POI SCRP, then the PTS Approval number, SCRP firmware version, and SCRP hardware version will be included in this field. MPoC Application(s) in MPoC Solution Listings will inherit the indicator of any dependencies to denote the MPoC Application supports dependencies that are not in Good Standing with PCI SSC (i.e., an MPoC Application dependent on an MPoC Software Product that is …
MPoC Application(s) in MPoC Solution Listings will inherit the indicator of any dependencies to denote the MPoC Application supports dependencies that are not in Good Standing with PCI SSC (i.e., an MPoC Application dependent on an MPoC Software Product that is not in Good Standing).
Modified p. 47 → 58
MPoC Application Re-Validation Due Date This date is inherited from the MPoC Solution Listing.
MPoC Application Revalidation Due Date This date is inherited from the MPoC Solution Listing.
Modified p. 48 → 59
Table 10: MPoC Software Listing fields on the Website.
Table 10: MPoC Software Listing Fields on the Website Field Description Notes MPoC Software Vendor The MPoC Software Vendor’s company name.
Modified p. 48 → 59
Each MPoC Software product will have at least 1 MPoC Application or MPoC SDK denoted under MPoC Software Details. Elements for Listing MPoC Software Details are described in Table 11.
Each MPoC Software product will have at least one instance of COTS-based MPoC Software denoted under MPoC Software Details. Elements for Listing MPoC Software Details are described in Table 11.
Modified p. 48 → 59
This reference number is unique per MPoC Software Vendor and MPoC Software Product and remains the same for the life of the Listing. A MPoC Software Vendor may have multiple Listed MPoC Products, each of which will have a unique Reference number.
This reference number is unique per MPoC Software Vendor and MPoC Software Product and remains the same for the life of the Listing. An MPoC Software Vendor may have multiple Listed MPoC Products, each of which will have a unique Reference number.
Modified p. 49 → 60
This field contains the totality of all account data entry methods supported by the MPoC Software Product.
This field contains the totality of all account data entry methods supported by the MPoC Software Product. If the MPoC Software Product supports more than 1 platform and operating system version: This field does not denote that every platform supported under the MPoC Software Product will support every account data entry method in this field.
Modified p. 49 → 60
Evaluation Lab The name of the MPoC Lab that performed the Evaluation and Validation of the MPoC Software Product against the MPoC Standard, and subsequently that MPoC Software is Accepted and Listed by PCI SSC as per this MPoC Software Product Listing.
Evaluation Lab The name of the MPoC Lab that performed the Evaluation and Validation of the MPoC Software Product to the MPoC Standard, and subsequently that MPoC Software is Accepted and Listed by PCI SSC as per this MPoC Software Product Listing.
Modified p. 49 → 60
Re-Validation applies if an MPoC Software Vendor chooses to have their MPoC Software Product Evaluated against a newer version of the MPoC Standard during the 3-Year Listing lifecycle of the MPoC Software Product. MPoC Software may be Evaluated against a different version of the MPoC Standard than any MPoC Solution or MPoC A&M Service into which it is securely integrated.
Revalidation applies if an MPoC Software Vendor chooses to have their MPoC Software Product Evaluated to a newer version of the MPoC Standard during the 3- Year Listing lifecycle of the MPoC Software Product. MPoC Software may be Evaluated to a different version of the MPoC Standard than any MPoC Solution or MPoC Service into which it is securely integrated.
Removed p. 50
Table 11: MPoC Software Details Listing fields on the Website.

MPoC SDKs are intended for integration into an MPoC Application. MPoC SDKs may be isolated or non-Isolated. This field Identifies each MPoC Application / MPoC SDK Evaluated as part of the complete MPoC Software Evaluation. Composite-based MPoC Application(s) in MPoC Software Listings will inherit the indicator of any MPoC SDK dependencies or other dependencies (i.e., PCI PTS POI SCRP) to denote the MPoC Application supports dependencies that are not in Good Standing with PCI SSC. MPoC SDK(s) will inherit the indicator of any dependencies (i.e., PCI PTS POI SCRP) to denote the MPoC SDK supports dependencies that are not in Good Standing with PCI SSC. If an MPoC Application dependency has more than one indicator, the most severe indicator will be inherited by the MPoC Application / MPoC SDK in MPoC Software Details Listing.

• Each MPoC Application must also support at …
Modified p. 50 → 62
Field Description Notes MPoC Application(s) and/or MPoC SDK(s) Evaluated MPoC Application name / MPoC SDK name and type (isolated or non-isolated), MPoC Application / MPoC SDK Version, OS: Operating system(s) on which the MPoC Application / MPoC SDK was tested and Validated, OS Version(s): Major version(s) of the operating system on which the MPoC Application / MPoC SDK was tested and is supported.
Table 11: MPoC Software Details Listing Fields on the Website Field Description Notes MPoC Application(s) and/or MPoC SDK(s) Evaluated MPoC Application name / MPoC SDK name and type (isolated or non-isolated), MPoC Application / MPoC SDK Version, OS: Operating system(s) on which the MPoC Application / MPoC SDK was tested and Validated, OS Version(s): Major version(s) of the operating system on which the MPoC Application / MPoC SDK was tested and is supported.
Modified p. 50 → 62
Each MPoC Application / MPoC SDK is not permitted to have or support only PIN Entry. Each MPoC Application is not permitted to have or support only PIN and magnetic stripe based transactions.
Each MPoC Application / MPoC SDK is not permitted to have or support only PIN Entry. Each MPoC Application must also support at least one form of chip-based cardholder data entry.
Removed p. 51
Applicable to each MPoC Application / MPoC SDK Evaluated. MPoC Applications / MPoC SDKs are not as themselves MPoC Products and are therefore not eligible under the MPoC Program for Listing independent of the MPoC Software. MPoC Applications / MPoC SDKs are bound to the MPoC Software Product and are the responsibility of the MPoC Software Vendor. When a candidate MPoC Software Product is submitted to PCI SSC, the submission must include Evaluation and Validation of the MPoC Application(s) and MPoC SDK(s) regardless of if the MPoC Application(s) / MPoC SDK(s) were Evaluated by a different MPoC Lab than the MPoC Software Product.
Modified p. 51 → 64
Applicable to each MPoC Application / MPoC SDK Evaluated.
Applicable to each MPoC Application / MPoC SDK Evaluated. Device(s) supported:
Removed p. 52
An MPoC Application is permitted to integrate up to two MPoC SDKs (although this is a not a requirement, and integration of one or no MPoC SDKs is also permitted). Each MPoC SDK may be Isolated or non-Isolated. An MPoC Application Listed as part of an MPoC Software Product must be developed by the MPoC Software vendor and must not integrate the MPoC SDK(s) of any other MPoC Software Product. Applicable to each MPoC Application / MPoC SDK Evaluated. If the MPoC Application supports PCI PTS POI SCRP, then the PCI PTS Approval number, SCRP firmware version, and SCRP hardware version will be included in this field. If the MPoC Application supports NON-PTS Approved MSR, then the designator will be included in this field. If the MPoC Application is composite-based, each MPoC SDK will be included in this field. MPoC Application(s) / MPoC SDKs in MPoC Solution Listings will inherit …
Modified p. 52 → 65
Re-Validation Due Date This date is inherited from the MPoC Software Listing.
Revalidation Due Date This date is inherited from the MPoC Software Listing.
Removed p. 53
Table 12: MPoC A&M Service Listing fields on the Website.

Supported MPoC Software Each MPoC Software Product name, version, and reference # supported by the MPoC A&M Service will be denoted here.

Each MPoC A&M Service must support at least one MPoC Software Product.

Each MPoC A&M Service may support many MPoC Software Products.

If a candidate MPoC Solution Provider pursues Acceptance of an MPoC Solution designed to securely integrate an MPoC A&M Service with monolithic software (and the absence of an MPoC Software Product) then: the monolithic software must first be Evaluated, Validated, Accepted and Listed as MPoC Software, and: The MPoC A&M Service must be Evaluated, Validated, Accepted and Listed denoting the MPoC Software is supported.
Modified p. 53 → 66
MPoC A&M Service Listing

• Data Elements
MPoC Service Listing

• Data Elements
Modified p. 53 → 66
Table 12 describes the MPoC A&M Service Listing fields, descriptions, and notes. MPoC A&M Listings are presented on the Website to include the totality of all functionalities that are available under that MPoC A&M Service.
Table 12 describes the MPoC Service Listing fields, descriptions, and notes. MPoC Service Listings are presented on the Website to include the totality of all functionalities that are available under that MPoC Service.
Modified p. 53 → 66
Field Description Notes MPoC A&M Service Provider The MPoC A&M Service Provider’s company name.
Table 12: MPoC Service Listing Fields on the Website Field Description Notes MPoC Service Provider The MPoC Service Provider’s company name.
Modified p. 53 → 66
The MPoC A&M Service name cannot be the same as the MPoC A&M Service Providers’ name. MPoC A&M Service Identifier MPoC A&M Service The name of the MPoC A&M Service under which the MPoC A&M Service is marketed. Provided by the MPoC A&M Service Provider.
The MPoC Service name cannot be the same as the MPoC Service Providers’ name. MPoC Service Identifier MPoC Service The name of the MPoC Service under which the MPoC Service is marketed. Provided by the MPoC Service Provider.
Modified p. 53 → 66
This reference number is unique per MPoC A&M Service Provider and MPoC A&M Service and remains the same for the life of the Listing. An MPoC A&M Service Provider may have multiple Listed MPoC Products, each of which will have a unique Reference number.
This reference number is unique per MPoC Service Provider and MPoC Service and remains the same for the life of the Listing. An MPoC Service Provider may have multiple Listed MPoC Products, each of which will have a unique Reference number.
Modified p. 53 → 66
Operating System(s) Supported All operating system(s) and operating system version(s) supported by the MPoC A&M Service An MPoC A&M Service must support at least one platform.
Operating System(s) Supported All operating system(s) and operating system version(s) supported by the MPoC Service An MPoC Service must support at least one platform. An MPoC Service may support multiple platforms and operating system versions.
Modified p. 53 → 71
An MPoC A&M Service may support multiple platforms and operating system versions.
An MPoC Service may support one or more Listed MPoC Software Products.
Removed p. 54
Re-Validation applies if an MPoC A&M Service Provider chooses to have their MPoC A&M Service Evaluated against a newer version of the MPoC Standard during the 3-Year Listing lifecycle of the MPoC A&M Service. An MPoC A&M Service may be Evaluated against a different version of the MPoC Standard than any MPoC Solution it is security integrated into.
Modified p. 54 → 67
Only MPoC Labs Listed on the Website are eligible to Evaluate and Validate candidate MPoC A&M Services for Acceptance by PCI SSC and subsequent Listing.
Only MPoC Labs Listed on the Website are eligible to Evaluate and Validate candidate MPoC Services for Acceptance by PCI SSC and subsequent Listing.
Modified p. 54 → 67
MPoC Standard Version The version of the MPoC Standard to which the MPoC A&M Service was Evaluated.
MPoC Standard Version The version of the MPoC Standard to which the MPoC Service was Evaluated.
Modified p. 54 → 67
Re-Validation Due Date Date Format: DD MMM YYYY If MPoC Program Requirements are not met, this MPoC A&M Service Listing is not in Good Standing with PCI SSC and indicators are displayed on the Website to reflect the severity. MPoC A&M dependencies in MPoC A&M Service Listings will inherit the indicator of any dependencies to denote the MPoC A&M Service supports an MPoC Product (i.e., MPoC Software) that is not in Good Standing. If the dependency has more than one …
Revalidation Due Date Date Format: DD MMM YYYY If MPoC Program Requirements are not met, this MPoC Service Listing is not in Good Standing with PCI SSC and indicators are displayed on the Website to reflect the severity. MPoC Service dependencies in MPoC Service Listings will inherit the indicator of any dependencies to denote the MPoC Service supports an MPoC Product (e.g., MPoC Software) that is not in Good Standing. If the dependency has more than one indicator, the most …