Notifications
Clear all
Topic starter
06/09/2026 3:44 pm
TL;DR: Mobile application MitM risk is not confined to network interception, because rooted devices and reverse engineering can expose traffic, keys, and client trust assumptions, according to Arxan Technologies. Layered controls such as certificate pinning, white-box encryption, and mTLS help, but each creates operational trade-offs that IAM and security teams must govern explicitly.
NHIMG editorial — based on content published by Arxan Technologies: When the Attacker Is the Client: Defending Against MitM Attacks
Questions worth separating out
Q: How should security teams handle mobile app trust when the endpoint may be hostile?
A: Treat the app as a potentially adversarial client, not a trusted network participant.
Q: Why does certificate pinning still fail in rooted mobile environments?
A: Because pinning depends on verification logic running inside the app, and that logic can be patched, hooked, or bypassed on a compromised device.
Q: How can organisations decide when mTLS is worth the operational overhead?
A: Use mTLS when the backend must distinguish legitimate app instances from everything else and the business impact of impersonation is high.
Practitioner guidance
- Classify mobile client certificates as privileged credentials Assign ownership for issuance, rotation, and revocation of app certificates in the same way you would for other high-trust machine identities.
- Use pinning only as one layer in a hostile-client model Deploy certificate pinning where interception resistance is required, but assume rooted devices can bypass the check.
- Protect client keys with white-box or hardware-backed mechanisms Where replay or impersonation would be material, keep client secrets out of recoverable memory wherever possible and prefer hardware-backed storage or white-box implementations for sensitive signing and decryption operations.
What's in the full article
Arxan Technologies' full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanations of how certificate pinning is implemented and bypassed in mobile apps.
- Operational trade-offs between white-box encryption, performance overhead, and endpoint resistance.
- How mTLS certificate issuance and revocation work at scale across large app populations.
- The vendor's specific guidance on combining pinning, white-boxing, and mTLS for different use cases.
👉 Read Arxan Technologies' analysis of mobile MitM defences and client trust controls →
Mobile app MitM defenses: are pinning and mTLS enough?
Explore further
06/09/2026 3:45 pm
Client trust is the real control plane in mobile application security: once the attacker owns the endpoint, encryption in transit stops being the main boundary. The mobile app begins to behave like a non-human client with its own trust material, lifecycle, and revocation problem. That makes this topic relevant to NHI governance as well as application security, because certificates and embedded keys are effectively machine identities in motion. Practitioners should govern mobile trust material as production access, not as a developer convenience.
A question worth separating out:
Q: What should teams do when mobile client certificates or keys could be extracted?
A: Assume extraction is possible and reduce the damage it can cause. Keep certificate lifetimes short, revoke aggressively, restrict API scope by identity, and store secrets in hardware-backed or obfuscated forms where feasible. The goal is to make a stolen credential narrow in utility, not universally reusable.
👉 Read our full editorial: MitM defense in mobile apps depends on layered client trust controls
