New security risks for mobile applications and how fintech can keep users’ assets safe

Mobile apps have become the default interface for crypto and fintech. For example, over 2.7 billion people used mobile payments in 2024, with total transaction volume reaching 8.1 trillion. And the growth continued in 2025 and into 2026 at a rate of around 28.0%.

As wallets, trading platforms, and payment apps converge on mobile, these same devices that enable instant access also concentrate risk, creating a single, highly exposed point of failure for sensitive financial data.

This is an architectural problem. Mobile devices are not a reliable infrastructure layer for protecting private keys, banking credentials, or other sensitive material. Any system that depends on the device to secure these assets becomes fragile as attackers are consistently finding ways to run code on the device itself or exploit its underlying OS and hardware.

In this article, we examine recent malware and hardware risks targeting Android devices, and show why these threats require a new standard where security is enforced beyond the local device, through hardened infrastructure and policy at execution.

Mobile is the wrong place for secrets

Both malware and hardware vulnerabilities point to the same issue: a fundamental flaw in the way secrets are stored in fintech applications and mobile wallets.

If private keys, signing authority, or API secrets exist on the device, they are inherently exposed to multiple layers of risk, including malware operating with system-level permissions, exploits targeting OS or hardware boundaries, and user-installed software that exists entirely outside the developer’s control.

Recent research by cybersecurity professionals on mobile Android devices shows how these risks might be applied in practice. Android alone accounts for around 70% of global mobile devices, which makes these risks both widespread and relevant to most applications in production. These aren’t edge cases, but reflect how financial applications can be targeted at scale.

Recent malware found in Android apps 

A recent report from The Hacker News highlights how six Android malware families are actively targeting financial applications, including crypto wallets and banking apps.

Once installed, they exploit accessibility services to gain deep control over the device and operate invisibly in the background. 

These attacks operate directly inside the device environment:

• Overlaying legitimate apps to capture credentials
• Using accessibility services to read screens and trigger actions
• Taking remote control of the device to initiate transactions
• Intercepting authentication flows

Instead of stealing credentials and acting later, some of these strains monitor the user’s screen in real time and wait for high-value moments, like initiating a payment. At that exact moment, the attacker intervenes, hijacking the transaction and redirecting funds before the user notices.

From the application’s perspective, nothing looks wrong. The user is authenticated. The request is valid. The session is active. But the attacker is already inside the device.

At that point, any secret stored or accessible on the device is compromised. Encryption, biometrics, and obfuscation do not change this. They protect access to the app, not the integrity of the environment the app runs in.

Android hardware cannot be trusted as a security boundary

Research from Ledger also shows how fragile mobile hardware-backed security actually is.

The team uncovered a vulnerability in widely used Android devices powered by MediaTek chips that allows attackers to bypass core security protections and extract sensitive data directly from the device. This includes data from mobile wallet apps like Trust Wallet, Kraken Wallet, and Phantom.

This is not a typical application-layer exploit, as it operates below the OS.

In the demonstrated attack:

• An attacker can connect to a device via USB
• Extract cryptographic material before Android even boots
• Recover the device PIN and decrypt storage offline
• Access sensitive data, including wallet seed phrases and private keys

In some cases, this can be done in under a minute.

These vulnerabilities target the exact components developers are told to trust, like secure boot chains and hardware-backed encryption.

Attackers can break isolation guarantees, execute code at the highest privilege levels, and access data that should never leave protected environments.

Even more importantly, these attacks do not need to scale perfectly. Financial applications concentrate value. A single successful exploit can expose wallet keys, drain accounts, and result in irreversible loss.

The takeaway is not that hardware protections are irrelevant. It is that consumer devices cannot be treated as hardened security infrastructure.

"This research proves what we've long warned: smartphones were never designed to be vaults," Ledger Chief Technology Officer Charles Guillemet. 

AI makes this worse, not better

As AI increases both the volume and sophistication of attacks, putting more authority on-device moves in the wrong direction. It shifts critical control into the most vulnerable part of the system at the exact moment that attackers are becoming more capable of exploiting it.

Many applications rely on locally stored encrypted keys that are decrypted when the user authenticates and held in application memory for the duration of the session. This model is the foundation of most non-custodial mobile wallets, where self-custody and ease of use are prioritized over isolating key material from the device environment.

In practice, it expands the attack surface. It assumes the device can be trusted to generate, store, and use signing authority safely, even temporarily. But as recent malware and hardware exploits show, that assumption is already breaking down.

If a key is decrypted in-process on a compromised machine, it can be observed and intercepted. Memory-level access, process injection, and system-level compromise all make these wallets exploitable in real-world conditions.

At the same time, AI has lowered the cost of executing sophisticated attacks. Capabilities that once required deep expertise can now be automated:

• Malware generation
• Phishing and UI spoofing
• Transaction construction and execution

AI does not just increase the number of attacks. It increases their precision. Attackers can tailor exploits to specific applications, automate timing around user behavior, and execute transactions in real time with minimal effort.

This increases the importance of where signing authority lives and how it is controlled.

Why this necessitates a new standard

These risks reflect a consistent pattern: sensitive operations are being executed in an environment that cannot be controlled.

The issue is not only more advanced malware or newly uncovered hardware weaknesses. It is that private keys, credentials, and transaction authority continue to live on devices that are inherently exposed.

That changes the core security question. Instead of asking, “How do we keep a key safe on a phone?” the better question becomes, “What is this system allowed to do?”

Policy and protection as the new foundation

A stronger model starts by moving secrets and execution out of that environment entirely. Private keys never reach the device. Authentication is treated separately from authorization. Each requested action is checked against defined rules before it can be approved or carried out.

Instead of granting broad authority after login, systems define exactly what is allowed: which transactions can be executed, which destinations are valid, how much value can move, and when additional approvals are required.

This is enforced at the point of signing, not at the point of request.

Even if an attacker gains control of a session, injects code, or operates from a compromised device, they cannot execute actions outside of those constraints. The system does not rely on detecting compromise. It assumes it and limits what can happen.

Turnkey: securing mobile applications by moving trust off-device

The more secure and preferred approach is to remove private keys from the device entirely and enforce control at execution. With Turnkey, this model is implemented through enclave-based signing, where keys never leave secure hardware and every action is evaluated against policy at the moment of execution.

This minimizes exposure and ensures that compromise at the device level does not translate into loss of funds or unrestricted access.

On iOS and Android, Turnkey provides a React Native SDK and TypeScript client that handle authentication and request orchestration, but never key custody. Mobile apps integrate passkeys, biometrics, or other authentication methods to verify the user, then securely request actions from Turnkey's infrastructure. The device proves identity, but it does not hold signing authority.

At a high level:

• The mobile app handles user interaction and authentication using native iOS and Android capabilities
• The device sends authenticated requests, but does not perform signing
• Turnkey infrastructure evaluates each request against policy before execution
• Signing and policy evaluation happens inside secure enclave infrastructure, not on the device

Private keys are generated, stored, and used entirely inside secure enclave infrastructure. They are never exposed to the application, the device, or any operator.

Every request to sign originates from the mobile app, is authenticated using platform-native methods, and is then sent to Turnkey's backend, where it is evaluated against policy and executed in an isolated environment. This allows mobile apps to deliver familiar UX while removing sensitive operations from the device entirely.

If a device is compromised, the impact is constrained by design:

• Keys cannot be extracted because they never exist on the device
• Arbitrary transactions cannot be executed because every request is checked against policy
• Authentication alone does not grant unrestricted authority

The device can originate intent, but it cannot expand its authority.

To secure your mobile application, get started with Turnkey 

Mobile devices are increasingly at the center of modern financial applications, but they are also increasingly targeted. Malware now operates across the application layer, the OS layer, and even the hardware layer. Each new class of attack reduces the reliability of the device as a place to secure financial operations.

At the same time, many systems continue to push critical logic and key management onto these devices, increasing the blast radius when something goes wrong.

A more reliable approach is to remove the device from the trust boundary entirely. Keep private keys in controlled infrastructure, treat every request as untrusted, and enforce rules at the moment of execution rather than after the fact.

This is not about hardening the device. It is about ensuring that the environment does not have the ability to cause damage in the first place. If you truly want to secure your application, you need to move trust out of the device and enforce control where execution actually happens.

Get started with Turnkey today.