Mfa adoption is rising, but phishing-resistant coverage lags

At a glance

What this is: This is an analysis of MFA trends in 2026, showing that adoption is broad but effective, phishing-resistant coverage remains incomplete.

Why it matters: It matters because IAM teams cannot treat second-factor presence as success when coverage, method choice, and enforcement determine whether authentication actually holds up under attack.

By the numbers:

• 94% of organizations have some form of customer MFA.
• 10% of them offer MFA across all their applications.
• 45% of organizations have deployed passkeys in at least one app.
• 82% experienced measurable business impact from authentication issues.

👉 Read Descope's analysis of MFA trends and phishing-resistant authentication

Context

MFA is the control many programmes count on to absorb credential theft and password abuse, but the control only works when it is consistently enforced across the full application estate. In practice, many organisations still have patchy coverage, older methods that depend on shared secrets, and deployment choices that reflect platform constraints rather than current threat models.

For IAM and customer identity teams, the problem is not simply adoption. It is whether the second factor is phishing-resistant, whether it applies everywhere it should, and whether step-up logic adapts to risk instead of adding friction blindly. That is why the gap between deployed MFA and effective MFA has become a governance issue, not just an authentication design issue.

Key questions

Q: How should security teams roll out phishing-resistant MFA without breaking user flows?

A: Start with the highest-risk applications and recovery paths, then expand by journey instead of by user population alone. Use passkeys or equivalent phishing-resistant factors where possible, but review enrollment, device recovery, and help desk support first so the new control does not fail at the fallback layer.

Q: Why does MFA still fail in organisations that already use it widely?

A: MFA fails when coverage is incomplete, when weaker methods such as SMS OTP remain in use, or when enforcement is inconsistent across applications and recovery paths. The control is only effective if it resists phishing, survives operational exceptions, and applies to the journeys attackers are most likely to target.

Q: How do organisations know whether adaptive MFA is working as intended?

A: Adaptive MFA is working when stronger verification appears only under elevated risk, when routine sessions stay low-friction, and when fallback logic does not quietly weaken the control. If the system cannot show clear step-up decisions tied to identity context, it is probably acting as a cosmetic layer rather than a real risk control.

Q: What is the difference between passkeys and older MFA methods in practice?

A: Passkeys remove the shared-secret dependency that makes older MFA methods vulnerable to phishing and interception. They bind authentication to a device-held private key and a local user action, which shifts the attack from code theft to device and recovery path protection. That changes both security posture and operational support design.

Technical breakdown

Why SMS OTP and knowledge-based MFA keep failing

SMS OTP and knowledge-based authentication still fail because they preserve a secret that attackers can intercept, replay, or socially engineer around. In MITM and AITM attacks, the attacker sits between user and service, captures the one-time code, and completes the session before the user notices. Push fatigue and credential stuffing compound the problem because the factor is still wrapped around a password-centric flow. The weak point is not the existence of MFA. It is the continued dependence on recoverable secrets and user-driven approval steps that attackers can manipulate.

Practical implication: replace secret-based second factors in the highest-risk journeys before you expand MFA coverage further.

Passkeys and phishing-resistant authentication as a control shift

Passkeys change the authentication model by binding login to a device-held private key and local biometric or PIN verification, which makes phishing far harder. They reduce dependency on shared secrets and remove the most common replay path that legacy MFA leaves open. The operational shift matters because a phishing-resistant factor is not just a better login method. It also changes help desk workflows, account recovery, and enrollment design, since recovery becomes part of the attack surface rather than an afterthought.

Practical implication: treat passkey rollout as an identity program change that must include recovery, enrollment, and fallback path review.

Adaptive MFA and risk-based step-up

Adaptive MFA uses live signals such as device trust, location, behavioural change, and session context to decide when to require additional verification. That makes authentication proportional to risk instead of identical for every session. The technical value is in reducing friction for routine access while forcing stronger checks when the session deviates from expected patterns. This only works when the policy engine has good telemetry and when the fallback path does not quietly revert to weak factors. Otherwise adaptive logic becomes a cosmetic layer over the same old weaknesses.

Practical implication: validate your risk signals and fallback paths before you rely on adaptive MFA for high-value access.

NHI Mgmt Group analysis

Coverage without enforcement is the false comfort pattern in MFA programmes. The article shows that many organisations have some form of MFA, but a much smaller share apply it consistently across all applications. That creates a governance gap where attackers only need the unprotected slice of the estate to succeed. Practitioners should stop reporting MFA as a binary and measure enforced coverage instead.

Legacy second factors persist because they fit old implementation habits, not because they remain defensible. SMS OTP, push prompts, and password-adjacent methods survive because they are easy to deploy across existing journeys. But the control assumption behind them is weakening under phishing, interception, and fatigue-based abuse. Teams need to treat method selection as a risk decision, not a UX preference.

Adaptive authentication works only when risk scoring is tied to real identity context. Device trust, session behaviour, and location signals can improve control precision, but only if the fallback experience does not quietly permit weak verification. That makes identity telemetry and exception handling part of the control itself. Practitioners should evaluate whether their step-up rules actually change attacker cost.

Phishing-resistant MFA is now a baseline expectation for customer and workforce identity design. Passkeys and similar methods do not eliminate identity risk, but they remove the most common interception paths that legacy MFA still leaves open. The market is normalising stronger methods, which means teams that delay will carry growing operational and audit friction. Practitioners should align authentication roadmaps with the shift toward resistance, not just assurance.

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 trajectory makes authentication design inseparable from governance, which is why teams should also review OWASP Agentic AI Top 10 as they harden identity controls.

What this signals

Adaptive authentication is becoming a governance problem, not just a login feature. As organisations extend MFA into more journeys, the real question is whether policy engines can distinguish ordinary access from risky access without creating brittle fallback paths. Teams that treat authentication as a product metric will be better placed to manage user friction and control strength together.

The next maturity step is to link authentication telemetry with lifecycle and recovery governance. That means tracking where weak factors still appear, how often exceptions are granted, and whether account recovery reintroduces the same weaknesses MFA was meant to remove.

Coverage gaps will matter more as passkeys normalise. Once phishing-resistant methods become the expected baseline, organisations that remain dependent on SMS OTP or password-adjacent controls will face higher audit friction and greater operational risk. The practical move is to modernise the control stack before exception handling becomes the default operating model.

For practitioners

• Measure enforced MFA coverage, not just deployment counts Inventory which applications, journeys, and recovery paths still allow password-only access or weaker fallback methods. Report coverage by protected application rather than by total MFA enrolment, and include exceptions that bypass policy.
• Prioritise phishing-resistant factors in the highest-risk journeys Move passkeys or equivalent phishing-resistant methods into admin, support, financial, and account recovery flows first. Keep SMS OTP and knowledge-based factors out of paths where interception or social engineering would create disproportionate exposure.
• Review adaptive MFA fallback rules and step-up triggers Validate that your risk engine really requires stronger verification when device trust, location, or session behaviour changes. Ensure fallback paths do not silently restore weak factors when a risk signal is unavailable or misclassified.
• Separate customer identity design from workforce IAM assumptions Avoid stretching workforce IAM controls into customer-facing journeys unless the implementation can support the required flexibility. Recheck recovery, branding, and enrollment constraints before you standardise across both populations.
• Treat account recovery as part of the attack surface Test recovery flows with the same rigour as primary sign-in, because attackers often target the weakest alternate path. Make sure reset, fallback, and help desk processes do not reintroduce password-centric weaknesses.

Key takeaways

• MFA is widely deployed, but inconsistent coverage and legacy methods still leave organisations exposed to credential abuse and phishing.
• Passkeys and adaptive authentication improve resilience only when recovery paths, fallback logic, and enforcement are designed with the same care as primary sign-in.
• IAM teams should measure effective coverage, not nominal adoption, because that is the difference between a control that exists and a control that actually works.

Key terms

• Phishing-resistant MFA: A multifactor authentication method that cannot be easily replayed or intercepted through phishing. It typically binds the login to a device-held credential and a local user action, reducing reliance on shared secrets that attackers can capture or coerce during the session.
• Adaptive authentication: An authentication approach that changes verification requirements based on risk signals such as device trust, location, and session behaviour. It reduces friction for routine access while increasing assurance when the context looks unusual or higher risk.
• Passkeys: A passwordless authentication method that uses public-key cryptography and device-bound credentials. The user proves possession of the device and confirms locally with biometrics or a PIN, which makes phishing and code interception much harder than with shared-secret methods.
• Step-up authentication: An additional verification step triggered when a session or request crosses a risk threshold. In modern IAM programmes, step-up should be driven by real context and should not silently fall back to weaker methods when the signal is missing or ambiguous.

What's in the full article

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

• Step-by-step examples of how SMS OTP, authenticator apps, passkeys, and magic links compare in real authentication flows.
• Vendor-specific implementation detail on how adaptive authentication uses device trust, location, and session risk signals.
• Practical rollout patterns for moving from legacy MFA to phishing-resistant methods without forcing a full auth rebuild.
• Examples of how customer identity teams can layer MFA into existing journeys using low-code orchestration.

👉 Descope's full post covers adoption data, passkey momentum, and adaptive MFA implementation detail.

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 NHI governance in your organisation, it is worth exploring.