Notifications
Clear all
Topic starter
19/08/2026 3:46 pm
TL;DR: A global survey of 1,360 mobile app developers and security leaders found that 72% of organisations experienced at least one mobile app security incident in the past year, while 65% reported customer churn or uninstalls tied directly to those issues, according to Guardsquare. The finding reinforces that client-side weakness is no longer a secondary concern, because tampering, reverse engineering, and API abuse now spill into business and backend risk.
NHIMG editorial — based on content published by Guardsquare: New Research Shows Mobile App Security Incidents are Now Widespread
By the numbers:
- 72% of organizations experienced at least one mobile app security incident in the past year.
- 65% of respondents reported customer churn or app uninstalls as a direct result of mobile app security issues.
- 63% of organizations were aware of unauthorized modding, cloning, or tampering of their mobile apps within the past 12 months.
Questions worth separating out
Q: How should security teams protect mobile APIs against tampering and bot abuse?
A: Use layered controls, not a single trust mechanism.
Q: Why do mobile apps create different trust problems than standard web applications?
A: Mobile apps run on devices the organisation does not control, so the client can be inspected, altered, or cloned.
Q: What breaks when teams rely on operating system protections alone for mobile security?
A: OS protections do not stop reverse engineering, request manipulation, or embedded secret extraction.
Practitioner guidance
- Instrument client-to-API trust boundaries Map every mobile app request path to the APIs it can reach, then identify which calls depend on hidden trust in the client.
- Replace OS-only assumptions with layered mobile controls Do not treat operating system protections as sufficient.
- Monitor API behaviour tied to mobile clients Create dashboards that separate legitimate app traffic from cloned, tampered, or scripted client behaviour.
What's in the full report
Guardsquare's full research covers the operational detail this post intentionally leaves for the source:
- Survey methodology and respondent breakdown across 1,360 mobile app developers and security leaders
- The full set of incident categories, including tampering, cloning, backend abuse, and customer churn effects
- Practical protection layers for development, release, and runtime phases that were only summarised here
- How the report frames AI-assisted development as a security and delivery challenge
👉 Read Guardsquare's research on mobile app security incidents and client-side risk →
Mobile app tampering and API abuse: what security teams need to fix?
Explore further
19/08/2026 4:23 pm
Client-side mobile risk is a governance problem, not just a code-protection problem. The survey shows that incidents are now routine, which means mobile app assurance has to be managed as part of enterprise security governance rather than left to release engineering alone. When the app itself becomes a trust boundary, identity, API, and runtime controls all need to align. Practitioners should treat mobile applications as governed access surfaces, not merely delivery artefacts.
A question worth separating out:
Q: Who should own mobile app security when client risk affects backend systems?
A: Ownership should be shared across application security, IAM, API governance, and mobile engineering. The application team understands release and runtime behaviour, while IAM and API owners control the trust decisions that turn a client request into access. If those groups stay siloed, the attack surface stays visible only in fragments.
👉 Read our full editorial: Client-side mobile app risk is now driving backend exposure
