Getting around MFA
MFA was on, and the account was still taken
When Cedar Inc. looked back at how Riley's account in the finance team was taken over, the first question was predictable: wasn't MFA turned on? It was. Riley signed in with a password and a code from an authenticator app, and Cedar checked both. A relay passed them to Cedar while they were still valid and kept the session that followed, as Phishing and relayed sign-ins describes. The MFA did exactly what it was designed to do. The attacker went around it.
That is the usual story. Attackers rarely break the cryptography behind a code or a passkey. They persuade the person to complete the second step for them, take over the channel a code arrives through, pick a weaker method the account still allows, or use a path that never asks for a second factor at all. In every case, a settings page can truthfully say "MFA: enabled" while the account is reachable with less.
Wearing down approvals
Suppose an attacker has an employee's password at a company that uses approval prompts, perhaps from a breach at another service, as Guessing, spraying, and stuffing describes. In this setup, the account asks for the password first and then sends an approval prompt to the employee's phone. The attacker starts a sign-in, then another, and another. At 2 a.m. the phone lights up again and again. Some people deny every prompt. Others, half asleep or worn down, approve one just to make them stop. This is approval fatigue, sometimes called prompt bombing.
A message alongside the prompts makes it worse. A call or text that claims to come from the company's IT team explains that a fault is causing the prompts and that approving the next one will fix it. Now the person has a plausible reason to approve, and a request from what sounds like authority.
Number matching removes the blind tap. The app asks for a number shown on the sign-in screen, and someone who did not start a sign-in has no number to enter. It does not remove the phone call. An attacker who is talking to the person can read out the number from the screen in front of them. And as with relays, nothing in the number tells the app whose screen it came from.
Other controls close more of the gap. A service can stop sending prompts after a few go unanswered or are denied, and require a different method for a while. The prompt can show which application is asking and roughly where the sign-in comes from, so a 2 a.m. request from an unfamiliar place looks wrong. Most usefully, the prompt can offer a way to report it: "I didn't try to sign in". That report denies the request, alerts the security team and marks the password as known, since in this setup a prompt is sent only after the correct password. In the records, approval fatigue looks like a run of denied or expired prompts for one account, followed by an approval for a sign-in from a network the person has never used.
Taking over a phone number
A text-message code goes to a phone number, not to a particular phone. As Codes, links, and approval prompts explains, whoever receives messages for that number at that moment receives the code. Phone numbers can move. A mobile carrier can transfer a number to a new SIM card when a customer reports a lost phone, or to another carrier when a customer switches. An attacker who persuades the carrier's support staff, using personal details gathered elsewhere, can have the number moved to a SIM card they control. This is called a SIM swap, or number transfer fraud.
The effect reaches further than sign-in codes. Many accounts use the same number for recovery, so the attacker can request a password reset, receive the reset code, set a new password and then receive the sign-in code as well. Two apparently separate checks have collapsed into control of one phone number. Often the real owner notices only because their phone suddenly shows no service.
Services can limit the damage. A phone number should not be the only way to recover a valuable account, and administrator accounts should not accept it at all. When the number on an account changes, or a reset is completed by text message, the service can notify the person's other channels, such as their email and enrolled devices, and hold sensitive changes for a waiting period. People can protect their own numbers too, since many carriers let a customer set a separate PIN or lock that must be given before a number moves. Attacks on recovery and the help desk returns to the reset side of this problem.
Choosing the weakest method on offer
Sign-in pages often offer a link labeled "Try another way" or "Use a different method". It exists for good reasons: a person whose phone battery is flat still needs to work. But the link offers whatever the account allows, and the attacker gets to choose from the list too.
Suppose a company requires a passkey for its finance staff, and an employee enrolls one. The employee's account still has a phone number for text-message codes from before the change, and the sign-in page offers it as an alternative. A relay cannot use the passkey, because the browser will not offer it at a look-alike site, as Phishing and relayed sign-ins explains. So the relay picks "Try another way" on its side, asks the employee for the password and then the text-message code, and forwards both. This is a downgrade: steering a sign-in to a weaker method that the account still accepts. The passkey requirement was real, but it was not what the attacker had to satisfy.
The fix is for the policy, not the sign-in page, to decide which methods count. If an account requires a passkey, any fallback offered at sign-in has to be just as phishing-resistant, such as a second passkey or a security key. A person who has lost every strong method goes through recovery, which can be slower and more careful, as Enrollment, replacement, and recovery describes, rather than through a weaker method at the sign-in page. The records help here as well. Someone who always uses a passkey and suddenly signs in with a text-message code, from a new network, is worth a closer look.
Paths that never ask
Some ways into an account skip the second factor entirely, usually for reasons that once made sense.
Older protocols are the classic case. Some mail and file protocols send a username and password straight to the service with each connection, so there is no sign-in page on which an identity provider could ask for anything more. If the service still accepts them, an account with MFA turned on can be reached with the password alone, which is why password spraying often aims at exactly these endpoints. App passwords, long generated secrets for older applications that cannot handle MFA, work the same way: each one is a single secret that opens the account without a second step.
Then there are gaps in the policy itself. Accounts left out of MFA during a pilot, a migration or after an executive complained. Service accounts excluded because they cannot answer prompts. A rule that skips MFA on the office network, combined with a VPN that puts remote connections on that network after a password. Each exception had a reason when it was made. Many outlive that reason, because nobody owns the exception and nothing makes it expire.
Finally, a session or token that already exists never asks again until it ends. That is by design, and it is why a stolen session is worth so much, as How sessions and tokens are stolen explains.
Checking every path to the account
The useful question is not "is MFA enabled?" but "what is the least evidence that gets someone into this account?" Answering it means listing every path: each sign-in method and fallback, each protocol the service still accepts, app passwords, recovery by email or phone, help-desk resets, and sessions and tokens that already exist. For each one, write down what it actually requires. The account's real strength is the weakest entry on that list, the point made in Why attackers go after identity.
Policies describe intent, and sign-in records describe what actually happened. Checking which method each successful sign-in used over a few weeks shows which paths are really in use: password-only sign-ins through an older protocol, text-message codes on accounts that were supposed to have moved to passkeys, members of an excluded group whose project ended long ago. Every exception needs an owner, a reason and an end date, and a regular review should remove the ones whose reason has passed.
Try finding the gap in a few fictional policies.
Find the path that skips MFA
Simulation. These policy summaries come from made-up organizations, for practice only. Checking an answer happens only in your browser and sends nothing.