Platform attestation verifies a device is genuine. It cannot tell you who is using it.
Mobile fraud defense has spent a decade answering the first question (is this device genuine?) and ignoring the second. Is this a real handset or an emulator? Is the app the one we shipped, or a repackaged copy? Did it come from the Play Store or a file someone downloaded from a forum? Those are answerable, and platform attestation answers them with cryptographic certainty.
The question platform attestation does not answer is who is driving the session.
That gap is where mobile fraud now lives. Picture a fraud farm operator running racks of cheap, genuine Android handsets. Every one of them passes every attestation check ever written. So does every kind of AI agent now reaching your app, whether it is working for one of your customers or running a campaign against them. Attestation answers questions about the device, the app, and the account presenting it - not about who is actually present in a session or why. Treating it as a complete mobile defense leaves the most expensive attacks untouched.
Today we are releasing Mobile Integrity Check (MIC) feature in Arkose Android SDK v3.0.0, built on the Google Play Integrity API. It closes the device and app question properly. The rest of this post is about why that only matters when something else is answering the second question.
What Mobile Integrity Check verifies
MIC integrates the Google Play Integrity API directly into the Arkose Android SDK, with an Arkose backend service brokering every interaction with Google and processing the verdicts that come back. It gives you a Google-backed answer on three things:
- Device integrity. The app is running on an uncompromised Android device, reasonably free of rooting, bootloader unlocking, or unauthorized OS modification.
- App authenticity. The running binary is the one you published, with a signing certificate matching what is registered in Play Console, not a cloned or repackaged build wearing your name.
- Distribution source. The app was installed through Google Play rather than a sideloaded or unauthorized channel.
- Account standing. Whether the Google account presenting the app holds a valid license for it and is in good standing.
- Request activity level. How frequently this device and app combination has requested integrity tokens, a coarse signal Google Play Protect uses to flag bot-like or automated behavior.
Verdicts are processed server side and returned in the Verify API response, alongside the Arkose risk signals your backend already consumes. The verdict is never handed back to the app on the device, which is what stops an attacker with control of that device from forging a clean result.
Because the verdict is Google-attested rather than inferred, it holds up in a fraud review in a way that a heuristic guess about emulator characteristics does not.
That is a real strengthening of the mobile signal set. It is also, on its own, insufficient.
Who is behind a verified device
Picture a session that passes every check above. Clean device, genuine app, Play Store install, an account in good standing, an unremarkable request rate. You still do not know which of these you are looking at.
A legitimate customer. Most of them. The check has told you something useful and you should get out of their way.
A person committing fraud at scale. Human fraud farms do not bother with emulators any more, because they do not have to. Racks of real, cheap, unmodified handsets are openly available, and every one of them attests clean. The economics work precisely because attestation cannot see the operation behind the device.
Software acting on someone's behalf. An AI agent operating inside a real app on a real phone produces an attestation verdict indistinguishable from your best customer's, and the self-disclosure conventions emerging on the web do not reliably extend to mobile. This group is not one population either. A crawler that publishes its identity, an assistant doing the work for a real customer that does not, and an adversary running a campaign all arrive through the same clean handset, and all three need a different answer. We wrote about telling them apart in See Every Agent. Classify by Intent. Enforce the Right Response.
One identical attestation result, several very different appropriate responses. That's the layering problem in miniature: attestation is one strong input into detecting fraud, not the whole answer.
What does Arkose Titan add on top of attestation?
Verdicts flow into Arkose Titan, which reads the session rather than only the device: how it behaves, how its device and network context compares to everything seen before, and how whoever is present responds when asked to complete a challenge.
That produces three things attestation cannot.
- Intent, separated from equipment. What distinguishes a fraud farm operator from a real customer is not the handset, it is the pattern: the pace, the repetition, the way one session resembles four hundred others. Titan evaluates that pattern, so buying genuine devices stops being a way to disappear.
- A read on agentic traffic based on what it is doing. Not every AI agent on your app is hostile, and blanket-blocking them costs revenue. Titan distinguishes an agent acting for a real customer from one acting against you, which is the distinction that determines whether letting agents through is an opportunity or an exposure.
- A response proportionate to the finding. Allow, observe, add friction or stop. Where attestation gives a clean yes or no on the device, Titan holds a suspicious session in between, testing it rather than waving it through or blocking it outright.
Underneath all three is the economic effect. Attestation raises the cost of the cheapest attacks by forcing attackers off emulators and onto real hardware. Titan raises the cost of everything above that, by making each genuine device an attacker buys deliver far less than it used to. Attacks stop because they stop paying, not because a single check caught them.
The layering is the point. Attestation supplies ground truth about the device and app. Titan supplies judgment about the session. Neither is much use alone: attestation without behavioral analysis misses everyone using real devices, and behavioral analysis without attestation spends effort on emulators it could have ruled out at the door.
How it behaves in a live app
The design principle throughout is that MIC adds a signal without adding a failure mode.
The check never blocks the challenge. It runs quietly in the background as the SDK starts up, with a timeout. If it fails, times out, or cannot run at all on that device, the Arkose challenge proceeds exactly as before. The only consequence is that the session arrives without an integrity verdict attached.
There is no change to what the user sees. No new screen, no new step, and no added waiting. The best outcome for a legitimate customer is that they never know the check happened.
It is off until you turn it on. MIC is opt-in, so upgrading the SDK changes nothing until you decide to enable it, and enabling it is a configuration step rather than a rebuild. Your Arkose team handles the rest.
The summary for security architects
Platform attestation is necessary and it is not sufficient. It establishes that a device and an app are genuine, which eliminates a whole class of cheap attacks and is worth doing for that reason alone. What it cannot do is tell you who is operating that genuine device, or what they are trying to accomplish, and that is the question the attacks worth worrying about now turn on.
Mobile Integrity Check gives Arkose Titan the device and app ground truth. Titan supplies judgment.
Get started: Android SDK · Mobile Integrity Check
FAQ
Does Mobile Integrity Check replace Arkose Titan?
No. Mobile Integrity Check verifies that the device and app are genuine. Arkose Titan reads the session and decides how to respond. Mobile Integrity Check verdicts feed into Titan, they do not replace it.
What happens if Mobile Integrity Check fails or times out?
The Arkose challenge proceeds exactly as before. The session simply arrives without an integrity verdict attached, and nothing changes for the user.
