Most organizations that got breached last year had multi-factor authentication switched on. That is the uncomfortable part. The attackers did not crack the second factor; they walked around it, using techniques that work precisely because the MFA in place asks a tired human to make a security decision at the worst possible moment.
If your MFA is an SMS code or a one-tap “Approve?” push, this is worth ten minutes of your attention. Those two methods are now the ones attackers plan around, not the ones that stop them.
Three attacks that beat “some MFA”
- Push-bombing (MFA fatigue). The attacker already has the password (from a breach dump, a phish, or reuse). They trigger login after login, firing a stream of approval prompts at the user’s phone until, out of confusion or just to make it stop, someone taps Approve. One tap and they are in. This is how several household-name breaches started.
- SIM swapping. SMS was never designed as a security channel. An attacker who convinces (or bribes) a mobile carrier to move a number to a new SIM receives every one-time code sent to it. No malware, no phishing page — just a phone call to a support desk.
- Adversary-in-the-middle (AiTM). A convincing fake login page proxies the real one in real time. The victim enters their password and their code; the attacker relays both instantly and steals the resulting session token. The code was valid. The MFA “worked.” The account is still gone.
The common thread: each of these methods depends on a secret or an approval that can be relayed: copied from the legitimate user and replayed by the attacker. Stop the relay and all three attacks stop with it.
What actually stops them: phishing-resistant, hardware-bound authentication
“Phishing-resistant” is not marketing language. It names a specific property. Two things have to be true at once: the key can never leave the user’s device, so there is nothing to capture and reuse; and the user can read exactly what they are approving, so nothing gets approved blindly.
- The key lives in the phone’s secure hardware. It is generated there and cannot be exported, copied, or SIM-swapped. There is no shared secret sitting in a database or arriving over SMS, which is what closes off interception, SIM swaps and AiTM relay.
- You can read exactly what you are approving. This is the part that stops push-bombing, and it is worth being precise about: no key and no biometric can help once a request reaches the phone, because the attack simply asks the user to say yes. A biometric only confirms the phone’s owner is the one tapping, not that the login is legitimate. What defeats push-bombing is that each request carries a specific, readable description of exactly what is being approved: this login, this server, from here, now. A prompt the user never initiated is visibly not theirs, so they decline it. The safeguard is a description precise enough to read at a glance, not a tired human resisting a blank “Approve?”.
- The session cannot be replayed. Because the signature is cryptographic and bound to the request, an AiTM proxy has nothing worth stealing.
That is the difference between MFA that raises the bar and MFA that an attacker has already scripted past.
Where Notakey fits
Notakey was built around exactly this property. The user’s key is generated inside their phone’s secure hardware and never leaves it, and every approval is a signed, timestamped record of the specific action, not an anonymous tap.
- No shared secret to phish, no SMS to intercept, no code to relay.
- Against push-bombing, the defense is what the user reads: every request shows a precise description of exactly what is being approved (which system, which action, from where), so a prompt nobody initiated is obvious on sight and gets declined. There is nothing to approve blindly.
- It covers the paths attackers actually use; see the practical guides for 2FA on a VPN over RADIUS, Windows remote desktop and Linux SSH.
See it for yourself
The quickest way to feel the difference is to approve a transaction the phishing-resistant way: reading and signing a specific action from your own phone, rather than tapping a context-free prompt.
Try the live demo to sign one in about two minutes, or request a demo and we will map your VPN, SSO or Windows logins to a pilot on your own infrastructure.