Device integrity

Device integrity is the assessment of whether a device, operating system, application and execution environment can be trusted for a particular action. In digital banking, it helps an institution distinguish a legitimate request from one originating from a rooted, jailbroken, emulated, tampered or otherwise risky environment.

Device integrity is one signal in a broader trust decision. It does not identify the customer on its own, and it does not prove that a legitimate customer intends to make a transaction. Its value comes from combining verified device and app evidence with identity, behavioral, transaction, location and authentication signals.

Why device integrity matters in banking

Financial applications run on devices that can be modified, inspected or controlled by an attacker. A compromised environment may expose session data, alter application behavior, capture sensitive content or automate requests against high-value functions.

Mobile malware is one threat to this environment, targeting mobile devices to steal information or interfere with legitimate activity.

For a bank, that can affect account access, password resets, endpoint changes, card controls, payment approvals and money movement. A device-integrity assessment helps the backend decide whether to allow an action, request additional authentication, limit the action or route it for review.

• Account takeover prevention: A risky environment can add context to a decision when stolen credentials are used.
• Transaction protection: Device evidence can be assessed before approving a transfer, payment or account change.
• Application security: App-integrity signals can indicate that the installed application has been modified.
• Abuse detection: Integrity and activity signals can help identify automation, emulators and repeated abusive behavior.
• Customer experience: Risk-based decisions can reserve additional authentication for actions that need more assurance.

For broader background on banking trojans, screen overlays and application vulnerabilities, see Mobile authentication: Transforming today’s mobile banking threats into tomorrow’s opportunities.

How device integrity works

Device integrity usually combines local security checks with server-verified attestation. Local checks can identify indicators such as root or jailbreak artifacts, emulators, debugging frameworks and altered system properties. Because a local check runs in an environment an attacker may control, it should not be treated as the final source of trust.

Attestation adds evidence that is generated by a platform security service and verified by the backend. The evidence can cover the application, device or operating environment, depending on the platform and service. The backend then applies policy based on the sensitivity of the requested action.

Bind the request → Verify the evidence → Assess the result → Apply a response

OWASP recommends server-side validation, freshness checks, request binding and layered controls. A client-side message that says a device is safe is not enough because an attacker may alter the application or intercept the local decision.

Platform examples

• Android device integrity

  Google’s Play Integrity API returns signals about the authenticity of the application, the account context and the device environment. Its device-integrity verdicts can help a backend assess whether an app is running on a genuine certified Android device or an environment associated with elevated risk, such as an emulator or an untrustworthy device.

  Google recommends checking the request details and app-integrity result before interpreting device trust. It also describes tiered responses, request binding and protection against replay and tampering. The appropriate response depends on the action being protected and the institution’s risk policy.

• Apple device and app integrity

  Apple’s DeviceCheck services support per-device state and app-integrity assertions. App Attest lets an app create a cryptographic key that Apple can attest, allowing a server to assess whether requests come from a legitimate app instance. DeviceCheck can also help an institution associate server-side risk state with a device.

  Apple notes that App Attest cannot definitively identify every device with a compromised operating system. That limitation matters: an integrity assertion should inform risk assessment rather than act as a universal allow or deny rule.

Device integrity, device identity and device fingerprinting

These terms describe related but different ideas.

Device-based authentication verifies possession of a trusted device, while device integrity assesses the security conditions surrounding its use. A recognized device may still be running a modified operating system, a tampered application or automation tooling. This is why identity and integrity should be assessed together.

Entersekt’s device identity guidance explains how a registered device can support authentication across banking and payment interactions. Its Browser Authentication approach adds cryptographic browser binding and risk signals for web journeys.

How financial institutions should use integrity signals

Device integrity works best as part of a risk-based authentication policy. A low-risk login from a known customer and a trusted environment may need little visible interaction. A high-value transfer from a newly observed or compromised environment may require step-up authentication, transaction confirmation or a temporary restriction.

Institutions should define responses before deployment.

Visible vs invisible banking security: The ongoing UX debate explores the balance between background protection and visible authentication, providing context for designing proportionate customer interactions.

A missing or weak verdict does not always mean that fraud is present. Device age, operating-system support, connectivity, platform availability and customer circumstances can affect the evidence returned.

• Start with telemetry to understand the institution’s device population.
• Set different thresholds for login, account recovery, payment setup and money movement.
• Keep verdict validation on the server and protect it against replay.
• Use more than one signal because attackers can obtain valid evidence from real devices.
• Give customers a clear recovery path when a device cannot meet a policy requirement.
• Review privacy, data minimization, regional requirements and retention practices.

Entersekt’s Authentication Advisor is designed around adaptive authentication decisions that use real-time risk assessment to select an appropriate authentication response. Device context can support that decision alongside behavior, transaction data and channel context.

What device integrity cannot do

Device integrity cannot prove that the person operating an app is the account holder. It cannot, by itself, detect every scam, social-engineering event or authorized payment made under manipulation. It also cannot guarantee that an apparently trustworthy device remains safe after the assessment.

For that reason, integrity checks should sit alongside phishing-resistant authentication, transaction signing, behavioral analytics, identity verification and scam controls. The aim is to make a better decision at the point of risk, not to turn one technical verdict into a complete fraud determination.

The Securing the mobile banking channel white paper explores a broader approach to mobile threats, authentication and usability.

FAQs about device integrity

➡️ What is device integrity?

Device integrity is an assessment of whether a device and its software environment can be trusted for a specific action. It can include evidence about app authenticity, operating-system state, device certification, tampering, emulation and other risk indicators.

➡️ Is device integrity the same as device identity?

No. Device identity asks which device or browser instance is being used. Device integrity asks whether that environment can be trusted. A bank can use both signals to recognize a returning customer while also checking for compromise or tampering.

➡️ How does device integrity support account takeover prevention?

Device integrity adds context when a login or transaction comes from a modified, emulated or otherwise risky environment. A bank can then request additional authentication or restrict sensitive actions instead of relying only on a username and credential.

➡️ Can device integrity stop all mobile fraud?

No. Device integrity is one part of fraud decisioning. It should be combined with identity, behavior, transaction context, authentication and scam detection because a legitimate device can still be used by a fraudster or manipulated customer.

➡️ What is device attestation?

Device attestation is a cryptographically verifiable assertion about an app, device or execution environment. The backend validates the assertion and uses its result in policy decisions. Effective implementations bind the assertion to a request and check its freshness.

➡️ Why should the backend verify integrity?

The backend is outside the application environment being assessed. Server-side verification gives the institution a more reliable place to validate signatures, request binding, freshness and policy before a sensitive action is completed.

Sources and related articles

• OWASP guidance on device attestation
• Google Play Integrity API overview
• Apple DeviceCheck documentation

Technical services and platform behavior can change. Financial institutions should verify current vendor documentation and applicable regulatory requirements before adopting an integrity policy.