Dating myself a little here, but I spent time in the trenches on the IT and cybersecurity side back in the early days of vulnerability management. We would run scans and report the results, and it felt productive. But the reality was that we were only scanning what we could see. Unless we had authentication credentials for a given endpoint, we weren’t really scanning it—we were just checking the locks on the front door and calling it a day.
I’ve said for 10-plus years now that the vast majority of attacks, at the point of attack, are “insider attacks.” Attackers are using compromised credentials—whether they got them through phishing, credential stuffing, or some other method. At the point of the breach, it’s a “valid” user doing these things. That changed the game for how we scan and how we defend. It meant unauthenticated scanning was only telling part of the story, and a small part at that.
That lesson has been thoroughly learned on the network and web application side. But mobile? Mobile app security is still stuck in that same trap—and it’s a much bigger problem than most organizations realize.
You Can’t Test What You Can’t Touch
The fundamental issue is pretty straightforward. Most mobile app security testing never gets past the login screen. The testing tools can’t authenticate, so they only analyze what’s visible before login. By some estimates, that means up to 95% of a mobile app’s actual attack surface goes untested. All of the sensitive stuff—financial transactions, personal data, internal APIs, regulated information—sits behind the login. That’s the whole point of having a login screen. And it’s exactly what most security testing skips.
I had an opportunity recently to chat with Alan Snyder, CEO of NowSecure, about mobile app security challenges, and this was a recurring theme in our conversation. Static analysis can see the entire app’s code, and that’s valuable. But as Snyder pointed out, you can’t test data in motion unless you actually put it in motion. If an app has a workflow where a user enters a credit card number, you need to actually exercise that workflow on a real device to know whether the data is being handled securely. You can’t determine that by reading the source code alone. You need to run the app, interact with it the way an actual user would, and see what happens. That requires getting past the login screen.
The workarounds have always been painful. Custom scripts that break every time the app’s UI changes. Manual pen testing that’s expensive enough that organizations only do it once a year. Or just accepting the limitations and testing what you can. None of those are great options, and as the number and complexity of mobile apps keep growing, they’re getting worse.
Compromised Credentials and the Mobile Blind Spot
For the last two years, the number one successful breach method has been compromised credentials. The Verizon DBIR, Google’s threat reports, and Mandiant’s findings all say the same thing. Your primary defense against compromised credentials is your authentication—MFA implementation, login workflows, and session management. If you’re not testing those things, you’re not testing your defenses against the most common attack vector. Snyder made a simple but effective argument on this point: the login screen exists for a reason. It’s there to protect the sensitive stuff. If your security testing doesn’t go past it, you’re not testing the thing that matters most.
This is where mobile gets overlooked in a way that it shouldn’t. Organizations tend to treat mobile like a secondary concern—a smaller-screen version of the web app. But a mobile app with authenticated access to your back-end systems is a door into those systems, same as a web app. An attacker doesn’t care whether they get in through the web front door or the mobile front door. They just want to go through one of them.
The data suggests this isn’t just a theoretical risk. A research study from Enterprise Strategy Group (now part of Omdia) and Guardsquare found that 62% of organizations experienced at least one mobile app security incident in the past year, with an average of nine incidents per organization. The financial impact ranged from $1 million to $20 million per attack, with the average landing around $7 million.
Melinda Marks, practice director for cybersecurity at Omdia, noted, “Companies across industries want to give their customers the convenience of using applications on the go via mobile apps, but they don’t always put the development of the applications through rigorous security testing, especially for mobile applications. Because so many of the applications include payments, it can be a lucrative target for attackers to target.”
There’s also an argument that mobile is actually the more attractive vector for reconnaissance. Snyder described a pattern he sees regularly: attackers download a company’s mobile app, reverse-engineer it on their own device, and enumerate the organization’s APIs—all locally. Unlike attacking a web app, where firewalls and network monitoring might flag the activity, mobile app reconnaissance happens on the attacker’s hardware. The organization never sees it. He noted that something like 20-25% of apps still ship with debug symbols enabled, which just makes that reconnaissance easier. Simple thing to fix—flipping a switch to turn those off—but a lot of teams aren’t doing it.
The Telemetry Problem
There hasn’t been a SolarWinds-scale breach that was definitively attributed to a mobile app. That’s part of why organizations feel comfortable deprioritizing mobile security. But I think the more honest assessment is that we probably just don’t know. Most companies don’t have the telemetry to trace a breach back to mobile with any real confidence. When I raised this with Snyder, he agreed—of course, breaches are coming through mobile. You’d be crazy to think they’re not. Organizations just can’t trace it back.
Think about it this way. My phone connects to OneDrive, Microsoft 365, Salesforce—the same back-end systems I access from my desktop. If a breach came through my phone, would the security team’s telemetry be granular enough to tell whether the attacker came in through the mobile app or the desktop? In most cases, there just isn’t enough runtime telemetry for mobile apps to provide that kind of smoking gun. The absence of evidence isn’t evidence of absence—it’s a gap in visibility. And when security teams are already stretched thin, it’s convenient to look the other way on a risk you can’t easily measure.
The Supply Chain You Didn’t Know You Had
About 70% of a typical mobile app is third-party code—SDKs, libraries, and components that the app developer didn’t write. That’s a software supply chain, and it comes with supply chain risks that a lot of organizations aren’t tracking closely enough. The Gravy Analytics breach is a good example. Data broker SDKs embedded in popular apps were collecting geolocation and user information, then selling it—without meaningful consent from either the consumer or, in many cases, the app developer who embedded the SDK in the first place. That “free” SDK was monetizing customer data behind everyone’s back. I remember seeing reports about this and wondering—are organizations paying enough attention to what those components are doing after they’ve been deployed? What happens when the SDK updates and its behavior changes?
Regulations are catching up. California, other US states, and the EU have all tightened requirements around user consent and data collection. Apple and Google are enforcing stricter privacy rules in their app stores. That’s a positive development. But it also means organizations need to actually test what their apps are doing with data—not just what their own code is doing, but what those third-party components are doing too. You can’t do that effectively without authenticated dynamic testing.
Now layer AI on top of the supply chain question. An organization might know where AI is in the 30% of the apps they wrote. But what about the other 70%? As Snyder noted, “You’re not going to get one AI in a mobile app. You’re going to get 20, because all of these components are going to add it.” Each one needs to be vetted for how it handles data, and each one expands the attack surface in ways that aren’t visible from static analysis alone.
Mobile Isn’t a Secondary Channel Anymore
There’s a generational shift happening that makes all of this more pressing. I see it in my own house—my youngest will be 20 this year, and she does everything on her phone virtually. Things I would instinctively pull up on a laptop, she handles on mobile without thinking twice. If she asks me to do something on the phone, I’m like, “Send me the link, and I’ll open it on my computer.” I literally don’t understand how she accomplishes what she does on that screen. But she’s not the outlier here—I am.
Adobe Analytics data shows mobile accounted for 53% of digital retail sales over the last holiday season, and that number climbs two to three percentage points every year. The younger the demographic, the more likely they are to be not just mobile-first but mobile-only. Every year that trend continues, the gap between how important mobile apps are to the business and how much security attention they receive gets harder to justify.
NowSecure AI-Navigator Takes on the Authentication Bottleneck
My conversation with Snyder was prompted by the launch of NowSecure AI-Navigator—a new functionality that directly addresses the authentication bottleneck. NowSecure has been doing mobile app security testing for about 10 years and has offered authenticated testing for most of that time, but the process relied on brittle scripts and manual configuration that broke every time an app updated.
AI-Navigator uses AI to automate the login process instead. Security teams provide credentials through the platform, click a button, and the AI navigates the app and handles authentication. When the UI changes between app versions, it adapts automatically. According to Snyder, early adopters saw testing time drop by more than 90%—from days to minutes.
I asked Snyder about the security of using AI to handle authentication, which is the obvious question. He stressed that the AI is used strictly for navigation—figuring out how to get to the login screen and work through the app. A completely separate capability handles the actual credential insertion. “The credentials never, ever, ever touch the AI model, and so can’t be trained, can’t be logged, can’t be stored,” Snyder explained. That kind of separation is important—you don’t want to solve one security problem by creating another one.
I asked Snyder whether authenticated dynamic testing is becoming table stakes for mobile app security. He said the mindset shift still needs to happen, but the practical barriers are gone. “It is now easy, it is fast, and it is very cost-effective to do it continuously,” he said. “The prior barriers that existed, they’re gone, and that’s the big news.” AI-Navigator is available now for Android, with iOS support coming soon.
Time to Close the Gap
Mobile apps aren’t a nice-to-have anymore. For a growing number of organizations, they are the primary way customers interact with the business. When more than half of your digital revenue comes through mobile, and that percentage keeps climbing every year, treating mobile app security as a secondary concern doesn’t make sense.
The tools to do authenticated dynamic testing are there. The data on the cost of getting it wrong is there. At this point, the only thing standing in the way is the decision to actually prioritize it.