Protecting Mobile Applications in a Zero Trust World

In the beginning, there was implicit trust. Networks were originally designed around the idea that all the digital assets within an organization could be protected with strong perimeter defenses (e.g., firewalls). If a user was deemed worthy to cross that perimeter and enter the network, they were generally trusted to do the right thing. But it didn’t take long for people to start abusing all-or-nothing access controls and feast at the tables set by implicit trust.

Over time, a broad array of security solutions and controls emerged to protect the different digital parts of organizations (devices, user identities, apps, data, etc.) from internal and external threats. But cybersecurity architectures were still largely designed around the core concept of implicit trust and centralized perimeter-based defenses.

In early 2020, COVID became a forcing factor for rapid network decentralization. Security teams scrambled to try and protect organizations that were suddenly transforming into “everything, everywhere, all at once” architectures. That’s when “zero trust” became an overnight buzzword. But it would be a huge mistake to write-off zero trust with other early pandemic trends like baking sourdough bread and homemade hand sanitizer.

What is zero trust?

Zero trust’s prime directive is to break with the old time religion of implicit trust in favor of first verifying (both user and device – plus relevant contextual clues like geolocation and time of day) and then assigning only the precise amount of access required for the specific transaction (known as “least privilege access”). Security must now make more complex decisions and provide answers beyond yes or no. What’s the user’s organizational role? How sensitive is the resource? Does the request deserve full access or will “read only” suffice? Is there anything suspicious about where, when, or how the request is coming in?

Zero trust doesn’t mean that no one is ever trusted. The common shorthand is “trust but verify”.

The “zero” is what everyone starts with and the “trust” is limited to what’s needed under each very specific circumstance. Because of the ongoing contextual references, some people prefer the term “continuous adaptive trust”.

A zero trust framework will still include many traditional perimeter protections for networks and on-prem business infrastructure, while extending new protections to users (at home, on-site, and in-between), devices (including mobile), and applications (wherever they live), as well as data (at rest or in motion). And it’s not just about traditional IT systems anymore. It applies to IoT smart devices, OT industrial control systems, as well as distributed workflows and processes (like DevOps). It touches branch offices, remote workers, third-party vendors, and extended supply chains.

The shape of everything, everyone, everywhere

Zero trust’s broad and abstract nature has also led to some confusion. Controlling access (of users, devices, etc.) is often the focus with zero trust, perhaps due to the popular Zero Trust Network Access (ZTNA) solution model for securing remote access to network resources (primarily applications). But Zero Trust Architecture (ZTA) offers a more generally applicable conceptual reference. NIST SP 800-207 outlines the basic tenets:

• All data sources and computing services are considered resources.
• All communication is secured regardless of network location.
• Access to individual enterprise resources is granted on a per-session basis.
• The enterprise monitors and measures the integrity and security posture of all owned and associated assets.
• All resource authentication and authorization are dynamic and strictly enforced before access is allowed.
• The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture.

NIST also very specifically calls out both internal and external applications as things that need to be secured according to zero trust principles:

Because of how modern applications are now built, trust across the broader software supply chain is also implicated. SDKs (often sourced from third parties) must be verified, secured, and monitored to protect them from becoming vectors for vulnerabilities or data exfiltration.

But even with the NIST guidelines in hand, a ZTA still isn’t a singular product or platform and there’s no prescriptive set of boxes to tick to arrive at a functional solution. So how do we proceed?

Without a defined perimeter, everything that we need to protect now lives in the wilderness – pounded by attacks, surrounded by unknown threats, and regularly exposed by newly discovered vulnerabilities. By accepting the hostile nature of the world as one big open network, it helps to think about security as a holistic problem with many situational solutions: different layers of continuous protection, control, and monitoring. It also helps to put security as close as possible to wherever it’s needed.

Applying a zero trust mindset to mobile applications

The nature of mobile applications tests the furthest limits of decentralization. Once front-end applications are released, they get installed on unknown devices by anonymous users and they can then travel virtually anywhere in the world. Accordingly, mobile apps must operate outside of trusted networks and controls, so any and all transactions are inherently untrusted. But the trust issues begin even before all this, starting with how these applications are designed and developed.

To earn and maintain a loyal user base, organizations need to verify trust throughout the entire lifecycle of the mobile applications they publish at every interaction point, not just access authentication. In DevOps environments, this means making sure that the original code they write is tested for flaws and that any open-source or third-party components are thoroughly checked for errors, vulnerabilities, and malicious content. Despite the convenience and cost savings offered by the extended software supply chain, there are a variety of hidden risks. For example, many mobile apps rely on SDKs for critical functionality (such as analytics or payments). Implicit trust of a compromised SDK could introduce a critical vulnerability or hidden malicious code insertion that undermines the entire app.

Post-release, applying a zero trust mindset means ensuring that the code is hardened with multiple layers of encryption and obfuscation to make reverse engineering much more difficult. It should also include runtime integrity checks that understand the application logic in real-time to protect against tampering, fraud, and data extraction risks. When a mobile app calls an API to request backend services (like account access), that interaction also needs to be verified to make sure it’s a legitimate application and not a cloned version designed to extract sensitive data or spread malware.

Recent findings from Sensor Tower’s State of Mobile 2025 Report highlight the importance of effective mobile application security going forward. Global user habits show increasing reliance on mobile apps as well as an expanding potential attack surface.

• Last year, the average person on Earth spent >500 hours using mobile apps (both iOS and Android) – a YoY increase of 5.8%.
• The average time spent per user/per day was 3.5 hours (+2.9% YoY).
• The number of apps used per user/per month was 26 (+9.2% YoY).
• In-app purchase revenue swelled to $150 billion worldwide (+12.5% YoY).

There are also real opportunities for exploitation within that expanding target. Researchers discovered more than 815,000 hardcoded secrets within a sample o f 156,000+ iOS apps, including thousands of very sensitive secrets and could directly lead to breaches or data leaks. From Q4 2024 to Q1 2025, the number of detected Android-based malware samples increased by more than a quarter (27%). Other common mobile app vulnerabilities include inadequate encryption, insecure data storage, and unsecured third-party libraries. The consequences of a successful attack can be significant: from downtime, to reputational damage, to legal fees and regulatory fines.

Solution: Securing the mobile app lifecycle

Applying zero trust principles to mobile applications is ultimately about eliminating risk exposures based on implicit trust. To achieve this, developers and DevOps teams need an integrated, multi-layered approach to security that deploys effective solutions across all phases of the software development lifecycle (SDLC). ZTA principles applied to a DevSecOps pipeline authenticates each step in the mobile app development process, enforces least privilege access, and ensures continuous security validation.

Code testing

While faster time-to-market will continue to be a pressure on developers and DevOps teams, over-prioritizing speed has shown to increase gaps in governance, risk, and security due to implicit trust of the modern software supply chain. Throughout the development process, organizations must ensure that all code is functional, secure, and trustworthy, regardless of its origin. Developers need to maintain quality by finding and remediating flaws and security issues while preserving visibility of dependencies (i.e., SDKs and libraries). This is especially true as they expand use of third-party/open source components and embrace new AI-based tools to accelerate dev cycles. Generative AI coders should be treated like any other identity in terms of least privilege access, and their results should be thoroughly tested and verified.

Mobile Application Security Testing (MAST) covers the processes and tools used to identify potential problems in mobile applications. Some tools also provide input to remediate identified issues and reduce risk. MAST can be performed manually or through the use of automated tools which apply a variety of techniques:

• Static testing (SAST) analyzes the source code, the binary, and other resources of the app for specific security issues at rest (without executing the application code).
• Interactive testing (IAST) is a form of dynamic analysis that checks the application while the app is running via an automated test, human tester, or any activity “interacting” with the application functionality. The application is instrumented, which allows for a more detailed assessment of the application. For example, it can provide detailed visibility of API calls (providing valuable contextual information like geolocation) to help verify and validate third-party libraries and other dependencies.

Application protection

As soon as a mobile application is launched on an app store, anyone can download it, including those with bad intentions. Threat actors will try to analyze and then exploit a mobile app any way they can – whether it’s by stealing innovative features, inserting malware, or reverse engineering and modifying a version of the app for their own malicious purposes.

To repel these common attacks in the wild, mobile app publishers need sophisticated runtime code protections against reverse engineering and tampering. This should include:

• Code hardening that applies multiple layers of obfuscation and encryption to enforce application package integrity.
• Runtime Application Self Protection (RASP) that continuously ensures code integrity during operation. RASP monitors both the app itself as well as the environment it’s running in (such as a jailbroken/rooted device). When a runtime threat is detected, the RASP features help defend against threat actors attempting to tamper with the app or perform a dynamic analysis.

API integrity

New research shows that 99% of organizations experienced API security incidents in the past year. A big part of these problems comes from untrustworthy “evil twin” mobile apps. Application publishers need API-level protection to verify that only a legitimate mobile app front-end (and not a bot, script, or cloned application that has been maliciously modified or tampered with) can interact with backend servers.

Mobile App Attestation guarantees that it’s an authentic application interacting with your APIs by preventing all non-genuine connection points. An effective app attestation solution uses tokens to ensure that APIs are not being abused and the application can be trusted. Tokens should be cryptographically signed and have a limited validation period. (But not all advertised app attestation services offer comprehensive protection against these kinds of attacks.)

Threat detection

In the wild, no environment or type of engagement should be entirely trusted. Mobile applications are continuously exposed to emerging and evolving threat variants that automatically apply both new and old tools and techniques, looking for any gaps or weaknesses that could compromise the app’s integrity.

Real-time threat monitoring continuously observes the mobile app in the field as the threat landscape evolves. Analyzing live threat data helps software developers understand how threat actors are attempting to compromise their apps. They can then take action on these real-time insights by isolating suspicious users or implementing security findings in version updates and future releases.

How Guardsquare can help

In many ways and for many reasons, the world was overdue for a redesigned approach to cybersecurity. As evidence of zero trust’s effectiveness, zero trust frameworks and “secure by design” guidelines referencing zero trust principles continue to be widely embraced by government policies, (e.g., US, Canada, UK, Australia) and specific industry regulations, such as the European Union’s DORA and NIS2.

A zero trust model like ZTA sets the key objectives, but developers still need an effective solution that’s purpose-built for multi-layered mobile app security across the SDLC. Guardsquare’s approach offers the industry’s most complete and comprehensive solution for mobile application security, covering all the aforementioned zero trust capability areas. Our solutions include:

AppSweep mobile application security testing, with SAST and IAST code analysis tools that deliver actionable insights for finding and fixing security issues without slowing down development cycles.

DexGuard (Android) and iXGuard (iOS) provide multiple layers of code hardening–including multiple obfuscation and encryption techniques–plus automated RASP capabilities to protect mobile apps from reverse engineering and tampering.

App Attestation verifies that the front-end app interacting with your APIs at runtime can be trusted as authentic (and not a malicious clone, bot, or script).

ThreatCast helps you monitor all your apps (both Android and iOS) with real-time threat detection insights that help you spot suspicious users and fine tune security controls in version updates and future releases.

Contact a Guardsquare expert today to learn more.