Mobile app security must shift from shielding to runtime defense

At a glance

What this is: OneSpan argues that mobile app shielding must evolve into runtime defence because many banking attacks now bypass traditional tamper checks and remain invisible inside normal-looking sessions.

Why it matters: This matters because mobile banking teams need controls that can detect device compromise, coercion, and fraud context in real time, not just prove the app was protected at build or install time.

Context

Mobile banking protection is no longer just an app-hardening problem. The article describes a governance gap where banks can have shielding, device checks, and fraud scoring in place but still miss attacks that only become visible during runtime, after the customer session begins.

The article also ties mobile defence to identity and access governance because the trust decision is now made from app integrity, device posture, and user behaviour together. For banks, that makes mobile channels part of the identity control plane rather than a separate front-end security concern.

Key questions

Q: What breaks when mobile banking apps do not use app shielding and secure session controls?

A: Without app shielding and proper session controls, fraudsters can reverse-engineer apps, create convincing fake apps, steal data from the app itself, or exploit open sessions. That creates a wider attack surface even when the login appears legitimate. Security teams should assume the mobile app, not just the account, is a target.

Q: Why do normal fraud signals miss many mobile scam and APP fraud cases?

A: Because many attacks originate from a trusted device and a familiar network, traditional markers such as new device, new IP, or known malware may be absent. The risk is often in the customer’s behaviour and the session context, not in a simple authentication anomaly.

Q: What are the signs that mobile fraud controls are too static?

A: A control set is too static when it can prove shielding exists but cannot show runtime compromise, session coercion, or transaction-specific fraud context. If the bank only knows the app was protected at install time, it is missing the live attack surface.

Q: Should banks treat mobile app security as an IT control or a governance issue?

A: Banks should treat it as both, but governance is the more important frame. The article shows that mobile attacks now affect revenue, regulation, and board accountability, so security teams need controls that can be measured, explained, and tied to operational response.

Technical breakdown

Runtime app shielding and device attestation

Traditional app shielding focuses on protecting the binary from reverse engineering, repackaging, and obvious tampering. Runtime defence goes further by measuring what the app is doing on the device, whether the environment is hostile, and whether integrity signals still hold after launch. Device attestation and app attestation provide stronger evidence that the session is running on a trusted device and in a trusted state, while telemetry can surface anomalous execution that static controls never see. The architectural shift is from pre-deployment hardening to continuous trust evaluation during the transaction itself.

Practical implication: Treat mobile app security as a live control surface and feed runtime integrity signals into fraud and risk decisions.

ATS malware, overlays, and MFA interception

Automated transfer system malware is effective because it does not always need to modify the app itself. Instead, it abuses accessibility services, overlay techniques, and MFA interception to ride through a normal customer session and move money without obvious tampering signals. That means controls built only around binary integrity or jailbreak detection can miss the attack path entirely. The defensive challenge is to detect abuse of the interaction layer, not just corruption of the app package. In practice, the same app can look clean while the transaction path is already compromised.

Practical implication: Look for controls that can detect interaction-layer abuse, not just malware signatures or code tampering.

Fraud context, behavioural analytics, and scam coercion

Modern mobile fraud detection has to account for attacks where the customer is not impersonated but manipulated. APP fraud and scam activity can originate from a trusted device and familiar network, which is why classic indicators such as new device, new IP, or known malware often fail. The useful signal becomes behavioural and contextual: how the session unfolds, whether the user is being coached, and whether remote access or social engineering is shaping the transaction. This is where cyber and fraud teams need to merge signals rather than rely on isolated scoring engines.

Practical implication: Bind behavioural analytics to device telemetry so scam-driven transactions can be interrupted before completion.

Threat narrative

Attacker objective: The attacker wants to complete fraudulent transactions from a trusted mobile banking session while avoiding controls that only look for visible app tampering.

1. Entry begins when the attacker reaches the banking session through social engineering, a compromised device, or malware that abuses accessibility services.
2. Credential capture or session abuse follows when overlay tricks, MFA interception, or remote control let the attacker operate inside what still appears to be a normal customer session.
3. Impact occurs when the fraud is executed from a trusted mobile channel, allowing account takeover, unauthorised transfer, or APP fraud without obvious tamper signals.

Breaches seen in the wild

• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Mobile banking security has moved from app protection to trust orchestration. The article shows that banks can no longer treat the mobile app as a passive endpoint to harden and forget. When device posture, app integrity, user behaviour, and fraud context all influence the same decision, the control problem becomes one of orchestrating trust in real time. Practitioners should view mobile channels as part of the identity and access decision path, not a separate security silo.

Static shielding creates a detection gap when attacks stay inside the trusted session. ATS malware and scam-driven fraud work because the app can appear normal while the transaction is already compromised. That is a governance failure of visibility, not deployment. The named concept here is runtime trust gap: the distance between an app being installed securely and the bank still knowing it is safe during use. Practitioners should design for that gap explicitly.

Fraud and cyber functions now need a shared operating model. The article makes clear that device signals, behavioral signals, and threat intelligence lose value when they are held in separate teams or tools. A bank that wants effective mobile defence needs a common response model for fraud, SOC, risk, and mobile security. Practitioners should align ownership around the session, not around departmental boundaries.

Regulatory pressure is turning mobile defence into an executive accountability issue. DORA, PSD3-related expectations, and scam reimbursement trends mean banks are being asked to show that controls work, not merely exist. That changes the conversation from control deployment to control effectiveness and evidence. Practitioners should expect board scrutiny on measurable mobile resilience, scam detection, and response capability.

From our research library:

• U.S. fraud losses are projected to reach $40 billion by 2027.

What this signals

Runtime trust gap: mobile banking controls now have to decide whether the session is trustworthy after launch, not merely whether the app passed pre-deployment checks. That shift should push banks toward telemetry-driven response models that combine device, app, and behaviour signals in one decision path.

The practical consequence is that fraud, SOC, and mobile security teams need shared indicators and a common escalation model. When the attack is hidden inside a normal-looking app session, the bank’s real control is the speed and quality of its cross-team response.

Banks should expect scrutiny on evidence of effectiveness rather than evidence of deployment. A mobile control that cannot demonstrate which attacks it saw, blocked, or escalated is no longer adequate for modern fraud and resilience expectations.

For practitioners

• Instrument runtime trust signals across the mobile journey Collect app integrity, device attestation, and session telemetry at transaction time, then pass those signals into fraud and risk workflows rather than leaving them inside the mobile team.
• Detect interaction-layer abuse, not just tampering Test for accessibility abuse, overlay activity, MFA interception, and remote access behaviours that let ATS malware operate without altering the app binary.
• Fuse fraud and cyber telemetry into one response path Share mobile threat intelligence, device signals, and scam indicators across fraud operations, SOC, and mobile security so teams can intervene on the same session view.
• Measure mobile control effectiveness, not control presence Build evidence that shows which attacks were detected, interrupted, or missed, and use that reporting to support audit, regulatory, and board-level reviews.

Key takeaways

• Mobile banking attacks now bypass purely static app shielding by exploiting runtime behaviour, device compromise, and fraud context.
• The article points to a detection gap where traditional signals can be absent even when fraud is underway inside a trusted mobile session.
• Banks need runtime trust telemetry, behavioural analysis, and shared fraud-cyber response to reduce losses without relying on friction alone.

Key terms

• Runtime Trust: Runtime trust is the idea that access should remain valid only while current context justifies it. Instead of trusting a setup decision indefinitely, teams continuously re-evaluate whether a workload or agent still deserves privilege. This approach is especially important for AI agents that can change behaviour mid-task.
• Automated Transfer System Malware: Automated transfer system malware is mobile malware designed to complete fraudulent payments inside a trusted-looking banking session. It commonly uses accessibility abuse, overlays, and interception techniques to manipulate what the customer sees and does without obvious app tampering.
• 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 Shielding: App shielding is a set of protective controls embedded directly into a mobile application so it can resist tampering, reverse engineering, debugging, and runtime analysis. It shifts part of the security decision-making into the app itself, helping preserve integrity when the device or execution environment cannot be fully trusted.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners building stronger identity controls. It helps security and identity teams connect governance models to the operational decisions their programmes depend on.