MPoC (Mobile PIN on COTS): security assumptions and gaps

The PCI MPoC standard — Mobile PIN on COTS — codifies how a merchant can accept a PIN on a commodity smartphone rather than a dedicated PIN entry device. The certifications have been rolling out for several product families since 2024. The security assumptions worth reviewing carefully aren't in the standard itself; they're in the integration.

Written July 2026 from field integrations across two solution providers.

What MPoC does well

The standard is careful about several important things:

• Attestation of the device state. The runtime must confirm the device isn't rooted, isn't in an emulator, has current OS patches, and hasn't had its trust anchors modified.
• Monitoring of the runtime. Anomalous behavior signals — an unexpected keyboard, an accessibility service reading the PIN field — must trigger a decline.
• Separation between the SPoC and the payment application. The PIN never appears in the application's memory; it's captured, encrypted, and dispatched by the SPoC.

Where integrations get careless

Three patterns that show up in reviews and shouldn't:

• Trusting client-side attestation without server verification. The device attests its own state; the server should re-check the attestation signature and its freshness. Skipping this step defeats the standard.
• Ignoring downgrade paths. If attestation fails, the flow should decline — not fall back to a mag-stripe transaction or a keyed-in PAN.
• Not treating MPoC as revocable. The device certificate can be revoked mid-lifecycle. If your fleet management doesn't check revocation, you can't respond to an incident.

What to review

• Verify the server-side attestation check is actually running on every transaction.
• Test the downgrade path with a deliberately failing attestation.
• Confirm your revocation-check cadence with the solution provider.

MPoC works when the whole chain — device, SPoC, application, server — enforces the assumptions the standard makes.