RASP Security
Assessment
We test the runtime protections in your mobile application: RASP, obfuscation, anti-tamper, root and jailbreak detection and certificate pinning. The work runs against the APK and IPA you publish.
You bought those protections on the vendor's claims. We tell you how they hold up when someone who did not sell them goes to work on the build your users install.
Why an independent assessment
Nobody has tested your vendor's claims on your build
Every claim a shielding product makes is a claim about what an attacker cannot do. You cannot read that off a datasheet, a licence key or a build log. It is a property of the binary once the protections have been applied to it.
Very little of this market is independently evaluated. 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 and not the shielding. The remaining vendors rely on self-assessment or on analyst recognition, which rates a company in a market and says nothing about 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.
Some products ship with a certificate. Appdome’s Certified Secure is generated at build time and issued by Appdome, and it records that the selected protections were compiled into the binary. It does not tell you whether they hold up under attack.
What is examined
What we examine
Six areas, scoped against OWASP MASVS and worked through the MASTG test procedures.
The protections as shipped
We retrieve, decompile and analyse the APK and IPA as they reach a device. Obfuscation, anti-debug, anti-tamper, certificate pinning and protected storage are examined on the artefact your users install.
Root and jailbreak detection
OWASP catalogues how these checks fail. MASWE-0051 names the most common shape: "Naive or Single-Point Checks: Implementing one easily located check whose removal or hooking disables the entire defense." We establish which shape yours is.
On-device checks and attestation
A runtime check runs on the device it is making a claim about, which puts the check and the attacker on the same side of the boundary. Attestation works differently: a Play Integrity or App Attest verdict is signed off-device and evaluated by your backend. We map which of your controls is which, so you know what each one can carry.
Obfuscation as configured
The R8 or ProGuard configuration, the mapping file, and what the shipped binary actually looks like. Buying a protection product and applying it to the release build are separate steps, and we check the second one.
The merged manifest and the permission set
Every uses-permission line in the merged manifest, including the ones a dependency contributed. For a lending app we read that set against the resources RBI names.
A report an auditor can re-check
Findings are tied to the artefact they were read from, so a reviewer can reproduce them. Executive and technical formats, with retest rounds included.
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. 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 ship. Most clients scope the two together.
Do you sell or implement RASP products?
No. We test them. We do not supply, resell or implement any protection product, and we do not recommend which one to buy.
We already have a protection product from a vendor. Why test it?
Because the party making the claims is the party selling the product. One vendor, Licel, has had its product independently evaluated and approved by EMVCo as a Software Protection Tool. Digital.ai holds a FIPS 140-3 validation covering a key and data protection module. The others rely on self-assessment or on analyst recognition, which is a market rating and not 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 they withstand an attacker working on the shipped artefact is what this assessment answers. Checked 3 September 2026.
Does a clean assessment make us compliant?
No. The assessment produces evidence about what your application does, which is what an auditor, a board or a regulator asks you to demonstrate. Filing and compliance stay with you.
What do you need from us to scope it?
The APK and IPA as published, any protection products in use, the form factors you ship on, and your regulatory status: bank, NBFC, SEBI-registered intermediary, or none. The last one decides which obligations apply and what the report needs 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