Mobile Application Penetration Testing Services (2026): Scope, MASVS Coverage and Cost

Quick answer: A mobile application penetration testing service tests the compiled app on iOS and Android against the OWASP Mobile Application Security Verification Standard, which defines 8 control groups and 24 controls, using the test procedures in the OWASP Mobile Application Security Testing Guide, which publishes 292 test cases, 163 for Android and 129 for iOS. Scope covers local storage, cryptography, authentication and session handling, network transport, platform interaction, code quality, resilience against reverse engineering and tampering, privacy, and the backend API the app calls. Testing runs 3 to 5 days per platform and 5 to 10 days for both, inside a 4 to 8 week calendar. Almost nobody publishes a mobile price: Software Secured publishes US$5,400 and Astra publishes tailored mobile pricing from US$2,200 per app on a shared codebase, and the rest of the category quotes. Stingrai delivers mobile engagements as fully human-led penetration testing by credentialed penetration testers from a CREST-accredited firm, scoped and quoted through Get a Quote, with published package prices for web application scope on the pricing page.

Every standard, control count, test count, price and regulatory quotation on this page was read from the named primary source on 11 September 2026 and links back to it. Where a provider publishes no figure, this page says "not published" instead of substituting a third-party estimate.

What a mobile application penetration test actually covers

The category has a real standard behind it, which is unusual and useful. The OWASP Mobile Application Security project publishes three things that fit together: the MASVS, which says what a secure mobile app must do; the MASTG, which says how to test whether it does; and the MASWE, a weakness enumeration that names the specific failure modes under each control.

The MASVS describes its structure plainly. The standard "is divided into various groups of controls, labeled MASVS-XXXXX, that represent the most critical areas of the mobile attack surface" (OWASP MASVS). There are eight of them, and a mobile engagement that does not state which eight it exercised is not testing to a standard.

Two things in that table are worth pausing on.

Platform interaction and resilience carry the largest test counts on both platforms. Together they account for 66 of the 163 Android tests and 60 of the 129 iOS tests, and they are the two groups a web application test has no analogue for. Inter-process communication, exported components, deep links, WebView bridges, screenshot and notification leakage, root and jailbreak detection, anti-hooking and anti-debugging: none of it exists on the server, and all of it is where a mobile engagement earns its fee.

Authentication carries only seven tests per platform, and that number is misleading. MASVS-AUTH-1 requires secure authentication and authorization protocols, and the control's own commentary notes that enforcement must happen on the remote endpoint. The authorization work in a mobile engagement mostly lands on the API, which is why backend scope belongs in the same engagement rather than a separate one six months later.

The 24 controls, stated by the standard

Each control is one sentence, published at mas.owasp.org/MASVS/controls with its mapped MASWE weaknesses. These are the sentences a report should answer against, per platform:

• Storage. The app securely stores sensitive data. The app prevents leakage of sensitive data.

• Cryptography. The app employs current strong cryptography and uses it according to industry best practices. The app performs key management according to industry best practices.

• Authentication and authorization. The app uses secure authentication and authorization protocols and follows the relevant best practices. The app performs local authentication securely according to the platform best practices. The app secures sensitive operations with additional authentication.

• Network. The app secures all network traffic according to the current best practices. The app performs identity pinning for all remote endpoints under the developer's control.

• Platform interaction. The app uses IPC mechanisms securely. The app uses WebViews securely. The app uses the user interface securely.

• Code quality. The app requires an up-to-date platform version. The app has a mechanism for enforcing app updates. The app only uses software components without known vulnerabilities. The app validates and sanitizes all untrusted inputs.

• Resilience. The app validates the integrity of the platform. The app implements anti-tampering mechanisms. The app implements anti-static analysis mechanisms. The app implements anti-dynamic analysis techniques.

• Privacy. The app minimizes access to sensitive data and resources. The app prevents identification of the user. The app is transparent about data collection and usage. The app offers user control over their data.

One change buyers still get wrong

MASVS v1 had three verification levels, L1, L2 and R, and plenty of requests for proposal still ask for "MASVS L2 coverage". The standard moved on. The MASVS page states that "starting on v2.0.0 the MASVS does not contain verification levels", that the three levels "have been reworked as MAS Testing Profiles and moved over to the OWASP MASWE", and that as a temporary measure "the OWASP MAS Checklist will still contain the old verification levels, associated with the current MASTG v1 tests" (OWASP MASVS).

The practical consequence: asking a provider for "L2" in 2026 is asking for a legacy checklist mapping. Ask instead for a per-platform coverage statement across the eight control groups, with the MASTG test identifiers exercised and the ones marked out of scope. That is auditable. A level label is not.

iOS and Android are two engagements, not one

Every provider that publishes a unit definition counts them separately. Astra's pricing page states the rule in one line: "Mobile is per platform, so an Android app and an iOS app are two targets" (getastra.com/pricing). The same page publishes the one exception worth knowing about: "If they share code base, we offer a tailored pricing starting from $2200/app depending on the scope."

The technical reason is not commercial. The two platforms diverge exactly where the findings are:

• Storage. Android apps use SharedPreferences, internal storage, external storage, SQLite and the Android Keystore. iOS apps use the Keychain, NSUserDefaults, Core Data and the Data Protection classes. The MASTG publishes 20 Android storage tests against 18 for iOS, and they are not the same tests.

• Platform interaction. Android exposes Activities, Services, Broadcast Receivers and Content Providers through the manifest, with intent filters and exported flags that a tester enumerates and abuses directly. iOS exposes URL schemes, universal links, app extensions and pasteboard behaviour. The attack surface has a similar size (36 Android tests against 35 iOS) and almost no overlap.

• Resilience. Root detection on Android and jailbreak detection on iOS are different checks, defeated by different tooling, on different device estates.

• Build pipelines. An APK or AAB and an IPA are produced by different toolchains, signed differently, and obfuscated differently. A finding in one is not automatically a finding in the other, even in a cross-platform framework, because the framework's platform channels are where the leakage usually happens.

Cross-platform stacks such as React Native and Flutter narrow the gap on business logic and widen it on packaging. A shared JavaScript bundle means shared logic flaws, which is why shared-codebase pricing exists. It does not mean shared transport behaviour: a Flutter app that pins certificates inside the Dart runtime will not be intercepted the same way as a native Android app that pins through the network security configuration, and a tester who assumes otherwise reports "pinning bypassed" or "pinning present" incorrectly.

Static and dynamic testing, and why one without the other is a partial test

A mobile engagement runs two information channels against the same target, and the useful findings usually come from the place where they disagree.

Static and binary analysis

The tester takes the shipped artifact, an IPA or an APK, and works on it at rest: decompiling, disassembling, reading the manifest or Info.plist, walking the strings table, inspecting embedded resources and third-party SDKs, and tracing data flow from input to dangerous sink. This is where hardcoded secrets, disabled transport protections, debuggable builds, weak cipher selection, over-permissive components and outdated bundled libraries surface.

Scale data says this channel still pays. Quokka's State of Mobile App Security, 2026, published 28 April 2026 from an analysis of more than 150,000 mobile applications across 2025, reports HTTP URLs present in 94.3% of Android apps and 61.7% of iOS apps, ECB mode ciphers in 68.1% and 24%, and hardcoded cryptographic keys in 47.8% and 17.6%. Those are indicators recovered from binaries at scale rather than validated exploits, which is precisely the point: a static pass tells you what is present, and a tester tells you whether it is reachable and what it is worth.

Source code access changes the economics of this phase rather than the phase itself. Cobalt's published mobile methodology states that its testers do not need access to application source code unless the client specifies it as a requirement (Cobalt). Black-box work on the binary is entirely viable. White-box work is faster per finding and reaches logic a decompiler obscures.

Dynamic and runtime analysis

The app then runs on a device while the tester watches and interferes. Traffic goes through an intercepting proxy. Runtime instrumentation, typically Frida or Objection, hooks methods to read arguments, patch return values and dump keychain or keystore contents. The tester exercises every role and workflow, tampers with requests, replays them, and drives the platform surfaces the binary exposes. Cobalt's published methodology names the toolset for this phase as MobSF, Frida, Apktool, Dex2Jar and Objection, with selection varying by engagement (Cobalt).

Jailbroken and rooted device testing

This is the part buyers most often scope out by accident, and it changes what the test can see.

A stock device enforces the sandbox. A rooted Android device or a jailbroken iPhone does not, which lets a tester read the app's private storage directly, attach a debugger to a release build, hook cryptographic calls and inspect keys in memory. That is the only way to answer MASVS-STORAGE-1 and MASVS-CRYPTO-2 honestly, because "the data is in the Keychain" and "the data is in the Keychain with the right protection class and access control flags" look identical from outside the sandbox.

Two objections come up, and both have clean answers.

"Our app blocks jailbroken devices, so this is unrealistic." Root and jailbreak detection is itself a MASVS control, MASVS-RESILIENCE-1, and the test is whether it can be bypassed, not whether it exists. Every provider worth hiring will bypass it and keep testing. If detection is the whole defence, an engagement that respects it measures nothing.

"Resilience controls are not in our threat model." A legitimate position for many apps, and the standard supports it: resilience raises the cost of reverse engineering rather than making it impossible. State the decision in the scope document rather than discovering it in the report. If the app handles payments, licensed media or offline entitlements, resilience is in the threat model whether it is in the scope document or not.

The backend API is in scope, and it is where the criticals live

A mobile app is a client. Almost every finding that makes a board slide lives on the other end of the connection: broken object-level authorization, missing function-level authorization, mass assignment, and business logic that trusts a value the client supplied.

MASVS-AUTH-1 says so directly in its own commentary: most apps connecting to a remote endpoint require user authentication and enforce authorization, and enforcement of those mechanisms must be on the remote endpoint. A mobile engagement that stops at the binary has tested the half of the system an attacker cares least about.

The practical scoping rule is simple. One engagement covers the iOS binary, the Android binary and the API they both call, with credentials for every user role. Splitting the binary and the API across two vendors and two quarters is how a broken authorization flaw survives an entire audit cycle, because each vendor reasonably assumes the other covered it. For the server-side counterpart of this scope, see the web application penetration testing services guide.

What is out of scope, and why saying so matters

A scope document that only lists inclusions is incomplete. These exclusions should each be an explicit line rather than an assumption:

• The mobile operating system itself. Kernel or firmware research on iOS or Android is a different discipline with a different budget.

• Third-party SDK vendors' infrastructure. An analytics or advertising SDK is in scope as a component. The SDK vendor's own servers are not, and testing them without authorization is somebody else's incident.

• App store review processes. Store review is a policy and malware screen. A published app has passed one and can still leak session tokens over cleartext.

• Denial of service against production, unless explicitly contracted with the backend owner.

• Physical device attacks. Chip-off, fault injection and hardware implants belong to a hardware assessment.

• Social engineering of app users. Separate engagement, separate authorization, separate rules.

• Resilience controls, when the threat model excludes them. Legitimate, but write it down and have the report state which MASVS-RESILIENCE controls were not exercised.

Deliverables and evidence

The report is the product. A mobile report should carry everything a web report carries plus two mobile-specific artifacts.

The general anatomy is covered in the penetration testing report sample guide: numbered proof-of-concept steps with screenshots, a CVSS 3.1 base score with the full vector string printed rather than just a number, business impact in plain language, the affected host or endpoint, external references, and retest evidence per finding stating what was retried and what failed.

The two mobile additions:

A MASVS coverage matrix, per platform. Eight rows for the control groups, a column for iOS and a column for Android, and a cell for each that says tested, tested with exceptions, or out of scope. Without it, "we tested your app" is unfalsifiable. Stingrai publishes this matrix as a standard deliverable on its mobile service page.

Build identification. The exact version, build number and artifact hash of the IPA and APK tested, plus the OS versions and device models used. Mobile apps ship weekly. A report that does not identify the build it describes cannot be matched to a fix six weeks later, and an auditor reviewing it a year later has no way to tie it to a release.

Ask also for the raw evidence package: intercepted requests and responses, Frida scripts, decompiled snippets. A finding you cannot reproduce internally is a finding your engineers will argue with instead of fixing.

Timelines

Active testing is the short part. The 2026 engagement timing analysis puts mobile testing at 3 to 5 days for a single platform and 5 to 10 days for iOS and Android combined, inside a total calendar of 4 to 8 weeks from first enquiry to delivered report.

The calendar breaks down roughly as follows: 1 to 2 weeks of scoping, 2 to 4 weeks of booking lead time before a tester is free, the active testing window above, 1 to 3 days of reporting, then the retest after remediation. Booking lead time, not testing time, is what misses an audit date. If a certification deadline sits ten weeks out, the scoping call happens now.

Add time for two mobile-specific dependencies that routinely slip. First, builds: a tester needs a non-store build, or a TestFlight or internal-track distribution, that is debuggable enough to instrument but representative enough to be worth testing. Second, accounts: one test account per role per platform, with the ability to reset state, or the authorization matrix cannot be walked.

What a mobile application penetration test costs in 2026

Very few providers publish a mobile figure, which makes the ones that do worth quoting exactly. Every row below was read from the vendor's own site on 11 September 2026.

Rather than repeat a market band nobody can audit, it is more useful to know the six variables that actually move a mobile quote:

1. Platform count. Two platforms is close to two tests. The MASTG publishes 163 Android tests and 129 iOS tests, and the overlap between them is conceptual rather than procedural.

2. Whether the backend API is in scope. Adding it roughly doubles the useful output and is the most likely source of a Critical.

3. Role and entitlement count. Every additional role multiplies the authorization matrix a tester has to walk, on both platforms.

4. Resilience depth. Bypassing root and jailbreak detection, anti-hooking and anti-tamper properly takes real time, and it is the difference between a compliance artifact and a test that reflects a motivated attacker.

5. Source code access. White-box work costs more to set up and finds more per day.

6. Retest terms. Ask whether a retest after remediation is included or billed. It moves the true annual cost more than the headline does.

For a scope-by-scope walk through the cost variables across engagement types, see the 2026 penetration testing cost guide. For a number against your own asset count rather than a market band, the pentest cost calculator shows its assumptions alongside its output.

Compliance drivers: what actually forces a mobile test

Four regimes push mobile engagements onto the roadmap, and they ask for different things.

PCI DSS, for payment apps. Requirement 11.4 of PCI DSS v4.0.1 requires a documented penetration testing methodology covering the full cardholder data environment, internal testing at least every twelve months and after significant change (11.4.2), external testing on the same cadence (11.4.3), and correction of exploitable findings with testing repeated to verify the corrections (11.4.4). The methodology under 11.4.1 must include application-layer testing covering the attack classes named in Requirement 6.2.4, which explicitly include attacks on business logic and attacks on access control mechanisms. A payment app that stores, processes or transmits cardholder data, or that can affect the security of the payment environment, sits inside that scope (PCI DSS Requirement 11.4 guide). Separately, solutions accepting PIN and contactless cardholder data on a consumer phone fall under the PCI Mobile Payments on COTS (MPoC) standard, where "Independent PCI-Recognized MPoC Laboratories evaluate MPoC solutions against the requirements of the PCI MPoC Standard". That is a laboratory evaluation programme, not a penetration test, and buying one does not satisfy the other.

HIPAA, for health apps. The Security Rule does not name penetration testing. It requires, at 45 CFR 164.308(a)(1)(ii)(A), that a covered entity or business associate "conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information", and at 164.308(a)(8) that it "perform a periodic technical and nontechnical evaluation" that "establishes the extent to which a covered entity's or business associate's security policies and procedures meet the requirements of this subpart" (45 CFR 164.308). A mobile app holding electronic protected health information on the device is squarely inside both. Evidence assembly is covered in the HIPAA penetration testing requirements guide.

SOC 2 and ISO 27001. Neither mandates a mobile test by name, and auditors for both accept one as evidence of a control operating. The framework-by-framework requirements guide sets out what each asks for and what form the evidence takes.

Google MASA, for a Play Store badge. The Mobile Application Security Assessment programme validates apps against MASVS Level 1 requirements and produces an independent security review badge in the Play Store Data safety section. Two assurance levels exist, AL1 "Verified Self Attest" and AL2 "Lab Eval", and assessments run through the published roster of authorized labs, which currently states that "due to the migration to Linux Foundation we have paused onboarding new labs". Separate MASA from penetration testing before you buy: MASA answers a baseline question with a badge attached, a penetration test answers what a motivated attacker can do to your users, and there is no rule that both must come from the same vendor.

For public-sector buyers, NIST SP 800-163 Revision 1, Vetting the Security of Mobile Applications, published April 2019, remains the reference many agency app-vetting programmes cite.

How to choose a provider, and the questions to ask

Nine questions separate providers who do this work from providers who resell a scan. Ask all nine in the scoping call, and write the answers down.

1. "Which MASVS control groups will you exercise on each platform, and which will you mark out of scope?" Any answer other than a per-platform statement across all eight groups is a red flag.

2. "Show me a redacted mobile report." Read one Medium finding. If a developer could not reproduce it without asking a question, the report is a list rather than evidence.

3. "Do you test on jailbroken and rooted devices, and will you bypass our detection?" The answer should be yes to both, with a description of how.

4. "How will you approach a pinned app with a second native networking layer?" This separates people who have done it from people who have read about it. Expect a specific answer involving runtime instrumentation of the pinning implementation, not a tool name.

5. "Is the backend API in this engagement, with credentials for every role?" If it is not, you are buying half a test.

6. "Who is testing, and what are their certifications?" Named testers, named credentials. Offensive Security and CREST registrations are the common currency here.

7. "What build do you need, and how do we get it to you?" A provider who has not thought about non-store distribution has not run many of these.

8. "Is a retest included after we fix, and for how long?" Get the window in writing. The gap between one retest and unlimited retesting for a contract term is worth more than most price differences.

9. "What do you do about the app's third-party SDKs?" MASVS-CODE-3 requires that the app only uses components without known vulnerabilities. Somebody has to enumerate the bundled SDKs and check them.

One question not to ask: "are you a MASA authorized lab?" Ask that only if you specifically need the Play Store badge. It has no bearing on how deep the testing goes.

Stingrai's mobile application penetration testing

Stingrai is a CREST-accredited offensive security company. Its penetration testers simulate real-world attacks across applications, cloud, networks, and people, with testing delivered through its PTaaS platform. The company was founded in 2021, is headquartered in Toronto, Canada with an office in London, UK, and delivers both one-time penetration tests and continuous testing programmes.

Mobile engagements are fully human-led. They are delivered by credentialed penetration testers holding OSCE3, OSCP, OSWE, CREST CRT and CISSP certifications, working the binary, the device and the backend directly. That is what regulated buyers in financial services, healthcare and SaaS are actually purchasing when they scope a mobile test against SOC 2, ISO 27001, PCI DSS or HIPAA: named, credentialed testers from an accredited firm, and a report an auditor will accept.

The published service scope covers iOS and Android, aligned to OWASP MASVS and MASTG, across three phases: static and binary analysis, including reverse engineering, cryptography checks and dependency review; dynamic and runtime analysis, including runtime instrumentation, transport security testing and traffic interception; and resilience and bypass resistance, including SSL pinning bypass and jailbreak or root detection bypass. Backend API testing is part of the engagement rather than an upsell.

Deliverables include a report with an executive summary, a MASVS coverage matrix showing what was tested on each platform, every finding documented with a reproducible proof of concept, a CVSS severity and business impact, and step-by-step remediation guidance. Findings also land in the PTaaS portal with Jira and GitHub integration, and the engagement includes a complimentary retest once fixes are deployed.

On output rather than process: Stingrai's State of Penetration Testing 2026 analysed 1,206 verified findings from 55 penetration tests. 92.7% of those tests surfaced at least one High or Critical finding, the dataset carried a 0.74% false-positive rate, and the median Critical finding took 10.5 days to fix. Those numbers are the reason retest terms belong in the contract: the fix window, not the test window, is where a report turns into a security outcome.

Mobile, cloud, network, social engineering and red team engagements are all scoped and delivered by Stingrai's penetration testers and quoted through Get a Quote. The published package prices on the pricing page apply to web application scope, covering one web application and its APIs. Stingrai's penetration testing supports SOC 2, ISO 27001, PCI DSS and HIPAA programmes by producing the scope statement, technical report, remediation record and retest evidence those programmes consume.

Mobile application penetration testing providers

Seven providers with a dedicated mobile practice, in the order published in the 2026 mobile companies ranking, which carries the full evaluation criteria and per-provider detail.

1. Stingrai. CREST-accredited, fully human-led mobile engagements on iOS and Android with backend API testing in scope, a MASVS coverage matrix as a standard deliverable, and a retest included. Service page.

2. NowSecure. Mobile-only specialist with a published mobile penetration testing service line and long-running participation in the OWASP MAS standards work. nowsecure.com.

3. NCC Group. Large consultancy with a dedicated mobile practice and an established assessment programme. nccgroup.com.

4. NetSPI. Publishes a mobile application security assessment service naming the four areas it tests manually: file system, memory, network communications and GUI. netspi.com.

5. Cobalt. Platform-delivered testing with a public mobile methodology document that names MASVS and MASTG and lists the toolset. docs.cobalt.io.

6. Appknox. Mobile-focused platform combining automated analysis with manual testing and per-build MASVS-mapped evidence. appknox.com.

7. Payatu. Product-security consultancy with a mobile assessment practice referencing OWASP MASVS. payatu.com.

What this means for buyers

• Buy the binary and the backend in one engagement. Authorization flaws live on the API and get discovered by a tester who has both the client and the credentials. Two vendors, two quarters, one missed Critical.

• Require a per-platform MASVS coverage matrix in the contract, not just in the report template. Eight control groups, two columns, every cell filled. That one artifact converts "we tested your app" into something an auditor and an engineer can both use.

• Stop asking for MASVS L2. The levels left the standard at v2.0.0 and became MAS Testing Profiles under MASWE. Ask for control-group coverage and MASTG test identifiers instead.

• Scope jailbroken and rooted device testing in explicitly. It is the only honest way to verify storage and key management, and root or jailbreak detection is a control to bypass, not a boundary to respect.

• Plan the calendar backwards from the audit date. Testing takes 3 to 10 days. Getting to the testing takes 4 to 8 weeks.

• Put retest terms in the comparison as a column. With a median Critical taking 10.5 days to fix, a retest window that outlives your sprint cycle is worth more than a few thousand dollars of headline price.

• Separate the badge from the test. MASA validates against MASVS Level 1 and produces a Play Store badge. A penetration test tells you what an attacker can do.

Frequently Asked Questions

What is a mobile application penetration testing service?

A mobile application penetration testing service is an authorised, manual security assessment of a compiled iOS or Android application, the data it stores on the device, the traffic it sends, its use of platform APIs, its resistance to reverse engineering and tampering, and the backend API it calls. Providers test against the OWASP Mobile Application Security Verification Standard, which defines 8 control groups and 24 controls, using the procedures in the OWASP Mobile Application Security Testing Guide, which publishes 292 test cases, 163 for Android and 129 for iOS. The output is a report with reproducible proof of concept per finding, a CVSS severity, remediation guidance and a per-platform coverage matrix.

How much does a mobile app penetration test cost in 2026?

Most providers quote rather than publish. Software Secured publishes a starting price of US$5,400 for mobile application penetration testing. Astra publishes tailored mobile pricing from US$2,200 per app where iOS and Android share a codebase, and otherwise counts each platform as one target against annual plans at US$2,999, US$5,999 and from US$9,999. NowSecure, NCC Group, NetSPI, Appknox and Payatu publish no figure. Stingrai publishes package prices for web application scope and quotes mobile per engagement through Get a Quote. Platform count, backend API scope, role count, resilience depth, source code access and retest terms are what move the number.

Do I need separate tests for iOS and Android?

Effectively yes, and the pricing models reflect it. Astra states the rule directly: "Mobile is per platform, so an Android app and an iOS app are two targets." The platforms use different storage APIs, different inter-process communication mechanisms, different keychain and keystore implementations and different resilience controls, and the OWASP MASTG publishes 163 Android tests against 129 iOS tests with almost no procedural overlap. A shared React Native or Flutter codebase narrows the gap on business logic and not on packaging, transport or platform interaction, which is why shared-codebase pricing exists and full discounts do not.

What is OWASP MASVS and what does MASVS coverage mean?

The OWASP Mobile Application Security Verification Standard is the industry standard for mobile app security. It defines eight control groups covering the mobile attack surface: MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE and MASVS-PRIVACY, holding 24 controls in total (mas.owasp.org/MASVS). MASVS coverage means a provider states, per platform, which groups it exercised and which it marked out of scope, backed by the MASTG test identifiers it ran. Ask for that matrix in the contract, because a report naming no control groups cannot be audited against the standard it claims to follow.

What is the difference between MASVS, MASTG and MASWE?

MASVS is the standard: what a secure mobile app must do, in 24 one-sentence controls across eight groups. MASTG is the testing guide: the procedures that verify those controls, 292 test cases split 163 Android and 129 iOS, plus techniques, tools and demonstrations. MASWE is the weakness enumeration: the specific failure modes mapped to each control, such as MASWE-0001, sensitive data stored unencrypted in private storage. A provider quotes MASVS to describe scope, runs MASTG to do the work, and references MASWE to classify findings. All three are published at mas.owasp.org.

Does a mobile penetration test include the backend API?

It should, and you have to ask, because scope varies by provider. MASVS-AUTH-1 states that the app uses secure authentication and authorization protocols, and notes that enforcement of those mechanisms must happen on the remote endpoint. Broken object-level authorization, missing function-level authorization, mass assignment and business logic flaws all live on the server, and they are the findings most likely to be Critical. Scope one engagement covering the iOS binary, the Android binary and the API both call, with credentials for every user role. The server-side equivalent is covered in the web application penetration testing services guide.

Do testers need a jailbroken or rooted device?

Yes, for any engagement that claims to verify local storage and key management. A stock device enforces the sandbox, so a tester cannot read the app's private storage, attach a debugger to a release build, or inspect cryptographic keys in memory. Rooted Android and jailbroken iOS devices remove that barrier and let the tester answer MASVS-STORAGE and MASVS-CRYPTO honestly. If the app implements root or jailbreak detection, that is MASVS-RESILIENCE-1 and the test is whether it can be bypassed, not whether it exists. Expect a competent provider to bypass detection and then keep testing.

How long does a mobile app penetration test take?

Active testing runs 3 to 5 days for a single platform and 5 to 10 days for iOS and Android combined, inside a total calendar of 4 to 8 weeks from first enquiry to delivered report (Stingrai, 2026). That calendar is roughly 1 to 2 weeks of scoping, 2 to 4 weeks of booking lead time, the testing window, 1 to 3 days of reporting, then a retest after remediation. Booking lead time, not testing time, is what misses audit dates. Add slack for two mobile-specific dependencies: getting a debuggable non-store build to the tester, and one test account per role per platform.

Does a mobile penetration test satisfy PCI DSS or HIPAA?

It provides the evidence those programmes consume rather than the attestation itself. PCI DSS v4.0.1 Requirement 11.4 requires a documented methodology covering application-layer testing for the attack classes named in Requirement 6.2.4, internal and external testing at least every twelve months and after significant change, and retesting to verify corrections, all of which a payment app's engagement produces (Stingrai PCI guide). HIPAA requires an accurate and thorough risk assessment at 45 CFR 164.308(a)(1)(ii)(A) and a periodic technical and nontechnical evaluation at 164.308(a)(8), and a mobile engagement against an app holding electronic protected health information feeds both (45 CFR 164.308).

Is Google MASA the same as a mobile penetration test?

No. MASA validates an app against MASVS Level 1 requirements through an authorized lab and produces an independent security review badge in the Play Store Data safety section. It has two assurance levels, AL1 "Verified Self Attest" and AL2 "Lab Eval", and the assessor roster currently states that lab onboarding is paused during the migration to the Linux Foundation. A penetration test is scoped to find exploitable flaws and chain them into attack paths, with no baseline ceiling and no badge attached. If the requirement is a store badge, the lab roster matters. If the requirement is finding what an attacker can do, tester depth matters and the roster does not.

Related Reading

• Best Mobile App Penetration Testing Companies (2026 Ranked), the full provider evaluation behind the short list above.

• Penetration Testing Cost in 2026, the scope-driven cost guide across engagement types.

• How Long Does a Penetration Test Take? (2026), the timing data behind the calendar above.

• What a Penetration Testing Report Should Contain (2026), the report anatomy a mobile deliverable extends.

• Web Application Penetration Testing Services (2026), the server-side counterpart to mobile scope.

• HIPAA Penetration Testing Requirements (2026).

• PCI DSS Penetration Testing: Requirement 11.4 (2026).

• Penetration Testing Requirements by Framework (2026).

Talk to Stingrai

Mobile scope is decided by five answers: how many platforms, whether the backend API is in, how many roles, how deep resilience testing goes, and whether source code is available. Bring those five and a scope comes back fixed rather than approximate.

Book a free scoping call to walk through platform count, roles and the API boundary, get a quote for a mobile engagement on iOS, Android or both, or read the published package prices for web application scope on the pricing page.

References

1. OWASP. Mobile Application Security Verification Standard (MASVS). Read 11 September 2026. https://mas.owasp.org/MASVS/. The eight control groups, and the statement that verification levels left the standard at v2.0.0.

2. OWASP. MASVS controls. Read 11 September 2026. https://mas.owasp.org/MASVS/controls/MASVS-STORAGE-1/. One page per control, carrying the 24 control statements quoted here.

3. OWASP. MASTG Tests. Read 11 September 2026. https://mas.owasp.org/MASTG/tests/. The test index: 292 unique test cases, 163 Android and 129 iOS.

4. OWASP. Mobile Application Security Testing Guide. Read 11 September 2026. https://mas.owasp.org/MASTG/. Testing methodology, platform knowledge base, techniques and tools.

5. OWASP. Mobile Top 10, 2024 edition. Read 11 September 2026. https://owasp.github.io/www-project-mobile-top-10. The awareness list, M1 through M10.

6. App Defense Alliance. Mobile Application Security Assessment (MASA). Read 11 September 2026. https://appdefensealliance.dev/masa. Validates apps against MASVS Level 1 for the Play Store Data safety badge.

7. App Defense Alliance. MASA Authorized Assessors. Read 11 September 2026. https://appdefensealliance.dev/masa/masa-assessors. The AL1 and AL2 assurance levels, and the paused lab onboarding notice.

8. Quokka. The State of Mobile App Security, 2026. Published 28 April 2026, read 11 September 2026. https://www.quokka.io/blog/the-state-of-mobile-app-security-2026-report-findings. More than 150,000 mobile applications analysed across 2025, with per-platform rates for cleartext URLs, ECB ciphers and hardcoded keys.

9. Astra Security. Pricing. Read 11 September 2026. https://www.getastra.com/pricing. The per-target definition, the per-platform mobile rule, tailored mobile pricing from US$2,200 per app, and annual plans at US$2,999, US$5,999 and from US$9,999.

10. Software Secured. Pricing. Read 11 September 2026. https://www.softwaresecured.com/pricing. Itemised price list including mobile application penetration testing from US$5,400.

11. Cobalt. Mobile application penetration testing methodology. Read 11 September 2026. https://docs.cobalt.io/en-us/articles/mobile-methodologies-M7k4hP5LUW. MASVS and MASTG alignment, IPA and APK intake, and the named toolset.

12. Cobalt. Pricing. Read 11 September 2026. https://www.cobalt.io/platform/pricing. The Autonomous Pentest promotional rate with its 31 December 2026 deadline, and the credit definition.

13. NetSPI. Mobile application security assessment. Read 11 September 2026. https://www.netspi.com/services/mobile-application-security-assessment/. Names the four areas tested manually.

14. NowSecure. Mobile app penetration testing. Read 11 September 2026. https://www.nowsecure.com/solutions/mobile-app-penetration-testing/. The published mobile penetration testing service line.

15. Appknox. Penetration testing. Read 11 September 2026. https://www.appknox.com/penetration-testing. Real-device testing with MASVS-mapped per-build evidence.

16. Payatu. Mobile application security testing. Read 11 September 2026. https://payatu.com/mobile-application-security-testing/. Mobile assessment practice referencing OWASP MASVS.

17. PCI Security Standards Council. Mobile Payments on COTS (MPoC). Read 11 September 2026. https://www.pcisecuritystandards.org/standards/mobile-payments-on-cots/. Laboratory evaluation programme for PIN and contactless acceptance on consumer devices.

18. Legal Information Institute, Cornell Law School. 45 CFR 164.308, Administrative safeguards. Read 11 September 2026. https://www.law.cornell.edu/cfr/text/45/164.308. Source of the HIPAA risk analysis and evaluation text quoted here.

19. NIST. SP 800-163 Rev. 1, Vetting the Security of Mobile Applications. April 2019, read 11 September 2026. https://csrc.nist.gov/pubs/sp/800/163/r1/final. The reference app-vetting process cited by agency programmes.

20. Stingrai. Mobile Application Penetration Testing. Read 11 September 2026. https://www.stingrai.io/services/mobile-application-penetration-testing. Published mobile scope, three-phase methodology and deliverables.

21. Stingrai. The State of Penetration Testing 2026. https://www.stingrai.io/blog/state-of-penetration-testing-2026. 1,206 verified findings across 55 penetration tests, with severity, false-positive and remediation timing.

22. Stingrai. How Long Does a Penetration Test Take? (2026). https://www.stingrai.io/blog/how-long-does-a-penetration-test-take-2026. Testing windows by engagement type and the end-to-end calendar.

23. Stingrai. Pricing. Read 11 September 2026. https://www.stingrai.io/pricing. Published package prices for one web application and its APIs, and the route to a quoted scope.