Service · 1–2 weeks · Fixed fee
Make sure your customer app holds up on a phone you do not control
I model the threats to your iOS and Android apps, review the protection you have or plan, and set a policy that stops attacks without locking out customers.
- 1–2 weeks
- Fixed fee
- OWASP MASVS
- OWASP MASTG
- OWASP API Security Top 10 (2023)
In short
A mobile app security assessment examines how a customer-facing iOS or Android app, and the APIs (application programming interfaces) behind it, resist rooted devices, hooking and repackaging. I build a threat model, review the RASP (runtime application self-protection) policy, check what the backend trusts, and deliver a protection policy and a test plan based on MASVS, the Mobile Application Security Verification Standard from OWASP (the Open Worldwide Application Security Project).
This is for you if
- The app moves money or holds data a fraudster would want
- App shielding was bought but still runs in report-only mode
- Rooted phones are either blocked outright or ignored, nothing between
- A regulator or auditor wants evidence of mobile app controls
When to call me
The moments this engagement is built for.
- 01A fraud case traced to the appA hooked or cloned app was used against customers, and you need to know what else is possible.
- 02Launching or rebuilding the appA new app or major rewrite is the cheapest moment to set protection policy and testing standards.
- 03Choosing an app shielding productYou want requirements and a threat model before the vendor demos, not after.
- 04Support calls after a root blockA hard block on rooted devices locked out real customers, and the business wants it relaxed safely.
How it runs · 1–2 weeks
From kick-off to a plan you can act on.
- 01App and threat context
- Review features, transaction flows and backend APIs
- Agree the threats that matter with fraud and digital
- 02Package and device checks
- Inspect the app package for secrets and weak storage
- Spot-check on rooted and jailbroken test devices
- Try hooking, repackaging and emulator runs
- 03Policy and backend trust
- Review RASP detections and responses per threat
- Check what the API trusts from the client
- 04Policy and test plan
- Draft the threat-to-response matrix per feature
- Write the MASVS test plan for future releases
What you get
Deliverables, not a slide deck of opinions.
- PDF reportMobile threat modelThreats per feature and device state, from rooted phones to repackaged clones and overlay abuse.
- SpreadsheetProtection policyA threat-to-response matrix: what to report, restrict, step up or block, feature by feature.
- SpreadsheetOWASP MASVS test planTest cases mapped to MASVS control groups, ready to run before every significant release.
- PDF reportBackend trust findingsWhere the API trusts the app too much, and what must hold even if the app is compromised.
- PDF reportTelemetry routingWhich runtime events should reach the SIEM and fraud team, and who owns each alert.
What happens next
Afterwards, you can decide.
An assessment is only useful if it changes a decision. These are the ones this engagement is designed to unlock.
- 1Which detections to enforce first, and which stay report-only for now
- 2How to treat rooted devices per feature: allow, step up, restrict or block
- 3Whether to adopt, tune or replace your app shielding product
- 4Which backend fixes must land whatever the app does
- 01
Assess
I audit your applications and the security you already have, across six areas. Evidence, not questionnaires.
- Findings with evidence
- Score per area
1–4 weeks
- 02
Recommend
A prioritised plan: what to fix first, what it costs, and what risk it removes.
- 30/90/365-day plan
- Board summary
With the assessment
- 03
Execute, case by case
If you want help delivering, I scope it by expertise, manpower and timeline. Your team, a partner or Innov8.
- Delivery options
- Independent oversight
Only where it makes sense
Method
Built on standards your auditors recognise.
- OWASP MASVS
- OWASP MASTG
- OWASP API Security Top 10 (2023)
Is a mobile app security assessment the same as a mobile pen test?
Not quite. A mobile penetration test hunts for exploitable flaws in one build. This assessment sets the defence around the app: the threat model, the RASP (runtime application self-protection) policy, what the backend must never trust, and a test plan based on MASVS (the Mobile Application Security Verification Standard) for future releases. It includes spot checks, and it makes later pen tests more focused.
How long does a mobile app security assessment take?
One to two weeks for a customer app on iOS and Android with its backend APIs (application programming interfaces). The first days go on the threat model with the fraud and digital teams, the middle on package checks, device tests and policy review, and the end on the protection policy and test plan. Several apps, or apps on different frameworks, take longer.
How do you set a RASP policy without locking out customers?
Start with every detection in report-only mode and study the real device population before blocking anyone. Then decide per threat and per feature: allow balance checks on a rooted phone, step up verification for a new payee, and block outright on active hooking or a repackaged app. Security, fraud, digital and customer service teams should agree that matrix together.
Do you assess both iOS and Android apps?
Yes. The threats differ by platform: overlay and accessibility abuse is mainly an Android problem, while jailbreak detection and integrity checks work differently on iOS. I review release builds of both, check that protection behaves consistently, and write one test plan based on MASVS (the Mobile Application Security Verification Standard), with platform-specific cases where the two diverge.
Can you help us choose an app shielding product?
Yes, as a neutral reviewer. Ravindu Fernando, a Colombo-based application security consultant who has rolled out Zimperium in-app protection for a leading private bank, writes requirements from your threat model first: detections needed, response options, SDK (software development kit) compatibility, performance on low-end devices and telemetry for the SOC (security operations centre). Every product is judged against that same list.
Other engagements
- AppSec maturity assessmentScored baseline, gap analysis, 12–24 month roadmap, board summary
- Application architecture reviewThreat model, control coverage map, prioritised fixes
- WAAP & API protection assessmentCoverage gaps, bypass paths, migration or tuning plan
- Exposure management (CTEM) assessmentPrioritisation model, validation approach, owner playbook, metrics
- Executive briefing or team workshopPlain-language risk briefing or hands-on workshop
- Fractional AppSec advisorRoadmap governance, vendor and design reviews, escalation support