RASP Security
Assessment
Independent testing of the runtime protections in your mobile application — RASP, obfuscation, anti-tamper, root and jailbreak detection, certificate pinning — examined on the APK and IPA you actually publish.
The protections in your app were bought on claims made by the company selling them. This is the exercise that establishes what they do when somebody who is not selling them goes to work on the shipped binary.
Why an independent assessment
A protection product is sold on claims about resisting attack
Every claim a shielding product makes is a claim about what an attacker cannot do. That is not a property you can read off a datasheet, a licence key or a build log — it is a property of the binary after the protections have been applied to it.
Very little of this market is independently evaluated. One vendor, Licel, has had DexProtector assessed and approved by EMVCo as a Software Protection Tool. Digital.ai holds a FIPS 140-3 validation, which covers a key and data protection module rather than the resilience of the shielding. The rest rest on self-assessment, or on analyst recognition — which is a rating of a company in a market, not an evaluation of whether software resists attack. Checked 3 September 2026.
One vendor, Promon, publishes the state of the market plainly:
“Resilience pentests are far less common than regular pentests, and are highly specialized.”
Promon sells a protection product and does not offer this testing itself. Checked 3 September 2026.
Where a certificate does arrive with the product, it is worth reading what it certifies. Appdome’s Certified Secure is generated at build time and issued by Appdome: it records that the selected protections were compiled into the binary. That is a different statement from whether they hold, and only one of the two is a security finding.
We have nothing riding on the answer. Security Brigade does not supply, resell or implement any protection product and does not advise on which to buy. The assessment is worth something because of that, not in spite of it.
What is examined
Six things, on the artefact you publish
Scoped against OWASP MASVS and worked through the MASTG test procedures that verify it.
The protections as shipped
The APK and IPA are retrieved, decompiled and analysed as they reach a device — not as they exist in your build pipeline. Obfuscation, anti-debug, anti-tamper, certificate pinning and protected storage are examined on the artefact a user actually installs.
Root and jailbreak detection, against the classes that defeat it
OWASP catalogues the ways these checks fail. MASWE-0051 names the shape directly — "Naive or Single-Point Checks: Implementing one easily located check whose removal or hooking disables the entire defense." We establish which shape yours is.
Where the claim is evaluated
A runtime check executes on the device it is making a claim about, so the check and an attacker sit on the same side of the boundary. Attestation is different: a Play Integrity or App Attest verdict is signed off-device and evaluated by your backend. We map which of your controls is which, because that distinction decides what each one can be trusted for.
Obfuscation, as configured rather than as licensed
The R8 or ProGuard configuration, the mapping file, and what the shipped binary actually looks like. A protection product in the dependency list and a protection applied to the release build are two different facts.
The merged manifest and the permission set
Every uses-permission line in the merged manifest, including those a dependency contributed rather than your own code — and, for a lending app, what that set means against the resources RBI names.
The report an auditor or a regulator can read
Findings tied to the artefact they were read from, so a reviewer can re-check them. Executive and technical formats, with retest rounds.
Who is asked for this, and by whom
The obligation depends on what kind of entity you are
Each of these names a mobile application and an entity class. Which one reaches you decides what your report has to carry, and it is the first thing we establish when scoping.
SEBI-regulated entities
CSCRF Annexure-L lists "VA & PT of Mobile applications" in its VAPT scope, and Annexure-A — the auditor’s declaration filed on the entity’s letterhead — carries a row where the auditor lists the number of APK and IPA files covered.
The auditor must be CERT-In empanelled and must declare it. SEBI’s Technical Clarifications made the mobile control guidelines recommendatory; the testing scope and the report format were not changed.
Commercial banks, small finance banks, payments banks, urban co-operative banks and credit information companies
RBI’s cyber Directions require periodic VA and PT of "critical, internet facing web / mobile applications" (¶150 for commercial banks), with VA at least six-monthly and PT at least annually for critical and DMZ customer-interface systems (¶151).
For urban co-operative banks the wording and the cadence sit in a single paragraph (¶116). For NBFCs the mobile application is reached through "critical information system" rather than by name.
Commercial banks running digital payment applications
The Digital Payment Security Controls Directions require security testing "including review of source code, Vulnerability Assessment (VA) and Penetration Testing (PT) of its digital payment applications" (¶32), and direct banks to OWASP-MASVS among other standards (¶39).
Chapter V ¶68(2) adds nine mobile application controls, code obfuscation among them. RBI attaches its own note that five of the nine are an illustrative list and that compensating controls may be adopted.
Clauses read from the regulators’ own published instruments and checked 3 September 2026. A test and a regulatory obligation are different things and neither discharges the other; what an assessment produces is evidence about what your application does.
Questions we are asked
Is this different from a mobile application penetration test?
Yes, and the difference is the target. A mobile pen test looks for vulnerabilities in your application. This looks at the protections themselves — whether the obfuscation, the tamper checks, the root and jailbreak detection and the pinning do what they were bought to do on the build you actually ship. The two are complementary and are often scoped together.
Do you sell or implement RASP products?
No. We do not supply, resell or implement any protection product, and we do not advise on which one to buy. That independence is the point of the exercise: the assessment is worth something precisely because we have nothing riding on the result.
We already have a protection product from a vendor. Why test it?
Because the claims about it are made by the party selling it. Of the vendors in this market, one — Licel — has had its product independently evaluated and approved by EMVCo as a Software Protection Tool. Digital.ai holds a FIPS 140-3 validation, which covers a key and data protection module rather than shielding resilience. Others rest on self-assessment or on analyst recognition, which is a market rating rather than a security evaluation.
Appdome issues a certificate with the build. Does that cover it?
Appdome’s Certified Secure is generated at build time and issued by Appdome. It records that the selected protections were compiled into the binary. Whether those protections withstand an attacker working on the shipped artefact is a different question, and it is the one this assessment answers. Checked 3 September 2026.
Does a clean assessment make us compliant?
No. A test and a regulatory obligation are different things, and neither discharges the other. What an assessment produces is evidence about what your application does, which is what an auditor, a board or a regulator asks you to demonstrate. The obligation stays yours.
What do you need from us to scope it?
The APK and IPA as they are published, the protection products in use if any, the form factors you ship on, and whether the entity is a bank, an NBFC, a SEBI-registered intermediary or none of those. That last answer changes which obligations apply and therefore what the report has to carry.
Find out what your protections actually do
Tell us the app, the protection products in use, the form factors you ship on, and what kind of entity you are. Those four answers scope it. Security Brigade works 24/7, on +91 22 4164 2220.
Request a Scoping Call