Mobile app security must shift from shielding to runtime defense

At a glance

What this is: This is an analysis of why mobile banking security now requires runtime visibility, fraud signals, and regulatory readiness rather than static app shielding alone.

Why it matters: It matters because mobile channels now sit on the critical path for authentication, transactions, and scam decisions, so IAM-adjacent controls must be evaluated in terms of effectiveness, not just deployment.

By the numbers:

• Roughly 80 percent of banks are doing something on mobile app security, and some deploy multiple overlapping controls, yet only about 11 percent are effectively protected across key attack vectors.
• In about 72% of fraud losses by value, traditional signals such as a new device, new IP address, known malware flags, remote access tools, and failed authentication are absent.

👉 Read OneSpan's analysis of mobile app security, fraud, and response

Context

Mobile app security is no longer just an endpoint problem or an anti-tampering problem. In banking, the mobile app has become a live trust surface where authentication, device state, user behaviour, and transaction intent all intersect, and static shielding cannot explain what happens once the session starts.

That matters for identity programmes because mobile banking now depends on layered signals across human identity, device identity, and session context. When fraud, app protection, and regulatory evidence are managed separately, teams miss the operational view needed to decide whether a session is genuine, coerced, or compromised.

Key questions

Q: How should banks detect mobile fraud when the app itself looks normal?

A: Banks should rely on runtime telemetry, device integrity, behavioural context, and transaction signals, not only on app tamper checks. Many mobile attacks succeed without changing the binary, so the session can appear normal while the device is compromised. Detection has to happen across the customer journey, especially before payment authorisation.

Q: Why do static app protections fail against mobile banking scams?

A: Static protections are designed to stop reverse engineering and repackaging, but scams and ATS malware often abuse the live session, accessibility services, overlays, or remote control. The weakness is assuming that protected code means a trusted interaction. In practice, the fraud decision depends on what the device and user are doing in real time.

Q: What do security teams get wrong about mobile malware and identity risk?

A: They often stop at authentication and overlook what happens after login. Mobile malware can abuse legitimate OS features, manipulate the user interface, and complete actions invisibly. That means the real control problem is not only proving identity, but continuously validating the session and the device behind it.

Q: Who is accountable when a compromised mobile device completes a fraudulent transaction?

A: Accountability usually spans fraud operations, IAM, mobile security, and the business owner of the transaction flow. If the programme treats device integrity as outside identity governance, the control gap is structural. Teams should define ownership for post-authentication session trust before fraud patterns force the issue.

Technical breakdown

Why static app shielding misses runtime abuse

Static app shielding focuses on package integrity, reverse engineering resistance, and code-hardening. That helps against repackaging and some forms of tampering, but it does not explain what happens on a rooted device, inside an emulator, or during a live session where the app itself remains intact. Modern mobile attacks often abuse the runtime environment rather than the binary, so the control boundary must extend beyond the app file to the device and session context.

Practical implication: banks need telemetry that can see device integrity and runtime behaviour, not just proof that the app was protected at build time.

How ATS malware bypasses traditional fraud controls

Automated transfer system malware uses accessibility services, overlay attacks, and MFA interception to manipulate the customer session without modifying the app in obvious ways. That means traditional anti-tamper and credential-theft logic can miss the attack because the login and transaction flow still appears legitimate from the app’s perspective. The real failure is that the security model assumes abnormal code changes will be visible before money moves.

Practical implication: fraud and mobile security teams should correlate behavioural telemetry, overlay detection, and remote-access indicators before approving high-risk transactions.

Why bank apps are becoming trust inputs for the backend

Mobile security is shifting from publishing a protected front end to treating the app as a source of trust signals. Integrity checks, device attestation, and runtime telemetry can feed fraud engines, orchestration layers, and risk decisions in real time. This changes the architecture: the app is no longer just an access channel, but part of the identity and decisioning fabric that supports the bank’s backend controls.

Practical implication: integrate app and device signals into backend decisioning so step-up, friction, and case handling respond to live risk rather than static policy.

Threat narrative

Attacker objective: The attacker’s objective is to complete fraudulent transfers while staying inside a trusted-looking mobile banking session.

1. Entry begins when the attacker delivers ATS malware or a scam that persuades the customer to run the malicious flow on a trusted mobile device.
2. Credential access and abuse occur through overlays, accessibility abuse, or MFA interception, allowing the attacker to ride the customer session without obvious tampering.
3. Impact follows when transactions are authorised from a device and session that appear legitimate to traditional fraud controls, resulting in unauthorised transfers and customer loss.

NHI Mgmt Group analysis

Static mobile app protection is now a governance liability when it is treated as the whole control set. The article shows that many banks have deployed shielding, yet runtime abuse, scam coercion, and ATS malware still pass through because the app is only one layer of the control plane. In governance terms, the problem is not missing controls alone, but a false belief that deployment equals effective protection. Practitioners should treat mobile security as a live assurance problem, not a build-time checkbox.

Mobile fraud has become an identity problem, not just a transaction problem. Once the customer is coached, coerced, or operating under remote control, the bank is no longer evaluating only whether the user authenticated successfully. It must evaluate whether the session reflects genuine intent, trusted device state, and normal behavioural progression. That is why mobile fraud detection now intersects with identity verification, behavioural analytics, and session assurance. Practitioners should connect fraud decisions to identity context rather than to login success alone.

Device attestation and runtime telemetry are becoming the practical bridge between mobile security and IAM decisioning. A protected app that cannot communicate integrity, environment, and behavioural signals leaves fraud engines blind to session risk. The article points to a model where app, device, and user signals inform orchestration in the backend, which is increasingly aligned with zero trust thinking for high-value transactions. Practitioners should align mobile controls with identity-aware decisioning, not isolate them inside the app team.

Regulatory pressure is turning mobile security evidence into board-level evidence. The discussion around DORA, PSD3, scam reimbursement, and regional mobile-threat guidance shows that banks are being asked to prove control effectiveness, not merely control existence. That changes the standard for reporting, audit, and executive oversight. It also means mobile security outcomes must be measurable in terms of fraud reduction, response quality, and resilience. Practitioners should prepare to defend the operating model, not just the toolset.

Cyber-fraud fusion is the named operating concept that this article implicitly validates. Fraud teams, SOC teams, intelligence teams, and mobile security teams need shared telemetry and shared escalation logic because the attack chain crosses all four domains. The bank that keeps these functions separate will continue to miss scams that look normal in one system and malicious in another. Practitioners should build common workflows and a shared language for mobile threat response.

What this signals

Mobile banking teams should expect more demand for evidence that controls work in live sessions, not just on paper. That means baselining runtime telemetry, feeding device trust into decisioning, and treating scam detection as an operational discipline rather than a narrow fraud task.

Session assurance gap: banks that cannot distinguish normal authentication from coerced or controlled behaviour will keep missing scam-driven losses. The practical response is to fuse app, device, and behavioural signals into one risk model, then use that model to drive step-up, intervention, or case escalation.

For identity and access programmes, the lesson is that mobile channels now act as part of the identity stack. Where session context and device trust inform backend decisions, teams should align those inputs with zero trust controls and identity governance expectations, using frameworks such as the NIST Cybersecurity Framework 2.0 where appropriate.

For practitioners

• Build runtime visibility into mobile sessions Instrument app, device, and session telemetry so teams can detect rooted devices, emulators, overlays, accessibility abuse, and anomalous behaviour during active use.
• Correlate fraud signals before step-up decisions Combine remote-access indicators, behavioural analytics, device intelligence, and transaction context before adding friction or approving a high-risk payment.
• Use attestation as backend input Feed integrity signals and device attestation into fraud engines and orchestration layers so response logic changes with live risk, not just static policy.
• Unify cyber and fraud operations Create shared escalation paths between SOC, fraud, intelligence, and mobile app teams so scams are investigated as cross-domain events rather than isolated alerts.
• Prepare evidence for regulators and audit Track control effectiveness over time with reporting that shows detection quality, intervention outcomes, and the reduction in successful scam and mobile fraud events.

Key takeaways

• Static mobile app shielding is no longer enough when attacks abuse the live session rather than the app binary.
• Fraud losses increasingly occur without the usual warning signs, which means risk teams need behavioural and device context to make defensible decisions.
• Banks should treat mobile security as an evidence problem, with shared telemetry, shared workflows, and measurable control effectiveness.

Key terms

• Runtime telemetry: Observation of what a system actually does while it is executing. In agentic CI/CD, this means seeing which commands, files, tools, and credentials an agent touched so security teams can detect misuse that static workflow review will miss.
• 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.
• Dynamic Friction: Dynamic friction is the practice of adding more user challenge only when risk rises. Rather than forcing every user through the same experience, the system adapts its response to context, which helps preserve conversion while still reducing fraud exposure in higher-risk scenarios.
• Cyber-fraud fusion: The convergence of fraud detection and identity security into one operating model. It treats onboarding, runtime behaviour, and relationship analysis as parts of a single trust problem, because attackers move across those layers rather than staying in one control domain.

What's in the full article

OneSpan's full post covers the operational detail this analysis intentionally leaves at the governance and control level:

• Regional regulatory differences across Europe, Asia, and the Americas for mobile threat controls
• Examples of mobile attack techniques including rooting, overlays, hooking, code injection, and remote access tools
• How banks are using dynamic friction and specialist intervention teams to interrupt scams in progress
• The discussion on explainability, model governance, and when machine learning helps fraud teams

👉 OneSpan's full post covers the panel discussion, regulatory context, and mobile threat examples in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle fundamentals. It is designed for practitioners who need to connect identity controls to real operational risk across security programmes.