POS terminal tampering — physical and firmware attack surface

1. Mechanism

A PCI PTS POI terminal protects its key store and cryptographic processor inside a tamper-resistant envelope [2]. The envelope is instrumented with mesh wires, switches, and sensors; on detected tamper, the device zeroizes its key store before the attacker can read it. The protections cover the device against:

• Physical penetration. Drilling, shimming, side-channel probes, cold-boot attacks. The mesh detects the breach; the switch trips; keys zeroize.
• Firmware flash. Replacing the firmware image with one containing a backdoor. The boot chain refuses to run an unsigned image; rollback counters refuse a downgrade.

PCI PTS specifies the floor for both. EMVCo Level 1 type approval [3] specifies the contact / contactless interface compliance. The two together are the certification regime for a fixed-function terminal.

The attack class is what happens when one of the protections does not perform as specified — a tamper switch fails to detect a specific penetration geometry, a signed-boot implementation has a bypass, the rollback counter is incorrectly enforced.

2. Where in the runtime it operates

Two surfaces:

• The mechanical envelope — switches, mesh wires, conformal coatings. Detection is electrical: a continuity break trips the zeroize logic.
• The firmware boot chain — bootrom signature verification, staged boot images, rollback counters in fuses or in the secure processor’s NVRAM.

Each surface has its own audit path. PCI PTS labs perform penetration testing under the modular requirements [2]; the attacks the labs catch are the attacks the field will eventually see.

3. Which checkpoints it bypasses

• PIN confidentiality and message integrity. The terminal’s Secure Cryptographic Processor holds acquirer-side keys — PIN-encryption keys (DUKPT-derived), message MAC keys, and SRED data-encryption keys. A successful tamper that recovers these keys lets an attacker derive future session keys (PIN encryption is DUKPT-based, so prior session keys are forward-secure under the BDK-derived key tree — extraction of the current key state lets the attacker derive forward-from-now session keys, not arbitrary historical sessions), forge MACs on acquirer-bound messages, or decrypt SRED-protected card data. ARQC generation is not in this surface: ARQCs are produced by the card using the card’s IMK-AC, derived from the issuer master key — keys the terminal never holds.
• Scheme terminal certification. Compromised firmware that passes the boot chain looks compliant from outside; the attestation chain (where the terminal supports it) is the layer that surfaces the discrepancy.

Tampering does not bypass device-side checkpoints in the way mobile attacks do — there is no Play Integrity equivalent on a PCI-PTS terminal. The certification regime is the checkpoint; the attacks live in the gap between specification and implementation.

4. Which signals make it observable

device.integrity. PCI PTS POI does not standardise a remote attestation channel; on terminals that do expose one (vendor SDK, OEM extension, or a TPM where present), the substrate observes:

• The current state of the tamper-switch logic (still armed, tripped, in service mode).
• The firmware version and the signed-boot chain measurement (TPM PCR values where the platform includes a TPM; the vendor’s measured-boot register otherwise — neither is prescribed by PCI PTS).
• The rollback counter compared to the firmware version’s expected counter.

The signals compose with EMV-rail evidence: a transaction whose card-issued ARQC validates but whose terminal-side evidence shows a tripped tamper-switch or a stale firmware version tells the operator something neither layer alone would.

5. Evidence Token shape when observed

The following example is illustrative; field names, type values, and schema are defined in YEI-001 §4 (available through the spec-access process).

{
  "ev": [{
    "ts":   "2026-06-15T10:23:14Z",
    "class": "device.integrity",
    "type":  "terminal.tamper_state",
    "data": {
      "envelope":               "armed",
      "firmware_version":       "5.7.2",
      "boot_signed":            true,
      "rollback_counter":       12,
      "pci_pts_poi_version":    "v6.1"
    }
  }]
}

The substrate emits the state at every transaction. Operators correlate against expected fleet versions; drift surfaces.

6. Cross-references

• Sibling articles: os-downgrade-attacks, mpos-side-loaded-apps, attestation-drift-distributed-fleets
• Theme 2: emv-and-emv-3ds, hardware-attestation
• Site: /pos — POS deployment surface

7. External references

[1] PCI Security Standards Council. PCI PIN Transaction Security (PTS) POI documents library. www.pcisecuritystandards.org/document_library/?category=ptsdoc. Cited 2026-02-16.

[2] PCI Security Standards Council. PCI PTS POI Modular Security Requirements v6.1 (September 2021). www.pcisecuritystandards.org/document_library/?category=ptsdoc. Cited 2026-02-16. (Operators should verify the latest published PTS POI version against the PCI document library at the time of citation.)

[3] EMVCo. Level 1 Type Approval — Contact and Contactless Terminal. www.emvco.com/approvals-certification/. Cited 2026-02-16.