A banking app authenticates a customer and sends a transaction request to the backend, and everything appears legitimate. But what if the request comes from a modified app running on a compromised device?

For banks and fintechs, a valid login does not necessarily mean the application behind it can be trusted. Attackers can interfere with how an app operates without triggering conventional authentication checks.

Mobile app attestation helps verify whether a request originates from a genuine application using mechanisms such as Google Play Integrity API and Apple App Attest. These checks give the backend stronger evidence of application authenticity, allowing it to make more informed decisions before sensitive actions proceed.

How Mobile App Attestation Verifies App and Device Integrity

Mobile app attestation verifies whether an application instance and, depending on the platform, its device environment meet expected integrity requirements. The backend checks cryptographically protected evidence from trusted platform services before approving sensitive requests.

Here's how the three key checks work:

1. App Integrity and Authenticity

This first check confirms whether the backend is communicating with the expected app. Depending on the platform, app integrity verification can assess:

• Application identity: Checks that the package or app identifier matches the registered application.

• Signing identity: Confirms the application is associated with the expected developer signing identity.

• Version and distribution status: Identifies recognized release or distribution state, where supported.

• Integrity status: Establishes if the platform recognizes the application instance as legitimate under its integrity requirements.

There is a distinction between the two forms of assurance. App authenticity establishes whether the application is the one the business expects, whereas app integrity establishes whether it meets the conditions required to trust its identity and execution.

2. Device and Environment Integrity

Verifying the application alone leaves another question: "What kind of environment is running it?"

Depending on the platform, device integrity verification provides signals about whether the operating environment meets expected security conditions. These signals can indicate rooted or otherwise compromised devices, as well as emulators and virtualized environments where detection is supported.

App attestation establishes the legitimacy of the application instance, while device attestation assesses the device and its security environment. A legitimate app can still run on a compromised device, and the available integrity checks vary by platform.

3. Cryptographic Verification and Backend Decisioning

App and device signals become useful when the backend receives evidence it can independently validate. Cryptographic verification establishes the origin and integrity of attestation evidence, reducing reliance on claims made by the mobile client itself.

The process typically follows five steps:

1. Initiate attestation: The application requests an integrity assessment, often associated with a server-generated challenge or specific request context.

2. Evaluate integrity: The platform assesses supported application and device signals.

3. Generate evidence: The platform produces cryptographically protected attestation evidence or an integrity verdict.

4. Verify on the backend: The application forwards the evidence, and the backend validates its authenticity, freshness, and relevant request binding.

5. Make a risk decision: Based on the verified result and applicable risk policies, the backend allows, challenges, restricts, or rejects the request.

The backend must verify attestation evidence rather than trust the app to validate itself. Verification and enforcement decisions belong on the backend, where a compromised client cannot directly alter the decision logic.

Related Read: How to Secure Mobile Apps Across Development and Runtime

How Does App Attestation Work on Android and iOS?

Android and iOS provide native mechanisms for verifying application integrity, but they differ in how they establish trust and what evidence they return to the backend.

Google Play Integrity API for Android

Google Play Integrity API allows Android applications to assess whether requests originate from a recognized application running on a device that meets Google's integrity requirements.

When an application requests an integrity check, Google Play evaluates relevant app and device signals and returns a protected integrity token. The backend sends the token to Google for verification and receives verdicts covering:

• App integrity: Whether the application and its signing certificate match a version recognized by Google Play.

• Device integrity: Whether the device meets Google's integrity requirements, with different assurance levels depending on its security state.

• Environment signals: Additional information about potentially risky conditions, such as applications capable of capturing screens or controlling device interactions, when enabled.

The backend evaluates these verdicts alongside the request context before deciding whether to proceed, require additional verification, or restrict the action.

According to Google's February 2026 Android security report, apps and games perform more than 20 billion Play Integrity API checks daily to protect against unauthorized access and abuse. The scale reflects how extensively integrity verification is used across Android applications.

Google Play Integrity provides evidence for risk assessment, but the verdict alone does not establish that every activity within the application is safe.

Apple App Attest for iOS

Apple App Attest uses hardware-backed cryptographic keys to prove that requests originate from a legitimate iOS app instance.

The process follows five steps:

1. Generate a key: The application creates a cryptographic key pair using Apple's App Attest service.

2. Attest the key: Apple provides attestation evidence linking the key to the legitimate application instance.

3. Validate the attestation: The backend verifies the evidence against Apple's trust requirements and registers the key.

4. Generate assertions: For subsequent sensitive requests, the application uses the registered key to sign assertions bound to the request context.

5. Verify the request: The backend checks the assertion, including its challenge or request binding and counter, to reduce replay risk before proceeding.

App Attest belongs to Apple's DeviceCheck framework, but the two serve different purposes. App Attest verifies application-instance authenticity, while DeviceCheck provides limited per-device state that businesses can use to track previously identified activity.

App Attest therefore establishes cryptographic evidence of application legitimacy without providing a general assessment of whether the operating system is compromised.

Google Play Integrity vs Apple App Attest

Google Play Integrity and Apple App Attest both provide verifiable evidence of application authenticity, but their security coverage differs. The comparison below highlights what each mechanism verifies and the operational considerations for mobile security teams.

Google Play Integrity provides broader app and device integrity signals, making it useful for evaluating the security state of Android requests. Apple App Attest focuses on establishing the legitimacy of an iOS app instance through cryptographic proof. Neither provides continuous visibility into runtime manipulation, so additional security controls remain necessary.

Two related Android capabilities also deserve consideration:

• SafetyNet Attestation migration: Google retired the SafetyNet Attestation API on January 31, 2025, replacing it with Play Integrity. Legacy implementations need updated backend verdict handling and integration logic to account for the newer API's behavior and quotas.

• Hardware-backed key attestation: Android Keystore also supports attestation of cryptographic keys, allowing servers to verify key properties and whether hardware protection uses a Trusted Execution Environment (TEE) or StrongBox. This serves a different purpose from Play Integrity's broader app and device assessments.

The threats each mechanism identifies depend on the integrity signals available, leaving some attack techniques outside native attestation coverage.

What Threats Can Mobile App Attestation Help Detect?

Mobile app attestation helps identify suspicious apps, devices, and requests before sensitive actions proceed. Its coverage varies between Android and iOS. 

Here are the specific threats mobile app attestation can help detect, depending on the integrity checks supported by each platform:

• Modified or repackaged applications: Fraudsters alter legitimate apps to bypass onboarding checks or create mule accounts. Versions that no longer match the recognized application are flagged before they are trusted.

• Unauthorized app instances: Cloned or unofficial apps are used to create fake accounts or operate multiple accounts under different identities. Clients that cannot prove they belong to the legitimate application warrant closer scrutiny.

• Compromised devices: Rooted or otherwise modified devices give attackers greater control over how an app behaves. Supported integrity checks can reveal signs of compromise during account access or transactions.

• Emulators and virtual environments: Device farms allow fraudsters to create accounts at scale, abuse promotions, or submit fraudulent loan applications. Some of these environments can be identified when they fail device integrity checks.

• Automated or fake clients: Scripts can send requests directly to backend APIs for credential stuffing or account takeover attempts. Requiring valid proof of app origin makes it harder for unauthorized clients to impersonate a genuine app, although automation inside a legitimate app may still go undetected.

• Replayed or manipulated requests: Attackers may try to reuse previously captured integrity evidence to make another request appear legitimate. Fresh challenges and request-specific verification make such attempts harder to execute.

There is also evidence of the impact of these checks. Google reported in March 2025 that applications using Play Integrity features experienced 80% lower unauthorized usage on average compared with other apps. The finding concerns activity from unverified or untrusted sources, rather than an overall reduction in mobile fraud.

That said, it is important to remember that attestation has limits. A successful check does not establish that the application remains safe throughout the session. Attackers can interfere with a running app after verification, while some threats fall outside the signals available from platform integrity checks.

Code injection, hooking, malicious overlays, and network manipulation require additional protection. For banking and lending applications, runtime security and backend fraud controls provide visibility into suspicious activity that app and device integrity checks alone cannot reveal.

Where Does App Attestation Fit Into a Mobile Security Architecture?

A mobile security architecture needs to account for different risks at different points in a session. Each security layer examines a specific part of the interaction, with the findings brought together before a sensitive action is approved.

The layers work together as follows:

• Authentication: Confirms the user's identity before granting access to an account.

• App attestation: Verifies the application's authenticity and supported integrity conditions.

• Device and environment intelligence: Assesses device reputation and signs of suspicious or manipulated environments.

• Runtime protection: Identifies attempts to interfere with the application while it is running, including code injection, hooking, or tampering.

• Network protection: Detects suspicious communication conditions, such as traffic interception or manipulated network connections.

• Backend risk decisioning: Evaluates the available signals alongside account and transaction context to allow, challenge, restrict, or reject an action.

Consider a banking customer who signs in and passes the initial security checks. Minutes later, a $20,000 transfer is initiated to a newly added beneficiary. Runtime monitoring detects a tool attempting to alter the transaction details, while network checks flag an unexpected proxy connection.

The backend now has additional evidence to evaluate alongside the customer's transaction history. Instead of approving the transfer based on the earlier checks, it can hold the payment and require additional verification or investigation before releasing the funds.

The example above shows how a transaction that initially appears legitimate can require further scrutiny when new risks emerge during execution.

How Bureau Extends Mobile App Integrity Protection

Runtime manipulation is more concerning when the affected device is linked to multiple identities or suspicious loan applications. Bureau connects runtime threat signals with persistent device intelligence and broader fraud risk context, allowing teams to investigate the activity behind an alert rather than treating every incident as an isolated security event.

Its Runtime Application Self-Protection (RASP) identifies threats during app execution, while its broader risk capabilities provide context for investigating suspicious sessions.

The capabilities work together in four ways:

• Connect runtime threats with device history: Bureau RASP detects rooting, jailbreaking, hooking, emulators, app tampering, and manipulated environments. Its persistent Device ID provides additional context about devices associated with suspicious activity, including repeat attempts across different accounts or sessions.

• Identify connections between suspicious accounts: Bureau's Graph Identity Network maps relationships between devices, identities, and accounts. A device showing signs of manipulation that is also linked to several newly created accounts, for example, warrants investigation for mule account creation or coordinated fraud.

• Evaluate integrity findings alongside behavioral risk: A missing or failed attestation result does not automatically establish fraudulent activity. Risk teams can consider device reputation, unusual interaction patterns, account history, and transaction context to determine the appropriate response.

• Apply risk-based responses: Bureau RASP supports configurable actions to monitor, warn, or block detected runtime threats. Its Unified Risk Decisioning Platform brings together broader risk signals to inform backend decisions, including whether to allow an action, request additional verification, restrict access, or reject a transaction.

Consider a digital lender receiving a loan application from a device showing signs of runtime manipulation. A runtime alert alone raises concern, but the device's association with several recently created identities and unusual application behavior gives investigators stronger grounds to examine the activity before approving the loan.

Bureau RASP complements Google Play Integrity and Apple App Attest by detecting threats during application execution. Its broader risk intelligence connects runtime findings with device history, identity relationships, and behavioral signals to support more informed fraud decisions.

Related Read: Compare 8 RASP Tools for Mobile Apps, Servers, and Cloud

Build Trust Beyond a One-Time Attestation

An attacker attempting to manipulate transaction details or interfere with an app's execution needs to be identified before the action is completed.

For financial institutions, detecting runtime threats before they lead to unauthorized transactions is as important as verifying the app at login. The priority is to connect security findings with the context needed to distinguish genuine users from potentially fraudulent activity.

Bureau brings device intelligence, behavioral signals, and runtime threat detection into a broader risk decisioning approach, helping financial institutions investigate suspicious sessions and apply proportionate controls without creating unnecessary friction for legitimate customers.

Book a demo to see how Bureau supports more informed fraud decisions across sensitive mobile interactions.

FAQs

1. What is mobile app attestation?

Mobile app attestation is a security mechanism that verifies whether an application is authentic and meets expected integrity requirements. It uses cryptographically protected evidence from trusted platform services to help the backend determine whether an app instance, and in some cases its device environment, can be trusted.

2. What is the difference between app attestation and device attestation?

App attestation verifies the authenticity and integrity of an application instance, while device attestation evaluates the security properties of the device or operating environment. Some platform mechanisms provide both types of signals, but the depth of device integrity information varies between Android and iOS.

3. How does Google Play Integrity API verify app integrity?

Google Play Integrity API evaluates an Android application's identity, signing information, and supported device integrity signals. It generates a protected token that the backend submits to Google for verification. The returned verdicts indicate whether the app is recognized and whether the device meets applicable integrity requirements.

4. How does Apple App Attest verify an iOS app?

Apple App Attest generates a hardware-backed cryptographic key and obtains attestation evidence from Apple. The backend verifies this evidence and registers the key. For subsequent requests, the application generates signed assertions that the backend validates to confirm the request originates from the attested app instance.

5. Can app attestation prevent app tampering?

App attestation can identify certain integrity failures associated with modified or unrecognized applications, but it does not directly prevent code modification. Protecting an application against tampering during execution requires additional controls, such as code hardening, runtime integrity monitoring, and active threat enforcement.

6. What should the backend do when attestation fails or is unavailable?

The backend should apply risk-based controls: permit low-risk actions where appropriate, require additional authentication for moderate-risk activity, and block high-risk transactions when sufficient trust cannot be established. For devices without Google Play Services, alternative device intelligence, behavioral signals, and stronger authentication can provide additional assurance.