Look at the product pages of the autonomous penetration testing companies that have raised serious money in the last two years. Read them closely enough to notice what they cover, and then notice what they do not.
Web applications. APIs. Sometimes cloud configuration. Occasionally network.
Mobile is on the roadmap. It has been on the roadmap for a while.
I want to be fair about why. Mobile is genuinely harder than web, and the reasons are structural rather than a matter of effort. But the gap has now been open long enough to be worth examining on its own terms, because the software being shipped has not waited for the testing to catch up.
What the browser boundary actually costs
A modern company does not ship a website. It ships a system, and the web application is one entry point into it.
Take a consumer fintech product. There is a web dashboard, a REST or GraphQL API behind it, an iOS app, an Android app, a set of cloud services, and third party integrations for payments and identity. The API is shared. The authentication is shared. The business logic mostly lives server side.
Test the web application thoroughly and you have tested one client against that shared surface. You have learned a great deal about the endpoints the web client calls, in the way the web client calls them.
What you have not learned is what happens when a different client, on a device you do not control, calls the same endpoints in ways the web client never would. Mobile clients hold long lived credentials. They cache data locally. They ship compiled logic to hardware in the hands of the user. They talk to endpoints the web application does not touch, because mobile features and web features diverge over time and nobody goes back to consolidate.
The result is a surface that is architecturally connected to the tested one and practically unexamined.
Why mobile resists automation
Four things make mobile harder to test automatically, and they compound.
The client is a binary, not a document. A web application arrives as markup and script that a testing system can read directly. An iOS app arrives as a compiled binary inside an IPA. An Android app arrives as a DEX inside an APK. Before any testing happens, you have to get from a compiled artefact to an understanding of what the application does, which means decompilation, symbol recovery where symbols exist, and inference where they do not. None of that has an equivalent step in web testing.
The traffic is defended against you. Any mobile application worth testing pins its certificates. That is correct engineering, and it exists specifically to stop a third party from reading traffic between the app and its backend. A penetration tester is, at that moment, indistinguishable from the threat the pinning was built to stop. Getting to the traffic requires defeating a control the developers deliberately added, on a platform designed to make that difficult.
The runtime is the interesting part. A significant proportion of real mobile findings are not in the network traffic at all. They are in what the application does on the device: what it writes to local storage, what it puts in the keychain or keystore, what it logs, which components it exposes to other applications on the same device, what it leaves behind after logout. Reaching any of that means instrumenting a running application on a real or emulated device, which is a fundamentally different technical problem from sending HTTP requests to a host.
Two platforms, no shared work. iOS and Android share almost nothing that matters here. Different binary formats, different storage models, different permission systems, different instrumentation tooling, different platform protections. Building mobile capability is not one project. It is two, and the second one does not get to reuse the first.
Any one of these is an engineering problem. Together they are the reason a company can ship excellent web testing and still be a long way from shipping mobile.
What a real mobile assessment has to reach
If you are evaluating a vendor's mobile claim, the useful thing is to ask what it covers rather than whether it exists. The OWASP Mobile Application Security Verification Standard is the framework most buyers already reference, and its structure is a reasonable checklist for the conversation. Its control groups cover storage, cryptography, authentication, network communication, platform interaction, code quality, resilience and privacy.
Note what that list implies. Storage, platform interaction and resilience are on-device concerns. They cannot be assessed from outside. A tool that tests the API a mobile app happens to call has covered a portion of the network and authentication groups and nothing else, and a report framed as mobile coverage on that basis is describing a subset without saying so.
Three questions are worth asking directly.
Does the assessment examine the binary, or only the traffic. Does it observe application behaviour on a device, or only at the network boundary. And does it cover both platforms with equivalent depth, or is one of them a summary of the other.
The authentication problem underneath all of this
There is a more fundamental version of this question, and it applies to web as much as mobile.
Can the tool authenticate?
It sounds trivial. It is not. Testing a modern application means holding a session across a long sequence of requests, refreshing tokens before they expire, handling identity provider redirects, and in many cases authenticating against a cloud provider to reach the services behind the application. If a tool cannot do those things, it does not fail loudly. It runs, produces output, and reports on the small unauthenticated portion of the application it could actually reach: the login page, the marketing routes, the public endpoints.
That output looks like a penetration test. It has findings and severities and a coverage figure. What it does not have is any contact with the authenticated application, which is where the business logic lives and where the findings that matter are.
On mobile this gets worse, because mobile authentication tends to involve long lived refresh tokens, device binding, and biometric gates that have no web equivalent. A tool that struggles with a web session will not survive a mobile one.
The question to put to any vendor, including us, is not what the tool found. It is what the tool could reach before it started looking.
Where the line currently sits
Autonomous testing today covers more ground, more often, than a scheduled engagement can. What it does not yet fully replicate is a specific and narrowing set of judgements: which of two low severity findings chains into something serious, when a plausible looking result is not real, where a target's business logic makes an unusual attack path worth pursuing.
That set is smaller than it was a year ago and it is still shrinking. The direction is not in question. But we are describing a frontier that moves, not a permanent division of labour, and anyone claiming the frontier is already behind them is selling something.
Mobile has its own version of this. Platform updates break instrumentation on a regular cadence, and keeping mobile coverage current takes continuous work in a way that web coverage does not. That is the unglamorous part of the problem and it does not go away once you have solved the first version of it.
I also want to be clear that the difficulty I have described is real difficulty. The companies with mobile on their roadmap are not being lazy. They are working on a genuinely hard problem, and some of them will solve it.
Where Deus Rex sits
Deus Rex covers web, iOS and Android. Not as roadmap items, but as coverage we are running in live engagements today, across binary, runtime and traffic on both mobile platforms.
We were able to build it that way because of where we came from.
Deus Rex is built on twelve years of offensive security work at Cyrex, across enterprise software, SaaS platforms, financial services, mobile applications, infrastructure and some of the world’s largest online games. Gaming added a particularly demanding dimension to that experience.
Games ship across mobile, desktop, console and web simultaneously. They expose compiled binaries to millions of users, some actively trying to break them. They combine backend infrastructure, APIs, real-time systems and client-side logic, often with real money moving through their economies.
That environment pushed our capabilities around binary analysis, runtime instrumentation and multi-surface testing significantly further. But those capabilities were never limited to games.
The tooling that reaches a compiled binary, instruments a running application and analyzes its traffic is tooling our engineers have built, refined and used for years across both gaming and enterprise environments. The autonomous layer wraps around that capability. It did not have to invent it.
If you want to know what an assessment finds on the surfaces you are currently not testing, that is a conversation worth having.
deusrex.ai
Written by
Tim De Wachter
CTO Deus Rex
