The Latest OS-Level Protections & Why Mobile App Security is Essential

Since day one, Google and Apple have integrated security features into their respective operating systems, Android and iOS. However, as mobile devices have grown to become near ubiquitous, so, too, have the attacks targeting them. In 2025, 43% of surveyed organizations cited mobile app threats as a top contributor to mobile security breaches, according to a report by Verizon. In response, Google and Apple have continued introducing stronger and more refined security tools and features with each new release.

This has understandably led many organizations and security leaders to believe that these OS-level protections are sufficient to protect their mobile applications. However, that is not the case. For developers and security teams responsible for mobile application development and release, whether a banking app, a mobile game or an authentication SDK, a dedicated mobile application security solution is needed in tandem with OS-level protections in order to minimize the risks of reverse engineering and runtime tampering.

What OS-level protections do well

OS-level protections are built with a primary focus: safety for both device and user. The protections weren't designed to comprehensively answer a different question: is this app's code still trustworthy once it's out in the world, running on a device the developer doesn't control?

Spam and scam protection

One of the main goals of OS-level protections is to guard users against social engineering attacks. Android has various features that will, for example, detect and flag unsafe links in Google Messages as well as identify callers that are outside the user’s contacts list and evaluate if they are spam. Similarly, Apple introduced a call screening feature with the release of iOS 26. When an unknown number dials, the OS will ask the caller for their name and the purpose of their call. It will then transcribe the answer into a notification that is shown to the user, who then decides whether to pick up the call or not.

Stolen device protection

Many OS-level protections aim to safeguard a user’s data in case of theft. For example, if a user’s device is located away from familiar places like work or home, iOS will require biometric authentication for sensitive actions such as changing passwords. Google, on the other hand, released AI Theft Detection for Android, a feature that can detect when the user’s phone is snatched from their hands and can subsequently lock the phone.

Advanced protection features

Both iOS and Android offer a global toggle that activates an entire set of advanced security features (“Advanced Protection Mode” for Android, “Lockdown Mode” for Apple). Among others, this includes the following:

• Android prevents apps not classified as accessibility tools from utilizing the accessibility services API
• Android prevents the user from installing any app that wasn’t downloaded from the Google Play Store
• Lockdown Mode will block most attachments within the messaging app, as well as blocking FaceTime calls from people who are not in the user’s contact list

However, a question remains: what happens if an app runs in an unsecure environment, such as a rooted device or an emulator, where platform safeguards can be bypassed? And more importantly, if OS-level protections aim to protect the user and their device, what is protecting the app and the sensitive data passing through it?

Where OS-level protections fall short

OS-level protections have one primary aim: protection of the user, their device, and sensitive data against social engineering attacks. But what they can’t do is protect against technical vulnerabilities inside the mobile app itself. In other words, OS-level protections cannot control what attackers do with an app running in an unsafe environment, such as on a rooted or jailbroken device. Let’s look at a few examples:

Fake apps, real consequences

Malicious actors will often create a fake version of an authentic app, such as a banking app or a gaming app, and embed it with malware. They will then distribute it through a sophisticated phishing campaign, whereby users receive an email with a link to download an “urgent update”. In this case, users are tricked into sideloading from sources other than an official app store, bypassing platform-level controls. In the case of banking or fintech apps, the fake app may request accessibility permissions and silently monitor the user's legitimate banking session, capture credentials, or automate taps to initiate unauthorized transactions.

Fake app versions like this erode brand trust and drive customer churn as victims blame the legitimate company. This creates direct financial exposure through fraud reimbursements, elevated support and investigation costs, plus regulatory scrutiny for enabling brand impersonation and customer harm.

Loss of revenue through app mods

Similarly, attackers will use a combination of static and dynamic analysis to understand a mobile app’s execution and logic. If they can decode which part of the app handles in-app purchases or which part of the app is responsible for displaying ads, they can create a new, “better” version of the app. However, in this specific case, “better” means better for the user, i.e. an app without ads, or access to premium content without paying the required subscription. These modded versions are then distributed through specialized stores, leading to substantial revenue loss for the company.

In this case, the user is no longer a victim that needs to be protected, but also a "malicious actor" who can willingly disable most of the OS-level protections, or even simply run a rooted or jailbroken device, bypassing most of Apple and Google built-in security features.

Lack of visibility into real-time attacks

It’s also important to note that neither Google nor Apple send raw telemetry data to app developers about specific devices running compromised versions of their app. In practice, this means that if a user runs an unsafe copy of a mobile app, the developer might never know that specific user is affected. App developers, therefore, cannot rely on OS-level protections to be notified and develop counter-measures to attacks targeting their mobile apps.

What this means for your app

OS-level security provides essential guardrails on the user-side against social engineering attacks as well as physically compromised devices (such as in the case of loss or theft). However, this is only one side of the equation. A dedicated mobile app security approach aims to complement this with code-level protections against reverse-engineering, tampering, and API abuse. Without proper mitigation, these threats can lead to IP theft, fraud, financial loss, and reputational damage.

Take, for example, the case of the malicious modded app posing as a banking app. In-depth code obfuscation (through string encryption, control flow obfuscation, and other techniques) will make the process of understanding the app logic or uncovering sensitive keys significantly harder. App developers can combine this with runtime application self-protection (RASP) checks that detect if the app is running on a rooted or jailbroken device, or if a debugging attempt is occurring, providing maximum security against suspicious behavior at runtime. If such checks are triggered, pre-programmed actions can be launched such as terminating the session or limiting functionality.

Real-time threat monitoring tools go one step further by aggregating telemetry data whenever RASP checks are triggered, providing a real-time view into attacks occurring on the mobile app. This allows app developers to not only understand the ways in which malicious actors are attempting to deconstruct their app, but also deploy targeted preventive measures, something that isn’t possible when relying solely on OS-level protections.

It’s time to step up your mobile security posture

OS-level protections are undeniably critical to the cybersecurity landscape; they enforce resource permissions and shield users from external social engineering attacks like email phishing, smishing, and more.

However, attackers often run mobile apps in unsafe environments, such as on rooted or jailbroken devices, to study their logic and behavior. This is one example among many of when an advanced mobile application security strategy is required. Advanced code obfuscation makes reverse engineering much harder, while RASP security prevents tampering such as detecting jailbroken or rooted devices, hooking attempts, and more.

Interested in stepping up your mobile app security posture? Reach out to our team.