Notifications
Clear all
Topic starter
18/08/2026 2:22 pm
TL;DR: SoftPOS is set to reach more than 34.5 million merchants by 2027, and Guardsquare argues that moving card-present payments onto smartphones shifts the security burden from dedicated terminals to app integrity, API protection, and runtime hardening. The governing problem is no longer just PCI compliance, but whether the app itself can resist tampering, reverse engineering, and fraud at scale.
NHIMG editorial — based on content published by Guardsquare: Why SoftPOS Raises the Stakes for Mobile App Security
By the numbers:
- It is expected that by 2027, more than 34.5 million merchants will accept payments through SoftPOS technology.
Questions worth separating out
Q: How should security teams govern SoftPOS apps in mobile payment environments?
A: Treat SoftPOS as a blended payment and identity problem.
Q: What fails when PCI compliance is treated as enough for mobile payment security?
A: PCI can validate parts of the payment path while leaving the wrapper app exposed.
Q: When do mobile payment controls need to become identity controls as well?
A: They need to do that whenever app access depends on tokens, certificates, or privileged APIs.
Practitioner guidance
- Add device attestation before payment authorisation Require rooted, emulated, or tampered devices to fail closed before the payment app can initiate card-present flows.
- Harden the app wrapper around the payment SDK Apply obfuscation, anti-debugging, anti-tamper checks, and runtime application self-protection to the code that surrounds the SoftPOS SDK.
- Separate PCI evidence from app-security assurance Treat PCI compliance as necessary but insufficient.
What's in the full article
Guardsquare's full article covers the operational detail this post intentionally leaves for the source:
- Practical guidance on balanced integrity checks for device context and runtime behaviour.
- Specific code hardening, obfuscation, and anti-tampering measures for mobile payment apps.
- Runtime application self-protection and malware-aware monitoring approaches for SoftPOS deployments.
- Automated security testing and protection steps to validate app resilience before release.
👉 Read Guardsquare's analysis of how SoftPOS changes mobile app security →
SoftPOS security: are your mobile app controls keeping up?
Explore further
18/08/2026 3:14 pm
SoftPOS creates a mobile trust boundary problem, not just a payment-security problem. When the payment terminal becomes an app, the security decision moves from fixed hardware to variable device context. That means the app must prove the device is safe at runtime, and identity-style trust signals now influence whether a transaction can proceed. Practitioners should treat device integrity as part of access governance, not as a separate mobile hygiene issue.
A question worth separating out:
Q: Who is accountable when a compromised device enables SoftPOS fraud?
A: Accountability usually spans mobile engineering, payments operations, IAM or secrets owners, and risk governance. If the app trusted an unsafe device, stored credentials too broadly, or lacked runtime tamper detection, the failure is shared across architecture and control ownership. PCI compliance alone does not resolve that accountability gap.
👉 Read our full editorial: SoftPOS shifts payment risk from terminals to mobile app controls
