PCI MPoC (Mobile Payments on COTS) is the PCI SSC security standard that lets you accept card payments — both contactless and with PIN entry — directly on an ordinary smartphone or tablet, with no dedicated hardware. It defines security objectives for the software, plus the attestation and continuous monitoring that make the model safe.
In practice, MPoC is what underpins "Tap to Pay" and SoftPOS solutions: an app installed on an off-the-shelf device (COTS, commercial off-the-shelf) reads cards over the NFC antenna and captures the PIN on the screen itself. Because that device was never designed to be a secure terminal, the standard shifts protection away from hardware toward a combination of attack-resistant software, encryption of account data, and an attestation and monitoring infrastructure that verifies, transaction by transaction, whether the environment can be trusted.
What does the acronym MPoC mean?
MPoC stands for Mobile Payments on COTS — mobile payments on commercial off-the-shelf devices. "COTS" is any unmodified consumer device: an Android phone, an iPhone, a tablet. That is the whole point of the standard: accepting card data on equipment that never went through a physical security evaluation, with no external reader and, when needed, capturing the PIN on the touchscreen.
Published by the PCI Security Standards Council in 2022, MPoC is an objective-based security standard, not a fixed checklist of mandatory controls. Instead of dictating "do exactly X", it defines the outcome that must be achieved and leaves it to the vendor to demonstrate, with evidence, that the implementation meets that objective. This gives flexibility across architectures — but it demands competent technical evaluation to prove equivalence.
What is the difference between MPoC, SPoC and CPoC?
MPoC unifies and extends two earlier standards: SPoC, focused on PIN entry, and CPoC, focused on contactless reading. Before MPoC, a provider that wanted both contactless and PIN on the same phone had to reconcile two separate standards. MPoC brings both scenarios into a single modular framework and also allows higher-value transactions with on-screen PIN verification.
| Aspect | SPoC | CPoC | MPoC |
|---|---|---|---|
| Acronym | Software-based PIN Entry on COTS | Contactless Payments on COTS | Mobile Payments on COTS |
| PIN entry on the phone | Yes, on screen | No | Yes, on screen (optional per module) |
| Contactless (NFC) reading | No (requires external SCRP reader) | Yes, on the COTS antenna | Yes, on the COTS antenna |
| External card reader | Required (SCRP) | No | No |
| Cardholder verification (CVM) | PIN | No CVM / limited | PIN on the COTS screen (PIN Entry on COTS module); other CVMs per the card/scheme |
| Structure | Prescriptive controls | Prescriptive controls | Security objectives, modular |
| Status | Earlier standard, still in force | Earlier standard, still in force | Current, unified standard |
The table reads clearly: SPoC solved PIN but depended on an attached secure card reader; CPoC solved contactless but without PIN, which capped transaction value; MPoC delivers both in the same app and replaces "prescriptive control" logic with an objective-based one, allowing more varied architectures as long as security is proven.
How does MPoC protect data without secure hardware?
The standard protects the transaction by distributing security across three fronts that work together, since none of them is trustworthy on its own on a consumer device. Trust does not come from the device: it comes from the software's ability to protect itself, encrypt the data, and be verified remotely on each use.
The three fronts are:
- Attack-resistant software. The SDK and the payment app are built with protections against reverse engineering, tampering, hooking and debugging. The standard treats the execution environment itself as hostile.
- Account data protection. The card number and PIN are encrypted as close as possible to the point of capture and are never exposed in clear text in device memory or in transit.
- Continuous attestation and monitoring. A backend verifies, transaction by transaction, the integrity of the app and the device — whether there are signs of root, emulation, tampering or a compromised environment — and can block or react in real time.
MPoC organises these requirements into modules. There are modules for the solution core (CORE), for SDK protection, for attestation and monitoring, for secure entry and processing of account data, for PIN entry on the COTS, for offline transactions, and for software management and integration. This modularity is what lets you evaluate only the parts relevant to each type of product.
How does the compliance evaluation work?
MPoC compliance is attested by a PCI SSC-recognised laboratory, not by self-assessment. The vendor does not "declare" itself compliant: it submits the solution or component to an accredited evaluator, who tests it against the security objectives and issues a report accepted by the Council.
The typical flow involves these stages:
- Scope and classification. Define what is being evaluated — a full MPoC solution or a component/SDK — and which modules apply to that architecture.
- Preparation and evidence. The vendor gathers design documentation, threat analysis, architecture decisions and the evidence that each security objective is met.
- Laboratory evaluation. The recognised laboratory runs the security analysis: design review, software testing (including attack resistance), validation of cryptography and of the attestation and monitoring logic.
- Listing. An approved solution or component is added to the PCI SSC public list of validated products, giving visibility to acquirers and schemes.
- Ongoing maintenance. Unlike a point-in-time audit, MPoC assumes attestation and monitoring in operation and periodic revalidation; material software changes require re-evaluation.
An important point: because the standard is objective-based, much of the effort goes into demonstrating equivalence — proving, with technical evidence, that an architectural choice meets the intended security objective. This is where the quality of the security work done before submission determines the time and cost of the evaluation.
Who needs PCI MPoC in Brazil?
You need MPoC if you develop or supply software that turns a consumer device into a card-acceptance instrument. In the Brazilian payments ecosystem, this reaches a growing group of companies as "Tap to Pay" becomes mainstream:
- Acquirers and sub-acquirers offering contactless acceptance on the merchant's own phone, with no card machine.
- Fintechs and payment facilitators embedding the receiving function inside their own app.
- ISVs and SoftPOS developers building the SDK or the payment app sold to third parties.
- Marketplaces and platforms that want sellers to accept in person using only a smartphone.
In Brazil, the MPoC requirement arrives through two channels that reinforce each other. The first is contractual and scheme-driven: Visa, Mastercard and other schemes require PCI validation to enable phone acceptance solutions, and that requirement flows down the chain to the developer. The second is regulatory: payment institutions and payment arrangements operate under Central Bank supervision, and the BACEN/CMN resolutions on cyber security — including 4.893 — impose risk-management and security requirements that make adopting recognised standards such as MPoC a natural part of governance. Anyone processing cardholder data must also observe the LGPD when handling that information.
Worth clarifying: MPoC covers the acceptance solution on the COTS. It does not replace PCI DSS compliance for the environment that processes, stores or transmits card data in the backend — the two coexist. A mature operation combines a validated MPoC solution at the edge with a PCI DSS-compliant environment at the back.
How Berghem delivers
Berghem supports SoftPOS vendors and payment institutions across every phase that precedes and sustains MPoC validation: threat modelling of the app and the SDK, attack-resistance analysis (reverse engineering, tampering, hooking and root/jailbreak detection), review of account-data and PIN cryptography, and evaluation of the attestation and monitoring logic. The goal is to reach the laboratory evaluation with evidence ready and gaps already fixed, shortening the cycle.
This work connects to the rest of the payment-security programme: mobile pentest of the app, API pentest of the backend integrations, and payment security across the whole chain. For those who also need to organise the backend environment, PCI DSS readiness runs in parallel. See the full approach in PCI MPoC and SoftPOS preparation.
Frequently asked questions
Does MPoC replace PCI DSS?
No. MPoC covers the solution that accepts payment on the consumer device; PCI DSS covers the environment that processes, stores or transmits card data in the backend. They are complementary standards. A mature SoftPOS operation keeps a validated MPoC solution at the edge and a PCI DSS-compliant environment at the back.
Do I need MPoC if I only use contactless, without PIN?
It depends on the product, but MPoC is the current path. It was created to unify the scenarios previously covered by SPoC (PIN) and CPoC (contactless) into a single modular standard. MPoC is the most recent and comprehensive standard; SPoC and CPoC remain published, but new solutions that combine contactless and PIN tend to be evaluated under MPoC, activating only the applicable modules.
Who issues the PCI MPoC validation?
Validation is performed by a PCI SSC-recognised laboratory, not by self-assessment. The evaluator tests the solution or component against the standard's security objectives and, once approved, the product is added to the PCI SSC public list of validated products, with continuous attestation and monitoring in operation.