Accepting cards and PINs on an ordinary phone moves the payment terminal's security boundary onto a device the merchant does not control, so the security has to come from software, cryptography and continuous back-end monitoring instead of tamper-resistant hardware. PCI Mobile Payments on COTS (MPoC) is the PCI Security Standards Council (PCI SSC) standard and validation programme for that model, and it is now the only route for new mobile acceptance solutions: PCI SSC stops accepting new SPoC and CPoC submissions after 31 October 2026. This guide explains what MPoC covers, how its components fit together, what changed in version 1.1, how validation and listing work, where machine identities and keys sit in an MPoC solution, and what merchants, acquirers and solution providers should check. It is written for payment product teams, mobile security engineers, acquirer risk teams and QSAs.
Key takeaways
- MPoC replaces two standards with one. PCI SSC describes MPoC as building on SPoC (software-based PIN entry) and CPoC (contactless on COTS), bringing PIN and contactless card entry onto the same commercial off-the-shelf device under one modular, objective-based standard.
- The SPoC and CPoC sunset ends on 31 October 2026. After that date PCI SSC accepts no new SPoC or CPoC submissions; existing listings stay valid until their own reevaluation or expiry dates.
- Version 1.1 is the current standard. PCI SSC announced MPoC v1.1 on 26 November 2024, adding flexibility for SDK integration, PIN entry on a POI, non-isolating SDKs and HSM options.
- Validation is by recognised labs, compliance is set by the brands. PCI-Recognized MPoC Laboratories evaluate solutions; the payment brands decide who must use a validated solution, so merchants should pick from the PCI SSC listing and confirm with their acquirer.
- The back end is half the security model. Attestation and monitoring (A&M) services, key management and the identities that connect phones to them are where a COTS solution succeeds or fails.
What it is and who it applies to
MPoC is described by PCI SSC as a flexible mobile standard and programme for payment solution development on COTS devices such as smartphones, supporting different acceptance channels and consumer verification methods. It is intended for entities that develop, deploy or manage solutions accepting PIN and contactless cardholder data on the same COTS device. The standard has been revised several times.
| Date | Event (PCI SSC sources) |
|---|---|
| 24 January to 22 February 2022 | First request for comments on the draft standard |
| 13 June to 15 July 2022 | Second request for comments |
| 16 November 2022 | MPoC v1.0 published (Security and Test Requirements, Program Guide) |
| February 2023 | MPoC v1.0.1 Security and Test Requirements; an errata bulletin for v1.0.1 is listed on the standard page |
| 26 November 2024 | MPoC v1.1 published |
| 1 May 2026 | SPoC and CPoC sunset bulletin issued; sunset period begins |
| 31 October 2026 | Sunset ends; no new SPoC or CPoC submissions accepted |
| Standard | What it covered | Status |
|---|---|---|
| SPoC (Software-based PIN Entry on COTS) | PIN entered on the merchant's COTS device by a PIN CVM application, card read by a Secure Card Reader for PIN (SCRP), with remote attestation and monitoring | Sunset 1 May to 31 October 2026 |
| CPoC (Contactless Payments on COTS) | Contactless card acceptance through the device's built-in NFC with no external reader | Sunset 1 May to 31 October 2026 |
| MPoC (Mobile Payments on COTS) | PIN and contactless on one COTS device, modular, with external readers supported for contact, magnetic stripe and contactless cards | Current, v1.1 |
- Solution providers and SDK vendors: build and validate the MPoC software, SDKs and back-end services.
- Acquirers and payment facilitators: choose which listed solutions to offer merchants and set brand compliance expectations. See the PCI DSS 4.0 Guide.
- Merchants: use a listed solution and follow its instructions; PCI SSC encourages merchants and acquirers to select from its MPoC listing.
- Assessors: PCI-Recognized MPoC Laboratories perform evaluations under the MPoC Program Guide; QSAs meet MPoC when assessing merchants or service providers that use it.
Structure and key requirements
The full Security and Test Requirements are distributed through the PCI SSC Document Library; this guide relies on PCI SSC's public pages, bulletin, blog and conference material, and does not reproduce requirement numbering from the standard itself. PCI SSC's own material describes the solution in terms of components and environments.
| Component (PCI SSC terms) | Role in the solution | Security focus |
|---|---|---|
| MPoC SDK | Payment library integrated into a mobile application; may be isolating or, from v1.1, non-isolating | Protection of card and PIN data on the device, secure channel, self-testing |
| MPoC Application (MPoC App) | The merchant-facing app that integrates the SDK | Integration testing; from v1.1 an app integrating an isolating SDK can be validated by that SDK's vendor |
| MPoC Software | The on-device payment software as a whole | Tamper and environment checks, data protection |
| Attestation and monitoring (A&M) service and software | Back end that checks the integrity of each device and app, and responds to compromise | Detection and response for compromised platforms (clarified in v1.1) |
| Key management | Keys protecting PIN and account data and secure channels | HSM use; v1.1 allows FIPS 140-2 Level 2 HSMs in controlled environments |
| Vulnerability management | Process for tracking and fixing flaws in the solution | Ongoing maintenance of the listed product |
| MPoC Solution | The complete validated combination offered to merchants | End-to-end listing |
PCI SSC conference slides show four environments around these components: the payment processing environment, the PIN processing environment, the attestation and monitoring environment, and the mobile network between them.
What changed in version 1.1
- Validation scope: Secure Software and kernel functional validation requirements removed, including Secure Software validation of back-end A&M software.
- SDK composition: one MPoC SDK can integrate another; non-isolating SDKs allow the integrating app to manage the payment secure channel; SDK self-testing requirements updated.
- PIN entry: PIN can be entered on the COTS device or on a POI where supported, with accessible PIN entry addressed.
- A&M service models: an A&M-only service or a combined A&M and payment service.
- Cryptography and fallback: acceptability of RSA 2048 and technical fallback transactions clarified; offline storage requirements changed.
Identity and NHI requirements
An MPoC deployment is a fleet of untrusted devices talking to trusted back-end services, and every link in it depends on machine credentials: the app's credentials to the A&M service, attestation results that act as short-lived device identity, keys for the secure channel to the payment processor, HSM-held keys for PIN processing, and service accounts that run the monitoring platform. PCI SSC's public material does not enumerate identity requirements, so the table below applies general practice to the components PCI SSC names.
| Non-human identity | Risk | Control to expect |
|---|---|---|
| App or SDK credentials to the A&M back end | Extracted from a rooted device and replayed from an emulator | No static shared secrets in the app; per-install keys bound to attestation; server-side anomaly detection |
| Device attestation results | Accepted after the device state changes | Short validity, re-attestation during the session, decision to stop acceptance on compromise |
| Secure channel keys | Key reuse across devices or merchants | Unique keys per device or session, managed under a documented key management process |
| HSM and PIN processing keys | Misuse by back-end operators or automation | Dual control, split knowledge and audited HSM roles. See the HSM Deployment and Operations Guide. |
| Back-end service and CI/CD accounts | A pipeline token that can push a modified SDK or change A&M rules | Least privilege, signed releases, separate deploy identities. See the PCI DSS Requirements for Service Accounts and NHIs Guide (8.6). |
OWASP MASVS gives a vendor-neutral checklist for the on-device side, with control groups for storage, cryptography, authentication and authorisation, network communication, platform interaction, code quality and resilience against reverse engineering and tampering. See the Mobile App Security Guide and the OWASP Mobile Top 10 M1 Improper Credential Usage Guide.
Implementation steps
For solution providers
- Decide the product shape. SDK only, SDK plus A&M service, or a complete solution; isolating or non-isolating SDK; PIN on the COTS device, on a POI, or both. These choices set what the lab evaluates.
- Obtain the documents. Download MPoC v1.1 Security and Test Requirements and the Program Guide from the PCI SSC Document Library, plus any technical FAQs.
- Design the A&M back end first. Define attestation checks, the response to a compromised platform (block, step down, alert), and how monitoring rules are changed and approved.
- Build key management. Define keys per device and per environment, HSM selection, ceremonies and rotation. See the Cryptographic Key Management Policy Template.
- Engage a PCI-Recognized MPoC Laboratory early. Agree scope and evidence, and run a pre-assessment against the test requirements.
- Plan for maintenance. Changes to the SDK, OS support and A&M logic need change submissions and periodic checkpoints to keep the listing current.
For merchants and acquirers
- Check the listing. Confirm the exact solution and version is on the PCI SSC MPoC listing, not just the SDK vendor's name.
- Confirm brand and acquirer expectations. PCI SSC states the payment brands manage compliance programmes; ask the acquirer what validation and reporting it requires.
- Follow the solution's instructions. Supported OS versions, device enrolment, and what to do when the app blocks acceptance.
- Manage the devices. Enrol merchant phones in MDM where possible and keep them updated. See the Mobile Device Management Security Guide.
- Migrate from SPoC or CPoC on the listing's timeline. Existing listings remain valid to their expiry dates; plan replacement before then rather than at the deadline.
Decision guidance
- Small merchant: use an acquirer-provided listed solution; your main jobs are device hygiene, staff awareness and following the vendor's instructions.
- Payment facilitator or large retailer building its own app: integrate a listed SDK and decide whether vendor validation of the app (isolating SDK) is enough or whether a full lab evaluation is needed.
- SDK vendor: isolating SDKs simplify customer validation; non-isolating SDKs give integrators more control of the secure channel but move more responsibility to them.
Evidence and assessment
MPoC evidence is produced for the laboratory evaluation and then for ongoing listing maintenance. The items below are what a solution provider should be able to show at any time.
| Evidence | Purpose | Metric |
|---|---|---|
| Lab evaluation report and PCI SSC listing entry | Proof of validation for the named version | Days until listing reevaluation or expiry |
| A&M detection logs | Shows compromised platforms are detected and acted on | Percentage of sessions with fresh attestation; median time from detection to blocking |
| Key management records | Key generation, distribution, rotation and destruction | Keys past their rotation date |
| Vulnerability management records | Flaws triaged and fixed in the SDK and back end | Open critical findings and their age |
| Change log for SDK and A&M rules | Changes approved and, where needed, submitted to PCI SSC | Unapproved changes detected in production |
| Supported device and OS matrix | Acceptance only on supported platforms | Transactions from unsupported OS versions |
Merchants and acquirers should monitor the vendor's listing status, the share of the estate still on SPoC or CPoC products, and decline or block events raised by the A&M service.
Mapping to other frameworks
| Framework | Reference | Relationship |
|---|---|---|
| PCI DSS v4.0.1 | Requirement 12.8 (third-party service providers), Requirement 8.6 (system and application accounts) | Merchants and service providers manage MPoC vendors as third parties; back-end accounts fall under 8.6 |
| PCI Secure Software Standard | Secure software validation | v1.1 removed the Secure Software validation requirement for back-end A&M software; PCI SSC is developing a Secure Software SDK module. See the PCI Secure Software Standard and Secure SLC Guide. |
| OWASP MASVS | MASVS-STORAGE, MASVS-CRYPTO, MASVS-NETWORK, MASVS-RESILIENCE | Vendor-neutral on-device controls that support MPoC objectives |
| NIST SP 800-53 Rev. 5 | SC-12, SC-8, SI-4, SI-7, SA-9 | Key management, transmission protection, monitoring, software integrity, external services |
| NIST CSF 2.0 | PR.DS-02, DE.CM-09, GV.SC-07 | Data in transit, monitoring of runtime environments, supplier risk |
Common pitfalls
- Treating the SDK listing as the solution listing: a listed SDK integrated into an unvalidated app, or with an unlisted back end, is not the same as a listed MPoC solution.
- Static secrets in the app: an API key compiled into the merchant app can be extracted from any rooted handset and reused against the back end, defeating per-device attestation.
- Attestation without enforcement: monitoring that logs compromised devices but keeps accepting payments meets nobody's objective.
- Leaving SPoC and CPoC migration to the expiry date: listings expire on their own dates, and device replacement and merchant retraining take longer than the software change.
- Unsupported OS versions in the field: merchants keep old phones; the solution must enforce its supported platform list.
- Uncontrolled A&M rule changes: monitoring logic changed by an over-privileged automation account can silently switch off protections across every merchant.
Practitioner checklist
- Confirm every mobile acceptance product in use is on the PCI SSC listing at the deployed version.
- Record listing reevaluation and expiry dates for any SPoC or CPoC product and plan replacement.
- Obtain MPoC v1.1 Security and Test Requirements and the Program Guide from the PCI SSC Document Library.
- Remove static shared secrets from mobile apps; bind back-end access to per-install keys and attestation.
- Define and test the response when the A&M service flags a compromised platform.
- Hold PIN and channel keys in HSMs with dual control and documented ceremonies.
- Restrict and log who and what can change SDK releases and A&M rules.
- Ask your acquirer which validation and reporting the payment brands expect for your merchant level.
Standards and references
- PCI SSC: Mobile Payments on COTS (MPoC)
- PCI SSC: PCI SPoC and PCI CPoC Sunset Bulletin
- PCI SSC: PCI Mobile Payments on COTS (MPoC) Standard Version 1.1 Now Available
- PCI SSC: Mobile and MPoC Updates (Community Meeting presentation)
- PCI SSC: Contactless Payments on COTS (CPoC)
- PCI SSC: Software-based PIN Entry on COTS (SPoC)
- OWASP: Mobile Application Security Verification Standard
Related NHI Mgmt Group resources: PCI DSS 4.0 Guide · PCI DSS Requirements for Service Accounts and NHIs Guide (8.6) · Mobile App Security Guide · PCI Secure Software Standard and Secure SLC Guide