Because attackers often target the person operating the terminal, not the payment technology itself. A phishing email, weak password, or social engineering call can give an attacker access that bypasses encryption and EMV protections. Once inside, malware can harvest card data or personal information. The lesson is that transaction security must be paired with identity controls, employee awareness, and continuous monitoring of suspicious behavior.
Why encryption and EMV do not stop the usual breach path
Encryption and chip cards mainly protect card data in transit and reduce some forms of card cloning, but they do not secure the surrounding environment that processes the payment. If an attacker gets a foothold through a person, workstation, vendor channel, or remote access path, the breach can happen after the cryptographic protections have already done their job. That is why the real attack surface is often the operator, the endpoint, and the credentials that reach the POS network.
The practical failure is that many POS incidents are not “broken encryption” events. They are access-control failures. Once an attacker has legitimate-looking access, malware can run, memory can be scraped, cardholder data can be intercepted before encryption, or related systems can be used to pivot deeper into the environment. Real-world breach patterns show that stolen credentials, social engineering, and compromised support paths remain effective even when the payment stack itself is modern. See The 52 NHI breaches Report for broader patterns of credential-led compromise and SonicWall VPN Mass Breach via Stolen Credentials for how valid access can become mass exposure.
For POS specifically, the security boundary is not just the card reader. It includes the cashier session, help-desk resets, remote administration, software update channels, and any credentials or tokens that can touch the terminal estate. If those supporting controls are weak, encryption and EMV only limit part of the damage, they do not prevent compromise of the system that handles the transaction.
Where attackers usually succeed in POS environments
Attackers typically look for the path of least resistance, and in POS that path is often human or administrative rather than cryptographic. Phishing can capture passwords, social engineering can reset access, and weak segmentation can let an attacker move from a low-value endpoint to a payment subnet. From there, malware or remote tooling can collect data before it is protected by encryption or after it is decrypted for processing.
This is why the supporting controls matter as much as the payment hardware. Strong authentication, least privilege, device hardening, and rapid monitoring for anomalous logins all narrow the window in which an intruder can operate. Guidance on NHI Mgmt Group’s Ultimate Guide to Non-Human Identities is useful here because POS estates also depend on service accounts, integration keys, update mechanisms, and other machine credentials that can widen exposure when left unmanaged. For a broader control view, NIST SP 800-207 Zero Trust Architecture is a good reference point for minimizing implicit trust inside the environment.
Encryption and chip cards still matter, but they are not a substitute for containment. If an attacker can authenticate as a user, vendor, or support technician, the payment technology may remain intact while the environment around it is already compromised.
What defenders should treat as the real control boundary
The control boundary should extend beyond payment processing to the full path of access into the POS estate. That means user onboarding and offboarding, password and session controls, remote support approvals, segmentation, logging, and endpoint monitoring all need to be treated as payment-security controls, not just general IT hygiene. A breach usually becomes possible when one of those layers is easier to bypass than the encryption layer is to break.
Practitioner teams should also assume that card data is not the only asset at risk. Attackers may be after login sessions, back-office data, customer information, or the ability to persist quietly and reuse access later. That is why visibility into suspicious authentication, unusual terminal behavior, and unexpected administrative activity is essential. The payment terminal may be the asset in view, but the compromise path often starts with the person or credential behind it.
One useful reminder is that many POS compromises are operationally ordinary, not technically exotic. The attacker does not need to defeat EMV if they can trick a user, reuse a stolen password, or exploit a poorly controlled remote tool. See also NIST Cybersecurity Framework 2.0 for the broader govern, protect, detect, respond, and recover structure that helps keep payment environments from being reduced to a single control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 6 — Access Control Management | POS breaches often follow weak or stolen access into terminals and admin paths. |
| CIS 8 — Audit Log Management | Suspicious logins and terminal changes are key signals of POS compromise. | |
| Recommendation — Enforce least-privilege access and remove unnecessary POS and support access. Collect and review POS authentication and admin activity logs for anomalies. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The question centers on access paths that bypass payment encryption. |
| DE.CM — Continuous Monitoring | POS compromise is often detected through abnormal endpoint or login behavior. | |
| Recommendation — Harden authentication and access control for every POS administrative pathway. Monitor POS endpoints and sessions for suspicious behavior and unexpected changes. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Boundary Protection | Segmentation limits lateral movement from a compromised user into payment systems. |
| IA-2 — Device and User Authentication | Valid-looking access is a common breach path in POS environments. | |
| Recommendation — Segment POS environments and deny implicit trust between user and payment zones. Require strong authentication before any access to POS terminals or support tools. | ||
| MITRE ATT&CK | T1566 — Phishing | Phishing is a common way attackers obtain the initial foothold behind POS breaches. |
| T1078 — Valid Accounts | Attackers often use stolen credentials rather than defeat encryption directly. | |
| Recommendation — Hunt for phishing-driven credential theft that can reach POS-adjacent systems. Detect and contain use of valid accounts across POS, vendor, and support access. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secret Leakage and Exposure | POS estates often rely on service credentials and integration secrets that can widen access. |
| NHI-03 — Excessive Privileges | Overprivileged support or service accounts can turn a small foothold into broad compromise. | |
| Recommendation — Inventory and protect non-human credentials used by POS integrations and support tooling. Reduce POS-related account privilege to the minimum required for each function. | ||
Practitioner Guidance
What to prioritize: Treat POS access as a privileged pathway, not a simple checkout function. If a user, vendor, or support process can reach the terminal fleet, verify the authentication strength, approval workflow, and logging before you focus on payment encryption settings.
What to verify: Confirm that terminal administrators, remote support users, and service integrations are individually accountable, time-bound where possible, and monitored for unusual session behavior. Also verify that alerts exist for password resets, new remote access, and changes to terminal software or configuration.
Practitioner takeaway: The decisive question is not whether card data is encrypted, it is whether any attacker can still get trusted execution inside the POS environment. If the answer is yes, the breach path is still open.
Related resources from NHI Mgmt Group
- Why do organizations still get breached even as cybersecurity budgets and tools increase?
- Why do cloud ERP environments still create identity and access risk even when workflow automation is in place?
- Why do SaaS environments still create identity risk even after SSO is in place?
- Why do air-gapped networks still get breached?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
