Why More MFA Doesn’t Mean More Security
There are two fundamental flaws in mobile authentication today:
The first is that we seem to have forgotten the main principle of authentication; that the second factor should live on a different device (out-of-band). Our obsession with – and reliance on – the mobile device means that we tend to be using it to carry out sensitive transactions and operations, and receive multiple factors of authentication there as well.
The second flaw is that authentication checks tend to be quite static and shallow; they are nowhere near substantial enough for the complexity and sophistication of threats that float and flutter around modern-day mobile devices.
If you can’t trust the device, then you can’t trust the factors of authentication that arrive on it. Until we recognize this fact and accept the need to rely on layered, trusted, tamper-proofed signals about the wider security of the device, the application, and the environment around it, then we’ll never have true authentication. Instead we’ll be left with something else entirely; the illusion of mobile authentication.
The second factor has stopped being a second factor
Authentication used to mean separation; the second factor lived somewhere else. But the mobile device – and our increasing dependence on it for almost everything – has collapsed those old boundaries.
Today, most authentication journeys begin and end on the same device. It’s surprising that this flaw isn’t discussed more often than it is. As we’ve mused a lot on this blog, there’s a fine balance between UX (and customer convenience) and security, and this is one example where the scales have definitely swung in the direction of the former and need to be rebalanced.
It’s a situation that has led to the current reality of mobile authentication; what we might call “authentication overload”. Perhaps as a result of our subconscious acceptance of this fundamental flaw, we now live with a seemingly never-ending layering of factor upon factor of authentication, which speaks to a long-lasting tension between UX and security where incremental fixes have been prioritized over architectural change.
Take a look at the following (far-from-exhaustive) list of authentication factors and have a think about the ones you have used recently:
- SMS OTPs and push notifications
- Email codes and magic links
- Authenticator apps
- Passkeys
- OS-level biometrics
- Facial recognition and liveness checks
- Callbacks and human verification
- NFC scans
It’s as if trust has been patched over a number of years rather than being redesigned or engineered fully. But the more that we rely on the mobile device for vital everyday transactions and operations related to our finances and our digital identity, the less we can accept papering over the cracks. At some point we have to get to the root of the problem.
Abracadabra
All of this layering gives an illusion of authentication and security. Instead of the three distinct factors of authentication that are often recognized as the desired approach - something you know, something you have, and something you are – you end up with one potentially compromised environment wearing three different costumes.
It doesn’t matter how many factors you have if they all execute in the same compromised environment. When that happens, you’re left with something performative; a bit like a magic trick.
Speaking of tricks, it’s not too difficult for a skilled attacker to tamper with and manipulate applications so that they can disguise and then display the correct – or at least the expected – credential when authentications are requested.
This is why it isn’t enough to simply check one credential or hash and assume that the user or application is legitimate and can be safely authenticated. Authentication must be multi-layered and factor in the hundreds of different threats and attack vectors that can trick the systems we’ve put in place in recent years.
The question that authentication currently asks is “did they authenticate successfully?” But should we not instead be asking whether we can trust the environment from which signals are arriving from? Can we trust the signals that this device is producing right now?
Meeting Henry
One way to understand the problem is to think about how we verify someone’s identity in the physical world.
Imagine that you’ve arranged to meet someone called Henry. You’ve met Henry once before at a party several years ago; you know roughly what he looks like and perhaps even have a photograph of him on your phone.
On the day of the meeting, someone shows up who matches that photo reasonably well. Similar height, build, style. Close enough.
Most of us wouldn’t stop there, though. Even subconsciously and without thinking, we’d probably ask Henry some questions, we’d expect him to recognise us, and we’d seek some kind of continuity in behavior, context, shared history. Perhaps we’d ask for some life updates on a friend we have in common. Under the surface, we’d likely be hyper alert to even the smallest inconsistencies.
And yet, in mobile security, it has somehow become acceptable not to probe for this wider context to make sure we’re talking to who we think we are. A lot of what amounts to integrity checks out there these days is actually little more than asking: does this look like the thing we saw the last time around?
If a single expected value (a hash, say, or maybe a signature or identifier) is a correct match, then the app is automatically treated as genuine. That cannot be right. An attacker doesn’t need to be Henry, after all; they just need to resemble him closely enough to pass a cursory glance.
When trust is reduced to a single static check, it becomes surprisingly easy to fake. A modified app can wear the right clothes, and a hostile environment can be staged to look healthy. An emulator can imitate a real device convincingly enough to pass a shallow inspection. We convince ourselves that we’re verifying identity, when in reality we’re only checking appearances.
Real trust doesn’t come from one confirmation, but rather from layers and layers of context. It comes from coherence across various independent signals and from noticing when something doesn’t quite add up.
The human brain is capable of carrying out these additional checks in a matter of seconds. Clearly it’s more difficult to program software to do the same thing, but such software does exist and you shouldn’t settle for something that only performs a rudimentary check.
Even supposedly strong mobile authentication can be flawed
If we return to our list of authentication factors from earlier in this article, then its instructive to learn that even mobile authentication methods like NFC scans (of a passport for example) - often seen as the pinnacle of what is currently available to us - can be exploited and overridden if the integrity of the mobile device cannot be authenticated. Malware is capable of replaying data without the passport even being required. Indeed, it’s now pretty common for attackers to redirect payment flows to fraudulent endpoints, including other mobile devices. We call attacks like these NFC Relay (or NFC Proxy Malware) Attacks.
In many cases of modern mobile fraud, the user actually did everything right, and indeed the system didn’t fail; it did exactly what it was designed to do. Accepting this lack of control on the mobile device is fundamental to understanding why a rethink is required when it comes to authentication.
Instead of just making sure that the credential arriving from a mobile device looks legitimate, we should be prioritizing integrity control to make sure that the device itself can be trusted, and ensuring that the data (or signals) that we receive have been tamper proofed and can therefore be trusted enough to make crucial decisions that can impact trust, reputations, and the bottom line.
Remember, phishing-resistant is not the same as compromise-resistant. Passkeys and push OTPs can be excellent protection against phishing, but they don’t protect against device compromise. In fact, if the device is already under an attacker’s control, then the strongest factor of authentication can actually be repurposed into being a willing accomplice.
The Mobile Authentication Illusion doesn’t end at the API
Even if we accept the weaknesses of modern authentication at the user and device level, there’s a second illusion that often goes unexamined: how the backend can authenticate the mobile app itself.
Most mobile backends still rely on familiar mechanisms to decide whether a request should be trusted; API keys, shared secrets, signed requests, client certificates, and access tokens. These controls are often described as “app authentication,” as if the backend were verifying the identity of the app in the same way a user authenticates themselves.
In reality, the backend isn’t authenticating an app at all but rather a credential. And this is a problem because in the mobile world credentials are not the same as identity.
Once an API key, signing secret, or token is extracted – be it via reverse engineering, runtime instrumentation, memory dumping, or simply reusing an older version of the app – then any script, bot, emulator, or modified client can present it just as convincingly as the genuine app.
From the backend’s point of view, everything still looks legitimate; the request is well-formed, the signature checks out, and the token is valid. Yet the entity on the other end may bear little resemblance to the app the backend believes it’s serving.
This is a similar illusion to the one we see in user authentication. That is to say false confidence built on shallow signals.
It’s a problem that is compounded by the fact that outdated app versions are often still accepted long after their security controls have been superseded. That means attackers don’t even need to fight the strongest version of an app if the backend is happy to talk to a weaker one.
In both cases, the backend believes it’s interacting with a trusted client when in fact it is responding to an impersonation.
True Mobile API trust, like true authentication, requires more than just possessing a secret. It requires evidence that the request is coming from a genuine, tamper-proofed, up-to-date app, running in a trustworthy environment.
Without that, we’re not really verifying identity identity at all. We’re just checking paperwork.
Authentication when the user isn’t human
Up to this point, we’ve been talking about humans and the applications that they use. But the authentication problem becomes even clearer when the user isn’t human at all. This is likely to be a growing challenge in the coming years and should focus minds to get the basics of authentication right now so that existing flaws aren’t exposed and exacerbated in the near future.
Autonomous AI agents are already logging into services, calling APIs, signing requests, and initiating transactions, after all; often on behalf of people or organizations. Today, they do so using the same mechanisms humans rely on: keys, tokens, certificates, and delegated credentials.
The uncomfortable question is this: how do we know which AI agent is making a request, on whose authority, and might it have been modified or cloned?
We recently asked these questions as part of a wider investigative article about how not to lose your identity in 2035.
Why the future of authentication should be quieter, not louder
The stakes are getting higher when it comes to the responsibility that we’re entrusting to our mobile devices for sensitive transactions and operations. It’s likely that within the next decade, billions of people will be using Digital ID applications to prove who they are, travel across borders, access healthcare, pay taxes, and sign official documents, for example. Being able to safely and effectively authenticate both users and applications in the modern digital world requires sophistication and depth.
Secure mobile authentication shouldn’t be about adding more and more layers, but rather making it easier to trust the layers we’ve already created. That means allowing for risk-based decisions and context-aware enforcement, but this can only be achieved if we can verify the integrity of the mobile channel where so many risks originate from.
Arguably this is the deeper meaning of authentication, because it’s impossible to truly authenticate if we don’t ask detailed questions that enable us to detect if something is out of place, if something has been modified or tampered with, or even if there is evidence of dynamic instrumentation tools having been used, however well attackers have tried to cover their tracks.
Authentication isn’t flawed because we don’t have enough factors; it’s flawed because we’ve stopped asking whether we can trust them in the first place. Smart, future-proofed security is about trusting fewer things much more deeply.
