A skimming attack is theft of payment card data by secretly copying information as it passes through a point of capture. The attacker may use a rogue card reader, malicious software or compromised checkout hardware to collect track data, card numbers or PIN entry before normal processing continues.
How skimming attacks work
Skimming attacks steal payment card data at the moment it is captured, rather than after the transaction finishes. The attacker interferes with the normal payment flow so card data, track data, or PIN entry can be copied without immediately disrupting checkout.
This makes skimming dangerous because it targets the point where the environment is supposed to trust the reader, terminal, or payment software. A rogue device, malicious code, or compromised point-of-sale hardware can all turn a legitimate capture step into a covert data-loss event.
Where skimming attacks happen
Skimming is most often associated with payment terminals, self-service kiosks, fuel pumps, and other card-present systems, but the core idea is broader than one device class. Any point where sensitive payment input passes through local hardware or software can become a capture point if the attacker can insert, alter, or subvert that component.
The practical security concern is that the compromise may sit upstream of normal payment controls. The merchant may still see approved transactions, while the attacker has already copied the data needed for fraud or resale.
Why skimming attacks are hard to spot
Skimming is designed to blend into expected payment activity. A physical skimmer can sit unnoticed on a reader, while malicious software can harvest data in memory or intercept input before encryption or transmission. In either case, the customer experience and the transaction result may look normal.
That low-friction abuse path is what makes skimming persistent. Organisations can miss it if they focus only on downstream fraud symptoms and not on the integrity of the capture point itself.
What skimming attacks mean for card data security
Once captured, card data can be used for counterfeit card creation, account abuse, or broader payment fraud. If the attacker also collects PIN data or related authentication material, the impact can extend beyond a single card number to stronger fraud enablement and replay-style abuse.
Defenders therefore need to treat skimming as both a data-theft problem and a trust-boundary problem. The control question is not just whether payment processing is encrypted, but whether the capture environment can be trusted before encryption, forwarding, or settlement begins.
Risk and Threat Considerations
Skimming attacks are dangerous because they attack the earliest trust point in the payment flow, where normal security monitoring may be weakest. A compromised reader, terminal, or checkout system can leak large volumes of card data before fraud controls or transaction monitoring have any chance to intervene.
Failure mechanism: The attacker captures payment data at input time by adding hardware, modifying software, or compromising checkout equipment so the data is copied before legitimate processing completes.
Impact: Stolen card data can be monetised quickly, and if PIN or other authentication data is also exposed, the attacker gains a stronger path to fraudulent use, cloning, or downstream payment abuse.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while PCI DSS v4.0 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| PCI DSS v4.0 | 4.2.1 — Protect Stored Account Data | Skimming directly concerns card data exposure and payment-card handling at capture and storage points. |
| 9.5.1 — Protect POI Devices from Tampering and Substitution | Skimming often relies on rogue readers or substituted payment hardware at the point of interaction. | |
| 11.6.1 — Periodic Security Testing and Monitoring | Skimming is detected through inspection, monitoring, and integrity checks around payment endpoints. | |
| Recommendation — Limit card-data exposure by enforcing point-of-capture protection and minimizing any retained sensitive authentication data. Inspect payment devices for tampering and substitution before use and during routine operations. Test and monitor payment endpoints for unauthorized changes, added hardware, or malicious code. | ||
| NIST SP 800-53 Rev 5 | SC-28 — Protection of Information at Rest | Payment data exposed by skimming creates a need to protect sensitive card data against later misuse. |
| SI-3 — Malicious Code Protection | Software-based skimming depends on malicious code intercepting payment input or terminal processing. | |
| Recommendation — Apply storage protections to minimize the value of any payment data that is captured or retained. Deploy malicious-code defenses on payment systems that process card data. | ||
Practitioner Guidance
What to watch for: Treat tamper evidence, unexpected hardware changes, strange terminal behaviour, and payment devices that fall outside standard maintenance or inventory controls as urgent signals. For merchants and operators, the strongest defence is to know exactly which devices should be present, how they are secured, and whether any component in the capture chain has been altered.
Practitioner takeaway: Skimming is fundamentally a trust-integrity problem at the point of capture, so controls should protect both the physical device and the software path that sees card data first.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org