A version of this article was originally published on Forbes.com
Multi-factor authentication (MFA) is widely accepted as a more secure alternative to password-only security.
Unfortunately, attackers have adjusted to that acceptance, relegating MFA to more of a speed bump instead of an outright deterrent. This renders MFA more akin to single-factor authentication because it is still relying on a single point of failure.
The user.
In this article, we’ll discuss the vulnerabilities of MFA and how you can shield your environment against them.
What is MFA?
MFA is a security method that requires users to verify identity using two or more independent methods before gaining access. MFA adds an additional layer to passwords, which can be more easily stolen or guessed.
The authentication factors fall into three categories:
- Something you know like a password or PIN
- Something you have like your mobile device or an authentication app
- Something you are such as facial recognition or fingerprint
By combining multiple factors, you can—ideally—reduce the likelihood of credential-based attacks.
What is two factor vs two step?
Both two-factor authentication and two-step verification are types of MFA.
Two-factor authentication (2FA) is a common subset of MFA that specifically requires two different types of authentication factors coming from different categories. So, a password followed by an authentication app verification.
Two-step verification (2SV) is more commonly used in general consumer services (like email) because it only requires two verification steps, usually from the same category. Entering your password followed by answering a security question or inputting an SMS code is an example of 2SV.
Requiring two distinct types of verification makes 2FA more secure on paper, but all types of MFA have weaknesses for attackers to exploit.
Why MFA isn’t as secure as you think
Cybercriminals have learned how to bypass MFA.
They no longer need to spend time cracking passwords when they can convince a user to input everything themselves on what they believe is a legitimate login page. All that’s needed is one user to accidentally click a link that lands them on a fake login page from a company-affiliated cloud or SaaS resource that looks exactly like the real thing.
If users are willing to enter their passwords on an imitation webpage, it’s safe to assume they will also enter their one-time code (OTC) when asked.
The attacker now has everything they need.
Why session tokens are the real danger
This is where most organizations underestimate risk. Attackers can forward valid credentials and the OTC in real time to the legitimate service, sitting in the middle of the session. Once authentication succeeds, the attacker gets access to that user, and more importantly, the session token.
This means one successful phishing attempt can keep an attacker inside your environment long enough to quietly explore it, access resources and sensitive data, and take actions that are difficult to detect until it’s too late.
How long a token lasts is dependent upon configuration.
When configured to time out upon inactivity, the attacker only has access for the duration of that session, potentially a short period of time. Unfortunately, plenty of damage can be done in just a few minutes.
If tokens are configured to last for days or weeks, attackers are then likely to use the resulting window to dig through email, access cloud storage, review internal documents, and identify valuable data.
From there, they can download sensitive information, tamper with key files, set up persistence through mailbox rules or new access methods, and even move laterally to connected systems.
No matter how the session token is configured, any amount of time an attacker is in your environment is too much.
Even a brief intrusion is often more than enough time to cause serious disruption, financial loss, or long-term reputational damage.
How to neutralize phishing and token theft with Zero Trust access control
The problem is that most MFA still relies on a single decision point: Will the user type in what the page asks for?
That’s not a strong enough security boundary anymore.
To truly reduce risk, organizations have to start thinking of adding a layer that can’t be phished so readily.
Instead of trusting valid credentials and code, add a requirement that any attempt to sign-in to a resource should come from a device and path explicitly approved by your organization.
That’s going to mean verifying the user’s identity and the trustworthiness of the actual device, whether that’s a laptop, a cell phone, or other device.
When access is tied to trusted devices and controlled routes into SaaS platforms, stolen credentials and intercepted codes become far less useful to attackers. This is the same philosophy behind Zero Trust deny-by-default controls: Block everything, allow only what’s necessary and trusted.
How ThreatLocker secures access beyond MFA
Another core tenet of Zero Trust is the assumption that every user, device, and application can be compromised.
You cannot trust credentials alone to grant access to your systems.
Zero Trust Network Access from ThreatLocker ensures only verified users on verified devices can initiate connections by shifting control to the device level. This means that even if an employee clicks on a phishing link and enters their password and OTC onto a fake login page, the attacker will not be able to use those credentials to gain access because they are not on an approved device.
Zero Trust Cloud Access enforces the same principles when it comes to accessing your cloud and SaaS platforms. Instead of trusting credentials alone, access is routed through a secure, ThreatLocker-managed broker that verifies the device being used, the pathway, the policy, and the specific request.
A secure environment requires Zero Trust
Multi-factor authentication remains an important step in protecting user identities and reducing the risk of unauthorized access, but it is far from foolproof.
Phishing kits, adversary-in-the-middle attacks, and malware can capture credentials, one-time-codes, and session tokens, and with the help of AI, more people have access to these attack techniques.
The path forward is Zero Trust.
No user, device, or application should be implicitly trusted, even after authentication. Continuous verification and enforcement of strict controls that dictate what can run, what can connect, and what actions are allowed offer the best defense against threats.
Even if attackers manage to authenticate, a Zero Trust architecture closes the gaps MFA leaves behind and ensures attackers can’t execute, move laterally, or do damage.
See how it works in practice—book a demo to explore how ThreatLocker can secure your environment beyond authentication.
