Mobile apps run on devices you do not control, so a security requirement that cannot be traced to a test is a requirement nobody can prove was met. The OWASP Mobile Application Security Verification Standard (MASVS) is the reference set of 24 controls for mobile app security, and the MASWE weakness list and MASTG test cases turn each control into something a tester can verify. This guide is the standard itself: every control group and control, how the MAS profiles decide which tests apply, how the three OWASP documents fit together, how to write MASVS into requirements and contracts, and what a defensible claim of compliance looks like. It is for application security leads, mobile architects and buyers who commission or accept mobile app assessments. For how to run the tests, see the Mobile App Security Testing Guide.
Key takeaways
- MASVS v2 has 24 controls in eight groups. STORAGE, CRYPTO, AUTH, NETWORK, PLATFORM, CODE, RESILIENCE and PRIVACY, each control written as a single outcome such as MASVS-NETWORK-2 "The app performs identity pinning for all remote endpoints under the developer's control."
- Levels moved out of the controls. Since v2.0.0 the L1, L2 and R levels no longer sit on controls; they became MAS profiles applied to weaknesses and tests, so one control produces different test sets for different risk levels.
- MASVS says what, MASWE says how it fails, MASTG says how to test. A finding should carry all three IDs so it is traceable from requirement to evidence.
- MASVS covers the app, not the backend. The standard states it only covers the client side; pair it with the OWASP ASVS for the APIs the app calls.
- No one is "OWASP MASVS certified". OWASP does not certify vendors, verifiers or software, so treat trust marks with care and ask for scope, profile and evidence instead.
What the MASVS is and where it came from
The MASVS describes itself as a standard "to be used as a metric, guidance, and baseline for mobile app security verification", including "during procurement". It is maintained by the OWASP Mobile Application Security (MAS) project, which also publishes the Mobile Application Security Weakness Enumeration (MASWE) and the Mobile Application Security Testing Guide (MASTG, previously the MSTG). All three are OWASP flagship projects licensed CC BY-SA 4.0.
- Version 1.x: requirements were numbered MSTG-STORAGE-1, MSTG-AUTH-12 and so on, grouped under three verification levels (L1, L2 and R). Version 1.5.0 was the last of this line.
- Version 2.0.0: released on 1 April 2023. The project removed redundant controls, narrowed the scope so that server-side topics rely on standards such as the ASVS, and removed L1, L2 and R from the controls.
- Version 2.1.0: released on 18 January 2024 and still the latest release when we checked on 9 November 2026. It added the MASVS-PRIVACY group with four controls and a CycloneDX version of the standard (OWASP_MASVS.cdx.json) so controls can be consumed by tooling.
The MASVS is a living document. Its own text says the profiles were revisited in the 2023 MASVS refactoring and again in the 2026 MASWE refactoring, so always check the live site before you fix control IDs into a contract.
The 24 MASVS controls
The control statements below are the wording in the MASVS source as of November 2026. They are deliberately short and outcome based: the detail lives in MASWE and MASTG.
| Group | Control | Statement |
|---|---|---|
| STORAGE (data at rest) | MASVS-STORAGE-1 | The app securely stores sensitive data. |
| MASVS-STORAGE-2 | The app prevents leakage of sensitive data. | |
| CRYPTO | MASVS-CRYPTO-1 | The app employs current strong cryptography and uses it according to industry best practices. |
| MASVS-CRYPTO-2 | The app performs key management according to industry best practices. | |
| AUTH | MASVS-AUTH-1 | The app uses secure authentication and authorization protocols and follows the relevant best practices. |
| MASVS-AUTH-2 | The app performs local authentication securely according to the platform best practices. | |
| MASVS-AUTH-3 | The app secures sensitive operations with additional authentication. | |
| NETWORK (data in transit) | MASVS-NETWORK-1 | The app secures all network traffic according to the current best practices. |
| MASVS-NETWORK-2 | The app performs identity pinning for all remote endpoints under the developer's control. | |
| PLATFORM | MASVS-PLATFORM-1 | The app uses IPC mechanisms securely. |
| MASVS-PLATFORM-2 | The app uses WebViews securely. | |
| MASVS-PLATFORM-3 | The app uses the user interface securely. | |
| CODE | MASVS-CODE-1 | The app requires an up-to-date platform version. |
| MASVS-CODE-2 | The app has a mechanism for enforcing app updates. | |
| MASVS-CODE-3 | The app only uses software components without known vulnerabilities. | |
| MASVS-CODE-4 | The app validates and sanitizes all untrusted inputs. | |
| RESILIENCE | MASVS-RESILIENCE-1 | The app validates the integrity of the platform. |
| MASVS-RESILIENCE-2 | The app implements anti-tampering mechanisms. | |
| MASVS-RESILIENCE-3 | The app implements anti-static analysis mechanisms. | |
| MASVS-RESILIENCE-4 | The app implements anti-dynamic analysis techniques. | |
| PRIVACY | MASVS-PRIVACY-1 | The app minimizes 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. |
Reading the groups correctly
- STORAGE versus CRYPTO: STORAGE asks whether sensitive data intentionally stored is protected and whether it leaks unintentionally (logs, backups, keyboard caches). CRYPTO asks whether the cryptography and key management behind that protection are sound, and points to NIST SP 800-175B and SP 800-57 for what "industry best practices" means.
- AUTH: the MASVS is explicit that enforcement must happen on the remote endpoint. AUTH-1 covers the protocol the app uses (for example OAuth 2.0 with PKCE), AUTH-2 covers local biometrics and device credentials, AUTH-3 covers step-up for sensitive operations.
- CODE: despite the name it includes supply chain (CODE-3, known-vulnerable components) and update enforcement (CODE-2), which is how you retire builds with obsolete pins or keys.
- RESILIENCE: defence in depth against reverse engineering and tampering. The standard spends more words on this group than any other, discussing business, transparency, platform lock-in and malware-analysis perspectives, because resilience controls only make sense for some apps.
- PRIVACY: a baseline focused on what can be tested from the app. The MASVS warns that it "should never replace" a Data Protection Impact Assessment under the GDPR or other legal assessments.
How MASVS, MASWE and MASTG fit together
The MAS project describes a chain: MASVS to MASWE to MASTG. The MASWE README calls the weakness list "the bridge" between the standard and the testing guide, modelled on MITRE CWE and intended as a complementary, mobile-specific list.
| Document | Answers | Unit | Example |
|---|---|---|---|
| MASVS | What must be true of the app | Control (MASVS-GROUP-n) | MASVS-STORAGE-2: the app prevents leakage of sensitive data |
| MASWE | How that control typically fails, and which profile cares | Weakness (MASWE-nnnn), mapped to MASVS v2 controls, MASVS v1 IDs and CWE | MASWE-0005 Insertion of Sensitive Data into Logs, profiles L1 and L2, CWE 532 among others |
| MASTG | How to test for the weakness on each platform | Test (MASTG-TEST-nnnn), plus techniques, tools and best practices | MASTG-TEST-0203 Runtime Use of Logging APIs (Android); MASTG-TEST-0296 Sensitive Data Exposure in Logs (iOS) |
Some more examples of the chain, from the MASWE and MASTG sources as of November 2026:
- MASVS-NETWORK-1: MASWE-0026 Network Traffic Not Encrypted and MASWE-0027 Insecure Certificate Validation (profiles L1, L2), tested by MASTG-TEST-0217 Insecure TLS Protocols Explicitly Allowed in Code and MASTG-TEST-0236 Cleartext Traffic Observed on the Network.
- MASVS-NETWORK-2: MASWE-0028 Insecure Identity Pinning (profile L2), tested by MASTG-TEST-0242 Missing Certificate Pinning in Network Security Configuration and MASTG-TEST-0243 Expired Certificate Pins in the Network Security Configuration. See Certificate Pinning.
- MASVS-CODE-3: MASWE-0044 Dependencies with Known Vulnerabilities (L1, L2), tested by MASTG-TEST-0274 and MASTG-TEST-0275, which check the app's SBOM on Android and iOS.
- MASVS-AUTH-2: MASWE-0020 Local Authentication Can Be Bypassed and MASWE-0022 Crypto Keys Not Invalidated on New Biometric Enrollment (L2).
- MASVS-RESILIENCE-1: MASWE-0051 Root/Jailbreak Detection Not Implemented and MASWE-0054 Device Attestation Not Implemented (profile R). See Mobile App Attestation.
The MASTG is mid-migration. Many older tests now carry status: deprecated with a covered_by pointer to a newer test ID, and new tests map to MASWE rather than directly to MASVS. If a supplier's report cites MSTG-STORAGE-7 or an old test ID, ask them to translate it to the current MASVS v2 control and MASWE ID.
MAS profiles: choosing the depth of verification
Profiles decide which weaknesses, and therefore which tests, apply to a given app. In the MASWE source as of November 2026, each weakness carries one or more profile tags: of 79 weakness files, 29 are tagged L1 and L2, 21 L2 only, 15 R and 13 P. A further tag, EUDIW, appears on almost every weakness alongside the others.
| Profile | Name on the MAS site | Use it for | Decision notes (NHI Mgmt Group view) |
|---|---|---|---|
| MAS-L1 | Essential Security | Every app. The MASTG says L1 tests are "applicable to all mobile apps". | Make L1 the minimum release gate for every app you build or buy. |
| MAS-L2 | Advanced Security | Apps handling sensitive data or functions: banking, health, identity, enterprise access. | Apply where the app holds tokens with real reach, or where a regulator expects controls such as step-up authentication. |
| MAS-R | Resilience | Apps where reverse engineering or tampering harms the business: payments, anti-fraud, licensed content, games. | Add only after L1 and L2; resilience slows an attacker but does not replace server-side checks. |
| MAS-P | Privacy | Apps processing personal data at scale or sensitive categories. | Pair with your DPIA and store privacy labels; see Mobile App Privacy Labels. |
The MASVS states that applying profiles fully or partially "should be a risk-based decision made in consultation with business owners", and that deviations from recommended controls should be justified and documented. In practice: record the chosen profile per app, record every MASWE you scope out and why, and get the business owner to sign it.
Writing MASVS into requirements, contracts and pipelines
The standard lists several uses beyond testing: security architecture guidance, a replacement for off-the-shelf secure coding checklists, a basis for test methodologies, a guide for automated unit and integration tests and a syllabus for secure development training. It also allows forking, provided traceability to the original control IDs is kept.
Implementation steps
- Classify each app. Use your data classification and the app's function to assign L1, L2, R and P profiles. Record the decision in the app's risk register entry.
- Generate the requirement set. Filter MASWE by the chosen profiles to get the weaknesses in scope, and keep the MASVS control and MASWE ID on each requirement. The CycloneDX file in the MASVS release helps if your tooling consumes it.
- Write it into contracts. For outsourced builds and purchased apps, name the MASVS version, the profiles and the evidence expected (see the evidence table below), and require findings in MASVS and MASWE terms.
- Automate what can be automated. Static checks for logging APIs, backup configuration, network security configuration and dependency SBOMs map cleanly to MASTG tests and can run on every build. The MASVS is clear that automated tools alone cannot complete verification.
- Test before release. Run the manual and dynamic MASTG tests in scope against a release candidate, open book where possible.
- Cover the backend separately. Verify the APIs against the ASVS. See Application Security Requirements from ASVS.
- Re-baseline on change. Re-run the scoped tests when the profile changes, a major feature lands or the MAS project changes IDs, and keep the version of MASVS you assessed against on the report.
Small and large organisations
- One or two apps: adopt L1 as a pipeline gate, add L2 for any app that signs users in to sensitive services, and commission an external open-book test annually or on major release.
- App portfolio or vendor-supplied apps: keep a register of app, owner, profiles, MASVS version assessed and date of last test, and refuse acceptance without MASWE-traceable findings. Preloaded apps and SDKs are in scope too: the MASVS calls out both and recommends evaluating how it applies to each SDK you embed.
Evidence, certification and what "compliant" means
The MASVS recommends verifying compliance through an "open book" review, with testers given access to architects and developers, documentation, source code and authenticated access with at least one account per role. Any report must state the scope (especially anything out of scope), and summarise passed and failed tests with how to resolve failures. Running a tool and reporting its output is explicitly not sufficient.
| Evidence item | What it proves | Ask for |
|---|---|---|
| Scope statement | Which app build, platforms, profiles and MASVS version were assessed | Build hash or version code, MASVS v2.1.0 or later, profiles L1/L2/R/P |
| Per-control results | Coverage of all in-scope controls, not just the failures | Pass, fail or not applicable per MASWE, with MASTG test IDs |
| Justified deviations | That scoped-out weaknesses were a business decision | Signed risk acceptance per deviation |
| Work papers | Reproducibility | Proxy logs, screenshots, notes and a clean-up list |
| Backend assessment | That server-side controls were tested elsewhere | ASVS or WSTG-based report for the APIs the app calls |
OWASP states that it "does not certify any vendors, verifiers or software" and that trust marks claiming (M)ASVS certification are not vetted by OWASP. Third-party schemes do build on it:
- App Defense Alliance MASA: Google recognises apps independently validated against a set of MASVS Level 1 requirements, with the MASTG as testing criteria, and developers can show this in the Play Store Data safety section. The ADA site notes the programme is moving to new Mobile App Profile specifications, so check the current spec before you rely on it.
- CREST OVS: launched in August 2022, CREST's OWASP Verification Standard programme accredits testing providers against the ASVS and MASVS.
- Government standards: the MAS project lists adoption by bodies including NIST (SP 800-163 Rev. 1 on vetting mobile apps), Germany's BSI (TR-03161 for eHealth apps) and Singapore's Cyber Security Agency, whose Safe App Standard 2.0 covers eight areas that closely track the MASVS groups.
Where identity fits
Several MASVS controls are really about non-human credentials. MASWE-0004 Sensitive Data Hardcoded in the App Package and MASWE-0003 Cryptographic Keys Stored Outside of Platform Keystore cover API keys, cloud keys and signing material shipped in the binary. Symantec's 2022 research found hard-coded AWS credentials in 1,859 Android and iOS apps, many shared through third-party SDKs: see Mobile Apps Hard-Coded AWS Keys 2022. Treat any secret in an app package as public, issue short-lived scoped tokens from a backend, and use attestation (RESILIENCE-1) to raise the cost of token abuse. See Secrets in Mobile Apps.
Mapping MASVS to other frameworks
These mappings are NHI Mgmt Group's own reading of where MASVS work fits; the MASVS itself maps to MASWE and CWE, not to these frameworks.
| Framework | Reference | How MASVS supports it |
|---|---|---|
| NIST CSF 2.0 | PR.PS-06 Secure software development practices are integrated | MASVS requirements and MASTG tests are the mobile-specific practices and their checks |
| NIST CSF 2.0 | ID.RA-01 Vulnerabilities in assets are identified, validated, and recorded | MASWE-traceable findings recorded per app |
| NIST SP 800-53 Rev. 5 | SA-4 Acquisition Process; SA-11 Developer Testing and Evaluation | Contract clauses naming MASVS profiles; developer-run MASTG tests as evidence |
| NIST SP 800-53 Rev. 5 | SA-8 Security and Privacy Engineering Principles; SA-15 Development Process, Standards, and Tools | MASVS as the design baseline and secure coding standard for mobile teams |
| OWASP Mobile Top 10 (2024) | M1 Improper Credential Usage to M10 Insufficient Cryptography | Top 10 is an awareness list; MASVS is the verifiable requirement set behind it. See the OWASP Mobile Top 10 Guide. |
| OWASP ASVS 5.0 | Whole standard | Covers the server side the MASVS excludes |
Measuring adoption
- Coverage: percentage of production apps with an assigned profile and a MASVS assessment within the last 12 months (our suggested interval).
- Gate pass rate: percentage of builds passing the automated L1 checks first time.
- Traceability: percentage of findings carrying MASVS, MASWE and MASTG IDs.
- Deviation hygiene: number of scoped-out weaknesses without a signed, dated justification (target zero).
- Secret exposure: count of builds where secret scanning finds credentials in the package (target zero).
- Time to fix: median days from L2 finding to fixed release.
Common failure patterns
- Citing MASVS v1 IDs in 2026. Reports and contracts still say MSTG-STORAGE-14 or "Level 2". Ask for v2 controls, MASWE IDs and named profiles.
- Treating R as a substitute for L2. Obfuscation and root detection on an app that stores tokens in plain files does not meet the standard. Resilience is additive.
- Assuming the MASVS covers the API. It does not, by design. Apps fail most often through the backend they talk to: the T-Mobile API Breach 2023 shows how an abused API, not the app, exposed customer data.
- Accepting "MASVS certified" badges. Without scope, profile, version and per-control results, a badge proves nothing about your build.
- Ignoring SDKs. Third-party SDKs bring their own storage, network and credential behaviour; the MASVS asks you to assess how it applies to each.
- Freezing test IDs. The MASTG is replacing tests and the MASWE is being refactored; pin the version you tested against and re-map on update.
Practitioner checklist
- Assign MAS profiles (L1, L2, R, P) to every production app and record the business owner's sign-off.
- Build the requirement set from MASWE filtered by profile, keeping MASVS and MASWE IDs on each item.
- Name the MASVS version, profiles and evidence items in every mobile development and app procurement contract.
- Automate the static MASTG checks for logging, backups, network configuration and SBOM dependencies in CI.
- Commission open-book assessments with per-control results, not tool output.
- Scan every build for embedded secrets and move API access to short-lived backend-issued tokens.
- Assess the backend APIs against the ASVS in the same release cycle.
- Assess embedded SDKs against the same profiles as the host app.
- Re-check MASVS, MASWE and MASTG versions at least annually and re-map changed IDs.
Standards and references
- OWASP: Mobile Application Security Verification Standard (MASVS)
- OWASP: MASVS releases and changelog
- OWASP: Mobile Application Security Weakness Enumeration (MASWE) repository
- OWASP: Mobile Application Security Testing Guide (MASTG) repository
- OWASP: MAS Testing Profiles
- App Defense Alliance: Mobile Application Security Assessment (MASA)
- Cyber Security Agency of Singapore: Safe App Standard 2.0
Related NHI Mgmt Group resources: Mobile App Security Guide · Mobile App Security Testing Guide · OWASP Mobile Top 10 Guide · Secrets in Mobile Apps