An app integrity check verifies whether an application has been altered, tampered with, or repackaged. It helps identify unauthorized changes to code or runtime behavior before the app is trusted. For mobile banking and wallet apps, integrity checks are central to limiting fraud and preserving trust in the client.
What App Integrity Checks Actually Verify
An app integrity check is about trust in the application itself, not just in the user or device around it. It looks for signs that the binary, package, runtime, or delivery path has been altered, repackaged, or instrumented in ways that could change how the app behaves once installed.
That matters because an app can appear legitimate while silently doing something different from what the publisher intended. In mobile and desktop environments alike, integrity is what helps distinguish the intended release from a modified copy, a cloned build, or an app that has been tampered with after signing.
Why Integrity Matters for Trust and Fraud Resistance
Integrity checks are often used when the application itself is part of the security boundary, especially in financial, payment, and account-sensitive apps. If an attacker can change the code, attach instrumentation, or swap in a repackaged version, they may be able to alter transactions, capture secrets, bypass protections, or weaken security logic.
For mobile banking and wallet apps, the practical value is not only detecting tampering but also preserving confidence that the client is still the client the organisation shipped. That is why integrity signals are frequently combined with other trust signals, such as device posture, attestation, and server-side risk checks.
Common Integrity Failure Modes
Integrity failures usually show up as modification after signing, repackaging with added malicious code, repointing traffic through a hostile proxy, or runtime hooking that changes how the app handles credentials and sensitive flows. In some cases the app remains functional, which makes the compromise harder to spot if teams rely only on surface-level behavior.
Some integrity schemes protect the package at install time, while others assess the runtime environment or the app’s behaviour after launch. A strong design treats these as complementary, because code integrity alone does not fully address injected libraries, overlays, automation abuse, or tampered runtimes.
How App Integrity Checks Fit into Application Security
Integrity checks are most effective when they are part of a broader application security strategy rather than a standalone gate. They help raise the cost of repackaging and tampering, but they do not replace secure coding, backend authorization, fraud monitoring, or hardening of secrets and session handling.
For teams shipping mobile or cross-platform apps, this usually means deciding which integrity signals are worth enforcing in the client, which checks should be verified again by the server, and what fallback behavior is acceptable when a check fails or is inconclusive. NHI Management Group’s On-Device AI Security Guide is relevant where shipped client components and local runtimes need to be trusted after deployment, and the Flutter and React Native Security Guide covers integrity-relevant limits in cross-platform app delivery and runtime behavior.
Risk and Threat Considerations
Integrity weaknesses create a direct trust problem: once a modified app is accepted as genuine, an attacker can alter behavior while keeping the outward appearance of a valid client. That can enable fraud, secret theft, policy bypass, or manipulation of sensitive flows without needing to compromise the backend first.
Failure mechanism: The attacker repackages, hooks, or instruments the app so the published code path is no longer the code path actually running on the device.
Impact: The organisation may continue trusting a hostile client, which can undermine transaction security, expose credentials or tokens, and invalidate assumptions used by fraud and risk controls.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V13 — Configuration | App integrity checks verify whether deployed app configuration and code have been altered. |
| Recommendation — Validate client integrity signals before trusting sensitive app behavior. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | This control family directly covers detecting unauthorized modification of software and related integrity checks. |
| CM-8 — System Component Inventory | Inventory supports deciding which apps must be checked for tampering or repackaging. | |
| SC-28 — Protection of Information at Rest | Integrity checks often complement protection of stored app assets and embedded sensitive material. | |
| Recommendation — Apply SI-7 to detect unauthorized code or runtime changes before trusting the application. Maintain an accurate app inventory so integrity monitoring covers the right components. Protect shipped app artifacts and sensitive embedded material from unauthorized alteration. | ||
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Client integrity for apps that depend on embedded secrets or cloud-backed trust paths overlaps with deployment trust risks. |
| Recommendation — Review client trust assumptions and remove brittle configuration dependencies from shipped apps. | ||
Practitioner Guidance
Why practitioners should care: App integrity is only useful when it informs a real trust decision. Teams should decide in advance what response is appropriate for a failed, bypassed, or uncertain integrity result, because an alert with no enforcement path quickly becomes noise.
What to watch for: Treat integrity as one control signal among several, especially in high-value apps. Pair it with backend verification, session monitoring, and careful handling of secrets so that tampering does not automatically translate into full account or transaction compromise.
In practice, the strongest programmes use integrity checks to raise attacker cost and reduce silent tampering, while keeping the ultimate trust decision on the server side.
Related resources from NHI Mgmt Group
- What do IAM teams need to check in self-service app stores?
- Who should own mobile app integrity controls in an enterprise?
- What breaks when mobile APIs trust the app session without verifying client integrity?
- What is the difference between app package integrity and code integrity in mobile attestation?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org