Who is accountable when a compromised device enables SoftPOS fraud?

Why This Matters for Security Teams

SoftPOS changes the accountability model because card acceptance moves onto a general-purpose mobile device that can fail in multiple ways at once: compromised firmware, malicious overlays, weak app integrity, or overly broad secrets exposure. The question is not only who approved the payment flow, but who owned device trust, application hardening, and fraud monitoring across the full transaction path. NIST control families for system and communications protection and access control remain directly relevant, especially when organisations map responsibilities to NIST SP 800-53 Rev 5 Security and Privacy Controls.

Security teams often get this wrong by treating SoftPOS as a payments-only issue when the real failure may start in mobile engineering or secrets handling. If the device is rooted, compromised, or operating outside approved posture, the payment layer may simply expose an upstream control gap. The practical challenge is that accountability is shared, but incident response still needs one owner for each control domain, including fraud operations, endpoint security, and identity governance. In practice, many security teams encounter SoftPOS fraud only after compromised devices have already been used to authorise transactions, rather than through intentional device trust enforcement.

How It Works in Practice

Accountability for compromised-device SoftPOS fraud should be mapped as a control chain rather than a single team assignment. Mobile engineering typically owns app resilience and secure coding. Device security or endpoint teams own posture enforcement, jailbreak or root detection, and runtime integrity checks. Payments operations owns transaction controls, fraud rules, and terminal or merchant enablement. IAM or secrets owners own token scope, key rotation, and whether the app can authenticate too broadly. Risk or GRC owns oversight, exception handling, and evidence that control decisions were approved.

Good practice is to define who decides, who implements, who monitors, and who accepts residual risk. That matters because “accountable” is not the same as “involved.” A SoftPOS deployment may pass PCI reviews while still failing operationally if the app accepts transactions from a compromised handset, trusts stale device attestations, or stores credentials in a way that allows reuse after compromise. For fraud response, teams should verify device provenance, confirm whether tamper and attestation signals were available at the point of sale, and correlate anomalous approvals with identity or secrets misuse.

• Assign a named control owner for device trust, app integrity, and payment fraud detection.
• Document when a device must be refused, quarantined, or re-enrolled.
• Limit secrets so compromise of one handset does not expose a wider payment estate.
• Feed device-health and transaction signals into SOC or fraud workflows for faster correlation.

The same governance pattern is appearing in adjacent AI-enabled attack scenarios, where a trusted system can be subverted by a compromised endpoint or abused toolchain, as highlighted in Anthropic — first AI-orchestrated cyber espionage campaign report. These controls tend to break down when merchant onboarding is decentralised and device exceptions are granted informally, because accountability fragments faster than telemetry reaches the fraud team.

Common Variations and Edge Cases

Tighter device enforcement often increases merchant friction and support overhead, requiring organisations to balance fraud reduction against checkout reliability. That tradeoff is real, especially in field service, hospitality, and high-turnover retail environments where shared devices, limited connectivity, or legacy handset fleets complicate strict posture checks. Current guidance suggests that accountability should still remain explicit even when operational constraints force compensating controls.

There is no universal standard for this yet on how to divide responsibility between the payment provider, the merchant, and the device owner in every SoftPOS deployment. In some models, the payment service provider retains control over app attestation and cryptographic material. In others, the merchant owns the devices outright and must prove runtime integrity and acceptable-use controls. The key question is whether the organisation can show who accepted the risk of running card-present payment functions on a device that may be physically accessible to users, managed by a third party, or enrolled in a permissive mobile device management policy.

Identity is also part of the answer. If a compromised handset is allowed to reuse cached credentials, long-lived tokens, or weak device binding, accountability extends to IAM and secrets governance, not just the app team. For that reason, NHI-style thinking is useful even in payments: every device identity, token, and attestation path should have a clear owner, review cycle, and revocation process.

Related resources from NHI Mgmt Group

• Who is accountable when an AI agent or mobile app enables authorized fraud?
• Who is accountable when a compromised business account is used for ad fraud or SSO pivoting?
• How should teams detect mobile fraud when the device itself is compromised?
• Who is accountable when a compromised mobile device completes a fraudulent transaction?