How a Card Payment Terminal Is Made: Tamper Response, EMV and PCI PTS

A card payment terminal is made by building a small computer around a secure processor that holds the keys, wrapping that processor and the PIN pad in tamper sensors that wipe the keys if the case is opened, and adding card readers and an EMV kernel that pass EMVCo testing. The finished design is then evaluated by a PCI recognised laboratory against the PCI PIN Transaction Security (PTS) Point of Interaction (POI) requirements, listed by the PCI Security Standards Council (PCI SSC), loaded with keys in a controlled facility, and only then shipped to a merchant.

This post walks through that chain from bare board to a key loaded terminal on a shop counter, using the public documents of PCI SSC, EMVCo, NIST and the X9 standards body. It goes one level deeper than our post on securing the retail point of sale software supply chain, which covers the software side of the till, and it sits next to our builds of a printed circuit board, which is where a terminal starts, and a smartphone, which increasingly acts as a terminal itself.

This is a defensive explainer. It describes how protections are designed and certified and what merchants should check. It does not explain how to defeat tamper protection, and it names no terminal makers.

Key takeaways

• A payment terminal is two computers in one case: a general application processor that runs the screen, network and merchant apps, and a secure processor inside a tamper responsive boundary that holds keys and handles PINs and card data.
• Tamper response is layered: conductive meshes, switches and sensors feed a monitor powered by a backup battery, and on intrusion the device erases (zeroises) its secret keys. PTS POI v7.0, published by PCI SSC on 29 May 2025, added a narrow allowance for keys that are not zeroised when forward secrecy is used and extracting them requires destroying the processing element.
• EMVCo tests the card interface (Level 1) and the kernel software that runs EMV transactions (Level 2). Level 3 testing, defined by each payment system, checks the terminal end to end with an acquirer or processor. EMVCo defines the processes; recognised independent laboratories do the testing.
• PCI PTS POI approval is tied to specific evaluated versions and carries an expiry date set by the version of the standard it was tested against.
• Keys are injected under dual control, and DUKPT (ANSI X9.24-3 for AES) derives a fresh key for each transaction from an initial terminal key.
• PTS POI v5 device approvals now expire on 30 April 2027 and v6 approvals in April 2032, after PCI SSC extensions in 2025. Whether a merchant may keep using an expired device is decided by the payment brands, not by PCI SSC.
• PCI SSC's SPoC and CPoC standards for phone based acceptance are in a sunset period that ends on 31 October 2026, with MPoC as the successor.

From bare board to a key loaded terminal: the step table

Each stage has its own security control and, often, its own certification.

What is inside a card terminal?

Inside a countertop terminal is a familiar set of parts arranged around one unusual idea: a security boundary. (Opening an armed unit erases its keys, which is the point.)

The PCI SSC description of the PTS POI standard lists the device categories this boundary has to protect in: PIN entry devices (PEDs), unattended payment terminals, non PIN acceptance devices evaluated for account data protection, encrypting PIN pads that are built into other machines such as ATMs, secure card readers that are components of POS terminals, and secure card reader PIN devices (SCRPs) that are designed to work with a commercial phone or tablet.

Two processors, one boundary

The design rule behind every modern terminal is that the general purpose side never sees secrets. The application processor can be compromised by a bad app or a network attack and the PIN must still be safe. To make that possible:

1. The PIN pad is wired to the secure processor, not the application processor.
2. The secure processor controls when the device is in PIN entry state and what the display shows, so an app cannot draw a fake PIN prompt.
3. Card data enters the secure side and leaves only encrypted, which PCI calls secure reading and exchange of data (SRED) on devices that support it.
4. Keys are generated, stored and used only inside the secure processor.

How is tamper response built?

Tamper response is the property that makes a terminal different from a phone. The device assumes an attacker may hold it for hours with tools, and it is designed so that physical access to the inside costs the attacker the very secrets they wanted.

The layers

A typical design combines several mechanisms. The exact mix is each vendor's engineering choice, and the PTS requirements describe outcomes rather than mandating a particular construction.

• Conductive meshes. Fine serpentine traces, printed on flexible film or built into inner board layers, wrap the secure area. The tamper monitor drives signals through them and watches for open circuits, shorts between traces or changes in resistance. Drilling, cutting or probing through the mesh breaks the pattern.
• Switches. Small spring contacts are held closed by the assembled case and keypad. Separating the case halves releases them.
• Environmental sensors. Many secure processors watch temperature, supply voltage and clock frequency, because extreme cold, voltage glitches and clock manipulation are classic ways to make chips misbehave.
• Potting and shielding. Epoxy or metal cans make the most sensitive parts hard to reach without triggering the mesh.
• Keypad protection. The PIN pad sits inside the protected area and is covered by the same sensors.

Battery backed key storage and zeroisation

The keys that matter most live in memory that is kept powered by the backup cell and wiped the instant a tamper sensor fires. Because that memory is volatile and battery backed, erasure is fast and does not depend on the main processor being awake. The device can be off, in a box, in a delivery van, and still react.

After a tamper event the device is no longer usable for payments. Most designs display a tamper message and need to go back to the vendor or a repair centre, where it is inspected, repaired if appropriate and has its keys loaded again. That is a feature: it turns a covert attack into a visible failure.

One design tension: a backup cell has a finite life, so a terminal left unpowered in a warehouse for too long can wake up "tampered" because its battery ran down. Vendors manage this with shelf life rules and by arming the tamper monitor late in manufacturing.

What PCI PTS POI says about physical security

PCI SSC describes the PTS POI standard as security requirements for the characteristics and management of devices used to protect cardholder PINs, account data and other sensitive card data at the point of interaction. The current major version is PTS POI Modular Security Requirements v7.0, which PCI SSC announced on 29 May 2025. Its announcement says v7.0 includes 59 requirement changes and 23 pieces of additional guidance, after two requests for comment in 2024, and lists among the changes:

• a new requirement for the physical and logical security of biometric interfaces;
• a new requirement allowing the use of third party applications, for example from app stores;
• consideration for secret or private keys that are not zeroised on tamper where forward secrecy is used and extracting the keys requires destroying the processing element that uses them;
• a rule that terminal security keys, such as firmware authentication and tamper or storage keys, must use cryptography with an effective strength of 128 bits or more;
• an option for an accessibility focused PIN entry feature that can be enabled per transaction.

The structure of the standard comes from v6.0, released on 16 June 2020. PCI SSC's release for v6.0 said it reorganised the requirements into modules covering physical and logical security, integration, communications and interfaces, and life cycle; limited firmware approval timeframes to three years; required devices accepting EMV cards to support elliptic curve cryptography; and improved support for magnetic stripe acceptance in phone based solutions. Interim releases followed: v6.1, announced in a PCI SSC bulletin dated 18 April 2022, and v6.2, announced in a bulletin dated 27 January 2023.

The standard and its derived test requirements are distributed through the PCI SSC document library under a licence agreement. The public pages make the model clear: a PCI recognised laboratory evaluates the device against the requirements, and PCI SSC reviews the report and lists the approved device.

How this compares with FIPS 140-3

NIST published FIPS 140-3 on 22 March 2019, superseding FIPS 140-2. It defines four increasing qualitative security levels, and its requirement areas include physical security, non invasive security, sensitive security parameter management, self tests and life cycle assurance. It is a different tool from PTS POI.

A terminal vendor can use a FIPS validated secure processor as a building block, but a FIPS certificate on its own does not make a device PCI approved, and the reverse is also true.

How do EMV contact and contactless kernels work?

EMVCo describes EMV Level 1 as the communication protocols between the card or phone and the acceptance device (the mechanical, electrical and radio frequency interfaces), and Level 2 as the software component, the "kernel", that holds the processing logic and data for an EMV contact or contactless transaction. On a terminal, the kernel is part of the firmware.

The contact flow in plain language

A chip transaction is a conversation between the kernel and the card's payment application. In outline:

1. Application selection. The terminal picks a payment application on the card that it supports.
2. Read data and authenticate. The kernel reads the card's records and, using payment system public keys loaded in the terminal, checks the card's signed data.
3. Cardholder verification. Card and terminal agree on a method: online PIN, offline PIN checked by the chip, a verification on the phone, a signature or none for small amounts.
4. Risk checks and cryptogram. The terminal applies its checks and asks the card for a cryptogram computed over the transaction with a key only the card and issuer know. A copy of the stripe or of static chip data cannot produce a valid cryptogram for a new transaction.
5. Authorisation and completion. The issuer verifies the cryptogram online and replies, and the kernel completes the transaction with the card.

EMVCo's contactless page says the same for taps: a one time security code is generated for every transaction.

Contactless kernels and Book C

Contactless differs in timing and in history. A tap has to finish in a fraction of a second, so the kernel does most work in a single short exchange while the card is in the field. Historically each global payment system defined its own contactless kernel. EMVCo publishes those individual specifications as the "Book C" series (Book C-2, Book C-3 and so on), and its contactless page listed Book C-2 and C-3 kernel specification documents dated July 2026 when we checked. EMVCo has also published Book C-8, the EMV Contactless Kernel, which can be licensed directly from EMVCo on the same terms as the EMV contact specifications. A terminal therefore carries a contact kernel plus one or more contactless kernels, and an entry point that decides which kernel handles a given card.

EMVCo's October 2025 explainer adds that the new contactless kernel can be approved as part of a full acceptance device or on its own, and that the kernel specification supports a "split architecture" in which processing happens in different places without changing the approval process.

What EMVCo certifies: Levels 1, 2 and 3

EMVCo's explainers stress two points. EMVCo does not test anything in house; recognised independent laboratories test with qualified tools. And EMVCo does not mandate its approvals, although other parties, such as payment systems, may require conformance.

Why terminals need recertification after changes

Every approval in this chain describes a specific configuration. The PCI listings disclaimer states that only the specific version or versions of a product identified on a list have been evaluated and found compliant. EMV kernel approvals likewise refer to a particular kernel build and configuration, and Level 3 certification covers a particular combination of terminal, kernel configuration and host.

So when a vendor changes something, the question is which evaluations the change touches:

• A new hardware revision of the secure area or the case reopens PTS physical testing.
• A new firmware version for the secure side needs PTS review, and since v6.0 PCI SSC has limited firmware approval timeframes to three years.
• A kernel code change or a new kernel configuration needs EMVCo Level 2 work, and often new Level 3 runs.
• A change to the application processor side, such as a new checkout app, may need only acquirer testing if it does not touch the secure side, which is exactly why the two sides are kept apart.

The exact rules for changes live in the PCI PTS Device Testing and Approval Program Guide and in EMVCo's process documents, and vendors plan releases around them.

How are keys injected, and why does the terminal never see the PIN in clear?

A brand new terminal has no payment keys. Getting them in safely is its own discipline, covered by several PCI standards.

The standards that govern keys

• PCI PIN Security covers the secure management, processing and transmission of PINs and their keys across the whole key life cycle: creation, conveyance, loading, usage and administration. Its audience is acquiring institutions and their agents, and it is assessed by Qualified PIN Assessors. It has no product listing.
• PCI PTS HSM covers the hardware security modules that sit at the processor and that are used to generate and load keys. PCI SSC notes that it supports validation of key loading devices (KLDs) and of remote administration platforms for HSMs.
• PCI Key Management and Operations (KMO) is a newer standard and programme for the secure management and operation of key management systems through the whole life cycle, from generation and conveyance to loading, use, archive, retirement and destruction. PCI SSC says its initial focus is keys used to secure PIN and P2PE data, including HSM as a service, and its listings page says listings are coming soon.
• PCI P2PE covers solutions that encrypt account data from the point of capture in the merchant's device to a secure decryption environment. PCI SSC notes that merchants using a listed P2PE solution have fewer applicable PCI DSS requirements.

Direct key injection

The classic method is direct injection in a secure room. A key loading device, itself a secure cryptographic device, connects to the terminal and loads an initial key. The process runs under dual control and split knowledge, so no single person ever holds a complete key, and every step is logged. Facilities that do this for other organisations are key injection facilities (KIFs). PCI SSC's P2PE FAQ lists the key injection facility service as a P2PE component that can be separately assessed and listed, and PIN Security covers key loading for acquirers and their agents. Merchants almost never do this themselves; it happens at the vendor, a distributor, the acquirer or a specialist service before the terminal ships.

Remote key loading

Shipping terminals back to a secure room every time keys change is slow and expensive, so modern terminals can receive keys remotely. The idea is that each terminal is given, at manufacture, an asymmetric key pair and a certificate signed by a trusted authority. Later, a host can authenticate the terminal by its certificate and send it a new symmetric key encrypted so that only that terminal's secure processor can unwrap it. No person ever sees the key, and the terminal never has to leave the shop. PCI PIN Security covers key conveyance and loading whichever method is used, and the P2PE programme lists certification and registration authorities as components that can be assessed and listed separately, alongside key injection facilities.

DUKPT: one key per transaction

Derived Unique Key Per Transaction (DUKPT) solves a different problem: how to avoid one long lived key protecting every PIN a terminal ever handles. X9, the accredited standards body for the US financial industry, publishes ANSI X9.24-3-2017, and its public test vector page explains that AES DUKPT derives transaction keys from an initial terminal DUKPT key based on the transaction number. The keys derived can be for encryption, authentication or HMAC, and AES DUKPT supports deriving AES-128, AES-192, AES-256 and double or triple length TDEA keys from AES-128, AES-192 or AES-256 initial keys.

In practice the terminal holds an initial key and a counter, never the base derivation key, which stays in the processor's HSM. The HSM works out each transaction key from the terminal identifier and counter that travel with the transaction, and one exposed transaction key does not reveal the others.

X9 also publishes Python reference code and test vectors for AES DUKPT, warning that the code is not a full implementation of the standard's requirements: test against the vectors, and still follow the whole standard.

Why the PIN is never in clear outside the secure area

Put the pieces together and you can trace a PIN:

1. The cardholder presses keys on a pad wired to the secure processor.
2. The secure processor builds a PIN block (the PIN formatted with other data) and encrypts it at once with the current PIN key.
3. The encrypted block crosses the application processor and the network as opaque bytes.
4. At the processor, an HSM translates or verifies it inside its own secure boundary.

For offline PIN the terminal sends the PIN to the card through the same protected path. Either way, the clear PIN exists only inside certified secure boundaries.

How is terminal firmware signed and updated?

The secure boot chain

A terminal boots like most secure embedded systems. Immutable code in the secure processor's ROM verifies the signature on the next stage with a public key whose hash is fused or stored in protected memory. Each stage verifies the next, up to the secure operating system and the PIN handling code. If a signature fails, the device refuses to run the image. PTS POI v7.0 requires that terminal security keys, including firmware authentication keys, use cryptography with an effective key strength of at least 128 bits.

Updates follow the same rule. The vendor signs the package with keys typically held in an HSM; the terminal downloads it from a terminal management system, checks the signature inside the secure processor and installs it only if it verifies. Many designs also refuse to roll back to an older signed version.

The split between the secure OS and payment apps

On the application side, the picture has changed a lot. Older terminals ran only the vendor's software. Modern smart terminals run a rich OS on the application processor and host apps from acquirers, independent software vendors and, under PTS POI v7.0, potentially third party app stores. The security model depends on keeping the split clean:

An app on the application processor should never be able to request a clear PIN, draw a PIN entry screen or read raw card data. It asks the secure side to run a payment and receives a result and an encrypted payload, and the secure side controls which numeric prompts apps may show.

Terminal management systems

Terminals in the field are managed from a terminal management system that holds the fleet inventory, pushes signed firmware and app packages, collects logs and reports tamper states. It is how you know which firmware every device runs and whether any device has reported a tamper event, and because it can push software to every lane, it deserves strong authentication, restricted network access and change control.

What does the PCI approved PTS device list record?

The PCI approved PTS devices list is a public, searchable database of devices that passed PTS evaluation. Before you can search it, PCI SSC shows a notice that sets out its limits: only the specific version or versions of a product identified on the list were evaluated; compliance is determined solely by the assessor or laboratory; and PCI SSC reviews the reports for quality assurance but does not test the products itself.

Each entry identifies an approved device and the specific versions that were evaluated, with its approval details and the expiry date that follows from the version of PTS POI it was tested against. PCI SSC's FAQs point merchants to these expiry dates, and its bulletins say vendors with active listings are notified when expiry timelines change. The exact fields shown can change as PCI SSC updates the listing site, so read the entry itself rather than relying on a summary. Match a device in your shop to its entry using the identifiers on its status screen.

Approval expiry and what it means for merchants

Every major version of the PTS POI requirements has a date after which new approvals are no longer granted and a later date when existing approvals expire. PCI SSC has moved those dates several times in recent years, and the bulletins are the authoritative record:

PCI SSC's 2025 bulletin on v5 devices gives the reasons for the extension: limited technician availability, constrained hardware supply and complex upgrade timelines, especially in embedded, unattended and multi component environments. It also says the Council does not believe the time bound extension materially increases risk, while acknowledging that earlier versions may offer lower resistance to some emerging attack vectors, and it strongly encourages migration to v6 or later.

What does expiry mean for a merchant? PCI SSC's FAQ is precise: whether buying and using a device beyond its approval expiry date is acceptable is decided by the individual payment brands, and merchants should ask their acquirer or the brands. Separate FAQs cover expired devices and SAQ B-IP eligibility, and expiry within PCI listed P2PE solutions. Expiry does not switch a device off, but it can change your compliance position, so plan replacements against the dates above.

Countertop terminal, mobile card reader or PIN on a phone?

Phones are now payment terminals in their own right, and PCI SSC has built a family of standards for them. The table compares the three main categories by certification path and attack surface. It describes categories only.

PCI SSC describes SPoC as solutions that capture and encrypt a cardholder's PIN with a PIN verification application on a merchant's commercial phone or tablet, used with an SCRP or a non PTS approved stripe reader, and relying on device hardware, application software and remote attestation and monitoring. CPoC covers accepting contactless payments with the phone's own NFC, without an external reader. MPoC builds on both, combining PIN and contactless entry on the same device in a modular, objective based standard. PCI SSC's bulletin of 1 May 2026 opened a sunset period for SPoC and CPoC that ends on 31 October 2026. After that date no new submissions are accepted, while existing listings stay valid through their normal lifecycle and expire on their existing dates.

In short, a dedicated terminal puts the risk in hardware that is expensive to attack and slow to change, while a phone solution puts it in software and monitoring that is cheaper to deploy but depends on an operating system the solution provider does not control.

Step by step: track terminal approvals and firmware like a software dependency

Treat the terminal fleet as an inventory with versions and expiry dates, the way you treat open source dependencies. This walkthrough uses plain files and a short script, so it works with any terminal management system export.

1. Record each terminal

Start a CSV with one row per device. Take the identifiers from the terminal's status screen or your terminal management system export, and the approval details from the PCI listing for that exact hardware and firmware.

serial,location,lane,model,hw_version,fw_version,app_version,pts_approval,pts_version,approval_expiry,last_inspected,photo_ref
SN10023,store-014,1,countertop-a,HW-2.1,FW-6.4.2,APP-3.8.0,4-XXXXX,v6,2032-04-30,2026-10-20,photos/014-1.jpg
SN10024,store-014,2,countertop-a,HW-2.1,FW-6.4.1,APP-3.8.0,4-XXXXX,v6,2032-04-30,2026-10-20,photos/014-2.jpg
SN20877,store-022,7,unattended-b,HW-1.0,FW-5.9.0,APP-2.2.4,4-YYYYY,v5,2027-04-30,2026-09-02,photos/022-7.jpg

The approval numbers above are placeholders. Copy real ones from the listing.

2. Write down what "approved" means for your fleet

Keep a small policy file that lists the firmware versions your acquirer or vendor supports for each model, and how much notice you want before expiry.

# terminal-policy.yaml
warn_months_before_expiry: 12
inspection_max_age_days: 30
models:
  countertop-a:
    allowed_fw: ["FW-6.4.2"]
  unattended-b:
    allowed_fw: ["FW-5.9.0", "FW-5.9.1"]

3. Check the inventory against the policy

This script reads both files and prints anything that needs attention: approvals expiring soon, firmware that is not on the allowed list, and inspections that are overdue. It uses only the Python standard library plus PyYAML.

#!/usr/bin/env python3
"""Flag terminals with expiring PTS approvals, unexpected firmware or stale inspections."""
import csv
import sys
from datetime import date, datetime, timedelta

import yaml  # pip install pyyaml

def months_between(today, later):
    return (later.year - today.year) * 12 + (later.month - today.month)

def main(inventory_path, policy_path):
    policy = yaml.safe_load(open(policy_path))
    today = date.today()
    problems = 0
    with open(inventory_path, newline="") as f:
        for row in csv.DictReader(f):
            tag = f"{row['serial']} ({row['location']} lane {row['lane']})"
            expiry = datetime.strptime(row["approval_expiry"], "%Y-%m-%d").date()
            left = months_between(today, expiry)
            if left < 0:
                print(f"EXPIRED  {tag}: PTS {row['pts_version']} approval expired {expiry}; ask your acquirer")
                problems += 1
            elif left <= policy["warn_months_before_expiry"]:
                print(f"EXPIRING {tag}: approval expires {expiry} ({left} months); plan replacement")
                problems += 1
            model = policy["models"].get(row["model"])
            if model is None:
                print(f"UNKNOWN  {tag}: model {row['model']} not in policy")
                problems += 1
            elif row["fw_version"] not in model["allowed_fw"]:
                print(f"FIRMWARE {tag}: {row['fw_version']} not in allowed list {model['allowed_fw']}")
                problems += 1
            inspected = datetime.strptime(row["last_inspected"], "%Y-%m-%d").date()
            if today - inspected > timedelta(days=policy["inspection_max_age_days"]):
                print(f"INSPECT  {tag}: last inspected {inspected}")
                problems += 1
    print(f"{problems} item(s) need attention")
    return 1 if problems else 0

if __name__ == "__main__":
    sys.exit(main(sys.argv[1], sys.argv[2]))

Run it:

python3 -m venv .venv && . .venv/bin/activate
pip install pyyaml
python3 check_terminals.py terminals.csv terminal-policy.yaml

With the sample data above and a run date of 24 October 2026, the second row is flagged for firmware FW-6.4.1 and the third row is flagged because its v5 approval expires on 30 April 2027, inside the twelve month warning window.

4. Run it on a schedule

Put the inventory and policy in a private repository and run the check weekly in CI, so the warning arrives long before an assessor asks.

# .github/workflows/terminal-fleet.yml
name: terminal-fleet-check
on:
  schedule:
    - cron: "0 7 * * 1"
  workflow_dispatch:
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install pyyaml
      - run: python3 check_terminals.py terminals.csv terminal-policy.yaml

Keep this repository private: a map of every terminal in every store is not something to publish.

5. Verify update packages you handle

If your team receives terminal packages or payment app builds from a vendor and stages them for your terminal management system, verify the vendor's detached signature before upload, using the public key and algorithm the vendor documents. With an ECDSA or RSA key and a SHA-256 digest, OpenSSL does it in one line:

openssl dgst -sha256 -verify vendor-signing-public.pem -signature package.sig package.bin
# Expected output: Verified OK

The terminal checks the signature again inside its secure processor, which is the check that counts; checking first keeps a wrong package out of your management system and leaves a record of what you staged.

A practical checklist for merchants

These steps are defensive and aimed at people who run shops, restaurants and unattended kiosks.

Before you buy or accept a device

1. Look up the exact model, hardware version and firmware version on the PCI approved PTS devices list, and note the approval expiry date.
2. Ask your acquirer which devices and firmware versions it supports, and whether it accepts devices past their approval expiry.
3. If you use a P2PE solution, confirm the device is part of the listed solution, because P2PE listings name specific devices.
4. Buy from the vendor, your acquirer or an authorised reseller, and refuse devices that arrive with damaged packaging or broken tamper evident seals.

When devices arrive

5. Record the serial number, model, versions and a clear photo of each device from several angles, including the card slot, keypad and underside.
6. Check the device shows no tamper message on power up and that its status screen matches the paperwork.

Every day or every shift

7. Compare each device with its photo. Look for overlays on the keypad, anything inserted or attached at the card slot, extra cables, labels that cover screws, or changes in how the device sits on its stand.
8. Check the serial number on the device matches your inventory, because swapping a whole terminal for a look alike is a known substitution trick.
9. Train staff to verify the identity of anyone who arrives to "service" or "replace" a terminal, and to call the known support number, not a number the visitor provides.

Over the device's life

10. Keep firmware current through your terminal management system and record the installed versions.
11. Review tamper alerts and unexplained reboots in the management system, and pull any device that reports a tamper state.
12. Plan replacements a year or more before approval expiry.
13. At end of life, return devices through the vendor or acquirer process so keys are destroyed and the device does not end up resold with your merchant configuration.

Use PCI SSC's skimming prevention guidance for merchants (updated in 2014) and your acquirer's inspection guide alongside this list.

Common mistakes

• Assuming "PCI compliant" is a property of the terminal alone. PTS approval covers the device. Your PCI DSS obligations cover how you deploy, inspect and manage it, and your acquirer may have extra rules.
• Matching the model but not the versions. A listing applies to specific hardware and firmware versions. A model name match is not enough.
• Ignoring expiry until an assessment. Approval expiry dates are public years in advance. Treat them like end of life dates for an operating system.
• Letting third party apps near PIN entry. If an app on the application processor can show a numeric keypad that looks like a PIN prompt, you have a design problem, whatever the certificates say.
• Skipping inspections because devices are "tamper proof". Tamper response protects the inside of the device. Overlays and look alike substitutes attack the outside and the process around it.
• Treating phone acceptance like a terminal. Tap to phone and PIN on glass solutions rely on the phone OS, attestation and monitoring. Keep phones updated, avoid rooted or jailbroken devices and follow the solution provider's rules.

FAQ

How do I check if my card terminal is PCI approved?

Take the model and the hardware and firmware versions from the device's status screen or your terminal management system and search the PCI approved PTS devices list. The versions must match, not just the model.

What happens when a PTS POI approval expires?

The device keeps working, but PCI SSC says the payment brands decide whether it may still be bought or used, so ask your acquirer. Under current bulletins, v5 approvals expire on 30 April 2027 and v6 approvals in April 2032.

What is the current version of PCI PTS POI?

Version 7.0 of the PTS POI Modular Security Requirements, published on 29 May 2025. New approvals under v6 were accepted until 30 June 2026.

What is the difference between EMV Level 1, Level 2 and Level 3?

Level 1 tests the physical and radio interfaces between card and terminal. Level 2 tests the kernel software that runs EMV transactions. Level 3 is each payment system's end to end test of the terminal integrated with an acquirer or processor host. EMVCo defines the Level 1 and 2 processes and the Level 3 testing framework, and independent recognised labs perform the testing.

What does a payment terminal do when someone opens it?

Sensors such as conductive meshes and case switches trigger a battery backed monitor that erases the secret keys, even when the device is off. The device then shows a tamper state and must go back for inspection and new keys.

What is DUKPT and why do terminals use it?

DUKPT, Derived Unique Key Per Transaction, is defined in ANSI X9.24-3 for AES. It derives a different key for every transaction from an initial terminal key and a transaction counter, so one exposed transaction key does not expose the others, and the terminal never holds the base key used at the processor.

Can a smartphone be used as a card terminal securely?

Yes, under PCI standards for commercial phones: CPoC for contactless, SPoC for PIN entry and MPoC for both. SPoC and CPoC are in a sunset period ending 31 October 2026. Security there rests on software protection, attestation and monitoring rather than a tamper responsive enclosure.

Does an EMV chip stop card skimming?

It stops cloned cards from producing valid chip transactions, because each chip transaction includes a cryptogram computed with a key that never leaves the card. It does not stop someone capturing stripe data or watching PIN entry, which is why encrypted readers, PIN privacy, inspections and issuer checks still matter.

Where Safeguard fits, honestly

Safeguard does not certify payment terminals, test tamper response, scan terminal firmware images, manage devices or generate hardware bills of materials, and it is not a PCI assessor or laboratory. Nothing in this post should be read as Safeguard making a terminal or a merchant compliant.

The overlap is the software around the terminal. Checkout apps, acquirer integrations, payment apps written for smart terminals, terminal management dashboards and the back end services that receive encrypted transactions are code your teams build with open source dependencies. If that code lives in repositories or container images, Safeguard can scan it (for example safeguard scan --dir . on a checkout or safeguard scan --image followed by an image name), match components against vulnerability databases, rank findings with reachability analysis, evaluate policies and gates, and open fix pull requests when you switch autonomous remediation on. It complements the PCI and EMV work above; it does not replace any of it.

Fix it without waiting for upstream

A terminal's hardware is certified once, but the software around it changes every week: payment apps on smart terminals, POS integrations and terminal management back ends all pull open source dependencies on every build. Keeping those dependencies current is ordinary supply chain hygiene, and it matters as much at the till as it does in a web service.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session asked to fix a lodash CVE: it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow fits a JavaScript checkout front end or a payment app web view that your team maintains for smart terminals.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Payment teams that prefer to keep source code for POS integrations inside their own network can scan locally in the same way.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. A team asking an assistant about its terminal management or checkout services can limit it to the read and scan tools it needs.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• PCI SSC, Standards overview
• PCI SSC, PTS Point of Interaction (POI)
• PCI SSC, PTS Hardware Security Module (HSM)
• PCI SSC, PIN Security
• PCI SSC, Key Management and Operations (KMO)
• PCI SSC, Point-to-Point Encryption (P2PE)
• PCI SSC, Mobile Payments on COTS (MPoC)
• PCI SSC, Software-based PIN Entry on COTS (SPoC)
• PCI SSC, Contactless Payments on COTS (CPoC)
• PCI SSC, Approved PTS Devices listing and notice
• PCI SSC blog, Just Published: PTS POI v7.0 (29 May 2025)
• PCI SSC press release, Updates Standard for Device Security, PTS POI v6.0 (16 June 2020)
• PCI SSC bulletin, PTS POI Modular Security Requirements v6.1 Published
• PCI SSC bulletin, PTS POI Modular Security Requirements v6.2 Published
• PCI SSC bulletin, Extension of Expiration of the PCI PTS POI v6 Security Requirements (3 April 2024, PDF)
• PCI SSC bulletin, Extension of Expiration of the PCI PTS POI v6 Security Requirements and Approvals (17 June 2025, PDF)
• PCI SSC bulletin, Extension of Expiration of PCI PTS POI v5 Devices (11 September 2025, PDF)
• PCI SSC bulletin, Announcement of Sunset Periods for the PCI SPoC and PCI CPoC Standards (1 May 2026, PDF)
• PCI SSC FAQ, What are the expiry dates for PTS POI device approvals?
• PCI SSC FAQ, Does the use of expired PTS POI devices meet eligibility criteria for SAQ B-IP?
• PCI SSC FAQ, How do PCI PTS-approved POI device expiry dates affect a PCI-listed P2PE solution?
• PCI SSC FAQ, What is a P2PE component?
• PCI SSC blog, New Terminal Software Module in PCI Secure Software Standard v1.1 (29 April 2021)
• PCI SSC press release, Merchant guidance on skimming prevention (10 September 2014)
• EMVCo, EMV Technologies
• EMVCo, EMV Contact Chip
• EMVCo, EMV Contactless Chip
• EMVCo, EMV Level 3 Testing
• EMVCo, Product approval processes for acceptance devices
• EMVCo, What are EMV Level 1 and Level 2 Testing? (15 October 2025)
• EMVCo, What are EMVCo Approvals and Evaluations? (15 October 2025)
• NIST, FIPS 140-3, Security Requirements for Cryptographic Modules (22 March 2019)
• X9, X9.24 Part 3 Test Vectors for ANSI X9.24-3-2017 AES DUKPT

Last reviewed: 24 October 2026.