iOS and Android security assessments covering reverse engineering, insecure data storage, certificate pinning bypass, and runtime manipulation testing aligned to OWASP MASVS.
Mobile applications present a distinct and often underestimated attack surface. Our Mobile Application Penetration Testing service covers both iOS and Android platforms with a methodology aligned to the OWASP Mobile Application Security Verification Standard (MASVS) and the OWASP Mobile Security Testing Guide (MSTG). We conduct both static and dynamic analysis — examining the application binary, local data storage, network communication, authentication flows, and runtime behaviour.
WHAT'S INCLUDED
Mobile application penetration testing assesses the security of iOS and Android applications across the device, the application binary, and the backend APIs it communicates with. Testing covers local data storage — including credentials, tokens, and cached data held in insecure storage — as well as network communication, certificate pinning, and runtime behaviour. The assessment examines whether the application can be reverse-engineered, whether its binary protections can be bypassed, and whether sensitive functionality is exposed through the device's debugging or instrumentation interfaces. The backend API used by the application is reviewed for authentication, authorisation, and input validation weaknesses, since the majority of mobile application breaches occur at the API layer rather than on the device itself.
Testing follows the OWASP Mobile Application Security Verification Standard (MASVS) and the OWASP Mobile Security Testing Guide (MSTG). Findings are mapped to the MASVS levels — L1 (standard), L2 (defence-in-depth), and the reverse-engineering resilience requirements — and are rated using CVSS v3.1. The approach combines static analysis of the application binary, configuration, and embedded resources with dynamic analysis using runtime instrumentation tools. Automated scanning is used for enumeration, but every finding is reproduced and validated manually to eliminate false positives. Where the application integrates custom features — biometric authentication, deep linking, or third-party SDKs — the test plan is expanded to cover the risks those introduce.
A scoping call establishes the target platforms (iOS, Android, or both), the application versions, the test accounts and data required, and whether backend API testing is in scope. Rules of engagement and timelines are documented before testing begins. Testing is delivered in sprints with progress updates, allowing your team to act on confirmed findings as they arise. Both static and dynamic analysis phases are completed against agreed builds. At the end of the engagement, a report is produced with an executive summary and a full technical section, followed by a complimentary retest once remediation is complete.
The report includes an executive summary describing the scope and the most significant risks in business terms, and a technical section documenting each confirmed finding with its CVSS severity, proof of concept, root cause, and remediation guidance. Findings are mapped to the relevant OWASP MASVS requirement and, where applicable, to ISO 27001 Annex A.8 controls. A retest is conducted after remediation, and an attestation letter is issued confirming that the verified fixes resolve the original findings.
Yes. Once your team has remediated the confirmed findings, a retest verifies that each fix resolves the original issue without introducing new weaknesses. Verified fixes are documented and an attestation letter is issued. The retest is included in the engagement price, and the engagement is not closed until it is complete.
A mobile application penetration test does not by itself achieve NIS2 or ISO 27001 compliance, but it provides evidence for specific control objectives. For NIS2 Article 21, documented testing of mobile applications that handle personal or operational data supports the risk-based technical measures the directive requires. For ISO 27001, Annex A controls A.8.8 (technical vulnerability management) and A.8.29 (security testing in development) expect evidence that in-scope applications are actively tested. The report maps findings to these controls so auditors and risk functions can trace the testing back to the relevant requirement. Testing frequency and scope should be aligned with your broader compliance programme rather than treated as a one-off exercise.
FAQ
Engagement length depends on the platforms in scope (iOS, Android, or both), the number of application builds, whether backend API testing is included, and reporting requirements. A precise timeline is confirmed during scoping. Testing is delivered in sprints with progress updates.
Testing follows the OWASP Mobile Application Security Verification Standard (MASVS) and the OWASP Mobile Security Testing Guide (MSTG), with CVSS v3.1 for severity rating. The approach combines static analysis of the binary and configuration with dynamic analysis using runtime instrumentation. Every finding is reproduced and validated manually.
Yes. Once your team has remediated the confirmed findings, a retest verifies that each fix resolves the original issue without introducing new weaknesses. Verified fixes are documented and an attestation letter is issued. The retest is included in the engagement price and the engagement is not closed until it is complete.
The report includes an executive summary and a technical section. Each finding has its CVSS severity, a proof of concept, the root cause, and remediation guidance. Findings are mapped to the relevant OWASP MASVS requirement and, where applicable, to ISO 27001 Annex A.8 controls.
A mobile application penetration test does not by itself achieve NIS2 or ISO 27001 compliance. It provides evidence for specific control objectives such as NIS2 Article 21 technical measures and ISO 27001 Annex A.8.8 and A.8.29. Testing should be aligned with your broader compliance programme.
Before testing, we need the target platforms and application builds, test accounts and sample data, any backend API documentation if API testing is in scope, and written authorisation. Rules of engagement and timelines are agreed during scoping. Builds and access are confirmed before active testing begins.
Book a scoping call and we'll define targets, rules of engagement, and timeline together.
Request a scoping call