Blind Spots on the Edge: Why the IoT SIM Is Payment Security’s Missing Witness
The industry spent twenty years fortifying the middle of the network. Attackers, being sensible people, walked round to the edge, where the patch cycles are glacial and nobody is watching. Distributed payment estates are now the softest target in finance, and the one telemetry layer that can see through a fully compromised terminal is the one most operators still treat as invisible plumbing: the cellular SIM.
The soft perimeter moved, and payments got left behind
Security architecture has spent two decades hardening the centre. Firewalls, web application firewalls and SIEM stacks were wrapped around the data centre and the cloud tenancy until the middle of the network became genuinely difficult to breach. Attackers responded the way water responds to a wall: they went round the side. The edge of the estate, where visibility is thinnest and patch cycles are slowest, became the path of least resistance.
Distributed payment infrastructure sits squarely in that blind spot. ATMs, self-service kiosks, unattended POS terminals, fuel pumps and mobile card readers are numerous, physically accessible, rarely patched and comfortably ignored by security programmes that still think of “the estate” as a rack in a building somewhere. They blend into the background noise of everyday traffic, and that is exactly the point.
The numbers make the scale hard to wave away. In a February 2026 FLASH alert, the FBI reported that it has tracked roughly 1,900 ATM “jackpotting” incidents in the United States since 2020, with more than 700 of those, over a third of the entire six-year total, landing in 2025 alone and accounting for losses in excess of twenty million dollars. Jackpotting is the crime where criminals use physical access and malware, commonly the long-running Ploutus strain, to issue commands directly to the ATM’s cash-dispensing layer and walk away with the money. No card, no PIN, no customer account, no bank authorisation. The US Department of Justice underlined the organised nature of it in December 2025 with indictments charging dozens of people in a single conspiracy.
That acceleration is not a coincidence. It reflects a broader shift in attacker strategy toward the unglamorous, overlooked layer of infrastructure that most programmes still treat as an afterthought: the edge device and the connectivity underneath it.
The playbook is already proven: Volt Typhoon and the edge-device beachhead
If you want a preview of how a patient, well-resourced adversary treats overlooked edge hardware, look at Volt Typhoon. Microsoft and the Five Eyes intelligence agencies disclosed the Chinese state-sponsored group in 2023, and the tradecraft was instructive precisely because it was so quiet. The group proxied almost all of its traffic through compromised small office and home office routers, deliberately avoiding custom malware where it could in favour of “living off the land” techniques that blend into legitimate administrative activity. The botnet was built on end-of-life kit that vendors no longer patch: Cisco RV320/325 routers, Netgear ProSAFE firewalls, DrayTek Vigor routers and Axis IP cameras.
A US-led operation disrupted the botnet in January 2024. It did not stay disrupted. Researchers at SecurityScorecard’s STRIKE team documented the group rebuilding within months, and the figure that ought to make every estate owner uncomfortable is this: in a single 37-day window, Volt Typhoon compromised roughly 30 percent of the internet-exposed Cisco RV320/325 devices the researchers could see. The devices were end-of-life, no patches were coming, and that was the whole attraction.
The lesson generalises directly to payments. Retail and payment analysts expect longer-dwelling, more targeted campaigns against POS estates rather than smash-and-grab data theft, aimed at memory-scraping malware, payment-gateway compromise and fraudulent tokenisation. The retail sector is attractive precisely because it processes real-time payment data across a large number of endpoints, many running outdated software on networks that mix payment traffic with office IT. Distributed, unattended and physically accessible payment terminals are the 2026 equivalent of Volt Typhoon’s forgotten SOHO routers: quiet, numerous, and very easy to lose track of.
The blind spot: a compromised device cannot witness its own compromise
Most payment security programmes still lean on device-layer controls. Endpoint agents, application allowlisting, host intrusion detection and behavioural analytics all run on the terminal’s own operating system. These tools work well against unsophisticated malware, but they share one structural weakness that no amount of tuning fixes: they depend on the integrity of the very device they are trying to protect.
Jackpotting is the clean illustration. The FBI’s own description is that the malware interacts directly with the ATM hardware, bypassing the communications and security of the original ATM software, and works across machines from different manufacturers with little adjustment because the underlying Windows operating system is what gets exploited. Once an attacker has that level of control, the local logs and agents become unreliable witnesses. A compromised device can suppress its own alerts, falsify its own telemetry, or simply go dark at exactly the moment it matters. You are asking the suspect to file the incident report.
Network design compounds the problem. Guidance for retailers keeps flagging the same root causes year after year: POS systems sharing a segment with office computers, unencrypted internal communications, and stale software. When a terminal talks over standard broadband or Wi-Fi, a compromised router, the same category of device Volt Typhoon feasts on, can sit on the local network for months, masking malicious traffic inside what looks like ordinary background chatter. In that model the network itself becomes complicit in hiding the attack, because the terminal, the router and the local monitoring stack are all potentially under the same attacker’s control. There is no independent witness anywhere on the path.
The cellular turn: the SIM as a tamper-resistant network witness
This is the gap that cellular-connected payment infrastructure closes, and it does so through a property that is easy to overlook. When a POS terminal, kiosk or ATM connects via an IoT SIM, eSIM or iSIM rather than local broadband, its traffic never touches the merchant’s potentially compromised LAN at all. The device registers directly with a mobile network operator’s core, and that core keeps its own record of every session: connection time, data volume, the cell-tower handshake, the destination it reached.
The crucial part is where that record lives. It exists entirely outside the device’s own operating system. An attacker who fully owns the terminal, the way a jackpotting crew owns an ATM once they have swapped its hard drive, still cannot reach into the mobile core and edit, suppress or forge what the network has already logged. The witness lives off the device.
Payment-focused connectivity providers have built commercial products around exactly this property. Purpose-built ePOS SIMs deliver encrypted communications for PCI DSS scope, multi-network access to reduce blackspots, and secure cloud connectivity for remote terminal management. Global M2M platforms serving payment processors go further, routing terminal traffic through PCI-certified private networks rather than the public internet, and using SIM logic that detects a degraded connection and switches operator automatically to preserve uptime. Multi-network retail SIM providers report supporting POS, self-service kiosks, digital signage and store security systems under a single connectivity platform with roaming agreements spanning hundreds of operators. None of it depends on the terminal’s local software being trustworthy, because the network layer keeps its own record regardless of what happens on the device.
A necessary reality check: what the SIM layer actually catches
Here is where a lot of vendor copy overreaches, and where it is worth being precise, because a cornerstone argument built on an exaggeration falls over the first time a sceptical engineer reads it. The cellular network does not watch the cash leave the ATM. In a classic jackpotting attack the criminal often disconnects the machine from the network entirely, or simply does not care about it, because the malware dispenses locally without ever contacting the bank. If your pitch is “the SIM would have seen the cash-out,” the pitch is wrong.
What the SIM layer actually provides is different, and arguably more useful: an out-of-band signal that a compromised or tampered terminal cannot suppress. A machine that suddenly drops off the network when it should be online. A device whose cell-tower handshake changes because it has been physically moved. A SIM that reappears in hardware it was never assigned to. A data-volume pattern that spikes or flatlines against a well-established baseline. The attacker controls the terminal’s operating system; they do not control whether the mobile core notices the terminal has gone quiet, relocated, or started behaving unlike its own history. That is the honest value proposition, and it is a strong one. It turns a silent event into an alertable one.
How the industry is responding on three fronts
For years payment operators treated SIM cards as commodity connectivity: a dumb pipe to move data from terminal to processor, with no thought given to what the SIM’s own network relationship might reveal about the device’s health. That posture is changing on three fronts at once.
Private APNs and dedicated tunnels
Rather than letting terminals reach the open internet, operators increasingly route traffic through private Access Point Names into encrypted tunnels that terminate directly at the acquirer’s data centre. Providers market this explicitly as a security and compliance feature: private, PCI-certified networks that keep payment traffic off the public internet entirely, with direct routing to a merchant’s own data centre or cloud over IPSec or leased lines. This does more than add encryption. It removes an entire class of internet-facing attack surface, because a terminal on a private APN is never reachable from the open internet in the first place. There is simply no public interface for an attacker to find.
IMEI locking and hardware-bound SIM profiles
IoT SIM management platforms now widely support binding a SIM to a specific device’s IMEI, so the SIM only functions in its assigned hardware. Pull a SIM out of a tampered terminal and drop it into a rogue device, and the platform sees the IMEI mismatch instantly, can alert the operator in real time, and can terminate or reissue the SIM automatically. This targets a well-documented category of IoT SIM fraud, cloning and swap fraud, where a displaced SIM is repurposed for unauthorised use. Retail-focused connectivity vendors package it as a core control specifically to manage SIM fraud at scale across large fleets. In the payments context it is the mechanism that converts physical SIM theft from a silent event into an immediate, actionable alert.
Multi-network failover with security-aware switching
Providers serving POS and ATM fleets increasingly combine resilience with security logic, switching to the next-best operator not only on signal loss but when a problem is detected on the current network path. That reduces both downtime and the window an attacker has to exploit a degraded or manipulated connection. It matters operationally too, because single-carrier dependency and limited network visibility are repeatedly cited as leading causes of payment interruption. Connectivity resilience and security visibility are increasingly the same engineering problem, not two separate ones owned by two separate teams.
| Traditional gap | SIM / network-layer countermeasure | What it achieves |
|---|---|---|
| Compromised OS suppresses local logs | Out-of-band mobile-core telemetry: session, data volume, cell handshake | An independent record survives full device compromise |
| Terminal traffic mixed onto the public internet | Private APN with an encrypted tunnel to the acquirer | Removes public-internet exposure entirely |
| Stolen SIM reused in rogue hardware | IMEI-to-SIM hardware lock with instant mismatch alerting | Detects and blocks physical SIM theft or swap in real time |
| Single-carrier outage or manipulated link | Multi-network failover triggered by anomaly, not just signal loss | Preserves both uptime and a clean connectivity path |
| Legacy SOHO router as the attacker’s beachhead | Bypassing the local LAN and router via direct cellular core registration | Removes the exact device class Volt Typhoon-style actors exploit |
Real-world momentum: SGP.32 lands in the payment estate
The shift is not theoretical, and 2026 has already produced the marquee examples. In March 2026 the Brazilian payment processor Cielo, one of the country’s largest, began piloting a move from manual, on-site SIM management to fully remote eSIM connectivity management across its nationwide POS fleet, built on the GSMA’s SGP.32 IoT remote SIM provisioning standard, in partnership with Thales. Cielo can now switch mobile network operators over the air in seconds without dispatching a technician, in what is described as one of the first large-scale SGP.32 deployments in the POS sector in Brazil.
Days later, Verifone announced a parallel initiative, also with Thales, to strip removable SIM cards and country-specific hardware variants out of its next-generation terminals, provisioning and managing connectivity profiles over the air across the device lifecycle instead. For an OEM, that collapses a supply-chain headache: no more stocking the right SIM per market, no more juggling operator relationships country by country, no more separate hardware SKUs to satisfy local connectivity rules. Industry commentary on the Verifone deal is careful to note why SGP.32 specifically matters here. It targets scalable, interoperable remote provisioning for IoT use cases, a meaningful evolution beyond the earlier eUICC approaches that were designed primarily for consumer handsets.
That distinction is worth a table of its own, because “eSIM” gets used as a single word for three genuinely different provisioning models, and the differences are the whole story for anyone running a payment fleet.
| Standard | Designed for | Who drives provisioning | Fit for distributed payment estates |
|---|---|---|---|
| SGP.02 | Early M2M | Operator, via the SM-SR | Works, but tied to operator-controlled infrastructure and awkward at fleet scale |
| SGP.22 | Consumer devices | The device itself, via an on-device LPA and user interaction | Assumes a screen and a human; poor fit for headless, unattended terminals |
| SGP.32 | IoT and headless fleets | Cloud-orchestrated, via the eIM, with a lightweight IPA on the device | Built for exactly this: remote, screen-free, centrally auditable at scale |
The practical upshot is that SGP.32 replaces manual, on-site SIM swaps with centrally auditable, remotely provisioned connectivity profiles. That reduces operational risk, and it removes the physical attack surface that removable SIM cards represent in a device sitting unattended in a public place. If you want the full mechanics of how the eIM orchestrates profiles and how it differs from the consumer model, we have covered the standard in depth on our sister sites, linked in the related reading below.
5G, edge computing and the compliance vice
The move toward 5G and edge computing in payments cuts both ways. Ultra-low latency and localised processing unlock real-time use cases such as biometric authentication at kiosks and instant mobile checkout, but they also multiply the number of distributed nodes handling sensitive data before it reaches centralised systems. The attack surface expands even as visibility per node shrinks. Analysts flag misconfigured 5G network slicing as a particular concern, since a compromised or poorly isolated slice can let an attacker move laterally into payment traffic running on a different, supposedly separated, slice.
Compliance is tightening in the same direction rather than relaxing, and it is worth being precise about what has changed, because this is an area where loose summaries do real damage. PCI DSS 4.0.1’s new client-side controls, requirements 6.4.3 and 11.6.1, became mandatory on 31 March 2025 and are fully in force for every assessment in 2026. They require merchants to inventory and authorise every script that runs on a payment page and to deploy tamper detection that alerts on unauthorised changes to those pages and their security headers. Those requirements specifically target browser-based e-skimming of the Magecart variety; they are about the checkout web page, not about the cellular link to a physical terminal, and anyone telling you otherwise has not read them.
The relevant point for physical estates is separate and, if anything, blunter. The PCI Security Standards Council states plainly that payment terminals are part of the cardholder data environment and in scope for PCI DSS because they store, process or transmit account data, and that a PTS-approved device does not by itself guarantee compliance or reduce the scope of the merchant’s cardholder data environment. Secure hardware is necessary and not sufficient. Scope inevitably includes the connectivity layer carrying account data off the device, which is exactly the layer this piece is about. The regulatory direction of travel, pushing continuous monitoring outward to every point where data moves, is the same direction the connectivity argument points.
The blueprint: building a zero-trust edge for payments
Closing the visibility gap means treating cellular connectivity intelligence and payment security as one discipline, not two silos owned by different teams who meet twice a year. The practical steps are not exotic.
- Feed SIM telemetry into the SIEM, not a connectivity dashboard. IMEI-SIM binding status, location and cell-handshake changes, session anomalies and data-volume spikes from the IoT SIM management platform should flow into the same tooling used for endpoint and network detection, correlated into a single risk view rather than stranded in a portal nobody in the SOC logs into.
- Make hardware-bound SIM identity standard, not optional. IMEI locking across ATM, kiosk and POS fleets, with automated alerting and bulk enrolment so large estates can be locked down without per-device manual work, converts SIM theft or terminal tampering from a silent event into an immediate alert.
- Route payment traffic through private APNs by default. Removing public-internet exposure by default, rather than relying on device-level firewalling alone, closes the exact pathway that legacy SOHO-router attacks depend on. There is no publicly reachable interface for an attacker to find.
- Build failover policy around security state, not just signal strength. A severed primary broadband link is a common physical-tampering precursor. Automated failover should trigger stricter access and firewall policy in that event, not simply fall back to a cellular link running the same permissive rules.
- Align with SGP.32 remote provisioning. The shift already piloted by Cielo and Verifone replaces manual on-site SIM swaps with centrally auditable, remotely provisioned profiles, cutting both operational risk and the physical attack surface of removable SIMs.
- Treat zero trust as continuous, not perimeter-based. Continuous verification of device identity, connection behaviour and micro-segmented access should extend to every payment terminal, with IoT and OT given the same scrutiny as user endpoints rather than a polite exemption.
Sources and further reading. ATM jackpotting figures are from the FBI’s February 2026 FLASH alert, reported by The Record (Recorded Future News). The Volt Typhoon resurgence figures, roughly 30 percent of visible Cisco RV320/325 devices compromised in a 37-day window, are from the SecurityScorecard STRIKE team threat research. Payment-terminal scope and the PTS clarification are drawn from the PCI Security Standards Council’s own guidance on how terminals are treated during a PCI DSS assessment. The Cielo and Verifone SGP.32 deployments were announced via Thales in March 2026. Product capabilities are described at the category level and are not an endorsement of any single vendor.
