PCI SPoC 2026: Prepare Your Phone-Based PIN Payments Before Sunset

The short answer: October 31, 2026 is not the date on which all PCI SPoC solutions will stop operating. According to the PCI Security Standards Council Bulletin: Announcement of Sunset Periods for the PCI SPoC and PCI CPoC Standards, PCI SSC’s sunset period runs from May 1, 2026, through October 31, 2026. After that date, PCI SSC will no longer accept new SPoC submissions; accepted listings will continue according to their individual lifecycles, expiration dates and maintenance requirements.

Therefore, merchants using PIN entry on mobile devices should not shut down their systems simply because they have heard the term “sunset.” They need to determine when the specific listing remains valid, whether the deployed configuration matches that listing, which party is responsible for PCI DSS obligations, and what will replace the solution if necessary.

Understand the Sunset Timeline and the Status of the Solution in Use

SPoC stands for Software-based PIN Entry on COTS, meaning a solution for entering PINs on commercial off-the-shelf (COTS) devices such as smartphones or tablets. According to PCI SSC’s description in Software-based PIN Entry on COTS (SPoC), a complete SPoC solution typically involves a PIN-entry application, a secure card reader (SCRP), a COTS device, and server-side monitoring and remote authentication systems.

The important distinction is that the sunset of the submission program and the expiration of a specific listing are not the same thing. Existing listings do not automatically expire on October 31, 2026; businesses must still comply with the expiration date, reassessment schedule and maintenance requirements applicable to each listing.

A merchant may fall into one of three situations:

1. Using an active SPoC listing: there is no basis for concluding that the solution must be replaced immediately. However, record the expiration date, maintenance requirements and the provider’s support plan.
2. Testing or selecting a solution that is not listed: do not assume that combining an application, reader and server system creates a valid SPoC solution. PCI SSC emphasizes that only complete, approved and listed SPoC solutions fall within the program, as stated in New FAQs on Software-based PIN Entry on COTS.
3. Planning a new deployment or requiring long-term support: ask the provider about PCI MPoC, which PCI SSC describes as having been developed from SPoC and CPoC, or consider dedicated payment hardware.

The sunset itself does not demonstrate that PIN entry on mobile devices has become unsafe. It means that the SPoC program will no longer accept new submissions after the announced period, while businesses must manage the lifecycle of the specific solution they use.

Check the Listing, Configuration and PCI DSS Responsibilities

Compare the Deployed Solution with the Listing

Ask the provider to supply, in writing, the exact solution name, listing identifier or reference, SPoC version, reassessment date, expiration date and support status. Do not check only the application’s commercial name. Compare the full configuration in operation at the merchant, including:

• the payment application and operating-system versions;
• the COTS smartphone or tablet model;
• the secure card reader (SCRP) model;
• the monitoring and authentication server system and relevant versions;
• any usage limitations or conditions stated in the listing.

You can create an inventory with columns for the provider’s legal entity, listing name and identifier, application version, SCRP model, expiration or reassessment date, support status, MPoC roadmap or replacement option, and incident contact. Then compare the information with PCI SSC documentation and the service agreement. If the provider only gives a general response that the “solution is PCI-compliant” but cannot identify the relevant listing and matching configuration, treat that as an unverified item.

Determine PCI DSS Responsibilities

SPoC is a solution-assessment program; it does not replace the merchant’s PCI DSS obligations in full. PCI DSS applies to entities that store, process or transmit payment account data; a low transaction volume does not automatically exempt a business from its data-protection obligations. The required validation method may be specified by the acquiring bank, payment organization or acquirer. See also Do small merchants with limited transaction volumes need comply with PCI DSS?.

Even when payment processing is outsourced to a third party and the business does not directly store, process or transmit card data, the PCI DSS scope may be reduced but responsibility does not disappear. The business still needs to verify the provider’s compliance status, have a written agreement defining each party’s responsibilities, and complete the required validation method. See Does PCI DSS apply to merchants who outsource all payment processing operations and never store, process or transmit cardholder data?.

Ask the acquiring bank, acquirer or provider to answer at least the following questions in writing:

1. Which SAQ or other PCI DSS validation method must the merchant complete?
2. Which system scope and responsibilities include the mobile PIN-entry solution?
3. Which requirements are the provider’s responsibility, and which are the merchant’s?
4. If the listing expires before the migration, what option is available for continuing to accept transactions?

Plan and Validate the Migration Before Making Changes

Follow the sequence below so that work does not begin only after the listing has expired:

1. Inventory the system: record every smartphone, tablet, SCRP reader, application, version, administrator account and point of sale in use.
2. Verify the listing: compare the deployed solution with the listing, expiration date, reassessment schedule and maintenance requirements.
3. Review the contract: look for provisions covering changes to the standard, version support, security incidents, expiry notices, service levels and migration costs.
4. Confirm responsibilities: obtain confirmation from the acquiring bank or payment acquirer regarding the applicable PCI DSS scope, migration requirements and approved approach.
5. Choose an approach: Options may include a suitable MPoC solution, a dedicated payment terminal or another method that does not require PIN entry on a COTS device. Do not assemble components yourself and treat the result as a solution approved by the PCI Security Standards Council (PCI SSC).
6. Test before migration: use an environment or procedure approved by the provider to test chip transactions, contactless transactions where supported, refunds, loss of network connectivity, application updates, device locking and procedures for a lost device.
7. Keep records: retain the listing, contracts, confirmations from the payment parties, test records, device configurations, responsibility assignments and recovery plan.

Remove the legacy solution only after the new approach has been tested, approved by the relevant parties and backed by a fallback payment method. If the current listing remains valid for a longer period, the business may continue operating under controlled conditions, but it should still set a review milestone before the actual expiry date.

Completion check: the person responsible must be able to answer three questions: until what date does the current solution remain valid; who is responsible for each part of PCI DSS; and, if support ends, which option will the merchant switch to without interrupting payments?

Security note: do not use an employee’s personal phone as a payment device if the business cannot control its configuration, applications, access permissions and ability to erase data remotely. PCI Mobile Payment Acceptance Security Guidelines for Merchants provides guidance on protecting devices and solutions according to the roles of merchants and providers; it does not replace PCI DSS.

If the migration fails, revert to the previous configuration only if its listing and contract are still valid. Record the incident, open a support request with the provider and use the fallback method approved by the acquiring bank or payment acquirer.

Reference source

• PCI Security Standards Council Bulletin: Announcement of Sunset Periods for the PCI SPoC and PCI CPoC Standards
• Software-based PIN Entry on COTS (SPoC)
• New FAQs on Software-based PIN Entry on COTS
• Does PCI DSS apply to merchants who outsource all payment processing operations and never store, process or transmit cardholder data?
• Do small merchants with limited transaction volumes need comply with PCI DSS?
• PCI Mobile Payment Acceptance Security Guidelines for Merchants