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.
Editorial analysis by NHI Mgmt Group, based on content published by Guardsquare: “New Research Shows Mobile App Security Incidents are Now Widespread”.
By the numbers:
- A global survey of 1,360 mobile app developers and security leaders underpins the findings, according to Guardsquare.
- 72% of organisations experienced at least one mobile app security incident in the past year, according to Guardsquare.
- 63% of organisations were aware of unauthorized modding, cloning, or tampering of their mobile apps within the past 12 months, according to Guardsquare.
Key questions
Q: What breaks when mobile apps are tampered with before backend requests are made?
A: The backend loses confidence that requests reflect the intended client behaviour, even if authentication still succeeds.
A: Reverse engineering matters because the binary can reveal how the app talks to servers, what values are embedded in code, and where defensive controls are weak.
Q: How do security teams know whether mobile application protection is actually working in production?
A: They should look for real-time telemetry on attack attempts, including debugging, hooking, emulator use, virtual environments, repackaging, and privilege escalation.
Practitioner guidance
- Implement app attestation at backend entry points Require the backend to verify app integrity before accepting sensitive requests from mobile clients, especially for flows that expose account, payment, or session data.
- Correlate client and API telemetry Unify mobile runtime signals with API logs so security teams can detect tampering, request manipulation, and abnormal backend use in the same investigation path.
- Harden apps against reverse engineering Use code hardening and runtime protections to raise the cost of extracting business logic, secrets, and request patterns from distributed mobile binaries.
Bottom line: Mobile app risk is now a trust and governance problem because client tampering can translate directly into backend exposure and business loss.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:23 pm
Client-side mobile security is now an identity and trust boundary problem, not just an app hardening problem. A mobile app that can be copied, instrumented, or modified outside organisational control cannot be treated as a trusted identity for backend access. That makes app attestation, runtime verification, and request-level scrutiny core governance issues, not optional hardening. Practitioners should think of the app instance as a security principal whose trust must be continuously proven.
A few things that frame the scale:
- Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: What should organisations do when mobile security and development priorities conflict?
A: Treat mobile app integrity as a release criterion, not a post-release enhancement. If teams cannot verify the app, protect it at runtime, and observe its backend behaviour, then speed has been bought at the expense of trust. Governance should make client protection part of the definition of done for mobile delivery.
👉 Read our full editorial: Client-side mobile app risk is now driving backend exposure