Notifications
Clear all
Topic starter
18/08/2026 2:11 pm
TL;DR: Mobile KYC systems remain exposed when reverse engineering, falsified inputs, and emulator-based spoofing let attackers bypass liveness and verification checks, according to Guardsquare. The governance lesson is that code hardening alone is not enough when fraud pressure, SDK reuse, and onboarding trust sit in the same mobile workflow.
NHIMG editorial — based on content published by Guardsquare: Mobile Developer in Central Asia Finds Protection for Sensitive KYC Systems
By the numbers:
- The company serves more than 20 clients with between three and four million total end users across banking, finance, and government services.
- Guardsquare says more than 1,000 customers worldwide rely on its mobile application security platform.
Questions worth separating out
Q: What breaks when mobile KYC controls rely on client-side trust?
A: Client-side trust breaks when attackers can inspect the app, modify behaviour, or replay inputs before the verification decision is made.
Q: Why do emulators and deepfakes make mobile identity checks less reliable?
A: Emulators and deepfakes reduce reliability because they let attackers imitate both the device and the person presenting themselves to the app.
Q: How can teams tell whether mobile verification is working?
A: Look for reduced fraud loss, fewer successful account recovery abuse cases, and lower approval rates on high-risk transactions that follow recent SIM changes.
Practitioner guidance
- Harden the full verification path Protect the camera input, app state, device signals, and backend decision points as one verification chain rather than separate controls.
- Separate APK and SDK assurance Define distinct test plans for standalone mobile apps and embedded SDKs because partner integration changes the trust boundary.
- Reduce reliance on client-observable logic Move critical verification decisions out of the mobile client wherever business rules allow.
What's in the full article
Guardsquare's full report covers the operational detail this post intentionally leaves for the source:
- How the team configured obfuscation and runtime protections separately for APK and SDK use cases
- What the guided onboarding and technical support process looked like during implementation
- Why the company planned to add scanning capabilities alongside protection, including pentest cost considerations
- How the protection model was applied across Android and iOS SDK versions
👉 Read Guardsquare’s case study on protecting mobile KYC systems from reverse engineering →
Mobile KYC tampering and reverse engineering: what should teams change?
Explore further
18/08/2026 3:03 pm
Mobile KYC is now an identity verification governance problem, not just an app protection problem. When verification logic, biometric intake, and anti-fraud decisions all sit inside the same mobile workflow, a single tampered client can undermine the whole control chain. That is why IAM and fraud teams need to treat the mobile app as part of the identity perimeter, not an isolated channel. Practitioners should align mobile assurance with identity governance, not only code protection.
A question worth separating out:
Q: Who is accountable when mobile KYC fraud succeeds?
A: Accountability sits across identity verification, application security, fraud operations, and the business owner of onboarding. If the mobile app can be tampered with or manipulated, that is not a single-team failure. Governance should assign explicit ownership for input integrity, anti-tamper controls, and fraud response so the gap does not fall between teams.
👉 Read our full editorial: Mobile KYC app protection still breaks at the tampering layer
