MFA benefits depend on adaptive controls, not baseline deployment

At a glance

What this is: This is a guide to the core benefits of MFA, with the key finding that those benefits only hold when MFA is deployed intentionally and adaptively.

Why it matters: It matters because IAM teams still treat MFA as a checkbox control, when the real governance problem is whether authentication strength matches user risk, device trust, and access context across human, workload, and emerging AI-adjacent identity flows.

By the numbers:

• Some reports estimate a doubling in use since 2020, despite some highly regulated industries and large organizations lagging behind.

👉 Read Descope’s guide to the real benefits of MFA when it is done correctly

Context

Multi-factor authentication is a stronger authentication pattern than passwords alone, but the control only delivers its intended value when it is deployed with risk awareness and not treated as a universal default. The primary keyword here is MFA, and the governance question is whether the factor challenge actually matches the sensitivity of the login.

For IAM programmes, the interesting issue is not whether MFA exists but where it is weak, fatiguing, or misaligned with the access path. That matters for human users today, and it also shapes the assumptions teams carry into broader identity design as machine and AI-driven access patterns increase.

Baseline MFA often stops at the presence of a second factor, while adaptive MFA asks whether the login context justifies extra friction. That distinction is where many programmes either strengthen assurance or create habits that users learn to bypass.

Key questions

Q: How should security teams implement MFA without creating user fatigue?

A: Use adaptive step-up authentication instead of forcing the same challenge on every login. Reserve stronger prompts for risky devices, unfamiliar locations, sensitive actions, and privileged accounts. That reduces friction for routine access while preserving assurance where the business actually needs it.

Q: Why do basic MFA deployments still get bypassed?

A: Basic MFA can be bypassed because attackers exploit weak factors, repeated prompts, and user approval habits. If the second factor is easy to proxy, guess, or socially engineer, the control becomes a speed bump rather than a barrier. Phishing resistance and context-aware policy raise the bar.

Q: When does MFA create less security than it promises?

A: MFA creates a false sense of security when exceptions, legacy pathways, and low-assurance methods dominate the environment. If privileged users still rely on push approvals or unchecked fallback flows, the programme is not delivering the assurance leaders think it is.

Q: What should identity teams prioritise after deploying MFA?

A: Prioritise policy quality, session scoping, and exception management. The goal is not just to add a second factor, but to make sure the authentication result actually reflects the risk of the access path and continues to matter after login.

Technical breakdown

Adaptive MFA and step-up authentication

Adaptive MFA evaluates context before deciding whether to challenge the user further. Step-up authentication raises the burden only when the login looks risky, such as from a new device, an unusual location, or a sensitive transaction path. This is different from static MFA, which applies the same challenge everywhere. The technical value comes from binding authentication depth to risk signals, device trust, and session sensitivity rather than to the username alone.

Practical implication: tune MFA rules so high-risk events trigger stronger verification while routine logins stay usable.

MFA fatigue and phishing resistance

MFA fatigue occurs when repeated prompts train users to approve challenges without scrutiny, weakening the control instead of strengthening it. Push-based or basic OTP flows can also be socially engineered, especially when attackers already possess credentials. Phishing-resistant methods reduce that exposure by tying the second factor more tightly to the device and origin of the request. The control is strongest when the factor is difficult to proxy or replay.

Practical implication: move high-value accounts to phishing-resistant methods before relying on user behaviour to compensate for weak prompts.

How MFA complements identity-based access controls

MFA is increasingly used as an identity control that partially replaces perimeter assumptions, especially for remote access. In practice, the session token issued after successful authentication becomes the gatekeeper for downstream resources, so the quality of the initial challenge shapes everything that follows. This is why organisations combine MFA with device binding, risk scoring, and session scoping. The design question is whether authentication creates meaningful assurance or just another login hurdle.

Practical implication: align MFA with session scoping and device trust so authentication strength carries through the full access path.

Threat narrative

Attacker objective: The attacker aims to convert stolen credentials into a trusted session that enables account takeover, data access, or administrative abuse.

1. Entry begins when an attacker obtains a password through phishing, credential stuffing, or prior breach reuse and attempts to authenticate against a target application.
2. Escalation occurs when baseline MFA is weak, overtrusted, or fatigue-prone, allowing the attacker to approve a prompt or bypass a low-assurance challenge and obtain a valid session.
3. Impact follows when the authenticated session grants access to sensitive accounts, admin portals, or protected data that the password alone should never have reached.

Breaches seen in the wild

• Microsoft Midnight Blizzard breach — Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
• Salt Typhoon US telecoms breach — Salt Typhoon APT used stolen credentials and Cisco CVE to breach US telecoms.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Baseline MFA is a control, not a governance outcome: The article is right to separate generic MFA from intentionally designed MFA. In practice, many programmes can claim MFA coverage while still leaving high-risk logins protected by weak factors, fatigue-prone prompts, or inconsistent step-up logic. The practitioner takeaway is that coverage metrics alone do not prove assurance.

Adaptive authentication is the real security boundary: MFA only changes the risk equation when it responds to context such as device trust, login sensitivity, and behavioural risk. That is why the same mechanism can either reduce account takeover or become a user habit that attackers exploit. The implication is that authentication policy, not factor count, is what defines control strength.

Factor choice now shapes broader identity architecture: As enterprises move beyond passwords, MFA design begins to influence session trust, remote access design, and the extent to which network controls still matter. This is where IAM, PAM, and Zero Trust intersect. Practitioners should treat MFA as part of the access architecture, not a standalone login feature.

User convenience is a security variable: The article correctly notes that convenience can either support or weaken MFA depending on how prompts are applied. If users are over-challenged, they look for shortcuts; if they are under-challenged, the assurance gap grows. The practical conclusion is that usability is not separate from control effectiveness.

Named concept. authentication assurance drift: MFA programmes often start with strong intent and degrade into routine prompt handling, inherited exceptions, and uneven application across systems. That drift matters because the organisation believes it has stronger authentication than it actually does. Practitioners need to measure whether deployed MFA still matches the risk model it was supposed to enforce.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• That pattern reinforces why the OWASP Agentic Applications Top 10 matters for identity teams that are preparing for non-human access at scale.

What this signals

Adaptive MFA is becoming a baseline expectation, but the governance lesson is broader than login hardening. Identity teams should expect pressure to prove not only that MFA exists, but that it still matches the risk of the access path, the device state, and the session value. That is the difference between a control on paper and a control that actually reduces exposure.

Authentication assurance drift: The longer MFA exists without active policy review, the more likely it is to accumulate exceptions, fallback paths, and low-friction shortcuts that weaken the original design intent. That drift is often invisible until an incident or audit exposes it. Teams should treat MFA quality as a lifecycle issue, not a one-time rollout.

As AI agents and machine identities proliferate, the same governance instinct will be tested in adjacent identity domains. If a programme cannot distinguish meaningful assurance from checkbox coverage for humans, it will struggle even more when non-human access becomes the norm. The strategic move is to align access assurance, session trust, and lifecycle governance before those gaps widen.

For practitioners

• Map MFA coverage to real assurance levels Inventory where MFA is present, then separate basic, adaptive, and phishing-resistant flows so the programme can see which accounts actually have meaningful protection. Prioritise admin consoles, remote access paths, and externally reachable apps first.
• Replace fatigue-prone prompts on sensitive accounts Reduce push-based overuse for privileged users and move high-value access to phishing-resistant methods where feasible. If a user can learn to approve a prompt by habit, the factor no longer serves as a reliable second check.
• Tie step-up rules to device and session risk Use device binding, trust scoring, and contextual triggers so authentication burden rises only when the login context justifies it. That preserves usability while still forcing stronger verification for unknown or risky sessions.
• Review MFA exceptions as governance debt Track bypasses, legacy exclusions, and business-approved weak paths as part of identity governance rather than as temporary convenience. Exceptions age quickly and often become permanent control gaps.

Key takeaways

• MFA improves assurance only when it is designed around risk, not just deployed everywhere as a standard checkbox.
• The scale of credential abuse means weak or fatigue-prone MFA leaves a real opening for account takeover and downstream abuse.
• Identity teams should measure MFA quality, exception debt, and step-up logic together because those controls determine whether the programme actually works.

Key terms

• Adaptive MFA: Adaptive MFA is an authentication approach that changes the challenge based on context such as device trust, location, user behaviour, or transaction sensitivity. It aims to preserve usability for routine access while increasing assurance when risk rises. In practice, it turns authentication into a policy decision rather than a fixed login step.
• Step-up Authentication: Step-up authentication is a stronger verification step triggered only when a login or action is considered higher risk. It is commonly used for privileged access, sensitive data, or unfamiliar devices. The control matters because it lets teams increase assurance without forcing every user through the same high-friction process.
• MFA Fatigue: MFA fatigue is the weakening of multi-factor authentication when users are repeatedly prompted and begin approving challenges without scrutiny. Attackers exploit that habit to gain access through social engineering or prompt abuse. The problem is not the factor itself, but the human behaviour created by poor deployment design.
• Phishing-resistant Authentication: Phishing-resistant authentication uses methods that are much harder for an attacker to intercept, proxy, or replay than passwords or basic OTPs. It is typically associated with device-bound or cryptographic factors. The practical value is highest for privileged users and internet-facing access paths where credential theft is likely.

What's in the full article

Descope's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of adaptive MFA flows for different login risk levels and user journeys.
• Specific factor types, including TOTP, push, passkeys, and risk-based step-up patterns.
• Operational examples of how MFA reduces friction in remote access and customer-facing use cases.
• Implementation detail on using risk services and branching logic to tune authentication decisions.

👉 The full Descope post covers the MFA flow stages, factor options, and adaptive implementation patterns.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.