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.

Which PCI PTS POI version applies to a new payment terminal?

PCI PTS POI version 7.0 was published on 29 May 2025. In a bulletin dated 17 June 2025, the PCI Security Standards Council extended the use of the v6 requirements for new device approvals to 30 June 2026, keeping its usual 12-month overlap between major versions, and pushed the expiry of v6 approvals from April 2031 to April 2032. A terminal already approved under v6 therefore stays listed until April 2032, while a new design should be planned against v7, which adds requirements for biometric interfaces, for third-party applications such as app stores, and an option for accessible PIN entry.

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. Both are being retired: the PCI Security Standards Council set a formal sunset period for SPoC and for CPoC running from 1 May to 31 October 2026. Their successor is MPoC (Mobile Payments on COTS), published in November 2022 and revised to version 1.1 on 26 November 2024, which covers PIN entry and contactless acceptance on the same COTS device.

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) is an approval for a reader that securely captures and encrypts card data. Its SCRP variant (Secure Card Reader, PIN) is the reader used in SPoC solutions, where the PIN itself is typed on the COTS touchscreen through a PIN CVM application rather than on the reader. 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

Hugues Orgitelloupdated 6 Oct 202612 min read

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.

Key dates for payment device programmes

Several of the reference points in this field moved between 2022 and 2026. The table lists the dates that change a plan, each taken from the body that set it.

Date	Event	Consequence for a product team
5 October 2022	EMVCo publishes the EMV Contactless Kernel Specification (Book C-8, Kernel 8)	A single EMVCo-defined contactless kernel exists alongside the brand kernels, with its own EMVCo approval process
16 November 2022	PCI SSC publishes the MPoC standard	PIN entry and contactless acceptance on the same COTS device fall under one standard
26 November 2024	MPoC version 1.1 published	Secure Software and kernel functional validation requirements removed from MPoC; one MPoC SDK may integrate another
29 May 2025	PCI PTS POI version 7.0 published	New requirements for biometric interfaces, third-party applications and accessible PIN entry
30 June 2026	Last date for new device approvals against PTS POI v6 (as extended by the 17 June 2025 bulletin)	New terminal designs are evaluated against v7
1 May to 31 October 2026	Formal sunset period of SPoC and of CPoC	New COTS acceptance products target MPoC
April 2032	Expiry of PTS POI v6 device approvals (extended from April 2031)	Installed v6 terminals stay on the approved list until then

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. For the contactless reader of a terminal (the PCD, proximity coupling device), EMVCo issues a Letter of Approval valid for four years.

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. On 5 October 2022 EMVCo added its own Kernel 8 (Book C-8), a contactless kernel defined by EMVCo rather than by a single card brand, with a dedicated EMVCo approval process. 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 current major version is v7.0, published on 29 May 2025. The council keeps a 12-month overlap between major versions, and its bulletin of 17 June 2025 set 30 June 2026 as the last date for new approvals against v6, with existing v6 approvals expiring in April 2032 instead of April 2031.

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.

Version 7.0 brings 59 requirement changes and 23 pieces of additional guidance, according to the council. Among them: a requirement for the physical and logical security of biometric interfaces, a requirement allowing third-party applications such as app stores, an effective key strength of 128 bits or stronger for terminal security keys such as firmware authentication and tamper or storage keys, and an option for accessible PIN entry that can be offered per transaction.

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 (Secure Card Reader, PIN) is the reader of SPoC solutions
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 of the COTS device	Modular standard that consolidates SPoC and CPoC; v1.1 since 26 November 2024

SPoC pairs a PCI-approved SCRP (Secure Card Reader, PIN) with a PIN CVM application on the COTS device, where the cardholder types the PIN, 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.

The choice is no longer open for a new product. The PCI Security Standards Council set a formal sunset period for SPoC and for CPoC from 1 May to 31 October 2026, so a COTS acceptance product started today is scoped on MPoC. A solution already validated under SPoC or CPoC can be submitted under MPoC, but because the scope and structure differ, expect a full evaluation rather than a paperwork transfer.

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 (April 2032 for PTS POI v6 approvals); firmware changes can require delta evaluations. EMVCo Level 1 PCD approvals carry a four-year Letter of Approval. 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 new COTS product is scoped on SPoC or CPoC, whose sunset period ends on 31 October 2026	Scope new COTS acceptance on MPoC, which covers both PIN on glass and tap
Designing to the old PTS version	A terminal designed against PTS POI v6 misses the 30 June 2026 cut-off for new v6 approvals	Design against PTS POI v7.0, including its biometric, third-party application and key length requirements
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/
Just Published: PTS POI v7.0 (29 May 2025), PCI Security Standards Council blog.pcisecuritystandards.org/just-published-pts-poi-v7-0
Bulletin: Extension of Expiration of the PCI PTS POI v6 Security Requirements and Approvals (17 June 2025), PCI Security Standards Council www.pcisecuritystandards.org/wp-content/uploads/2025/06/Bulletin-Extension-of-Expiration-of-the-PCI-PTS-POI-v6-Security-Requirements-and-approvals.pdf
PCI Software-based PIN Entry on COTS (SPoC), standard page and sunset notice, PCI Security Standards Council www.pcisecuritystandards.org/standards/software-based-pin-entry-on-cots-spoc/
PCI Contactless Payments on COTS (CPoC), standard page and sunset notice, PCI Security Standards Council www.pcisecuritystandards.org/standards/contactless-payments-on-cots-cpoc/
PCI Mobile Payments on COTS (MPoC) Standard, PCI Security Standards Council www.pcisecuritystandards.org/standards/mobile-payments-on-cots/
PCI SSC Publishes New Standard for Mobile Payment Solutions (16 November 2022), PCI Security Standards Council www.pcisecuritystandards.org/about_us/press_releases/pci-ssc-publishes-new-standard-for-mobile-payment-solutions/
PCI Mobile Payments on COTS (MPoC) Standard Version 1.1 Now Available (26 November 2024), PCI Security Standards Council blog.pcisecuritystandards.org/pci-mobile-payments-on-cots-mpoc-standard-version-1-1-now-available
EMVCo Publishes EMV Contactless Kernel Specification (5 October 2022), EMVCo www.emvco.com/news/emvco-publishes-emv-contactless-kernel-specification/
EMVCo, PCD Level 1 Approval Process, EMVCo www.emvco.com/processes/pcd-level-1-approval-process/
EMVCo, What are EMV Level 1 and Level 2 Testing?, EMVCo www.emvco.com/knowledge-hub/what-are-emv-level-1-and-level-2-testing/
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/

Frequently asked questions

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.
Which PCI PTS POI version applies to a new payment terminal?: PCI PTS POI version 7.0 was published on 29 May 2025. In a bulletin dated 17 June 2025, the PCI Security Standards Council extended the use of the v6 requirements for new device approvals to 30 June 2026, keeping its usual 12-month overlap between major versions, and pushed the expiry of v6 approvals from April 2031 to April 2032. A terminal already approved under v6 therefore stays listed until April 2032, while a new design should be planned against v7, which adds requirements for biometric interfaces, for third-party applications such as app stores, and an option for accessible PIN entry.
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. Both are being retired: the PCI Security Standards Council set a formal sunset period for SPoC and for CPoC running from 1 May to 31 October 2026. Their successor is MPoC (Mobile Payments on COTS), published in November 2022 and revised to version 1.1 on 26 November 2024, which covers PIN entry and contactless acceptance on the same COTS device.
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) is an approval for a reader that securely captures and encrypts card data. Its SCRP variant (Secure Card Reader, PIN) is the reader used in SPoC solutions, where the PIN itself is typed on the COTS touchscreen through a PIN CVM application rather than on the reader. 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.