SPoC and CPoC Are Sunsetting: What the MPoC Migration Timeline Means for Your Payment Fleet
SPoC CPoC to MPoC migration has a hard deadline of October 31, 2026. The PCI Security Standards Council has confirmed that no new PCI SPoC or PCI CPoC submissions will be accepted after that date. If you are building a new mobile payment acceptance solution, or replacing a fleet validated under the older standards, this is the last window in which the old route is open — and a decision made now is far cheaper than the same decision made in December.
Here is what is changing, and what is not.
What actually changes on October 31, 2026?
Very little for deployments that are already live — and that is the part most procurement teams get wrong in both directions.
The PCI SSC sunset bulletin of May 1, 2026 is explicit on this point. All existing PCI SPoC and PCI CPoC listings will remain valid through their normal listing lifecycle, expire in accordance with their existing reevaluation or expiration dates, continue to be eligible for Annual Checkpoints and change submissions during their active listing period, and continue to be subject to program maintenance requirements throughout their validity period. The bulletin’s own summary line is worth quoting because it directly contradicts most of the alarm circulating: there is no change to the lifecycle treatment of currently accepted and listed PCI SPoC and PCI CPoC solutions.
What closes on October 31 is the door for new work, not the door for running fleets.
| What | Status during 2026-05-01 to 2026-10-31 | Status after 2026-10-31 |
|---|---|---|
| New SPoC submissions | Accepted, process unchanged | No longer accepted |
| New CPoC submissions | Accepted, process unchanged | No longer accepted |
| Existing listings | Valid, normal lifecycle | Still valid, normal lifecycle |
| Annual Checkpoints | Eligible | Eligible until listing expires |
| Change submissions | Accepted | Accepted until listing expires |
| New COTS acceptance projects | SPoC / CPoC / MPoC all open | MPoC only |
The practical consequence: a merchant who already runs a certified SoftPOS deployment does not need to rip anything out. A merchant who has not started yet does not have a choice of standards any more.
Which three standards are closing, and why the dates match
The PCI SSC standards portfolio page shows three sunset notices, all carrying the identical window of 1 May – 31 October 2026: the SPoC Standard, the CPoC Standard, and the PCI 3-D Secure (3DS) Software Development Kit (SDK) Standard.
Three unrelated standards do not pick the same six-month window by coincidence. The council’s stated reason is portfolio maturity around MPoC — PCI MPoC builds on the existing SPoC and CPoC standards and now handles both PIN and contactless cardholder data on the same COTS device. Closing the two narrower mobile acceptance routes plus the CNP software route at once is a consolidation of the certification entry point, not three separate technical decisions.
For buyers, the practical reading is narrow and useful: if your roadmap touches COTS mobile acceptance in 2027, MPoC is not the default choice among options. It is the only choice.
| Dimension | SPoC | CPoC | MPoC |
|---|---|---|---|
| PIN entry | Yes, on the COTS touchscreen | No | Yes |
| Card capture | Separate SCRP secure reader | Built-in NFC of the COTS device | NFC, or external reader |
| Attestation and monitoring | Required | Required | Required, modular |
| Accepted after 2026-10-31 | No new submissions | No new submissions | Yes |
Can you convert an existing SPoC or CPoC listing to MPoC?
Yes in principle, but vendors consistently describe it as a full evaluation rather than a paperwork transfer, because the scope and structure differ.
What carries over is evidence — platform attestation results, software protection testing, architecture documentation. What does not carry over is the conclusion. PCI-recognised laboratories assess MPoC products against the MPoC requirements and Program Guide, and the MPoC v1.1 release note lists ten substantive changes, including removal of Secure Software and kernel functional validation requirements, allowance for one MPoC SDK to integrate another, changes to some offline storage and security requirements, clarification of detection and response for compromised platforms, updates to PIN entry requirements covering accessible PIN entry and PIN entry on external devices, updates to self-testing requirements for MPoC SDK integration, non-isolating SDKs so the MPoC Application can manage secure channels, allowance for FIPS 140-2 L2 HSMs in controlled environments, and clarification on RSA2048 and technical fallback transactions.
Those changes cut in both directions. v1.1 removed requirements and added requirements in the same release. A vendor whose SPoC evidence was rejected over a Secure Software validation dependency may now find it out of scope; a vendor whose offline storage model changed may find that requirement moved.
What does this change for hardware buyers?
Less than the headlines suggest, and this is worth saying plainly to anyone who has just spent money on rugged payment terminals.
MPoC, SPoC and CPoC are all standards for software-based acceptance on commercial off-the-shelf devices. None of them certifies the handheld computer itself. A rugged Android terminal sold into a mobile acceptance project is evaluated as a platform the certified solution runs on, not as a certified payment device. Hardware certification for card acceptance is a separate track — PCI PTS Point of Interaction, which we covered separately, including the full certificate list on our credentials page.
So “will this terminal still work after the SPoC sunset” is the wrong question. The right one is narrower: does the certified software solution you chose support the device class you are buying, and what does your acquirer require on top of the PCI listing.
This is also where the honest industry truth sits. MPoC is not primarily a certification milestone; it is an ongoing operational obligation. Attestation and monitoring means a backend continuously evaluating whether the device has been tampered with, and that evaluation can revoke a device while it sits on a counter. Vendors selling certification as a one-time badge are selling something the standard does not offer. Buyers should ask who operates the attestation and monitoring backend, what the revocation path looks like, and what happens mid-shift.
alt=”Kingtop V520 mobile POS terminal with integrated card reader and keypad” loading=”lazy” width=”600″ height=”600″>A checklist for the remaining migration window
Nine weeks is short, and the critical path runs through people, not paperwork. Two failure modes dominate: ordering hardware against a solution that does not support your device class, and assuming an SPoC listing transfers to MPoC without work.
| # | Action | Owner | Why it blocks |
|---|---|---|---|
| 1 | Ask your acquirer what they will accept post-October 31 | Payments lead | PCI listing alone is not deployment approval |
| 2 | Confirm whether an existing SPoC or CPoC solution has an announced MPoC path | Solution vendor | Conversion is a re-evaluation, not a transfer |
| 3 | Identify who runs attestation and monitoring for the solution | Operations | Revocation is an ongoing operational event |
| 4 | Ask for the hardware device class the certified solution supports | Solution vendor | Determines what you can actually buy |
| 5 | Freeze new SPoC or CPoC submissions in your own process | Programme manager | After the deadline the route does not exist |
| 6 | Separate hardware certification (PTS) from software certification (MPoC) in your tender documents | Procurement | Conflating them causes tender mismatches |
If your fleet is already certified and stable, rows 1 and 3 are the whole project. If you are building something new, rows 2 and 4 are where the money and the schedule actually go.
Frequently asked questions
Do existing SPoC and CPoC solutions stop working after October 31, 2026?
No. The PCI SSC bulletin states that existing listings remain valid through their normal listing lifecycle, expire according to their existing reevaluation or expiration dates, and stay eligible for Annual Checkpoints during their active listing period. The sunset closes new submissions, not running deployments.
Is MPoC certification harder than SPoC or CPoC?
It is broader. MPoC permits both PIN and contactless cardholder data entry on the same COTS device, and adds offline transaction handling, manual card entry including camera capture, remote kernels, external magnetic stripe and secure readers, and enterprise devices not sold to the public. Broader scope means more of your actual use case is inside the assessment than it was under either older standard.
Can a hardware vendor certify my terminal for MPoC?
No. MPoC certifies solutions and software, evaluated by PCI-recognised MPoC laboratories. Hardware is assessed separately under PCI PTS. A terminal manufacturer can support a certified solution and can hold its own PTS approvals, but it cannot make your terminal MPoC certified.
We already have a certified SPoC deployment. Should we migrate anyway?
Only for a reason. Over-migrating is the expensive default here — a re-evaluation costs months and it solves a problem you do not have. Migrate if your acquirer requires it, if your vendor discontinues the listed product, or if your roadmap needs offline transactions, camera-based card entry or enterprise devices that SPoC cannot express.
Does the sunset affect the PIN pad and smart card reader we already own?
No. The sunset applies to COTS software acceptance standards. A separately PTS-approved PIN pad or secure card reader is unaffected, and continues under its own approval lifecycle with its own expiration date. Check that expiration date separately from the MPoC question.
alt=”Kingtop S600 handheld smart POS terminal with card reader” loading=”lazy” width=”600″ height=”600″>About this article
This article was written by the Kingtop Product Team and last updated on October 22, 2026. Kingtop is a China-based manufacturer of rugged mobile computing hardware, including 5G PDA handheld terminals, mobile hotspots, POS terminals, body-worn cameras and rugged tablets, supplying wholesale, OEM and ODM programmes to distributors and system integrators in North America, Europe and Southeast Asia. Our certification and credential documentation is published in full on the Kingtop credentials page, including FCC identifiers, CE RED and SRRC/CCC/CTA approvals.
Our editorial policy is straightforward: claims about payment standards are traced to the issuing body’s own published documents, competing-product parameters come from manufacturer-published specifications, and statements about our own hardware are limited to specifications we can substantiate. Where a standard body states an explicit position, we quote it rather than paraphrase. Corrections go to the same contact address as commercial enquiries.
If you are planning a mobile acceptance project and need to know which device class a certified MPoC solution supports, start with our mobile POS terminals and the V510 platform, or send us your target use case and we will tell you plainly whether a payment terminal is the right hardware at all — for many field and warehouse workflows, a rugged handheld computer is the correct answer and a payment terminal would be over-specification. Browse the full range at kingtop5g.com.
Add comment