What is the difference between EMVCo and PCI certification?

EMVCo certifies that a device correctly implements the EMV protocols for reading and transacting with chip and contactless cards: Level 1 covers the electrical and physical interface, Level 2 covers the application kernel. PCI Security Standards Council certification, principally PCI PTS POI, addresses the physical and logical security of the device that captures and processes the PIN and account data: tamper resistance, key management and secure cryptography. A payment terminal that reads cards and accepts a PIN generally needs both, because they cover different concerns.

When does a product with a card reader need EMVCo Level 1?

A device needs EMVCo Level 1 contact or contactless approval whenever it acts as the physical reader that communicates with an EMV chip card or a contactless card or wallet. Level 1 demonstrates electrical, protocol and analogue compliance with the EMV specifications (ISO/IEC 7816 for contact, ISO/IEC 14443 for contactless). It is a prerequisite before Level 2 kernel testing, and before any acquirer or scheme approval, because the schemes build their type approval on top of the EMVCo Letters of Approval.

Is PCI PTS POI mandatory or is it a scheme requirement?

PCI PTS POI is a standard published by the PCI Security Standards Council, not a law. It becomes effectively mandatory because the card schemes (Visa, Mastercard, and others) and the acquiring banks require a valid PCI PTS approval for any device that accepts a PIN or processes cardholder data at the point of interaction. Without a listed PTS approval, an acquirer will normally refuse to board the terminal, so in commercial practice the certification is unavoidable for attended and unattended payment devices that handle a PIN.

What are SPoC and CPoC and how do they differ?

SPoC (Software-based PIN entry on COTS) and CPoC (Contactless Payments on COTS) are PCI standards that let a commercial off-the-shelf device such as a smartphone or tablet take payments. SPoC pairs a secure card reader (SCRP) with a PIN entry application and a back-end monitoring system to allow PIN entry on the touchscreen. CPoC allows contactless acceptance using the built-in NFC of the device, without PIN on glass. The newer MPoC standard (Mobile Payments on COTS) merges and extends both into a single modular framework.

How long does EMVCo and PCI PTS certification take?

Timelines vary with the maturity of the design and the laboratory queue, but a realistic plan reserves several months. EMVCo Level 1 and Level 2 testing at an accredited laboratory typically runs over weeks once the hardware and kernel are stable. A PCI PTS POI evaluation is heavier because it covers physical tamper, logical security, key management and the device life cycle, and often runs in parallel with EMVCo work. Scheme type approval (Visa, Mastercard) then consumes additional time on top.

What is the difference between PTS POI, SCR and EPP?

Within PCI PTS, POI (Point of Interaction) is the overall device approval class for a payment terminal. EPP (Encrypting PIN Pad) is a PTS approval class for a PIN pad module integrated into a larger machine such as an ATM or an unattended kiosk. SCR (Secure Card Reader), and specifically the SCRP variant used in SPoC, is an approval for a reader that securely captures and encrypts card data and, in the SCRP case, also captures the PIN. Each class maps to a different integration scenario.

Does a contactless-only reader still need PCI certification?

It depends on whether the device captures a PIN and on the deployment model. A pure contactless tap, with no PIN entry and no display of account data, has a lighter security envelope than a PIN-accepting terminal, and the CPoC or MPoC route may apply for COTS devices. A dedicated hardware reader that encrypts card data still generally needs an SCR or POI approval, and the acquirer and scheme rules determine the exact obligation for the target market.

How do EMVCo and PCI relate to Common Criteria and FIPS 140-3?

EMVCo and PCI PTS are payment-specific schemes, but they lean on broader security evaluation methods. PCI PTS requires the device to behave as a secure cryptographic device with sound key management, concepts that overlap with the secure cryptographic device requirements of ISO 13491 and with FIPS 140-3 module validation. Some secure components inside a terminal carry Common Criteria certificates against payment Protection Profiles. These frameworks are complementary rather than interchangeable.

EMVCo and PCI PTS: payment device certification

Author Hugues Orgitello Last updated 29 May 2026 ~9 min read

Guide, payment devices

A device that reads a bank card and processes a payment sits at the intersection of two distinct certification worlds. EMVCo governs the functional correctness of the chip and contactless transaction, through its Level 1 (interface) and Level 2 (kernel) type approvals. The PCI Security Standards Council governs the security of the device that captures the PIN and the cardholder data, principally through PCI PTS POI for terminals and the newer software-based schemes SPoC, CPoC and MPoC for commercial off-the-shelf hardware. On top of both sit the scheme approvals of Visa, Mastercard and the other networks, plus the acquirer onboarding rules. This guide maps which approval a card-reading product needs, in what order, and how the pieces fit together.

The certification landscape for payment devices

Three layers of approval combine before a payment terminal can be deployed in the field. They are independent in their criteria but sequential in practice, because each layer assumes the one below it.

Layer	Owner	Question it answers	Typical artefact
Functional EMV	EMVCo	Does the device correctly read and transact with EMV chip and contactless cards?	EMVCo Letter of Approval (Level 1 and Level 2)
Device security	PCI Security Standards Council	Is the PIN and account data protected against tampering and extraction?	PCI PTS POI approval (or SPoC, CPoC, MPoC for COTS)
Scheme and acquirer	Visa, Mastercard, others, and the acquiring bank	May this specific device run on our network and be boarded by this acquirer?	Scheme type approval and acquirer registration

EMVCo and PCI are global, brand-neutral bodies. EMVCo is collectively owned by the major payment networks and maintains the EMV specifications. The PCI Security Standards Council maintains the security standards for the payment ecosystem. The schemes then build their commercial type approval programmes on top of these neutral foundations, which is why the EMVCo and PCI approvals normally have to exist before a scheme will grant its own approval.

ISO/IEC 7816 ISO/IEC 14443

Who needs what

The decision starts with two questions: does the product read cards, and does it accept a PIN or handle cardholder data.

A device that reads EMV cards (contact, contactless, or both) needs EMVCo Level 1, and Level 2 for each card kernel it runs.
A device that accepts a PIN or otherwise captures sensitive cardholder data at the point of interaction needs a PCI PTS approval (POI, EPP, or a COTS scheme).
A device intended to operate on a given network needs the corresponding scheme type approval and must be accepted by the acquirer.

A simple contactless-only acceptance app running on a phone follows a very different path (CPoC or MPoC) from a fully attended countertop terminal with a physical PIN pad (Level 1, Level 2 and PTS POI).

EMVCo: functional type approval

EMVCo type approval demonstrates that a device behaves correctly against the EMV specifications. It is split into two levels that test different parts of the stack.

Level 1: the interface

EMVCo Level 1 covers the electrical, electromechanical and protocol layer between the device and the card. For contact cards it verifies compliance with the EMV contact specifications layered on ISO/IEC 7816 (physical contacts, power, clock, transmission protocols T=0 and T=1). For contactless it verifies the analogue and digital radio interface layered on ISO/IEC 14443 (the EMV Contactless Communication Protocol, formerly the analogue and digital books). Level 1 testing uses calibrated reference equipment and a defined test bench, and it is agnostic to the payment application.

ISO/IEC 7816 ISO/IEC 14443

Level 2: the kernel

EMVCo Level 2 covers the application kernel, the software that runs the transaction logic on top of a Level 1 compliant interface. For contact, this is the EMV Integrated Circuit Card Specifications kernel. For contactless, EMVCo defines a family of kernels (historically numbered, for example the kernels associated with the major card brands) within the EMV Contactless Specifications for Payment Systems, often referred to as Book C. A device that runs several contactless kernels must obtain a Level 2 approval for each.

Level 3 and acquirer testing

EMVCo itself approves Levels 1 and 2. End-to-end testing of the combined terminal and acquirer host, sometimes labelled Level 3, is not an EMVCo approval but an integration and acceptance activity run by the acquirer or a scheme test service, validating that the configured terminal transacts correctly against the live host.

EMVCo step	What is tested	Approving body	Output
Level 1 contact	Electrical and protocol interface, ISO/IEC 7816 based	EMVCo via accredited lab	Letter of Approval
Level 1 contactless	Analogue and digital RF interface, ISO/IEC 14443 based	EMVCo via accredited lab	Letter of Approval
Level 2	Application kernel transaction logic, per kernel	EMVCo via accredited lab	Letter of Approval
Level 3 (acquirer)	End-to-end terminal plus host configuration	Acquirer or scheme test service	Acceptance, not an EMVCo LoA

PCI PTS POI: device security

While EMVCo asks whether the device transacts correctly, PCI PTS POI (PIN Transaction Security, Point of Interaction) asks whether it protects the secrets it handles. The standard is published by the PCI Security Standards Council as the PTS POI Modular Security Requirements, and an approved device is listed on the council website with an expiry date tied to the standard version it was approved against.

The modules

PTS POI is modular. A device is evaluated against the modules relevant to its design:

Core physical security: resistance to physical tamper, penetration and bench attacks, with active tamper response that zeroises keys.
Core logical security: firmware authenticity, secure boot, access control, protection of the PIN entry path.
Online and offline PIN: the secure handling and encryption of the PIN.
SRED (Secure Reading and Exchange of Data): account data encryption at the point of capture, an optional but widely required module.
Open protocols: hardening of any IP or network stack exposed by the device.
Integration: rules for combining the device into a larger system.

Approval classes within PTS

The PTS programme covers several device shapes through distinct approval classes.

PTS class	Device type	Typical deployment
POI	Complete payment terminal	Attended countertop, mobile (mPOS), unattended
EPP (Encrypting PIN Pad)	PIN pad module only	ATM, fuel dispenser, vending and kiosk integration
SCR (Secure Card Reader)	Secure reader that encrypts card data	Component readers; the SCRP variant adds secure PIN for SPoC
HSM	Hardware Security Module	Back-end key management and transaction processing

The HSM standard sits within the PCI PTS family and applies to the back-end devices, not the customer-facing terminal. The terminal-facing classes are POI, EPP and SCR.

Secure cryptographic device and key management

PCI PTS treats the terminal as a secure cryptographic device in the sense of ISO 13491, the financial services standard for retail secure cryptographic devices. Key management must follow disciplined principles: unique keys per device where required, no clear-text keys outside the secure boundary, dual control and split knowledge for manual key loading, and increasingly the use of remote key loading and methods such as DUKPT (Derived Unique Key Per Transaction) for transaction key derivation. Tamper response, secure key storage and a controlled device life cycle from manufacture to decommissioning are central to the evaluation.

ISO 13491

Software-based acceptance: SPoC, CPoC and MPoC

The classic model assumes purpose-built secure hardware. The PCI council also publishes standards that let a commercial off-the-shelf (COTS) device such as a smartphone or tablet take payments, shifting part of the security burden to software and to a back-end monitoring system.

Standard	Full name	PIN entry	Card capture	Note
SPoC	Software-based PIN Entry on COTS	Yes, on the COTS touchscreen	Via a separate SCRP secure reader	PIN protected by software plus a monitored back end
CPoC	Contactless Payments on COTS	No	Built-in NFC of the COTS device	Tap only, no PIN on glass
MPoC	Mobile Payments on COTS	Optional (PIN on glass)	Built-in NFC or attached reader	Modular standard that consolidates SPoC and CPoC

SPoC pairs a PCI-approved SCRP (Secure Card Reader for PIN) with a PIN entry application on the COTS device, backed by a back-end monitoring and attestation system that watches the COTS fleet for tampering and revokes compromised instances. CPoC allows contactless acceptance using the phone built-in NFC, without a PIN. MPoC, the more recent standard, merges and generalises both into a modular framework that can support PIN on the screen and contactless together, and it introduces an ongoing monitoring and security requirement rather than a single point-in-time test. For new COTS acceptance products, MPoC is the strategic target.

Scheme and acquirer approvals

EMVCo and PCI approvals are necessary but not sufficient. Each payment network maintains its own type approval programme that consumes the EMVCo Letters of Approval and the PCI listing and adds brand-specific requirements.

Visa maintains an approved devices and terminal programme; a device must appear on the relevant Visa list to run Visa transactions.
Mastercard runs its Terminal Quality Management and related approval processes.
Other networks (for example domestic schemes) maintain comparable programmes.

The acquiring bank then performs onboarding (boarding) of the specific device and configuration, which is where end-to-end (Level 3) testing happens. A device cannot be deployed simply because it holds EMVCo and PCI approvals; it must also be accepted by the schemes whose cards it will process and registered by the acquirer that settles its transactions.

How the approvals chain together

The dependencies run bottom-up. A break at any layer blocks the layer above.

Confirm the EMVCo Level 1 interface approval for contact and contactless as applicable.
Obtain EMVCo Level 2 approval for each kernel the device runs.
Complete the PCI PTS POI evaluation (or the COTS-route standard) and get listed.
Apply for scheme type approval with each network, citing the EMVCo LoAs and the PCI listing.
Complete acquirer onboarding and end-to-end (Level 3) acceptance with the host.

Step by step: planning a payment device certification

A structured plan reduces the risk of expensive late surprises in a payment device programme.

Define the device class. Decide whether the product is an attended terminal, an unattended terminal, an EPP module, a secure component reader, or a COTS-based acceptance app. This selects the applicable PCI class and the SPoC, CPoC or MPoC route.
List the EMV interfaces. Determine whether the device supports contact, contactless, or both, and enumerate the contactless kernels it will run. Each interface and kernel maps to an EMVCo Level 1 or Level 2 approval.
Choose the laboratories. Select EMVCo-accredited and PCI-recognised laboratories early, and reserve slots, because queues drive the timeline more than the testing itself.
Freeze the security architecture. Settle the tamper-responsive boundary, the secure boot chain, the key management scheme (including remote key loading and DUKPT) and the SRED account-data encryption before evaluation.
Run EMVCo and PCI in parallel. The functional and security tracks are independent and can proceed together once hardware and firmware are stable.
Target the schemes and acquirer. Identify the networks and the acquiring bank early, since their specific requirements may feed back into the hardware design.
Plan maintenance. PCI approvals expire with the standard version and need renewal; firmware changes can require delta evaluations. MPoC adds continuous monitoring obligations.

Common pitfalls

Pitfall	Manifestation	Mitigation
Treating EMVCo and PCI as one approval	Programme assumes a single test campaign, then discovers two independent tracks	Plan EMVCo (functional) and PCI (security) as separate, parallel work streams
Forgetting a contactless kernel	Device runs several brand kernels but only one Level 2 approval was obtained	Enumerate every kernel at design time and budget a Level 2 per kernel
Late security architecture	Tamper boundary or key management reworked after PTS evaluation starts	Freeze the secure cryptographic device design before booking the PTS lab
Ignoring approval expiry	A device drops off the approved list when its PTS standard version sunsets	Track the expiry date tied to the PTS version and plan re-evaluation
Underestimating scheme approval	Team plans only for EMVCo and PCI, not for Visa and Mastercard type approval	Add scheme type approval and acquirer onboarding to the schedule
Wrong COTS route	A PIN-on-glass product is scoped as CPoC, which forbids PIN entry	Map PIN entry need to SPoC or MPoC, reserve CPoC for tap-only acceptance
Skipping end-to-end testing	Certified components fail in production against the live host	Budget Level 3 acquirer acceptance after EMVCo and PCI approvals

Sources and references

Sources & references

EMVCo, EMV Contact and Contactless specifications and the Type Approval process , EMVCo www.emvco.com/
PCI Security Standards Council, PTS POI Modular Security Requirements and approved devices list , PCI Security Standards Council www.pcisecuritystandards.org/
PCI Software-based PIN Entry on COTS (SPoC) Standard and Programme Guide , PCI Security Standards Council www.pcisecuritystandards.org/document_library/
PCI Mobile Payments on COTS (MPoC) Standard , PCI Security Standards Council www.pcisecuritystandards.org/standards/mobile-payments-on-cots/
ISO/IEC 7816, Identification cards, integrated circuit cards with contacts , ISO/IEC www.iso.org/standard/54089.html
ISO/IEC 14443, Cards and security devices, proximity contactless objects , ISO/IEC www.iso.org/standard/73599.html
ISO 13491, Financial services, secure cryptographic devices (retail) , ISO www.iso.org/standard/79518.html
Visa Approved Devices and Mastercard Terminal Quality Management programme references , Visa www.visa.com/