H6.12.1MFA strength optionsdesignresearch

MFA should offer strength options between convenience and security

Aliases: AAL choices · 2FA method picker · authenticator ladder

What it is

Multi-factor authentication asks for a second kind of proof besides a password or other first factor. Second factors do not share assurance: SMS OTP is channel-restricted; authenticator apps and security keys are stronger. Strength options means the product lets people (or the action) choose along convenience versus assurance, rather than offering only the weakest kind and calling it “two-step on.” This entry is how the options are laid out. It is not about a backup when the second factor is lost, and not about checking device availability before a mandate.

Why it happens

Drawing every second factor as one switch makes SMS and a hardware key look equal, so high-consequence actions sit behind the weak factor alone. NIST distinguishes authenticators that are allowed versus restricted at a given assurance level; a product with only SMS looks like MFA and actually stops at the restricted tier. When options exist, everyday sign-in can use a convenient factor, and password change, rebinding, and funds step up. Without options, the product either forces keys on everyone (locking out people without hardware) or SMS on everyone (attackers aim at SMS). Options are not a per-login tap of “I want weaker”; they are several factors enrolled in advance, with a policy picking the lowest acceptable tier per action.

Studying it

Compare “SMS only,” “security key only,” and “several factors enrollable with step-up by action”: which tier high-consequence actions actually use, and whether people understand the gap.

Independent variables: enrollable set, whether actions force step-up, whether settings copy distinguishes strength. Dependent variables: share of high-consequence actions passed by SMS alone, enrollment of stronger factors, judging all factors equally safe.

Completion rate is friction. A phishing drill can show codes copied versus keys not phished; do not invent “MFA cuts takeover by X percent.” Speak assurance in guidance language, not an in-house score.

Where it stops holding

When regulation or a payment network specifies a tier, options must not go below it. Enterprises may lock the set; individuals have no choice, and settings should show the locked tier rather than an empty switch. Markets with only one enrollable factor (no keys for sale, SMS also down) collapse options to on/off; the limits of that tier must still be written. When a passkey is the first factor, MFA combinatorics change; do not label “already using a passkey” as “two-step still off,” which duplicates the prompt.

Applying it

  • Allow several second factors; group them in settings by assurance (SMS restricted, authenticator and security key higher); do not use one green “protected” dot.
  • Require a factor above SMS for rebinding and funds; everyday sign-in may use a lower enrolled tier.
  • Explain differences with channel facts, not an abstract score.
  • Verify: list factors each sensitive action accepts and close high-consequence paths that SMS alone can pass. Ask people uninvolved in the design which factor resists phishing better, and check that settings grouping supports that judgment. A new account should be able to enroll at least one tier without buying hardware, and see that a stronger tier can still be added.

Related

  • Within the group: H6.12.2 A failed second factor needs a pre-enrolled backup method · H6.12.3 Assess device availability before mandating MFA · H6.12.4 Recovery-code custody must be explained to the person who holds them
  • Adjacent: H6.03 OTP and passwordless login · H6.05 Biometrics
  • Search terms: authenticator assurance · MFA methods · step-up authentication

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/H6.12.1