OWASP MASVS Level 2 was the defense-in-depth verification level in the older MASVS, meant for apps handling sensitive data such as financial and healthcare apps, adding stronger controls on top of the standard security baseline. The current MASVS, version 2.0, retired the numbered L1 and L2 levels and the separate resilience level, reorganizing the standard into eight control groups, and moved the level concept into testing profiles in the MASTG. So Level 2 today is best understood as applying the stronger, defense-in-depth end of each control group for a high-risk app: hardware-backed key storage, strong authenticated cryptography, robust authentication, pinned transport, careful platform use, and resilience controls like root or jailbreak detection layered on top.
Short answer
MASVS Level 2 meant defense-in-depth for sensitive apps, and MASVS v2.0 replaced the numbered levels with eight control groups plus MASTG testing profiles. Per the OWASP MASVS, the groups are MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE, and MASVS-PRIVACY. A Level 2, defense-in-depth app applies the stronger requirements across these, including hardware-backed key storage under storage and cryptography, and root or jailbreak detection under resilience. Per the OWASP MASTG, you verify these with the corresponding testing profile. Treat the checklist below as the plain-English translation of what Level 2 asks of a high-risk app.
What MASVS Level 2 means and the v2.0 change
MASVS Level 2 comes from the older structure of the standard, where verification had tiers: Level 1 was the standard security baseline every app should meet, and Level 2 was defense-in-depth, a higher bar for apps that handle sensitive data and face a stronger threat. A separate resilience set, often labeled R, covered anti-tampering and reverse-engineering resistance. Financial, healthcare, and similar apps were the typical Level 2 targets, because a breach of them is more consequential.
The current MASVS, version 2.0, restructured this. It retired the numbered L1 and L2 levels and the separate resilience level, and reorganized the requirements into eight control groups covering distinct areas of mobile security, with the level and depth concept moved into testing profiles in the companion MASTG. So there is no longer a formal Level 2 inside the standard itself. The idea it captured, applying stronger controls for a higher-risk app, remains valid and useful, and the practical way to pursue Level 2 today is to meet the demanding end of each control group and verify with the matching profile.
The control groups Level 2 spans
A Level 2, defense-in-depth posture spans all eight control groups, applying the stronger requirement in each. MASVS-STORAGE covers keeping sensitive data out of insecure storage. MASVS-CRYPTO covers using strong, standard cryptography correctly. MASVS-AUTH covers robust authentication and authorization. MASVS-NETWORK covers securing data in transit. MASVS-PLATFORM covers safe interaction with the operating system and other apps. MASVS-CODE covers code quality and safe handling of inputs and dependencies. MASVS-RESILIENCE covers resistance to tampering and reverse engineering. MASVS-PRIVACY covers protecting user data and honoring consent.
For a high-risk app, defense-in-depth means not treating any one group as optional and applying the stronger version of each. Where a standard app might use platform default storage, a Level 2 app uses hardware-backed key storage; where a standard app uses transport security, a Level 2 app adds pinning; and a Level 2 app adds resilience controls that a baseline app might skip. The checklist later in this piece walks the groups in this defense-in-depth spirit, and the two questions developers ask most, about hardware-backed keys and root detection, sit in the storage and resilience groups.
Hardware-backed keystore
A hardware-backed keystore is a core Level 2 expectation for protecting cryptographic keys, and the answer to whether you need one for a defense-in-depth app is yes. Instead of holding keys in software where a compromised app or device could extract them, you store them in the platform's hardware-backed key storage: the Android Keystore backed by secure hardware, including StrongBox where available, and the iOS Secure Enclave. Keys generated and kept there are not exposed to your app's process, and cryptographic operations happen inside the secure hardware, so the key material never leaves it.
This raises the bar significantly, because even an attacker who compromises the app cannot simply read the key. For a financial or healthcare app, using hardware-backed storage for keys that protect sensitive data is what the storage and cryptography controls expect at the defense-in-depth level. In practice, generate keys in the Keystore or Secure Enclave rather than importing them, use them for encryption and signing without extracting them, and require user authentication for the most sensitive keys where appropriate. Hardware-backed key storage is one of the clearest markers separating a baseline app from a Level 2 one.
Root detection and resilience
Root and jailbreak detection belong to the resilience group, which corresponds to the anti-tampering requirements a Level 2 or high-risk app typically adds, so the answer is that it is expected, with an important caveat. Resilience controls, including root and jailbreak detection, anti-tampering, anti-hooking, and obfuscation, raise the cost of attacking your app on a compromised device and are part of a defense-in-depth posture for sensitive apps. Including them is appropriate for the Level 2 tier.
The caveat is that resilience controls are defense-in-depth by definition and explicitly do not replace the other controls. Root detection can be bypassed on a device the attacker controls, so it is a hardening layer that deters and raises cost, not a security boundary you can rely on alone. This is the standard's own position: the resilience group supplements the storage, crypto, auth, network, and platform controls rather than substituting for them. So implement root detection and the other resilience measures for a Level 2 app, and at the same time keep your real security in the other groups and, where it matters, in server-side verification, since the resilience layer is the outer wall and not the vault.
The Level 2 defense-in-depth checklist
Translated to plain English, a Level 2 app should meet the stronger requirement in each group. For storage, keep no sensitive data in insecure locations and hold keys in hardware-backed storage. For cryptography, use current authenticated algorithms correctly and avoid weak ciphers and hardcoded keys. For authentication, verify identity robustly, prefer strong and multi-factor methods, and enforce authorization on the server. For network, use strong transport security with certificate pinning and validate it.
For platform, request only the permissions you need, handle inter-app communication and any web components safely, and mark sensitive screens secure. For code, validate inputs, keep dependencies current, and avoid unsafe patterns. For resilience, add root or jailbreak detection, anti-tampering, and obfuscation as defense in depth, backed by server-side attestation. For privacy, minimize the data you collect, disclose it accurately, and honor consent. Meeting the demanding end of each of these is what a Level 2, defense-in-depth app looks like in practice.
Testing it: profiles and environment
Verifying a Level 2 posture is done with the MASTG, which provides the test cases and, in the current model, testing profiles that align with the depth you are targeting. You work through the tests for each control group against your app, confirming that each control is present and behaves as intended, and for a defense-in-depth app you include the resilience tests that check whether your anti-tampering and detection hold up. This is how the abstract requirements become concrete pass-or-fail checks.
Do the testing responsibly and against your own app. Use a device or virtual instance you own, including a rooted or jailbroken one for the resilience tests, keep it isolated from personal accounts and production, and only test applications you are authorized to test. When you probe a control such as root detection to see if it can be bypassed, that is a legitimate resilience assessment of your own app that tells you how much the control adds. The environment for Level 2 testing is the same controlled setup used for any responsible mobile security assessment, applied across all eight groups.
Level 2 controls at a glance
Mapping each control group to its defense-in-depth focus makes the target concrete. The table below summarizes them.
| Control group | Defense-in-depth focus | Example control |
|---|---|---|
| MASVS-STORAGE | Keep sensitive data and keys protected | Hardware-backed key storage |
| MASVS-CRYPTO | Strong, standard cryptography | Authenticated encryption, no weak ciphers |
| MASVS-AUTH | Robust authentication and authorization | Multi-factor, server-side enforcement |
| MASVS-NETWORK | Secure data in transit | TLS with certificate pinning |
| MASVS-PLATFORM | Safe platform interaction | Least permissions, secure IPC and screens |
| MASVS-RESILIENCE | Resist tampering and reverse engineering | Root detection plus attestation |
Read the table as the spine of a Level 2 program: the storage and resilience rows hold the two questions developers ask most, hardware-backed keys and root detection.
Level 2 checklist
Working through these steps applies the defense-in-depth requirements. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Secure storage | Sensitive data and keys in hardware-backed storage | [ ] |
| Strong cryptography | Standard authenticated crypto, no weak ciphers or hardcoded keys | [ ] |
| Robust authentication | Server-enforced, multi-factor where appropriate | [ ] |
| Pinned transport | Strong TLS with certificate pinning and validation | [ ] |
| Minimal platform surface | Least permissions, safe IPC, secure sensitive screens | [ ] |
| Resilience layer | Root detection and attestation as defense in depth | [ ] |
The step that most defines Level 2 is hardware-backed storage of keys, since it separates a defense-in-depth app from a baseline one, while resilience adds the outer layer without replacing the others.
Assess your app against MASVS
Because a Level 2 program spans eight control groups, seeing where your app stands against them is the practical starting point, rather than assuming coverage. Knowing which controls are present and where sensitive data, keys, and permissions sit tells you what a defense-in-depth posture still needs.
A scanner like PTKD.com analyzes your build and reports issues such as insecure data storage, weak cryptography, leaked keys, over-broad permissions, and weak binary protections by severity, mapped to OWASP MASVS control groups, so you can see your app against the same categories a Level 2 checklist uses. To be clear about the boundary: PTKD covers what is analyzable from the build and does not perform every manual MASTG test, such as verifying your server-side authorization logic. It gives you a MASVS-mapped view of your app to prioritize the defense-in-depth work.
What to take away
- MASVS Level 2 was the defense-in-depth verification level for sensitive apps, and MASVS v2.0 retired the numbered levels, reorganizing into eight control groups with MASTG testing profiles.
- Pursuing Level 2 today means applying the stronger requirement in each control group, from storage and cryptography to resilience and privacy.
- Hardware-backed key storage, using the Android Keystore or iOS Secure Enclave, is a core Level 2 expectation, keeping key material out of your app's process.
- Root and jailbreak detection belong to the resilience group and are appropriate for Level 2, but as defense in depth that supplements the other controls, not a boundary to rely on alone.
- Verify against the MASTG on your own app, and use a MASVS-mapped scanner like PTKD.com to see where your app stands across the control groups.
