The Device Was Genuine. The Key Was Hardware-Backed. The Fraud Was Real.

Platform security moves forward, and fraud routes around it.

Attackers do not need to defeat the best version of Android (or iOS). They need to find one accepted combination of hardware, software, application version and runtime state that gives them a usable path.

A modern onboarding flow may depend on a camera, a biometric sensor, a liveness process, a document scan, a device identity and backend risk decision.

The institution is not merely asking whether an image looks convincing. It is asking whether the entire path that produced the image can be trusted.

Was a real camera used? Was a fabricated video injected into the camera feed? Was the application genuine? Was the runtime instrumented? Was the device emulated or modified? And were the signals changed before reaching the backend?

AI has made fabricated identities and synthetic media cheaper and more convincing. The defensive response cannot be another visual puzzle. It must protect the input path and establish trust across the whole channel.

Security should be applied to the final compiled application after the ordinary build process, so that the artifact being protected is the artifact that reaches the customer.

Post-build, on-premises protection reduces exposure and allows the institution to harden code, resources and security logic without sending sensitive application material to a third-party cloud.

The application must be able to detect and resist tampering, debugging, hooking, instrumentation, code injection, root or jailbreak concealment, hostile containers and malware interference.

The question is not whether the package was genuine when it left the app store, but whether the application remains trustworthy while the sensitive operation is happening.

Hardware evidence is useful, but it should be independently evaluated alongside application and runtime evidence.

Keyboxes are in active circulation today that pass Play Integrity and Key Attestation as genuine hardware. Google revokes them eventually, but revocation follows discovery, and in the interval services relying on a standard attestation verdict are trusting devices that should already have been flagged. That is the window where credential stuffing farms, eKYC bypass, and payment fraud operate with a valid hardware identity. Here at Licel, we already know which ones they are, as we see maliciously used keyboxes two months earlier on average.   

Revocation, when it arrives, gives a binary answer. Revoked or not. That is not the distinction an institution needs. A certificate being actively weaponized and a certificate belonging to a device that will simply never receive a renewal are different problems: one is a threat, the other is a false positive waiting to cost you a legitimate customer.

This intelligence is live in Alice RDA, and is already available to a limited number of our clients.

A durable binding connects account state to protected cryptographic material and to the trusted state of the application and device.

Re-enrolment, recovery and migration flows must be treated as security-critical events. Attackers frequently target the process of replacing the trusted device rather than the trusted device itself.

Consider how this fails in practice.

The attacker does not attempt to compromise the bound device. They obtain credentials, initiate a recovery flow, and enroll a device of their own. The binding is then re-established correctly, cryptographically, exactly as designed, to hardware the criminal controls.

Every control downstream of that moment reports green. The application is genuine. The runtime is clean. The device is properly bound. The transaction is signed by a key generated in secure hardware and validated without error.

Nothing has been defeated. The trust relationship has simply been reissued to the wrong person.

A key held in secure storage can be invoked by a hostile process. A transaction displayed on screen can differ from the one submitted for authorization. In both cases the cryptography performs exactly as specified, and the result is fraudulent.

Sensitive operations such as key handling, token generation, request authorization, and authentication logic should therefore execute inside an environment isolated from the surrounding application and from a hostile runtime. Not only so the material stays protected, but so that the operation itself remains bound to the transaction the customer intended.

A virtual trusted execution environment provides that isolation consistently across Android and iOS, including devices where hardware capabilities vary.

The backend should not accept a request merely because its syntax is correct or because it contains a reusable secret. 

It should be able to verify that the request originated from a genuine, current and untampered application instance operating under acceptable security conditions.

Short-lived cryptographic proofs, app-version enforcement, replay resistance and binding to runtime integrity turn mobile API access into an enforceable trust decision rather than a client-side puzzle.