Why Multi-Factor Authentication Is Not Enough on Its Own

Multi-factor authentication remains one of the most effective ways to reduce account compromise, but attackers have adapted to it. Session-cookie theft, adversary-in-the-middle phishing, MFA fatigue, help-desk manipulation, stolen OAuth tokens, compromised devices, and weak recovery processes can all give attackers a path around the login challenge. The practical lesson is to keep MFA as a core control while strengthening the identity system around it.

TL;DR

Multi-factor authentication dramatically improves account security because a stolen password alone is often no longer enough to sign in. The limitation is that modern identity attacks increasingly target the authentication process around MFA rather than trying to defeat the cryptography itself.

An attacker can trick a user into completing a legitimate MFA challenge through a phishing proxy, steal the authenticated session that follows, convince a help desk to reset the factor, abuse an already authorized OAuth application, or compromise the endpoint where the trusted session is running.

A stronger identity model combines phishing-resistant authentication with conditional access, device trust, tightly controlled account recovery, session monitoring, least privilege, privileged-access controls, and continuous detection of unusual identity behavior. The aim is to make every stage of account access harder to abuse, from the first login through the authenticated session and the eventual recovery or privilege-escalation process.

Key Takeaways

• MFA remains essential, particularly because it blocks many attacks that rely only on stolen or reused passwords.
• Several common MFA methods can still be phished. SMS codes, one-time passwords, and push approvals can be intercepted or socially engineered in ways that phishing-resistant methods such as FIDO2 security keys and passkeys are designed to resist.
• Session theft changes the problem. Once a user has completed MFA successfully, an attacker who steals the resulting authenticated session may be able to access the account without repeating the MFA challenge.
• MFA fatigue still matters when users receive repeated approval prompts and are persuaded or worn down into accepting one.
• Help-desk and account-recovery processes can become alternative authentication paths if attackers can persuade staff to reset MFA or enroll a new device.
• OAuth tokens and third-party applications deserve the same attention as passwords because a compromised authorized application can provide ongoing access to cloud data.
• Device security matters because malware on an authenticated endpoint can steal cookies, tokens, browser data, and credentials after MFA has already succeeded.
• Privileged accounts should receive stronger authentication, tighter session controls, and shorter-lived access than ordinary user accounts.
• Identity monitoring should look for suspicious behavior after authentication, including unusual locations, privilege changes, token activity, new MFA registrations, and abnormal access patterns.
• The objective is to build layered identity security around MFA, so compromising one authentication factor or session does not automatically expose the entire account.

Attackers Have Learned to Work Around the MFA Prompt

Multi-factor authentication has changed the economics of credential theft. A username and password stolen from a phishing page or malware infection no longer guarantee access when another factor is required, which is precisely why MFA remains such an important baseline control. Attackers have responded by changing what they target.

Microsoft’s identity-security researchers say the growth of MFA has been accompanied by a rise in adversary-in-the-middle, or AiTM, credential phishing, where the attacker inserts infrastructure between the victim and the legitimate authentication service so the victim completes the real sign-in while the attacker captures the resulting credentials and session.

That distinction matters because the attacker does not necessarily need to crack, guess, or technically break the second factor. In an AiTM flow, the victim can enter the correct password, complete the legitimate MFA challenge, and reach the real application while the attacker’s proxy captures the authenticated session created during that process.

Microsoft has documented campaigns in which attackers intercepted MFA and captured session cookies before using those sessions for follow-on business email compromise. Once the session is stolen, the attacker may be able to replay it without asking the victim to authenticate again.

The technique is becoming easier to operationalise. Okta reported in 2026 that session-token replay had become one of the most commonly observed identity attack patterns in its threat intelligence, while phishing-as-a-service platforms such as Tycoon 2FA were being used to capture credentials, MFA responses, and authenticated sessions at scale.

Its analysis describes Tycoon 2FA and related services as part of a broader shift toward session-focused phishing, which is significant because these platforms lower the technical barrier for attackers who previously would have needed to build their own proxy infrastructure.

There are also attacks where the authentication system is defeated through people rather than browser infrastructure. Google’s threat intelligence team described the 2026 BlackFile extortion operation using voice phishing and adversary-in-the-middle techniques to compromise single sign-on and bypass conventional MFA controls.

In attacks of this kind, help desks, employees, MFA enrolment processes, and identity-recovery workflows can become part of the attack surface because a convincing attacker may be able to persuade someone to approve, reset, or re-register access rather than technically defeating the authentication method.

The right conclusion is therefore to keep MFA and strengthen what surrounds it. Authentication has become a chain that includes the factor itself, the browser session created afterwards, the device receiving access, the recovery process, third-party applications, privileged roles, and the monitoring that watches what the identity does after login. MFA makes one part of that chain substantially harder to attack. Modern identity security has to protect the rest of it as well.

The Type of MFA Matters More Than Most Companies Realise

MFA is often discussed as though every second factor provides roughly the same level of protection. In practice, the authentication method makes a substantial difference.

SMS codes, authenticator-generated one-time passwords, push notifications, number matching, security keys, and passkeys all add friction for an attacker, but they resist phishing in very different ways. Once attackers begin targeting the authentication flow itself, that difference becomes important.

One-time codes are vulnerable because the user can still be persuaded to hand them to the attacker. An adversary-in-the-middle phishing site can collect the username and password, relay them to the legitimate service, ask the victim for the newly generated code, and immediately relay that as well.

The code is real and the authentication service is real. The attacker succeeds because the user has been tricked into completing the authentication ceremony through infrastructure controlled by the attacker.

Push notifications improve convenience but create another behavioural weakness. If users are conditioned to tap “Approve” whenever their phone asks them to authenticate, repeated prompts can eventually become difficult to distinguish from legitimate activity.

Number matching reduces that risk by requiring the user to enter or select information displayed during the actual sign-in attempt, but it still depends on the user correctly understanding whether they initiated the login.

Phishing-resistant authentication changes the structure of the exchange. CISA’s guidance on phishing-resistant MFA identifies FIDO/WebAuthn-based authentication as the strongest widely available form of MFA, because the authenticator is cryptographically bound to the legitimate website rather than asking the user to transfer a reusable code between systems.

A security key or properly implemented passkey therefore cannot simply provide a valid response to an attacker’s lookalike domain in the way a one-time password can.

Authentication method	Resistance to common phishing	Main weakness
SMS code	Low	Code can be phished, intercepted, or affected by SIM attacks
Authenticator OTP	Moderate	User can still enter the code into a phishing proxy
Push approval	Moderate	Susceptible to social engineering and approval fatigue
Number-matching push	Better	Still depends on user recognising the legitimate sign-in
FIDO2 security key	Very high	Requires supported devices and enrolment processes
Passkey / WebAuthn	Very high	Deployment and account-recovery design still matter

This does not mean every organisation needs to replace every MFA method immediately. Risk should determine the migration order. Administrators, executives, finance staff, remote-access users, developers with production access, and people who can alter identity systems are sensible places to introduce phishing-resistant authentication first. Lower-risk populations can follow as application support and device compatibility improve.

The important change is to stop treating “MFA enabled” as a binary security outcome. A company with SMS codes everywhere and a company using phishing-resistant credentials for privileged identities may both report 100% MFA adoption, while their resistance to modern phishing is materially different.

The useful question is therefore which authentication methods protect which users, and whether the strongest methods are being applied where a compromised identity would cause the most damage.

Session Theft Can Make a Successful MFA Challenge Irrelevant

The biggest conceptual weakness in treating MFA as the finish line is that authentication is only the beginning of a session. Once the user has proved who they are, the application typically issues a session cookie or token so that the browser does not need to repeat the full authentication process on every click.

That is necessary for usability, but it also creates something valuable to steal. If malware, a phishing proxy, or another compromise captures that authenticated session, the attacker may inherit the access that MFA was meant to protect without needing to complete the second factor again.

This is why identity security increasingly has to continue after login. Microsoft documents how token theft can allow an attacker to replay an authenticated user’s session, and has introduced token-protection controls that bind supported sign-in tokens to the device on which they were issued.

The underlying security idea is important even where a particular product is not being used: the organisation needs ways to make a stolen token less portable, shorten how long it remains useful, and recognise when an authenticated session starts behaving differently from the legitimate user.

Device compromise makes the problem more difficult because the attack can happen on the same endpoint that legitimately completed MFA. Information-stealing malware can collect browser cookies, credentials, stored tokens, and other authentication material from an already trusted device.

Google has described infostealers as an increasingly important credential source in the broader threat ecosystem, with stolen browser data feeding account takeover and follow-on attacks. In that situation, stronger MFA at the front door still helps, but endpoint security and session controls determine whether the attacker can reuse what was stolen afterwards.

A stronger post-authentication model therefore looks beyond the initial login:

Control	What it helps protect against
Shorter session lifetime	Reduces how long a stolen session remains useful
Device-bound tokens	Makes replay from another device more difficult
Continuous risk evaluation	Reassesses access when user or device behaviour changes
Conditional access	Restricts access based on device state, location, risk, or application
Endpoint detection and response	Detects malware that may steal browser or authentication data
Session revocation	Terminates active access after suspected compromise
Reauthentication for sensitive actions	Requires stronger proof before privileged or high-risk activity

Sensitive actions deserve particular attention because there is a large difference between reading ordinary email and changing MFA methods, creating OAuth credentials, downloading large amounts of data, modifying forwarding rules, or assigning administrative privilege. Requiring fresh authentication or stronger controls for those actions can reduce the damage available to someone who has obtained a session but does not fully control the identity.

The practical lesson is that MFA protects the moment of authentication, while session security protects everything that happens afterwards. Organisations that monitor only whether MFA was successfully completed can miss the more important question: whether the authenticated session is still being used by the person and device that originally earned it.

Once session behaviour becomes part of the identity-security model, stolen cookies and tokens become considerably harder to turn into persistent access.

Account Recovery Can Become the Weakest Authentication Path

Even a strong MFA deployment can be undermined if the process for resetting it is easier to manipulate than the authentication method itself. Organisations need recovery mechanisms because employees lose phones, replace devices, forget passwords, and occasionally get locked out.

Attackers know this, which is why help desks and enrolment workflows have increasingly become part of the identity attack surface. Instead of defeating a security key or authenticator, the attacker may try to persuade support staff to register a new factor or reset the existing one.

The MGM Resorts breach in 2023 is a useful example of how damaging that route can become. According to reporting from Bloomberg, members of the Scattered Spider group used social engineering against MGM’s IT help desk after gathering information about an employee, and the incident ultimately disrupted hotel systems, digital room keys, slot machines, and other operations.

The lesson from attacks like this is broader than one company. A carefully configured MFA policy provides limited protection if a caller can convince support staff to alter the identity behind it.

Recovery therefore needs its own authentication standard. A request to reset MFA for a privileged administrator should require considerably stronger verification than a routine password-reset request from an ordinary employee.

Information such as employee ID, manager name, date of birth, or other details that can be found through LinkedIn, breached datasets, or social media should carry relatively little weight because attackers can collect that material before contacting the help desk.

A stronger recovery design can look like this:

Recovery control	What it reduces
Strong identity verification before MFA reset	Social engineering of help-desk staff
Manager or secondary approval for privileged accounts	Single-person reset failures
Separate controls for administrators and executives	High-impact account takeover
Notification when a new factor is enrolled	Silent attacker persistence
Short delay before sensitive actions after recovery	Immediate abuse of newly recovered accounts
Logging of reset and enrolment activity	Makes suspicious recovery events easier to investigate
Rapid revocation of old sessions after reset	Prevents existing stolen sessions remaining active

New MFA enrolment also deserves monitoring because it can tell the security team that the attacker is trying to turn temporary access into something more durable. Microsoft Entra, for example, exposes authentication-method registration and audit activity that organisations can monitor, allowing teams to investigate unexpected changes to a user’s authentication methods.

A privileged user suddenly registering a new authenticator immediately after an unusual login should carry considerably more weight than either event viewed separately.

The broader principle is that recovery should never provide an easier route into the account than normal authentication. If the organisation invests in phishing-resistant MFA while allowing high-value identities to be reset through weak knowledge-based checks or an informal phone conversation, attackers will naturally move toward the easier route. Strong MFA therefore needs equally strong enrolment, reset, and recovery controls around it.

OAuth and Third-Party Apps Can Create Access That MFA Never Sees

Modern business accounts are connected to far more than the login page. Employees routinely authorise SaaS tools, browser extensions, automation platforms, calendar apps, file-sharing services, CRM integrations, and collaboration tools to access cloud data on their behalf.

Once an application receives an OAuth token or delegated permission, it may continue accessing information without asking the user to complete MFA every time. That makes consent and application permissions part of the identity perimeter.

The risk becomes serious when users approve an application that asks for more access than it needs. Microsoft has documented consent-phishing attacks in which malicious applications request permissions to mail, files, contacts, or other cloud resources.

The victim may complete a legitimate sign-in and MFA challenge, then approve the application’s access request. From the identity provider’s perspective, the user authenticated correctly. The abuse happens after authentication, through the permissions the user grants.

OAuth abuse can also create persistence because tokens may remain valid after the original browser session ends. An attacker who obtains a refresh token or controls a malicious authorised application may be able to request new access tokens over time, depending on the platform and permissions involved.

This is why identity investigations increasingly need to look beyond passwords and MFA events and examine application consent, token issuance, unusual API use, and newly authorised integrations.

A practical control model should cover the application layer as well:

Control	What it reduces
Restrict user consent for high-risk permissions	Prevents employees approving powerful apps casually
Admin approval for sensitive integrations	Adds review before broad data access is granted
Review existing OAuth applications	Finds unused or overly privileged integrations
Monitor new consent events	Detects suspicious applications early
Revoke refresh tokens after compromise	Removes persistent application access
Limit third-party application permissions	Reduces blast radius if an app is compromised
Separate privileged identities from routine SaaS use	Protects high-value accounts from unnecessary integrations

The difficulty is that legitimate applications can create the same kind of access path as malicious ones. A productivity tool may genuinely need mailbox or file permissions, but those permissions can still expose substantial amounts of business data if the application itself is compromised or the integration is no longer required.

Old integrations therefore deserve the same lifecycle management as old user accounts. If nobody remembers why an application has access to email, storage, or directory data, that access should be reviewed rather than allowed to persist indefinitely.

This is another reason MFA cannot be treated as the complete identity-control layer. MFA answers whether the user successfully authenticated at a particular moment. OAuth governs what applications can continue doing on that user’s behalf afterwards. Strong identity security needs to manage both, because an attacker who can obtain authorised application access may never need to challenge the MFA prompt again.

Device Trust Matters Because MFA Cannot Protect a Compromised Endpoint

A user can complete MFA correctly and still lose control of the account if the device itself is compromised. Malware running on an authenticated laptop can steal browser cookies, scrape credentials, intercept tokens, capture screenshots, monitor clipboard activity, or operate through the user’s existing session. In that situation, the attacker does not need to defeat MFA at all. They are operating from the same endpoint that the organisation already trusts.

This is why endpoint security and identity security have started converging. Microsoft’s Conditional Access model allows organisations to factor device state and compliance into access decisions, so authentication is evaluated alongside the health and trustworthiness of the device requesting access. A managed, encrypted, compliant corporate laptop can therefore be treated differently from an unknown personal device using the same valid credentials.

The practical controls sit across both identity and endpoint layers:

Control	What it helps address
Endpoint detection and response	Malware, infostealers, persistence, suspicious processes
Device compliance checks	Unmanaged or unhealthy devices
Managed browser policies	Risky extensions, downloads, and session handling
Disk encryption	Data exposure if the device is lost or stolen
Rapid patching	Exploitable endpoint vulnerabilities
Conditional access	Restricts sign-ins from devices that fail policy
Session revocation	Removes access after compromise is detected

This becomes especially important for privileged users. Administrators who can modify identity systems, cloud infrastructure, security tooling, or financial applications should not routinely perform sensitive work from unmanaged endpoints.

Dedicated administrative workstations or tightly controlled privileged sessions can materially reduce the chance that ordinary browsing, email, or consumer software introduces malware into an account with broad authority.

The device also provides context that MFA alone cannot. A successful login from a trusted corporate laptop that has been used by the employee for months carries a different risk profile from the same login appearing from a newly registered browser on an unmanaged endpoint.

When identity systems can combine authentication signals with endpoint telemetry, unusual behaviour becomes easier to detect before the attacker turns one valid session into broader access.

The important point is that MFA proves something about the authentication event. It does not prove that the endpoint is clean, that the browser session remains under the user’s control, or that malware is not operating after login. Stronger account protection therefore treats the device as part of the authentication decision rather than as a neutral container around it.

Privileged Accounts Need Stronger Controls Than Ordinary User Accounts

MFA becomes much more important when the account can change the environment rather than simply use it. A compromised administrator, cloud owner, domain administrator, security engineer, or finance approver can give an attacker access to identities, production systems, security tooling, data, and recovery mechanisms in a way that an ordinary user account usually cannot.

That difference in consequence means privileged identities should sit behind a stronger access model rather than receiving the same authentication treatment as everyone else.

Microsoft’s guidance around Privileged Identity Management reflects this by encouraging eligible, time-bound administrative access instead of permanent role assignment. An administrator may remain a normal user for most of the day and activate elevated privileges only when a specific task requires them. That reduces the amount of standing access available if the account or session is compromised.

Privileged accounts also deserve tighter authentication requirements:

Control	Why it matters for privileged users
Phishing-resistant MFA	Makes credential phishing much harder to convert into admin access
Just-in-time privilege	Reduces permanent high-level permissions
Separate admin identities	Prevents everyday email and browsing activity from sharing the same privileged account
Device restrictions	Keeps privileged work on managed and trusted endpoints
Shorter privileged sessions	Reduces the usefulness of stolen tokens
Reauthentication for sensitive actions	Adds friction before major changes
Detailed audit logging	Makes privileged activity easier to investigate
Break-glass accounts with tight controls	Preserves emergency access without creating routine exposure

Separation is particularly valuable. An administrator who uses the same identity for email, browsing, collaboration tools, and domain administration exposes a high-value account to far more everyday attack surfaces.

A separate privileged identity can be restricted from ordinary SaaS use and activated only through approved administrative workflows. The user may still work from the same organisation, but the most powerful permissions are no longer continuously present in the account that receives phishing emails and interacts with the wider internet.

The same principle applies to machine identities and service accounts. A deployment pipeline, automation platform, or workload with broad administrative permissions can be just as consequential as a human administrator, yet these identities often receive less scrutiny because they do not log in interactively.

Their privileges should be scoped narrowly, credentials should be temporary where possible, and unusual use should be monitored just as closely as privileged human access.

This is where MFA needs to sit inside a broader privilege-management strategy. Strong authentication makes it harder to enter the account, while temporary elevation, device controls, separate identities, and session monitoring reduce what an attacker can do even if they get through. For high-value accounts, that layered model is far more resilient than relying on the MFA prompt alone.

Identity Monitoring Has to Continue After the Login Succeeds

A successful MFA challenge should be treated as one useful signal in the access decision, rather than as proof that everything that follows is trustworthy.

Once the user is authenticated, the account can still behave in ways that are inconsistent with its normal pattern: a mailbox rule may be created, a new OAuth application may be authorised, an unfamiliar device may appear, a privileged role may be activated, or large amounts of data may suddenly be accessed. Those events often provide the first indication that a valid session is being abused.

This is where identity threat detection becomes important. Microsoft Entra ID Protection, for example, evaluates user and sign-in risk based on suspicious authentication behaviour and other identity signals, which allows organisations to apply different controls when the context around a login changes. The practical value is that access is no longer judged only once at the beginning of the session. Risk can be reassessed as new evidence appears.

A useful monitoring model should connect authentication with what the identity does afterwards:

Identity signal	Why it matters
Sign-in from an unfamiliar device or location	May indicate stolen credentials or session replay
New MFA method registration	Can indicate an attacker establishing persistence
Privileged role activation	Increases the consequence of compromise
New OAuth consent	May create long-lived application access
Mailbox forwarding-rule creation	Common post-compromise persistence or collection behaviour
Large or unusual data access	May indicate exfiltration
Rapid access across multiple services	Can reveal automated attacker activity
Session use after password or MFA reset	May indicate an old token remains active

Correlation matters because any one of these events can be legitimate. A travelling employee may sign in from a new country. An administrator may activate a privileged role during maintenance. A user may approve a legitimate application.

The risk rises when several events happen together, particularly when they are unusual for that identity. A new location followed by MFA registration, privilege escalation, and large data downloads tells a very different story from a new location on its own.

The response also needs to be graduated. Some events justify additional authentication, some warrant session revocation, and others should trigger immediate investigation or containment. The organisation does not need to challenge users constantly, but it should be capable of increasing friction when the behaviour around an authenticated identity becomes materially riskier.

This is the broader shift behind modern identity security. MFA protects the point where access begins. Continuous monitoring protects the period in which that access is actually being used. Combining the two makes account compromise considerably harder to sustain because the attacker has to behave like the legitimate user after getting through the login process, rather than merely succeeding once at the MFA prompt.

MFA Works Best as One Layer Inside a Broader Identity Control Model

The strongest way to think about MFA is as one part of an identity stack rather than the final control. Authentication establishes confidence that the person requesting access is legitimate, but the organisation still needs controls around the device, the session, the privilege level, the application being accessed, and the recovery process if something goes wrong.

NIST’s current Digital Identity Guidelines separate authentication assurance from the wider identity lifecycle, which is useful because it reflects how modern identity systems actually fail: compromise can happen before authentication, during the challenge, or after a valid session has already been established.

The authentication factor itself should also reflect the risk of the account. NIST’s latest guidance says services operating at Authentication Assurance Level 2 must offer a phishing-resistant authentication option, while the highest assurance level requires phishing-resistant authentication built around public-key cryptography.

That provides a useful direction for businesses even outside federal environments: the accounts capable of causing the greatest damage should receive the strongest authentication methods first.

A practical layered model can look like this:

Layer	Security objective
Password and credential hygiene	Reduce basic credential compromise
Phishing-resistant MFA	Make stolen passwords and phishing proxies less useful
Device trust	Restrict sensitive access from unmanaged or compromised endpoints
Conditional access	Evaluate location, device, application, user risk, and other context
Session protection	Reduce token replay and terminate suspicious sessions
Privileged-access management	Limit how much authority exists at any one time
OAuth and application governance	Control what third-party apps can do on behalf of users
Recovery controls	Prevent help-desk and factor-reset abuse
Identity monitoring	Detect suspicious behaviour after authentication
Incident response	Revoke sessions, credentials, tokens, and privileges quickly

The strength comes from the interaction between those layers. Consider an attacker who successfully steals a password. MFA blocks the first attempt. If the attacker then uses a sophisticated phishing proxy, phishing-resistant authentication makes that route significantly harder.

If a session is somehow obtained, device binding and conditional-access controls can restrict where it is replayed. If the attacker reaches the account, least privilege limits what is immediately available, while identity monitoring can surface unusual privilege changes, new authentication methods, or abnormal data access.

Recovery should complete the same loop. When compromise is suspected, the organisation needs a way to revoke sessions, rotate credentials, remove malicious OAuth grants, reset authentication methods, investigate the endpoint, and review privilege changes rather than simply changing the user’s password. Otherwise, an attacker who already holds a valid token or application grant may retain access after the apparent remediation is complete.

This is the real upgrade from basic MFA to mature identity security. The organisation continues using MFA because it removes an enormous amount of low-effort credential risk, while designing the surrounding controls for attacks that assume MFA is already present. That makes authentication harder to bypass, stolen sessions harder to reuse, privileged access harder to abuse, and account compromise much easier to detect before it turns into a wider breach.

The Practical Priority Is to Harden the Accounts That Matter Most First

Most small and mid-sized organisations do not need to rebuild their identity environment all at once. The fastest improvement usually comes from identifying the accounts and workflows where a successful takeover would create the largest business impact, then applying stronger controls there first.

Administrators, executives, finance teams, developers with production access, remote-access users, and people who can reset other users’ credentials are sensible starting points because those identities either hold more authority or sit closer to sensitive systems and transactions.

A practical rollout can therefore be risk-based:

Priority	What to strengthen first	Why it matters
Privileged administrators	Phishing-resistant MFA, separate admin accounts, just-in-time privilege	Compromise can affect the whole environment
Finance and payment approvers	Strong MFA, transaction verification, session monitoring	Direct route to financial fraud
Executives	Phishing-resistant MFA, device controls, recovery protection	High-value social-engineering targets
Help-desk and identity teams	Strong reset procedures and elevated authentication	Can create or reset access for other users
Developers with production access	Strong MFA, device trust, temporary privilege	Can reach code, infrastructure, secrets, and deployment systems
Remote-access users	Strong MFA plus device and location checks	Access originates outside the trusted office environment
General workforce	MFA, safer authentication methods, identity monitoring	Reduces the broad credential attack surface

The second priority is to close the paths that bypass normal authentication. Help-desk reset procedures, OAuth consent, long-lived sessions, unmanaged devices, shared accounts, standing privilege, and weak recovery processes should all be reviewed because attackers increasingly look for the easiest identity path rather than attacking the MFA factor directly. A company that strengthens MFA while leaving those routes unchanged will still have exploitable gaps around the control.

The third priority is visibility. Security teams should be able to see when authentication methods change, when new applications receive consent, when privileged roles are activated, when sessions appear from unusual devices or locations, and when authenticated users suddenly behave differently from their normal pattern. Those signals become far more valuable when they are correlated rather than reviewed one at a time.

For most companies, the objective is therefore incremental hardening rather than a dramatic identity redesign. Improve the strongest authentication methods for high-risk users, reduce standing privilege, tighten recovery, control third-party application access, connect authentication to device trust, and monitor what happens after login. That creates multiple chances to stop an attacker even when one identity control fails.

MFA Is Strongest When the Rest of the Identity System Is Designed for Failure

MFA remains one of the most valuable controls a company can deploy because it removes a large amount of password-only risk. The mistake is allowing that success to create false confidence. Modern attackers increasingly target the surrounding identity system: the session after login, the device holding the session, the help-desk recovery process, third-party application consent, or the privileged role that becomes available once authentication succeeds.

A mature identity programme therefore assumes that one control can fail and builds the next layer accordingly. Phishing-resistant MFA makes credential theft harder to turn into access. Device trust reduces the usefulness of stolen sessions. Conditional access adds context around location, risk, and endpoint state.

Privileged-access controls reduce the amount of authority sitting permanently inside accounts. Recovery processes prevent attackers from simply talking their way around the controls, while identity monitoring watches for suspicious behaviour after the login has already been approved.

The practical value of this layered approach is resilience. An attacker may still obtain a password, trick a user, compromise an endpoint, or steal a token, but each additional control reduces how far that initial success can travel. That is a much more realistic way to think about identity security than expecting any single authentication method to carry the entire burden.

MFA should therefore remain a baseline, but the real objective is to make account takeover difficult to complete, difficult to sustain, and difficult to turn into meaningful privilege or data access. Once the organisation starts measuring identity security in those terms, MFA becomes what it should be: a strong first barrier inside a much stronger system.

FAQs

1. Is multi-factor authentication still worth using if attackers can bypass it?

Yes. MFA still blocks a large amount of credential-based compromise, particularly attacks that rely only on stolen or reused passwords. The fact that attackers have developed ways around some MFA methods does not reduce its value. It changes what needs to sit around it.

The stronger approach is to keep MFA in place while improving the surrounding identity controls. Phishing-resistant methods, device trust, conditional access, session monitoring, tighter recovery, OAuth governance, and privileged-access controls make it much harder for an attacker to turn one stolen credential or session into sustained access.

2. Which types of MFA are easiest for attackers to bypass?

SMS codes, one-time passwords, and push approvals are generally more vulnerable to phishing and social engineering than FIDO2 security keys or passkeys. Attackers can sometimes trick users into entering OTP codes into phishing proxies or approving login prompts they did not initiate.

Phishing-resistant methods are stronger because the authentication response is cryptographically tied to the legitimate service. That makes it much harder for an attacker to relay the challenge through a fake login page. For high-value users such as administrators, executives, finance staff, and developers with production access, stronger methods should be prioritised.

3. What is MFA fatigue?

MFA fatigue happens when an attacker repeatedly triggers push notifications in the hope that the user eventually approves one. The attacker may also contact the victim pretending to be IT support and claim that approving the prompt is necessary to resolve a technical issue.

Number matching and phishing-resistant authentication reduce this risk because the user has to complete a more specific interaction than simply tapping “Approve.” Monitoring repeated authentication prompts is also useful because an unusual burst of MFA requests can indicate an active takeover attempt.

4. How can attackers steal a session after MFA has already been completed?

After successful authentication, applications usually issue a session cookie or token so the user does not need to complete MFA on every request. If malware or an adversary-in-the-middle phishing site steals that token, the attacker may be able to replay the authenticated session.

This is why session protection matters. Shorter session lifetimes, token binding, conditional access, endpoint protection, reauthentication for sensitive actions, and rapid session revocation all reduce the usefulness of stolen cookies or tokens.

5. Can a compromised laptop bypass MFA?

In practice, a compromised endpoint can undermine the protection MFA provides. Malware running on a trusted device may steal browser cookies, tokens, passwords, or other authentication material after the user has already signed in successfully.

That is why device security and identity security need to work together. Endpoint detection, device compliance, patching, managed browsers, conditional access, and restrictions on privileged workstations make it harder for malware on one endpoint to inherit the user’s trusted access.

6. Why are help desks a risk to MFA security?

Help desks often have the ability to reset passwords, remove authentication methods, or help users enrol new MFA devices. Attackers can target those workflows through social engineering because convincing a support agent may be easier than defeating a strong authentication factor technically.

Recovery procedures should therefore use strong identity verification, especially for privileged users. Sensitive resets may require manager approval, secondary verification, logging, session revocation, and alerts when new authentication methods are registered.

7. Can OAuth applications bypass MFA?

OAuth applications do not necessarily bypass MFA in the traditional sense, but they can create access that continues after the original authentication event. A user may complete MFA legitimately and then approve an application that receives permission to read mail, files, contacts, or other cloud data.

The risk comes from overly broad or malicious consent. Organisations should review third-party applications, restrict high-risk permissions, require admin approval where appropriate, monitor new consent events, and remove unused integrations. MFA protects the login, while application governance controls what authorised software can continue doing afterwards.

8. Should privileged accounts use different MFA controls from ordinary users?

Yes. Privileged identities can change security settings, create users, access sensitive infrastructure, modify cloud environments, or disable protections, so their compromise has a much larger consequence. They should receive stronger authentication and tighter controls.

A good privileged-access model combines phishing-resistant MFA with separate administrator accounts, just-in-time privilege, managed devices, shorter sessions, detailed logging, and reauthentication for sensitive actions. This limits both the probability and the potential impact of compromise.

9. How do we know whether an account is compromised even if MFA succeeded?

Look at what happens after authentication. Unusual devices, new locations, unexpected MFA registrations, OAuth consent, privileged-role activation, mailbox forwarding rules, large data downloads, and rapid access across multiple services can all indicate that a valid session is being abused.

The strongest detection comes from correlating those signals rather than treating them separately. One unusual login may be legitimate. An unusual login followed by a new authentication method, privilege escalation, and mass data access deserves immediate investigation.

10. What should companies add on top of MFA first?

Start with the accounts where compromise would create the greatest damage. Move administrators, executives, finance teams, identity-support staff, and developers with production access toward phishing-resistant authentication. Then tighten account recovery, reduce standing privilege, restrict OAuth consent, connect access to trusted devices, and improve session monitoring.

The goal is to create several barriers around the same identity. If one control fails, the attacker should still have difficulty keeping the session, gaining privilege, accessing sensitive data, or establishing persistence. That layered model is what turns MFA from a useful login control into part of a resilient identity-security programme.