Due to time-to-market pressure and resource constraints, mobile app developers are shipping code that’s under-tested and under-protected. A recent Checkmarx report shows that the vast majority (81%) of organizations admit to knowingly shipping vulnerable code either sometimes or often. Maybe they know they have a problem and plan to fix it downstream. Or maybe they’re overconfident about their security approach. In the latter case, they have a problem nested inside another problem, like a Russian Doll.

Whatever the justification, shipping vulnerable code is a precarious proposition. Right now, the mobile app landscape is experiencing increasing threat activity, an expanding attack surface, and greater risk to businesses. According to Verizon’s 2025 Mobile Security Index:

  • 85% of organizations are seeing a surge in mobile attacks.
  • 80% of organizations reported mobile phishing attempts targeting their employees.
  • 43% of organizations cited mobile app threats as the top contributor to breaches.

Verizon’s data also shows that most companies are taking the risks seriously to some degree. Mobile security investments are on the rise: 75% of organizations increased mobile security spending in the past year, and 76% expect their mobile security budgets to increase again in 2026.

But investments for the sake of investments won’t fix the problem (let alone the problem within the problem). There’s some relevant context here that almost no one is talking about. So let’s look at three inconvenient (but essential) truths to help you effectively secure your mobile apps in the coming year.

#1: Mobile applications need purpose-built testing and protection.

Maybe you’ve heard this one: “Code is code. It’s all the same.” When it comes to comparing web apps to mobile apps, that’s a load of listeria-contaminated baloney (conveniently cheap but completely toxic advice).

The truth is that mobile apps need purpose-built security that combines both testing and protection capabilities. Device and OS-level protections do not extend across critical mobile app attack surfaces. Retrofitted or cross-purposed web application security solutions are not designed for the specific nature of mobile apps. OWASP started providing separate testing guidance and verification standards for mobile applications for a reason – because their operational distinctions require a customized approach to security.

Once a mobile app is released, it doesn’t sit on a server behind multiple firewalls. It lives out in the wild – installed by anonymous users on unknown devices that can travel virtually anywhere in the world. This functional necessity exposes mobile apps to many more acute risks than common web applications. For example, an unprotected mobile app can be downloaded by an attacker, reverse-engineered, modified, repackaged, and re-released for malicious ends (e.g., stealing sensitive information, spreading malware, perpetrating fraud).

With the realities of “wilderness survival” in mind, effective mobile app security must be designed for specific environmental exposures. You may need to wear some kind of jacket at your office job (web app), but you’ll need a very different kind of purpose-built jacket as well as other clothing layers, tools, and safety checks to climb Mount Everest (mobile app). Similarly, mobile app development teams need to rigorously test their code for potential security issues and also incorporate multi-layered protections designed for some harsh realities.

Testing: “Better late than never” might be sound advice if you miss an oil change on your Prius, but not here. The earlier a security issue is found in the mobile app lifecycle, the easier (and less costly) it is to fix it, because the original circumstances of writing that specific code are still fresh in the developer’s mind. Continuous testing practices help teams identify, analyze, and prioritize critical issues in context. Security should be part of continuous integration (CI) by incorporating automated mobile application security testing (MAST) throughout the design, development, and testing phases, both before release and during ongoing maintenance.

Protection: Without multiple layers of built-in protection to preserve the integrity of the original code, an app is vulnerable to different forms of attack. What’s at stake may vary (a banking app has different risk tolerance than a mobile game), but the consequences can include IP theft, downtime, fraud, reputational damage, poor user retention, and regulatory fines.

  • Applying different code-hardening techniques can block static analysis of a reverse engineering attack or attempts by a threat actor seeking to extract secrets or sensitive information related to authentication, transactions, and in-app purchases. This should include things like name obfuscation, control flow obfuscation, code virtualization, and data encryption.
  • To counter dynamic analysis attacks, runtime application self-protection (RASP) offers built-in security checks within the mobile app code to monitor the app’s behavior in real time and then provide automated defensive responses.
  • Stop treating your mobile app like it lives on a server. It doesn’t. Application attestation is another essential runtime protection because it prevents API abuse by verifying that every frontend app on a mobile device is authentic, unmodified, and running in a secure environment. This helps to enforce dynamic security policies that automatically block bots and non-genuine apps from gaining access to backend resources.

#2: Security must be built into each phase of the mobile development lifecycle.

Beware of oversimplifying promises (“one-click!”) and buzzwords du jour (“no-code!” “low-code!” “AI-anything!”).

What often gets lost in the noise is that there are no easy answers with mobile application security. There’s no single point of protection or wrap-it-in-a-bow solution. No intelligent scanning tool will instantly find and fix all the coding issues. No perfect way to block all phishing attacks.

A proactive and comprehensive approach is one that applies mobile application security at each stage of the software development lifecycle (SDLC). It includes the aforementioned testing in the stages of planning, design, and development as well as those multi-layered protections to ensure application integrity post-release.

And, like development, security needs to happen in a continuous loop. This means real-time threat monitoring and continuous testing to help maintain the code, eliminate vulnerabilities, enhance user experience, and optimize performance.

#3: AI-based development tools need trust-based checks and balances.

The final “thing they’re not telling you” deals specifically with AI (and not because it’s on everyone’s 2025 bingo card).

This year, there have been countless hot takes proclaiming AI as a kingmaker in the app development world – enabling innovation and iteration beyond the speed of human thought. There have also been just as many warnings about “the rise of the machines” and other more subtle modes of fear-mongering. As Public Enemy warned way back in 1988, “Don’t Believe the Hype” – both the grandstanding and the pearl-clutching varieties.

The unsexy thing no one is really saying about AI is that the ultimate path forward lies somewhere in the gray zone. Gartner predicts that by 2028, 90% of software engineers will use AI code assistants. While these tools are already helping dev teams meet aggressive time-to-market goals, they’re also introducing high volumes of potentially serious security problems.

Those facts won’t do much to slow the wheels of progress. The inevitability of AI-assisted development reinforces a need for mobile app security that’s grounded in zero trust principles to enable its success.

Zero trust is ultimately about eliminating risk exposures based on implicit trust. To effectively do that, software development teams need tools for testing and protection that seamlessly integrate with their existing workflows and processes. The applied concepts of a zero trust architecture (ZTA) applied to a DevSecOps pipeline help authenticate each step in the mobile app development SDLC, enforce least-privilege access, and ensure continuous security validation.

GenAI coding tools and LLMs should be treated like any other identity in terms of least privilege access. And like code generated or obtained from any other source, it should be thoroughly tested, verified, protected, and monitored throughout its useful lifespan.

Why does it matter?

Whether stemming from overconfidence or just kicking the can down the road, inadequate mobile app security presents an existential risk. A recent survey of developers and security professionals found that organizations experienced an average of nine mobile app security incidents over the previous year. The total calculated cost of each incident isn’t just about downtime and raw dollars, but also “little things” like user experience, customer retention, and your reputation.

To recap, don’t compromise mobile app security in favor of development speed or user experience because all three are essential to your success. Choose security that’s purpose-built for mobile apps (testing and multi-layered protection, plus threat monitoring). Organizations need to ensure their security approach covers the full mobile application lifecycle and adheres to the core principles of zero trust.