1. Start
  2. Introduction
  1. Principles

  2. The big picture
  3. What needs protecting
  4. Develop a threat model for your application
  5. The four layers of mobile application protection
  1. Threats

  2. Decompilation and modification
  3. Dynamic analysis and tampering
  4. Emulators and Virtualization Apps
  5. Malware
  6. Network communications interception
  7. Mobile app fraud
  1. Practice

  2. Mobile app protection checklist
  3. Continuous security
  1. Summary
Threat Model

Guide Home Guide Home / Principles / 03 Develop a threat model for your application

Security starts with knowing what’s most important to your app and what’s attractive to potential attackers. This is where the mobile application threat model comes in. It’s the process of identifying assets, analyzing how they might be targeted, and finding the best ways to protect them.

What is a mobile application threat model?

A threat model is designed to identify three key elements:


Parts or components of your mobile application that an attacker is likely to target.


Modes of attacking your mobile application.


Security and protection mechanisms you can employ to deter the identified threats.

Why you need a threat model

A mobile application threat model provides you and your team with complete visibility of your app from a security perspective. It shines a light on the assets, how they might be attacked or compromised, and how you can protect them. This in turn allows you and your team to develop and deliver a safer mobile application for your end users.

A threat model also stops security vulnerabilities from getting all the way into the final product as early as possible. It can act as a solid foundation for testing and QA teams to write proper test suites. This helps to make sure that every line of code you write is safe and that all required or necessary security controls are in place and are working properly.

Having a threat model is also evidence that you’ve put robust security measures in place and have thoroughly considered protection throughout the mobile application lifecycle. This can help you to achieve industry compliance with regulations. And it can act as reassurance for your end users that you take security seriously.

Should you decide you need support from a third-party vendor to help protect your mobile app, a threat model can act as a requirements checklist, too. It can work as a quality gate to help you filter, compare, and choose the most appropriate protection solution.

The mobile application threat modeling processes

The best threat models are those created in a way that makes it convenient and easy for you and your team to understand them and communicate them with one another. 

Try to position your threat model from the attackers' perspective. As difficult as it sounds, you have to attempt to step into their shoes and think the way they would think. That’s why asset-centric threat modeling is the most effective and realistic approach you can take. 

It consists of the following steps:

Identify assets that might be targeted by attackers and are worth protecting

The first step is to identify exactly what needs to be kept secure and protected. 

As mentioned elsewhere in this guide, assets can be divided between three main categories:

Internal data and intellectual property (IP)

Restricted functionalities

Sensitive user data

All apps contain internal data and IP in their binaries; many provide restricted functionalities to authenticated users during runtime; and the majority process or provide access to sensitive user data. 

The precise balance of assets and their relative value to the attacker will vary from app to app. An important element of devising a threat model is to identify the exact assets, their value, and the threats they face, starting with how they may be accessed by an attacker.

Analyze your mobile application and points of exposure

The next step of the threat modeling process is to gain some understanding about how your system is built, and identify potential points of exposure for assets. It’s crucial for you to understand the internal and external components of your mobile app, including any data that may flow through it or which is contained within. This process is often called decomposition.

Internal components are:

These include:

External components refer to those that are not integral or specific to the application, but which nevertheless interact with it directly, including:

Once you have all the information you need about your mobile application, you can start to model it. You can represent it in a visual form like a diagram, a table, or any other way that makes it convenient for you and your team to understand it and reference it collectively.

Here’s an example:

Component Boundary (Attack Surface) Component Name Typical Asset(s) targeted by attackers


Code Files and Executables

  • Business logic (e.g. proprietary algorithms, encryption-decryption routine)
  • Cryptographic keys
  • Remote endpoint credentials


Runtime Memory

  • Business logic (e.g. proprietary algorithms, encryption-decryption routine)
  • Cryptographic keys
  • Remote endpoint credentials
  • Authentication tokens
  • Users’ data


App-specific storage

  • Business logic (e.g. proprietary algorithms, encryption-decryption routine)
  • Authentication tokens
  • Application-specific data (preferences, defaults, etc.)


Remote endpoints

  • Users’ data


Shared storage

  • Application-specific data (preferences, defaults, etc.)


IPC drivers

  • Cryptographic keys
  • Users’ data

Identify how attackers might target your mobile application assets

Now that you’ve identified your app’s assets and how they might be exposed, you can begin to assess how attackers could target and exploit them. The following pages in the Threats section of this guide are there to help you learn more about this topic. And resources such as the OWASP Mobile Application Security Testing Guide provide more information on how security testers (and attackers) probe apps for points of exposure.

Identify the appropriate security controls and mitigation techniques

Once you have a list of assets linked to the tools and techniques attackers use to exploit them, the next step is to identify the appropriate security and protection measures required for prevention and mitigation. Be careful though not to take a simplistic check-box method in threat mitigation. The best approach for protecting your mobile application is via a holistic and multi-layered defense that combines secure development with specific threat detection and comprehensive in-app protection.

For example, data-at-rest encryption might deter attackers with elevated privileges from compromising sensitive data in the file system. But detection of privilege escalation can also be implemented to prevent the app from operating with any sensitive data if privilege escalation (via rooting or jailbreaking) is detected.

And keep in mind that these protection measures themselves also need to be protected. After all, a root detection module is next to no use if it is not combined with protection against dynamic instrumentation frameworks and binary modifications. That’s why it’s crucial to focus on multiple mutually reinforcing layers of security and protection.

Next The four layers of mobile application protection