Key takeaways
- MASVS v2.1.0 was released on 18 January 2024, adding the new MASVS-PRIVACY control group (4 controls) and CycloneDX SBOM support.
- OWASP Mobile Top 10 2024 is the first major revision since 2016. Four categories are brand-new; the priority order has shifted dramatically. Improper Credential Usage (M1) is now the top risk; Inadequate Supply Chain Security (M2) is the second.
- Verification Levels (L1, L2, R) are gone from MASVS v2.0+ replaced by Testing Profiles in MASWE. RFP responses still asking for “MASVS Level 2” are working from a stale playbook.
- This article maps both standards, shows where they overlap, and gives a practical remediation order based on what we see scanning real mobile apps in 2024–2026.
If you build mobile applications and you have not refreshed your understanding of OWASP’s mobile guidance since 2023, you are working against an outdated map. Two significant updates landed within months of each other:
- OWASP MASVS v2.1.0 released 18 January 2024 the first significant revision since the v2.0.0 refactor of April 2023.
- OWASP Mobile Top 10 2024 released in May 2024 the first major refresh since 2016.
Together they redefine what “good” looks like for mobile app security. This is the practitioner’s guide to what changed, why it matters, and what to do about it before your next code review or audit.
What MASVS actually is, in 2026
The OWASP Mobile Application Security Verification Standard (MASVS) is the industry standard for mobile app security controls. It is part of the broader OWASP MAS project, which also publishes:
- MASTG (Mobile Application Security Testing Guide) the comprehensive how-to-test handbook
- MASWE (Mobile Application Security Weakness Enumeration) the catalog of weaknesses, replacing the old verification-level approach
- MAS Checklist the operational artefact testers and auditors actually use
MASVS is the standard. MASTG tells you how to test for it. MASWE catalogues the weaknesses. The MAS Checklist is what your auditor will hold in their hand.
The standard is divided into eight control groups in v2.1.0:
| Group | Focus |
|---|---|
| MASVS-STORAGE | Secure storage of sensitive data on the device (data at rest) |
| MASVS-CRYPTO | Cryptography used to protect sensitive data |
| MASVS-AUTH | Authentication and authorisation mechanisms |
| MASVS-NETWORK | Network communication security |
| MASVS-PLATFORM | Interaction with the underlying mobile platform |
| MASVS-CODE | Secure coding and binary protection |
| MASVS-RESILIENCE | Resilience against reverse engineering and tampering |
| MASVS-PRIVACY | NEW in v2.1.0 Privacy controls to protect user privacy |
That last group is the headline change.
The big change: MASVS-PRIVACY (new in v2.1.0)
The MASVS-PRIVACY control group was added to MASVS v2.1.0 in January 2024 in response to the increasing convergence of privacy and security requirements. It introduces four controls focused on user privacy specifically:
- MASVS-PRIVACY-1 The app minimises access to sensitive data and resources.
- MASVS-PRIVACY-2 The app prevents identification of the user.
- MASVS-PRIVACY-3 The app is transparent about data collection and usage.
- MASVS-PRIVACY-4 The app offers user control over their data.
These are not abstract principles. They map directly to obligations under DPDP (India), GDPR (EU), UAE PDPL, KSA PDPL all of which expect demonstrable, code-level privacy controls, not just policy documents. Building MASVS-PRIVACY into your scanner ruleset and into your release evidence pack is now the cleanest way to make a privacy lawyer’s life easier and your audit faster.
The big change: Verification Levels are gone
This is the change that catches RFP writers and procurement teams off guard.
Up to MASVS v1.x, the standard defined three “verification levels”:
- L1 (basic security)
- L2 (defence in depth)
- R (resilience against reverse engineering)
Many organisations wrote these into their procurement specifications: “the platform must support MASVS L2 testing.” That language is now stale. Starting from v2.0.0, MASVS does not contain verification levels. The concept was replaced by MAS Testing Profiles, which were moved to MASWE.
The MAS Checklist still surfaces the old level associations as a temporary measure during the migration, but in any new RFP or vendor specification, the correct framing is:
- “We require coverage of MASVS v2.1 control groups [list applicable]”
- “We require testing aligned to MAS Testing Profiles defined in MASWE”
Not “we require MASVS L2.” If your supplier still writes that, gently update them.
OWASP Mobile Top 10 2024 what changed
The OWASP Mobile Top 10 is a separate project from MASVS, focused on awareness rather than verification. The 2024 release is the first major refresh since 2016 meaning many in-house mobile teams and pentest reports are still working off the eight-year-old list.
The 2024 categories, in order:
| # | 2024 Category | Notes |
|---|---|---|
| M1 | Improper Credential Usage | NEW priority. Hardcoded secrets, insecure transmission and storage of credentials, weak auth methods. |
| M2 | Inadequate Supply Chain Security | NEW category. Compromised third-party SDKs, build-time injection, malicious dependencies. |
| M3 | Insecure Authentication / Authorisation | Reordered. Weak session management, broken access control. |
| M4 | Insufficient Input / Output Validation | NEW emphasis. Injection-class flaws on both client and API surfaces. |
| M5 | Insecure Communication | Reordered. Weak TLS, certificate pinning failures. |
| M6 | Inadequate Privacy Controls | NEW category. Mirrors MASVS-PRIVACY emphasis. |
| M7 | Insufficient Binary Protections | Reordered. Lack of obfuscation, anti-tamper, root detection. |
| M8 | Security Misconfiguration | Renamed and broadened. Insecure defaults, exposed debug endpoints. |
| M9 | Insecure Data Storage | Demoted. Still important; less prevalent than M1. |
| M10 | Insufficient Cryptography | Demoted. Weak algorithms, poor key management. |
Four new or significantly reframed categories: M1 (Improper Credential Usage), M2 (Inadequate Supply Chain Security), M4 (Insufficient Input/Output Validation) and M6 (Inadequate Privacy Controls). The rest are 2016 categories reordered to reflect the empirical prevalence in mobile apps over the past decade.
The most striking shift is M1 to the top. Hardcoded API keys, AWS credentials, OAuth secrets baked into APKs and IPAs have been the consistent #1 finding across mobile pentest engagements for several years research by CloudSEK in 2021 estimated roughly 1 in 200 Android apps was leaking AWS credentials through hardcoded API keys, and the rate has not improved.
How MASVS and Mobile Top 10 map to each other
The two documents are designed to be complementary, not competing. MASVS gives you the controls you need to verify; the Mobile Top 10 gives you the risks organised by what attackers are actually exploiting.
A practical mapping:
| Mobile Top 10 2024 | Primary MASVS v2.1 control groups |
|---|---|
| M1 Improper Credential Usage | MASVS-AUTH, MASVS-CODE |
| M2 Inadequate Supply Chain Security | MASVS-CODE, MASVS-PLATFORM |
| M3 Insecure Authentication / Authorisation | MASVS-AUTH |
| M4 Insufficient Input / Output Validation | MASVS-CODE, MASVS-NETWORK |
| M5 Insecure Communication | MASVS-NETWORK |
| M6 Inadequate Privacy Controls | MASVS-PRIVACY |
| M7 Insufficient Binary Protections | MASVS-RESILIENCE |
| M8 Security Misconfiguration | MASVS-PLATFORM, MASVS-CODE |
| M9 Insecure Data Storage | MASVS-STORAGE |
| M10 Insufficient Cryptography | MASVS-CRYPTO |
Use the Mobile Top 10 to communicate risk to executives and product owners (“we have an M1 finding”). Use MASVS to drive engineering remediation and audit evidence (“we now satisfy MASVS-AUTH-2 with this fix”). They are two different views of the same data.
Practical remediation priorities what to fix first
Based on real scan data across hundreds of mobile apps in GCC and India in 2024–2025, the empirical priorities for an existing app trying to clean up against MASVS v2.1 + Mobile Top 10 2024 are:
Priority 1 Credentials (MASVS-AUTH, MASVS-CODE / Mobile Top 10 M1). Find every hardcoded secret in your binary. This is the single highest-impact, lowest-effort remediation in mobile security. Tools that produce false positives here are common; verify each finding manually. Move secrets to: server-side fetching at runtime (best), platform secure storage with attestation (good), or build-time substitution with restricted-scope keys (acceptable for some categories). Never to: source code, asset files, BuildConfig fields, or third-party SDK initialisation parameters.
Priority 2 SDK supply chain (MASVS-CODE / Mobile Top 10 M2). Generate an SBOM (CycloneDX format explicitly supported in MASVS v2.1.0) for every app on every release. Identify SDKs with known CVEs. Identify SDKs with vendor risk profiles you would not accept in your supply chain. Identify SDKs that exfiltrate personal data without your control. This is now a privacy control as much as a security control.
Priority 3 Local data storage and crypto (MASVS-STORAGE, MASVS-CRYPTO / Mobile Top 10 M9, M10). Are you using SharedPreferences (Android) or NSUserDefaults (iOS) for anything sensitive? Are you using SHA-1 or MD5 anywhere? Are you using AES-128-ECB? These are the classic findings. Ship Android Keystore / iOS Keychain with platform-bound keys. Move to AES-256-GCM. Audit for accidental crypto downgrades when supporting older OS versions.
Priority 4 Network controls (MASVS-NETWORK / Mobile Top 10 M5). Certificate pinning on your backend domains. Public-key pinning over certificate pinning where operationally feasible (cleaner rotation). Avoid TrustManager overrides that disable validation in debug builds and accidentally ship to production.
Priority 5 Privacy controls (MASVS-PRIVACY / Mobile Top 10 M6). Audit every permission your app declares against the data your app actually uses. Audit every analytics SDK, attribution SDK, crash-reporting SDK against your published privacy notice. Implement consent capture per purpose, with audit log. This is the priority that will compound: every regulator from DPDP to GDPR is moving in this direction.
Priority 6 Input/output validation (MASVS-CODE / Mobile Top 10 M4). Particularly relevant for hybrid apps using WebView and for apps with deep-link / intent-handling. Sanitise everything that crosses a trust boundary.
Priority 7 Binary protections (MASVS-RESILIENCE / Mobile Top 10 M7). Threat-model dependent. A consumer banking app with high-value transactions needs root detection, anti-debug, anti-tamper, certificate pinning, runtime integrity. A B2B productivity app probably needs less. Don’t over-invest here at the expense of the more impactful priorities above.
How to test against both standards
The full coverage requires three distinct tooling layers, not one.
Layer 1 Static analysis (SAST + binary). Catches: hardcoded secrets, weak crypto, insecure storage patterns, missing pinning, exported activities, debug flags, SDK CVEs. Maps to: most of MASVS-STORAGE, MASVS-CRYPTO, MASVS-CODE, MASVS-NETWORK (configuration), and Mobile Top 10 M1, M2, M9, M10.
Layer 2 Dynamic analysis (DAST on a real device or instrumented emulator). Catches: runtime auth bypasses, broken session management, certificate pinning that’s configured but not enforced, runtime crypto downgrades, behavioural privacy violations. Maps to: MASVS-AUTH (runtime), MASVS-NETWORK (runtime), MASVS-PRIVACY (behaviour), and Mobile Top 10 M3, M5, M6.
Layer 3 Manual penetration testing. Catches: business logic flaws, complex authorisation issues, novel attack chains, social-engineering-adjacent flaws. Maps to: anything that requires human creativity. This is the layer automated tools cannot replace but it’s also the layer where you get diminishing returns past 1–2 engagements per year per app.
A mature mobile security programme combines all three. Static + dynamic on every release, manual pentest annually or semi-annually, with automated continuous monitoring of the published versions.
This is what HEXMobileSuite is built for. The MPTL rule engine 124 production rules maps every finding to MASVS v2.1 control IDs and OWASP Mobile Top 10 2024 categories simultaneously. SBOM is generated in CycloneDX format on every scan. Reports are signed PDFs with the dual mapping clearly labelled. See [link to /owasp-masvs] for the full rule-to-control mapping, or run a free scan at hexmobsuite.hiesencyber.com to see your app against both standards.
Where MASVS and Mobile Top 10 are heading
OWASP MAS is an active project. A few signals worth tracking:
- MASWE expansion. MASWE the weakness enumeration that replaced verification levels is actively being filled out. Expect more granular weakness IDs through 2026, which will let scanners and reports get more specific.
- MAS Checklist consolidation. OWASP is converging on the MAS Checklist as the single operational artefact for mobile audit. If your supplier doesn’t reference it, ask why.
- Privacy convergence. MASVS-PRIVACY will likely expand. The four controls in v2.1.0 are a foundation; v2.2 or v3.0 will likely add controls on cross-border data transfer, retention, and consent specifically.
What to do this quarter
- Update your internal mobile security standard. Reference MASVS v2.1.0 and Mobile Top 10 2024 explicitly. Strike out references to verification levels.
- Audit your current scanner output against the new mapping. If your tooling still maps to MASVS 1.x or Mobile Top 10 2016, schedule the upgrade.
- Run one app through a current MASVS v2.1 scan. [link to /free-scan] 30 minutes, no credit card, gets you a signed PDF with the dual mapping.
- Brief your engineering leads on M1 and M2. Hardcoded credentials and SDK supply chain are now the top two risks; remediation has to start in code review, not in pentest.
- Add MASVS-PRIVACY to your privacy programme inputs. The MASVS-PRIVACY-1 to PRIVACY-4 controls are the cleanest engineering bridge to your DPDP / GDPR / PDPL obligations.
The two standards together are the working playbook for mobile security in 2026. Use them.
HEXMobileSuite’s MPTL rule engine maps every finding to OWASP MASVS v2.1 and OWASP Mobile Top 10 2024 simultaneously. CycloneDX SBOM generated on every scan. Signed PDF reports with dual mapping. Try free at hexmobsuite.hiesencyber.com.