Summary
MFA is not the finish line” describes the gap between having multi-factor authentication and being protected by it. A second factor stops attackers who only hold a password. It does not stop those who target the factor itself, the enrolment and recovery processes around it, or the session left open after login. Phishing-resistant MFA, such as FIDO2 or PKI-based authentication, closes the first gap. Controlling enrolment, recovery and sessions addresses the rest.
A caller says they are from IT and asks for the six-digit code that has just arrived on an employee’s phone. The employee reads it out. The MFA system did its job, and the attacker now holds a valid code.
In July 2025, the FBI, CISA and international partner agencies updated a joint advisory on Scattered Spider, a criminal group that targets large companies and their IT help desks. It describes this technique. Most Multi-Factor Authentication (MFA) programmes were scoped to answer one question: is a second factor enforced at login? Attackers ask which part of the factor they can intercept, trick or reset. A rollout with full coverage can leave every one of those routes open.
Four ways attackers get past a second factor
Attackers have used each of these to get past a second factor:
- Code harvesting. Posing as IT staff to convince employees to share their one-time password.
- Push bombing. Sending repeated approval prompts until an employee presses Accept.
- SIM swap. Convincing a carrier to move the victim’s number to a SIM the attacker holds.
- Help desk resets. Posing as an employee to have the help desk reset the password and move the MFA to a device the attacker controls.
Each one attacks how the factor is entered, approved, delivered or registered, not the cryptography behind it. NIST’s 2025 guidelines name the shared flaw: a typed code is not tied to the session being authenticated, so an impostor can relay it to the real service.
What “phishing-resistant” means in practice
NIST defines phishing resistance as a protocol that keeps secrets and valid authenticator outputs away from a fake verifier without depending on the user to spot the fake. Typed codes and out-of-band approvals cannot meet it. Cryptographic authentication can.
In practice that means FIDO/WebAuthn or PKI-based authentication, which resist phishing and are not susceptible to push bombing or SIM swap. FIDO2 selects the credential using the verified domain name of the site, so a lookalike domain cannot obtain a usable output.
The NCSC, in guidance reviewed in September 2024, ranks methods in the order it recommends them:
- FIDO2 credentials on trusted devices or roaming keys
- Challenge-based authenticator apps
- App-based code generators
- Hardware-based code generators
- Message-based methods (email, SMS and calls)
It notes that challenge-based apps give only partial phishing resistance because of prompt fatigue, and that message-based methods suit only cases where nothing stronger is possible.
NIST permits biometrics only alongside a physical authenticator and requires presentation attack detection for facial recognition.
The weak points sit around the login
-
Enrolment:
NIST requires that adding a new authenticator be authenticated at the right assurance level, with the user notified through an independent channel. If a device can be registered with a password and a text message, the strongest factor is only as strong as that step.
-
Recovery:
NIST requires a notification for every recovery event. At AAL2 it requires two recovery codes obtained by different methods, one code plus a bound single-factor authenticator, or repeated identity proofing. Agent-assisted recovery is allowed only on a documented risk analysis, a fair standard for your own help desk. Verizon’s 2026 DBIR reports that mobile-centric social engineering, such as fake text messages and voice calls, has a success rate 40% higher than traditional email phishing. The figure covers social engineering generally, not help desk resets, but a reset call is an interactive attack on the one person who can change a factor.
-
Sessions:
After login, the browser holds a session secret. NIST notes that secrets used as bearer tokens can be stolen and cites device-bound session credentials as one mitigation. A strong login that issues a stealable token has moved the target, not removed it.
Match the factor to the system
The right strength depends on the role and the criticality of the application. NIST builds tiers into its assurance levels: applications at AAL2 must offer a phishing-resistant option, and AAL3 requires a non-exportable cryptographic authenticator. The NCSC frames it as a balance within risk appetite, for example hardware security keys for every IT administrator. Where possible, phishing-resistant MFA should cover every service, especially webmail, VPNs and accounts that access critical systems.
Legacy applications are where plans stall. The NCSC notes that FIDO2 and challenge-based MFA can be enabled through federated single sign-on even where the service lacks native support.
How the tiers map to a deployable stack
Each tier maps to a method per user group, and infrastructure decides what is practical. Accops HyID is one example of a platform that supports the method types ranked above, so tiers can be set by policy:
- Administrators and critical systems: FIDO security keys, or device hardware ID with PKI certificates.
- Standard workforce: push notifications or mobile app OTP, with fingerprint, face or QR-code passwordless login where policy allows.
- Phones not permitted: FIDO security keys or hardware tokens.
- Lowest tier: OTP over SMS or email, where nothing stronger is possible.
HyID deploys on-premises, as an Accops-hosted cloud service or as a hybrid. Its MFA covers modern, legacy, cloud and on-premises applications, including those that do not natively support MFA. FIDO keys and QR login depend on edition or add-ons, so check the editions page against your tier plan. Configuration and enforcement, not method support alone, decide the assurance you get.
A test for your next security review
Pick the most privileged account in your organisation. Trace every route that ends with an attacker holding a valid session for it: the login, the device registration, the reset call, the stored session token.
The weakest control on any of those routes is your real authentication strength. Coverage figures show where MFA is switched on. This exercise shows where it can be walked around.
If tracing those routes turns up gaps you want a second opinion on, the Accops team can compare them against the options above.
Frequently Asked Questions
Standard MFA adds a second factor, but typed codes and approvals can still be relayed through a fake login page. Phishing-resistant MFA, such as FIDO2 or PKI, ties the login to the genuine site, so a lookalike gets nothing usable.
Start with accounts that can do the most damage if taken over: webmail, VPNs, accounts that access critical systems and administrator accounts. An example is hardware security keys for every IT administrator.
Identify applications without native MFA support. Then upgrade or replace them, or enable stronger MFA through federated single sign-on, which works even where the service lacks native support. Treat message-based codes as the last resort.
