The Device Was Genuine. The App Was Manipulated. The API Was Breached.

The security of a financial application is defined not by the strongest device available, but by the weakest environment the institution's API still accepts.

For years, our team has worked at the front line of mobile application and API security. We were there when the central challenge was simply obfuscating code. We watched the attack surface expand into runtime manipulation, API abuse, Man-in-the-Middle (MitM) attacks, device compromise, identity spoofing, and bot-driven onboarding fraud.

That experience has led me to an uncomfortable conclusion:

While Google and Apple understand mobile OS security exceptionally well, that is a very different security problem from the one faced by a bank, wallet, payment provider, or digital identity platform.

Google can secure the latest versions of Android, and Apple can lock down the newest iPhones. But a financial institution must secure the complete interaction between a customer, an application, a device, a runtime environment, and a backend API.

Those are not the same job.

The Attacker Chooses the Battlefield

Every new OS release improves something. New hardware strengthens isolation. Patches close vulnerabilities. Play Integrity and DeviceCheck provide useful signals.

All of that matters, but the attacker is not obliged to use the latest device, the latest OS, or the strongest implementation.

The attacker chooses the battlefield.

They will not attempt to gain root, hide their presence, and manipulate the secure element on a fully patched, current-generation device when the institution still allows API requests from an older phone, a repackaged application build, a scripted bot, or a manipulated runtime.

This produces the rule that should govern every mobile-security architecture:

The security level of your mobile channel is not defined by the strongest device available with the latest OS. It is constrained by the weakest client environment your backend API is still willing to trust.

Platform security moves forward, and fraud routes around it.

Attackers do not need to defeat the best version of Android or iOS. They need to find one accepted combination of hardware, software, application version, and runtime state that gives their automated scripts a usable path to your backend.

A Platform Verdict is not a Trust Architecture

This is why platform attestation, while valuable, cannot be the entire answer.

Google itself positions Play Integrity as one component of a broader anti-abuse strategy, rather than a sole fraud-prevention mechanism. That distinction is critical.

Attestation is evidence. And evidence must still be validated, correlated, and interpreted continuously.

Is the certificate chain valid? Is the application genuine, unmodified, and current? Is the runtime being manipulated? Is a debugger attached? Is a framework like Frida hooking into the app? Are the API requests originating from a genuine app, or a script mimicking one?

Tools such as TrickyStore and modern root-cloaking frameworks are important not because they prove that every hardware-backed control is universally defeated. They prove something more fundamental: attackers actively target the evidence on which backend trust decisions depend. TrickyStore, for example, is explicitly designed to modify the certificate chain produced for Android key attestation.

A signed platform verdict is not automatically a complete root of trust. The institution needs independent, continuous controls around app provenance, API integrity, runtime state, and channel security.

Hidden Secrets are not Non-abusable Secrets

In-app protections and secure elements are valuable. But simply hiding API keys or storing cryptographic material securely is often discussed as though it solves the whole problem. It does not.

A secure element or deep code obfuscation may prevent a static API key from being extracted. However, that does not automatically prove that every API request made with that key is legitimate.

If a hostile process, a compromised application, or a manipulated runtime can invoke your API on demand, the API key may remain physically protected while its authority is abused.

Often, the most useful attack is not to extract the key at all. It is to turn the legitimate application into an oracle—or to use a bot network—that performs valid API operations on the attacker’s behalf.

Therefore, client-side protection must sit inside a larger architecture that protects the execution path, the user interaction, and, crucially, the API communication with the backend.

The Two Pressure Points: Onboarding and Account Takeover

The weakness becomes clearest at two moments.

1. Onboarding

A modern onboarding flow may depend on a camera, a biometric sensor, a document scan, and a backend risk decision.

The institution is not merely asking whether an image looks convincing. It is asking whether the entire path that produced the API payload can be trusted.

Was a real camera used? Was the application genuine? Was the API call generated by a real device, or a script pumping synthetic identities into the backend?

AI has made fabricated identities and synthetic media cheaper and more convincing. The defensive response cannot just be another visual puzzle or static CAPTCHA. It must protect the input path and establish cryptographic trust across the whole channel.

2. Account Takeovers

Account takeover attacks target continuity.

The criminal may have stolen credentials, intercepted an OTP, or scripted a credential-stuffing attack against your login API.

The decisive question for your backend is not simply: “Did the user enter the correct password?”

It is: “Is this request actually coming from our genuine, unmodified mobile application, running in a safe environment, communicating over an uncompromised channel?”

Once onboarding and account takeovers are treated as end-to-end API trust problems, client-side security stops being an isolated feature. It becomes one part of a coherent system.

Banks Cannot Solve This by Blocking Everyone

There is a tempting response: Reject every older device and every ambiguous signal.

However, that is not a serious operating model.

Financial institutions serve large and diverse customer populations. Devices age. Customers do not all upgrade on the same schedule. False positives have real human and commercial consequences.

The real challenge is precision: institutions need evidence-based, dynamic controls that separate a genuinely dangerous script or repackaged app from a merely imperfect, older device.

Regulators are increasingly explicit about this expectation. This is why static checks are insufficient when the goal is not to blindly trust every old device or reject every unusual one, but rather to understand the risk of the exact API interaction and apply the appropriate response.

What a Financial Institution has to be Able to Establish

A credible architecture has to connect all of the relevant layers to shield the API.

Establish App and Runtime Integrity

The application must be able to detect and resist tampering, debugging, hooking, instrumentation, code injection, root/jailbreak concealment, and malware interference. The question is not whether the package was genuine when it left the app store, but whether the application remains trustworthy at the exact moment the API request is made.

Protect the Communication Channel (MitM Protection)

A genuine app means nothing if the connection to the backend is compromised. Institutions must enforce Dynamic Certificate Pinning to ensure that attackers cannot intercept, view, or modify API traffic, even if they manage to install a rogue root certificate on the user's device.

Verify the Device and Hardware-Backed Evidence

Hardware evidence is useful, but it should be independently evaluated alongside continuous application and runtime evidence. Keyboxes are in active circulation today that pass Play Integrity as genuine hardware. Relying solely on standard attestation verdicts leaves a window where credential stuffing farms and automated bots operate with a valid hardware identity.

Protect the Mobile API Relationship

The backend should not accept a request merely because its syntax is correct, because it contains a static API key, or because the user provided the right password.

It should be able to verify that the request originated from a genuine, current, and untampered application instance. This is achieved by binding short-lived, cryptographically signed tokens to API requests—turning mobile API access into an enforceable trust decision rather than a client-side puzzle.

What We have Built at Approov

Approov has spent years protecting high-risk applications and APIs from evolving threats. As the attack surface expanded, our focus shifted from just the mobile application to securing the entire mobile API channel.

We have built a comprehensive suite designed specifically for this reality:

• Approov Mobile App Attestation: Continuously verifies that the app is genuine, untampered, and running in a safe environment, issuing short-lived cryptographic tokens only to passing apps.
• Dynamic Certificate Pinning: Protects the channel from Man-in-the-Middle attacks, managing certificate rotation dynamically without requiring app updates.
• Approov API Threat Protection: Ensures your backend can easily inspect Approov tokens at the edge, blocking scripts, bots, repackaged apps, and hostile environments before they ever hit your core business logic.

These are not disconnected features. Together, they establish a chain of trust across the application, runtime, device, communication channel, and backend API.

That is true mobile channel protection.

Google Secures Android. Banks must Secure the API Channel.

The next generation of mobile fraud will not be defeated by asking only whether an operating system is secure or if a credential is correct.

The decisive question is more specific:

Can this exact API request, from this exact application instance, on this exact device, in this exact runtime state, be trusted right now?

Google secures Android, Apple secures iOS, and device vendors secure hardware.

Financial institutions must secure the API interaction across all of them. Attackers do not need to defeat the future. They only need to find one weakly authenticated endpoint that your backend still trusts.