Topic starter
19/08/2026 3:24 pm
TL;DR: AI-assisted tooling is increasing the speed and scale of reverse engineering, credential theft, API abuse, and mobile tampering, while 79% of mobile developers cite time-to-market pressure as the main barrier to stronger protection, according to Guardsquare. The practical shift is toward polymorphic, layered controls that change per build so one successful attack does not generalise across an entire app portfolio.
Editorial analysis by NHI Mgmt Group, based on content published by Guardsquare: “Polymorphism: Why the Shape of Mobile App Protection Must Change”.
By the numbers:
- 82% of mobile app publishers say API abuse is increasing.
- 15 different attack techniques are now being bolstered by generative AI.
Key questions
Q: What breaks when mobile app protection stays the same across releases?
A: Static protection lets attackers reuse one successful reverse-engineering method across many apps and builds.
Q: Why do AI-assisted tools make mobile app attacks more scalable?
A: They reduce the time needed to find secrets, analyse app structure, and adapt tampering methods.
Q: What are the signs that mobile API controls are failing?
A: Repeated insecure communication findings, hardcoded credentials, tamperable clients, and inconsistent attestation decisions are strong warning signs.
Practitioner guidance
- Implement build-specific protection variance Use polymorphic code hardening and randomized runtime checks so each app build presents a different reverse-engineering target.
- Move secrets out of static app assets Eliminate hardcoded secrets, tokens, and backend access mechanisms from mobile packages and developer workflows.
- Bind API trust to app attestation Require attestation and runtime integrity checks before allowing sensitive mobile API calls to reach backend services.
Bottom line: AI-assisted tooling makes static mobile app protection easier to reuse across many targets, which is the real scaling problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:09 pm
Polymorphic protection is now a governance requirement, not just a hardening preference. If every build exposes the same security shape, attackers get a reusable playbook and defenders lose the advantage of one-off uniqueness. The article’s core point is that mobile app security has to deny scale, not merely absorb individual attacks. For AppSec leaders, that means treating build variability as a control objective.
A few things that frame the scale:
- 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: How should teams govern mobile app attestation and runtime checks?
A: Teams should treat attestation and runtime integrity as prerequisites for sensitive API access, not as optional telemetry. The practical aim is to verify that the client is still the intended build before high-value actions are allowed. That keeps mobile trust tied to the application state, not just to the moment of login.
👉 Read our full editorial: Polymorphic mobile app protection must change for AI-enabled attacks