How do I tell whether a login flow is really multifactor authentication?

What makes a login flow count as real MFA?

What matters is the proof structure, not the marketing label. A login flow is only MFA when the second check is drawn from a different factor type and is actually required at sign-in, not merely available as a backup path. That distinction matters because many flows look stronger than they are once you examine how the session is established.

Different factor types also behave differently under attack. A password plus another password is still one category, and a password plus a recovery prompt can still collapse into the same category if both depend on knowledge. The practical test is whether the flow resists theft of one factor without letting the attacker reuse the same proof path.

When you are reviewing a product or internal control, treat the factor claim as unproven until you can see the concrete login sequence. A real MFA flow should also show that the second factor is bound to the active session or device, so a captured proof is not trivially replayed into a different context.

Why factor type and binding both matter

Factor diversity is the first line of defence, but it is not the whole control. If the second step is not tied to the session, device, or transaction context, an attacker may still replay, relay, or inject the approval into a different login attempt. That is why many “MFA enabled” deployments are weaker than they sound in practice.

Session binding is especially important for flows that use push approval, one-time codes, or browser-based federation. The control should make it hard for an attacker to move a valid proof from one login to another, or to trick the user into approving a sign-in that was initiated elsewhere. In that sense, MFA is not just about asking for two things, it is about constraining how the second proof can be used.

A better way to judge the design is to ask whether stealing one factor still leaves the attacker blocked. If the answer is yes only in the brochure and not in the live flow, the implementation is not delivering the assurance people think it is.

How to verify the flow is not just “MFA by name”

Start by mapping each step to its actual factor category. Password plus password reset questions is not MFA, and password plus SMS code may be technically two steps without being strong enough for high-risk access. Stronger designs usually combine independent proof with phishing resistance, such as a hardware-backed or device-bound authenticator.

Then test the unhappy paths, because that is where false MFA claims usually show up. Check what happens when the second factor is unavailable, when the user falls back to recovery, when the help desk intervenes, or when the same session can be resumed from another device. If the fallback path silently degrades to single-factor access, the effective assurance level has changed.

It is also worth checking whether the login flow supports step-up only after an initial weak sign-in. That can be legitimate, but it should not be described as full MFA for the whole session if the most sensitive actions still depend on stronger reauthentication later.

Risk and Threat Considerations

False MFA confidence creates a real security gap because teams may treat an exposed login as protected when it is still vulnerable to phishing, replay, MFA fatigue, or recovery-channel abuse. The danger is not only account takeover, but also the mistaken belief that a control exists when the attacker can still complete the same authentication journey.

Failure mechanism: The login flow reuses one factor category, or the second factor is not bound tightly enough to the session or device, so an attacker who captures the first proof can still complete authentication through relay, prompt abuse, or recovery bypass.

Impact: Users, defenders, and auditors may all overestimate the strength of the control, which can leave privileged access, remote access, or recovery paths exposed even though MFA appears to be enabled.

Practitioner Guidance

What to verify: Confirm that each required step comes from a different factor category and that the second factor cannot be replayed into a new session. If the product only describes “two steps,” do not accept that as evidence of MFA.

Common mistake: Treating SMS, knowledge-based recovery, or push approval as automatically equivalent to strong MFA. The real question is whether the flow resists phishing, relay, and fallback abuse, not whether it contains two prompts.

Decision rule: If the second proof can be transferred, relayed, or recovered too easily, classify the flow as weaker than true MFA and raise the assurance requirement before allowing sensitive access.

Practitioner takeaway: Real MFA is defined by independent factor categories plus usable binding, not by the number of screens a user clicks through.

Related resources from NHI Mgmt Group

• How can organisations tell whether an API login flow is outside its intended boundary?
• How can security teams tell whether their iOS authentication flow is compliant enough for review?
• How can security teams tell whether their authentication ceremony really meets the intended AAL?
• How can organisations tell whether authentication is actually phishing-resistant?