Multi-factor authentication is the security measure with the best ratio of effort required to risk removed. It stops the great majority of unauthorised sign-ins, and this post does not call that into question.
Presenting it as an unbreakable barrier would be incorrect, though — and counterproductive. Anyone who believes they are covered against everything lowers their attention exactly where it is needed: almost every technique that bypasses MFA goes through the person, not the technology.
Knowing which ones they are is what allows you to recognise them. This post describes them from the point of view of somebody on the receiving end, in order to defend; it contains no operational detail. It is the threat-side completion of the recommendation protecting accounts with a second factor.
The starting point
With MFA enabled, the password alone is no longer enough. Anyone wanting to get in therefore has to obtain the second step too, and has three routes:
- be handed the code — by convincing you to type it or read it out;
- be given the approval — exploiting distraction or tiredness;
- avoid the second factor altogether — going through a route that does not require it.
The first two depend on an interaction with you. The third is the most insidious, because it does not even try to face the protection: it goes around it.
1. Prompted approval
In plain terms. Somebody already has your password and sends confirmation requests until you approve one.
How it works. The notifications arrive repeatedly, often at night or during activities where the phone is disruptive. One confirmation given out of distraction is enough, or one given to make the notifications stop.
Why it works. It does not attack the technology: it attacks tiredness and the habit of approving with a single gesture.
Signs of suspicion. Verification requests you did not start, especially if repeated or at unusual hours.
How to protect yourself. Never approve a request you did not start, for any reason. If the notifications will not stop, the answer is to change the password, not to confirm. Where available, use the variant that requires typing a number shown on screen.
2. A fake page that asks for the code too
In plain terms. A copy of the real site asks you first for the password and then for the second-factor code, and uses both immediately.
How it works. Whoever built the page receives what you type and enters it on the real service while the code is still valid. From your point of view, the page “does not work” or shows an error.
Why it concerns codes. It is the reason why methods based on a typeable code — text messages, authenticator apps, simple notifications — do not protect against this scenario: the code is transferable information.
Signs of suspicion. You reached the page from a link you received; the address is similar but not identical to the usual one; your password vault does not fill it in automatically; the page asks for the code at a moment when you were not signing in.
How to protect yourself. Never sign in from links you receive: open the app or type the usual address. Use a password vault, which compares the address. And where possible, use hardware keys or passkeys: they check the site and simply do not respond to a copy.
3. An already open session reused
In plain terms. The second factor is not beaten: a sign-in that had already been completed is exploited.
How it works. After a successful sign-in, the service remembers the device so as not to ask for verification every time. Anyone obtaining that “memory” — from a compromised device or a fraudulent page — can present themselves as an already authenticated session.
Why it matters. It explains something that often causes confusion: you can find a successful sign-in despite MFA being enabled and correctly configured.
Signs of suspicion. Sign-ins that no longer ask for verification; trusted devices you do not recognise; activity from an unusual context with no confirmation request at all.
How to protect yourself. Check the trusted devices periodically and remove those you do not recognise. After a suspicion, revoke every active session — it is the only action that closes this scenario, and it goes after the password change.
4. Fraudulent transfer of the phone number
In plain terms. Your number is transferred to a SIM controlled by somebody else, and the text codes arrive there.
How it works. It goes through a request to the mobile operator, supported by personal information gathered elsewhere. It does not touch your devices.
Why it only concerns text messages. It is that method’s specific limit: it depends on the number, not on a device you own.
Signs of suspicion. The phone suddenly loses service for no reason; you stop receiving calls and messages; notices arrive from the operator about changes you did not request.
How to protect yourself. Move to an authenticator app or a key where possible. Check whether your operator offers a lock or a PIN against number transfers. And remove text messages as a method from critical accounts, once a better method is in place.
5. Account recovery used as a shortcut
In plain terms. MFA is not confronted: the recovery procedure is used, which sometimes asks for less.
How it works. Recovery procedures exist for people who have lost access, and by necessity they are more permissive. If the data they ask for — secondary email, phone number, security questions — is reachable or derivable, the main protection is bypassed from the side.
Why it is the most insidious route. It leaves none of the usual signals: there are no verification requests, because the second factor is never consulted.
Signs of suspicion. Recovery-started emails you did not request; recovery codes reported as used; changes to your recovery details.
How to protect yourself. This is where you see why the main email has to be protected first: it is the channel through which recovery for almost everything else passes. Check your recovery details periodically, and replace security questions with answers that are not real information about you.
6. A direct request for the code
In plain terms. Somebody calls or writes to you posing as support and asks you to read out the code that has just arrived.
How it works. The call comes a few seconds after a sign-in attempt, so the code has just appeared on your phone. The tone is helpful: “we are checking a suspicious sign-in, can you confirm the code so we can block it?”
Why it works. Because it looks like the reaction to a real problem — and in a sense it is: the sign-in attempt genuinely happened, made moments earlier by whoever is calling.
Signs of suspicion. Any request to read out a code or approve a verification. Urgency. A request not to hang up, or not to check elsewhere.
How to protect yourself. One rule with no exceptions: no legitimate service asks for a verification code, for any reason. End the conversation and check through the official channel.
7. A compromised device
In plain terms. If the device is controlled by somebody else, the second factor is already there.
How it works. Unwanted software can read codes and notifications directly on the device that is supposed to be protecting you.
Why it matters. It is the structural limit: MFA assumes the device is trustworthy.
Signs of suspicion. Unusual slowdowns, abnormal consumption, apps or extensions you do not remember installing.
How to protect yourself. An up-to-date operating system, software only from official sources, an active screen lock. For the most critical accounts, a hardware key separates the second factor from the device.
Summary table
| Technique | What it depends on | Signs of suspicion | Most effective defence |
|---|---|---|---|
| Prompted approval | On you | Repeated requests you did not start | Never approve; push with a number to type |
| Fake page asking for the code | On you | A link you received, the vault does not fill in | Hardware keys or passkeys |
| Already open session reused | On the device | Sign-ins with no verification request | Revoke sessions and trusted devices |
| Number transfer | On the operator | Sudden loss of service | Authenticator app instead of text messages |
| Recovery as a shortcut | On your recovery details | Unrequested recovery emails | Protect the email; verified recovery details |
| Direct request for the code | On you | Somebody asks for a code | No service asks for it: never share it |
| Compromised device | On the device | Unusual behaviour | Updates, official sources, hardware key |
What the table shows
Two observations that are worth more than the individual entries.
Four techniques out of seven go through you. Not through the encryption, not through a weakness of the method: through a confirmation, a code read out loud, a link followed. That is good news, because it means the defence is within anyone’s reach and requires no complex technical choices.
None of these techniques is as common as signing in with the password alone. MFA remains the measure that removes the largest share of risk: the scenarios described here are what is left after enabling it, not a reason not to enable it.
The three rules that cover almost the whole table:
- Never approve a request you did not start, and never share a code with anyone.
- Always sign in from the app or the usual address, never from links you receive.
- Protect your main email first, because it is the recovery route to everything else.
Protection checklist
- ☐ I never approve verification requests I did not start
- ☐ I know that no legitimate service asks for a verification code
- ☐ I sign in to services from the app or the usual address
- ☐ I use an authenticator app or a key instead of text messages, where possible
- ☐ I have checked my trusted devices in the last few months
- ☐ My accounts’ recovery details are up to date and verified
- ☐ My main email has the strongest protection of all my accounts
- ☐ The device where I receive codes is up to date and has a screen lock
How this connects to the Cyber Welfare Framework
| Pillar | What this content contributes |
|---|---|
| Awareness | Knowing the real limits of a protection, without overrating it or giving it up |
| Skills | Recognising which defence answers which technique |
| Secure Behaviour | Never handing over a code and never approving out of habit |
Reference level: FL3 — Autonomous, with elements of FL4 — Skilled in the parts on sessions and recovery.
Conclusion
Multi-factor authentication is not unbeatable, and saying so openly is useful: anyone who treats it as final is more exposed exactly where the protection depends on something they do.
But the overall picture stays clear. The techniques described here nearly always require unintentional cooperation on your part — an approval, a code read out, a link followed. They are far less frequent, and far more avoidable, than a sign-in with a password circulating in a list.
Something to think about. If you received a call right now from somebody presenting themselves as support and asking you to confirm a code that just arrived, what would you do?
Related content
- Protecting accounts with a second factor — the recommendation this belongs to
- Unexpected verification requests — the indicators these techniques leave
- Which second factor to choose — which methods resist phishing
- How to turn on a second factor — the configuration that reduces these scenarios
Start with the first step: the Cyber Welfare Programme guides you free of charge, one recommendation at a time.
