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.
Expanded Definition
An app integrity check is a control that tests whether an application still matches the trusted version that was built, signed, packaged, and approved for use. It looks for tampering, repackaging, injected code, altered libraries, emulation artefacts, or runtime changes that indicate the app can no longer be treated as the intended client.
The term is used most often in mobile and consumer-facing applications where the client itself becomes part of the trust boundary. A banking or wallet app, for example, is not just software delivery; it is also a decision point that may determine whether sessions, transactions, or sensitive workflows should proceed. Guidance is consistent that integrity validation should be tied to the trust decision, not treated as a cosmetic signal. That means a failed check should affect access, step-up authentication, telemetry, or transaction handling rather than simply generating an informational alert.
App integrity checks are sometimes confused with generic malware scanning, but they are narrower. They assess whether the app instance is the one that was expected, not whether the device is healthy in every respect. For that reason, they sit closer to anti-tamper and client trust assurance than to broad endpoint protection.
Examples and Use Cases
Integrity checks appear in several practitioner workflows where the client application must remain trustworthy before it is allowed to operate.
- Mobile banking apps check whether the package name, signing certificate, or binary hash still matches the expected release before allowing high-risk actions.
- Wallet apps verify that the client has not been repackaged with altered transaction logic or UI overlays that could redirect payments.
- Enterprise mobile apps use integrity signals to decide whether to permit access to protected APIs, especially when the app is distributed outside tightly controlled stores.
- Fraud teams combine integrity outcomes with device signals because an altered client often correlates with automation, emulation, or interception attempts.
- Developers use integrity validation to detect tampering introduced after release, such as code injection, repackaging, or removal of controls intended to enforce safe behaviour.
The main trade-off is between stronger trust decisions and user friction. Aggressive checks can block legitimate users on rooted, jailbroken, or heavily customised devices, so organisations must decide how much risk they are willing to absorb versus how much access they will challenge or deny.
Security Implications
When app integrity checks are weak or absent, an attacker can modify the client without immediately breaking the user experience. That creates a high-value path for fraud, credential theft, API abuse, transaction manipulation, and suppression of security prompts. In mobile financial apps, a repackaged client can become a trustworthy-looking delivery vehicle for malicious code because users often judge it by its familiar icon and interface.
Integrity failure also reduces the quality of downstream controls. If the app can be altered freely, certificate pinning, transaction confirmation flows, local policy enforcement, and UI protections can all be bypassed or rewritten. The result is not just a compromised binary but a compromised trust model, where the server may continue to accept requests from an untrusted client instance.
Failure mechanism: tampering, repackaging, injection, or runtime hooking changes the app’s behaviour while preserving enough normal function to avoid immediate suspicion.
Impact: fraud paths widen, telemetry becomes less reliable, and security teams lose confidence that the app presenting itself to the backend is the one they shipped.
Domain and Governance Relevance
App integrity checks matter most in domains where the client’s authenticity directly affects transaction trust, customer safety, or regulatory exposure. For mobile banking, payments, digital wallets, and other high-risk consumer applications, the integrity result becomes part of the control decision about whether the session should be trusted at all.
From a governance perspective, the important question is not whether an integrity check exists, but whether it is tied to an explicit policy outcome. A check that only logs anomalies leaves the organisation exposed to altered clients that can still reach sensitive functionality. A check that is embedded in release governance, fraud monitoring, and access policy gives the organisation a measurable trust boundary around the app itself.
NHIMG treats this as a client trust problem first, and an identity problem only when the application is the front door to sensitive authenticated activity. In that setting, the integrity of the app affects how much confidence the organisation can place in the session, the user, and the actions requested through the client.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 10 — Audit Log Management | Integrity checks rely on trustworthy signals and tamper evidence. |
| 4 — Secure Configuration of Enterprise Assets and Software | App repackaging and altered builds are software integrity failures. | |
| Recommendation — Log integrity failures and alert on repeated client tampering signals. Enforce signed releases and verify approved software before trust decisions. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Client integrity protects the confidentiality and correctness of protected app data. |
| PR.PT — Protective Technology | Integrity checks are a protective trust control at the application boundary. | |
| Recommendation — Protect application binaries and runtime state from unauthorised modification. Apply anti-tamper controls to validate client authenticity before access. | ||
| MITRE ATT&CK | T1406 — Code Repositories | Repackaging and tampering reflect modification of software artefacts used by attackers. |
| Recommendation — Monitor for altered application artefacts and investigate unexpected build drift. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | Integrity checks matter when altered apps can expose stored credentials or tokens. |
| Recommendation — Limit secrets exposure in client apps and invalidate credentials after tamper detection. | ||
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
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
