SoftPOS shifts payment risk from terminals to mobile app controls

At a glance

What this is: SoftPOS moves card-present payments onto mobile devices, making app integrity, API security, and runtime protection part of the payment control plane.

Why it matters: This matters to IAM and security teams because payment apps now depend on device trust, attestation, and protected credentials in ways that overlap with identity, access, and secrets governance.

By the numbers:

• It is expected that by 2027, more than 34.5 million merchants will accept payments through SoftPOS technology.
• 27 days
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Guardsquare's analysis of how SoftPOS changes mobile app security

Context

SoftPOS is software that turns a mobile device into a card-present payment terminal, which shifts trust away from dedicated hardware and onto the app, operating system, and device state. That change expands the attack surface because payment security now depends on code integrity, runtime checks, and protected APIs, not only on the payment kernel or PCI scope.

For identity and access programmes, the important issue is that payment apps increasingly depend on trusted device context, attested execution, and tightly controlled credentials and secrets. Once card acceptance moves into a mobile app, governance has to cover both payment security and the identity controls around APIs, tokens, and privileged app behaviour.

Key questions

Q: How should security teams govern SoftPOS apps in mobile payment environments?

A: Treat SoftPOS as a blended payment and identity problem. Require device attestation, app hardening, and runtime monitoring before transaction approval. Then limit payment API scope, protect secrets inside the app, and make security decisions based on device context, not just merchant authentication. The goal is to prevent a compromised phone from behaving like a trusted terminal.

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. If the app is tamperable, reverse engineerable, or allowed to use broad API credentials, attackers can manipulate transactions without defeating the payment kernel itself. That is why app-layer controls and secrets governance must sit beside compliance, not behind it.

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. At that point, the payment environment is also an identity environment, because the app is asserting trust on behalf of merchants and devices. Least privilege, short-lived credentials, and lifecycle review become essential to preventing abuse.

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.

Technical breakdown

Why mobile device integrity becomes a payment control

SoftPOS and tap-to-phone models use the phone as the checkout endpoint, so the security model must verify the device before payment is trusted. Integrity checks look for rooting, jailbreaking, emulator use, tampering, and unsafe runtime conditions that can alter the payment flow. In practice, this turns device posture into a transaction control because the same app can be legitimate on one device and unsafe on another. PCI MPoC strengthens that requirement by pushing payment solutions to prove the environment is trustworthy before card-present processing proceeds.

Practical implication: enforce device attestation and risk-based blocking before the payment flow reaches card acceptance.

How app hardening blocks reverse engineering and API abuse

When payments move into software, attackers stop targeting only terminals and start targeting the application layer. Obfuscation, anti-debugging, anti-tamper checks, and runtime application self-protection make it harder to inspect logic, alter screens, replay requests, or extract embedded secrets. These controls do not eliminate fraud, but they raise the cost of cloning the app, manipulating requests, or abusing predictable business logic. That matters because payment apps often expose the exact paths criminals need: authentication, authorisation, and transaction APIs.

Practical implication: treat the payment app as a protected asset and test its resistance to reverse engineering, request replay, and tampering.

Why PCI compliance does not cover the full app risk

PCI validates aspects of the payment kernel and card-data handling, but it does not automatically secure the surrounding app code, UI logic, secret handling, or API access patterns. That gap matters because many attacks do not need to break PCI controls if they can manipulate the mobile app directly, exploit exposed keys, or hijack the runtime with malware. In other words, compliance can coexist with exploitable software weakness. Organisations therefore need to separate compliance evidence from security assurance and govern both explicitly.

Practical implication: add app-layer security requirements to PCI programmes instead of treating PCI certification as the endpoint.

Threat narrative

Attacker objective: The attacker wants to turn trusted mobile checkout into a fraud channel by controlling the app, the device context, or both.

1. Entry begins when an attacker targets the mobile payment app or the device running it, often through malware, modified app builds, or compromised runtime conditions.
2. Escalation follows when the attacker uses overlay attacks, accessibility abuse, or reverse engineering to observe or alter payment logic, API calls, or credential handling.
3. Impact occurs when the attacker steals merchant credentials, injects fraudulent requests, or circumvents environment checks to automate payment fraud at scale.

NHI Mgmt Group analysis

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.

App-layer controls are now the decisive control plane for card-present fraud. The article is right to separate PCI scope from application security because attackers increasingly target the wrapper around the payment SDK, not only the SDK itself. This is where secrets management, API authorisation, and runtime protections intersect with identity governance, especially when service credentials or tokens are embedded in mobile workflows. Practitioners should assume that a compliant payment kernel can still sit inside a vulnerable app.

Runtime tampering is the named concept that should anchor SoftPOS governance. In mobile payments, tampering is no longer an edge case; it is the failure mode that collapses trust in the transaction path. Obfuscation, anti-debugging, and RASP matter because they reduce the attacker’s ability to see, change, or replay sensitive logic. Practitioners should measure whether their controls can still distinguish legitimate merchant activity from manipulated execution.

SoftPOS adoption widens the identity footprint of payment systems. Once merchants, apps, APIs, and devices all participate in the trust chain, governance has to extend beyond payment operations into identity and secrets lifecycle management. That makes attestation, token protection, and least-privilege API access part of the same control story. Practitioners should align mobile payment rollouts with identity governance from day one.

The market signal is clear: fraud resistance is becoming a software assurance problem. The article shows that mobile checkout is now judged by how well the app resists abuse in the wild, not only by how well it passes compliance checks. That shifts procurement and architecture decisions toward runtime assurance, anti-tamper validation, and stronger control evidence. Practitioners should expect mobile payment governance to look more like secure software governance over time.

What this signals

Runtime tampering is becoming the operational boundary for mobile payment trust. Once SoftPOS shifts checkout into software, teams need to watch for signals that the app can still be manipulated after installation, not just whether it passed pre-release testing. That makes attestation, telemetry, and secrets governance part of the same control loop, especially when mobile checkout depends on protected credentials and API access.

The identity footprint of payment apps is widening. Merchant credentials, device posture, and application trust now influence the same transaction decision. For practitioners, that means mobile payment programmes should be reviewed alongside IAM, secrets management, and API authorisation rather than treated as a pure payments-engineering issue.

SoftPOS adoption will reward teams that can prove runtime control, not just compliance documentation. PCI and security policy matter, but attackers target the app layer where fraud can be automated and scaled. Practitioners should expect stronger evidence requirements around tamper resistance, secret lifetime, and monitored execution before mobile payments are trusted at larger scale.

For practitioners

• Add device attestation before payment authorisation Require rooted, emulated, or tampered devices to fail closed before the payment app can initiate card-present flows. Tie the attestation result to transaction policy so risk decisions happen before authorisation, not after settlement. This reduces the chance that a compromised device can participate in trusted checkout.
• 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. Focus testing on reverse engineering, request replay, and UI manipulation, because that is where attackers can convert software weakness into fraud.
• Separate PCI evidence from app-security assurance Treat PCI compliance as necessary but insufficient. Add explicit controls for secrets storage, API authorisation, attestation, and malicious tooling detection so the app’s runtime security is assessed independently of the kernel’s compliance status.
• Review mobile secrets and merchant credentials lifecycle Inventory any keys, tokens, and certificates used by the payment app, then minimise their lifetime and scope. If the mobile layer is compromised, exposed credentials should not grant broad access to payment APIs or merchant functions.

Key takeaways

• SoftPOS turns mobile devices into payment endpoints, which means app integrity, device trust, and API control now shape transaction security.
• PCI compliance is necessary but not sufficient because attackers can still exploit the app wrapper, exposed secrets, or runtime tampering.
• Teams that combine attestation, hardening, and secrets governance will be better positioned to scale mobile payments without expanding fraud exposure.

Key terms

• Softpos: SoftPOS is a model that lets a smartphone or tablet accept card-present payments through software instead of dedicated payment hardware. It expands flexibility but also moves trust into the device, operating system, and app runtime, where tampering, malware, and exposed credentials become direct payment risks.
• Runtime Application Self-Protection: RASP is a runtime control that detects and can block suspicious application behaviour as it happens. In NHI contexts, it can contain abuse from service accounts or tokens, but it does not replace identity ownership, entitlement review, rotation, or deprovisioning.
• Device Attestation: Device attestation is the process of checking whether a device and its software environment meet expected integrity conditions before trust is extended. For identity workflows, it should support the verification decision, not replace stronger evidence about whether the capture stream itself is authentic.
• App Wrapper: The app wrapper is the code and logic surrounding a payment SDK or similar embedded component. It often contains the user interface, API handling, secrets, and business rules, which means attackers may bypass the secure core by exploiting weaknesses in the surrounding application layer.

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.

👉 The full Guardsquare article covers integrity checks, hardening techniques, and runtime protection for SoftPOS apps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader security programmes that now underpin mobile and API-driven services.