Choose MFA Methods Without Treating Them as Equivalent

Start with the access path, not the MFA label

Multifactor authentication adds protection beyond a password, but the available methods do not all have the same security or operational properties. CISA’s MFA guidance describes MFA as an additional identity check and shows that services may offer different methods. NIST SP 800-63B-4 states that manually entered out-of-band and OTP outputs are not phishing-resistant, while qualifying cryptographic authentication can be phishing-resistant. NIST also treats account recovery as distinct from normal authentication.

Those sources support MFA, property-based comparison, and separate treatment of recovery. They do not prescribe the eight stages, labels, 16 fields, stop conditions, or fictional example below. Those are PlainFort editorial choices for a small team—not NIST, CISA, or NCSC requirements, a regulated assurance determination, certification, guarantee, product ranking, or universal winner.

Choose for one bounded account scenario at a time. A completed matrix cannot guarantee provider behavior, successful enrollment or recovery, endpoint integrity, accessibility, or protection from compromise.

Separate four layers that interfaces often collapse

Do not compare only the label shown in a settings screen. Separate:

1. Authenticator or mechanism — what proves possession, control, or another authentication property to the verifier.
2. Hosting device or medium — such as a phone, computer, or hardware key. The device is not automatically the factor itself.
3. Local activation or user verification — such as a local PIN or biometric gesture that unlocks an authenticator. A biometric used locally is not automatically a standalone remote authenticator or proof of phishing resistance.
4. Fallback and account recovery — alternative routes for regaining access. They are distinct from normal authentication and may weaken the effective protection of the primary method.

Treat SMS, email, manually entered OTP, push approval, passkey, security key, biometric, and other labels as prompts to investigate—not as equivalent mechanisms or reliable conclusions. Implementations under the same label can differ. Record the real documented flow, dependencies, and recovery path. If those cannot be established, use Unknown — follow up or Blocked — provider behavior unverifiable.

Compare phishing resistance without hiding downgrade paths

Phishing resistance belongs to the actual authentication mechanism and protocol, not automatically to the words MFA, two factors, biometric, push, passwordless, passkey, or security key.

For each candidate, record whether the actual mechanism is documented as phishing-resistant and the evidence for that conclusion. Then inspect enrollment, reset, help-desk, email, SMS, administrator override, and recovery paths separately. A stronger primary method with a weaker fallback must not be described simply as a phishing-resistant account. Record the primary property and the residual downgrade as different facts.

NIST’s statements have a federal digital-identity scope. They support the property distinction here; they do not select a method for every small business or validate a product implementation.

Use eight stages for a bounded decision

The order, fields, comparison states, and completion test in these stages are PlainFort editorial judgment. They can be simplified for a small team, but a simplification must not hide authority, accessibility, recovery, continuity, or unknown provider behavior.

1. Bound the scenario

Name the non-sensitive account class, business impact, affected roles, access availability need, internal decision owner, and recovery authority. Do not record a username, email address, tenant, phone number, device identifier, or account detail.

2. List currently supported options

Use the service’s current primary documentation. Record only non-secret method-family labels, constraints, the source, and the check date. Do not enroll, test, rank, or infer an option the service has not documented.

3. Identify the real mechanism

Separate the authenticator or protocol from its hosting device, local activation, and recovery path. Do not treat a fingerprint, phone, QR flow, or settings label as a complete technical classification.

4. Compare protection and dependencies

Record the phishing-resistance basis, device and platform dependencies, network or hardware availability, portability, user accessibility, and known limitations. If a supported method is inaccessible to an affected user, that is a decision constraint—not a reason to hide the user or declare the method universally best.

5. Map enrollment and replacement safely

Document the authorized owner and the provider’s current rules for initial enrollment, adding a replacement, and retiring an old authenticator. This guide does not perform those actions. A later authorized process should preserve a viable path while a replacement is added and verified where the provider permits; removal comes only after completion evidence and continuity are inspected.

If the provider forces removal first, the current method is the last viable administrator path, or failure could interrupt critical work, use Blocked — qualified help required.

6. Inspect fallback and recovery

List documented routes and the authority that may invoke them, but never record recovery material. Mark each route’s downgrade, device dependency, accessibility constraint, and unknown behavior. Recovery readiness means roles, documentation, non-secret evidence, stop conditions, and escalation are known—not that recovery has been performed or proven.

7. Test continuity on paper

Consider device loss, an unavailable user, an inaccessible method, provider outage, and an unavailable last administrator. Use documentation or a tabletop review only. Suspected theft, compromise, remote wiping, forensic preservation, and general incident response belong in trigger-specific incident guidance, not this routine decision.

8. Decide, preserve exceptions, and review

Record the selected method for the bounded scenario, rejected candidates with concise reasons, fallback downgrade, unresolved risk, exception owner and expiry, completion evidence, and the next review trigger. Selected means selected for the stated scenario; it does not mean certified, guaranteed, or universally strongest.

Stop before lockout or unsafe recovery

Before any separately authorized live enrollment, replacement, removal, fallback, or recovery, stop and confirm:

• an accountable internal owner and authorized executor;
• backup ownership and escalation authority;
• whether the authenticator belongs to the last viable administrator;
• the business impact and acceptable interruption boundary;
• an accessible alternative appropriate to the affected user;
• current primary provider documentation and support constraints;
• whether a non-destructive documentation or tabletop check is sufficient;
• whether qualified product, IT, security, accessibility, legal, contractual, or incident help is required.

Do not use this guide to perform live recovery, remove an authenticator, change production access, or respond to suspected compromise.

Break-glass is a narrowly scoped emergency-access pattern, not an informal shared account, a recovery-code list, or a default fallback. It requires a purpose, internal owner, authorized roles, protected storage outside this article, access control, logging where available, a review or test trigger, post-use review or rotation where applicable, and an expiry or exit condition. This guide does not create, configure, reveal, or test a break-glass path.

Keep sibling decisions separate

AA-06 owns password-manager rollout, adoption, conceptual vault structure, individual-credential migration, and process-level recovery readiness. AA-07 supplies the method, fallback, and recovery-tradeoff decision that AA-06 records as AA-07 decision required; it does not repeat AA-06’s seven-stage rollout or legacy-storage handling.

AA-08 owns which everyday and administrator accounts must be separate, when elevation is used, and what exceptions apply. AA-07 may note that an administrative scenario changes impact and constraints, but it does not design the account split.

AA-09 owns departure-triggered revocation, authority, session handling, evidence, and exceptions. AA-07 may require that authenticators be attributable and removable, but it does not execute offboarding.

AA-10 owns whether a shared login is eliminated, replaced with individual accounts, delegated, brokered, placed in controlled shared access, or retained as a bounded exception. AA-07 must not solve sharing by sharing a phone, security key, OTP seed, recovery code, or another authenticator. Use AA-10 decision required and stop.

Use a 16-field vertical method-selection record

Use one vertical block per bounded scenario and candidate method. Do not use a wide table that hides fallback, accessibility, or evidence on a small screen.

1. Bounded scenario — the account class and business use; no real account identifier.
2. Internal decision owner — the role accountable for this decision; not automatic proof of competence or authority.
3. Non-secret service reference — an invented label or controlled non-secret reference; no username, tenant, endpoint, or device identifier.
4. Source checked and date — the primary provider document inspected and its date; not a hands-on claim.
5. Provider-supported method label — the wording shown in documentation; not a technical conclusion.
6. Authenticator or mechanism class — the documented mechanism; use Unknown — follow up rather than inference.
7. Hosting device or medium — the required device or medium and dependencies; never a real device identifier.
8. Local activation or user-verification role — how local activation relates to the authenticator; no PIN, biometric sample, template, or secret.
9. Phishing-resistance property and evidence basis — the property of the actual mechanism plus evidence and uncertainty; not a score.
10. Availability and platform dependencies — hardware, network, platform, synchronization, or provider constraints without product testing.
11. Accessibility and user constraints — an operational constraint stated without personal medical or identifying details.
12. Enrollment, replacement, and old-authenticator removal boundary — authority, safe-order assumption, and stop condition; no live instructions.
13. Fallback and account-recovery paths — non-secret path categories, downgrade, and authority; never codes, links, seeds, or values.
14. Continuity, backup, last-administrator, and escalation state — coverage, interruption risk, and escalation destination.
15. Decision, exception, residual risk, and completion evidence — the bounded choice, unresolved limits, expiry, and evidence actually inspected.
16. Expiry or review trigger — provider, method, device, recovery, role, accessibility, exception, or threat change that reopens the decision.

Useful states include Candidate, Selected for bounded scenario, Rejected for stated reason, Unknown — follow up, Blocked — provider behavior unverifiable, Blocked — accessibility gap, Blocked — last administrator, Exception — expiry required, AA-08 decision required, and AA-10 decision required. These are workflow states, not points, regulated assurance levels, certifications, or proof of security.

Fictional example — do not copy as a completed MFA decision

Example Co. is comparing two method families documented for the invented ExampleMail administrator scenario. No real provider, person, account, phone, device, credential, authenticator, recovery material, or hands-on result is represented.

1. Bounded scenario: ExampleMail administrator access — continuity-sensitive.
2. Internal decision owner: Operations lead; authority confirmation remains part of the decision evidence.
3. Non-secret service reference: ExampleMail — Scenario M-01.
4. Source checked and date: Invented primary-document reference D-01 — review date recorded; no real provider claim.
5. Provider-supported method label: Candidate A — cryptographic method family; Candidate B — manually entered OTP family.
6. Authenticator or mechanism class: Candidate A is documented in the fictional record as a qualifying cryptographic flow; Candidate B requires manual OTP entry. This is invented comparison data, not a product finding.
7. Hosting device or medium: Candidate A depends on supported hardware available to the administrator role; Candidate B depends on an approved authenticator host. No device is identified.
8. Local activation or user-verification role: Local activation required — value and biometric data not recorded; local activation is not treated as the remote mechanism.
9. Phishing-resistance property and evidence basis: Candidate A is Candidate — property requires primary evidence; Candidate B is Not phishing-resistant — manual OTP class. The example does not generalize from a marketing label.
10. Availability and platform dependencies: Candidate A’s spare-hardware availability is unresolved; Candidate B’s host replacement path is unresolved.
11. Accessibility and user constraints: Blocked — accessibility gap until an affected-role constraint can be met without recording personal details.
12. Enrollment, replacement, and old-authenticator removal boundary: Documentation/tabletop only; no enrollment or removal occurs; last viable access must remain available in any later authorized process.
13. Fallback and account-recovery paths: the fictional provider offers a weaker recovery category, recorded as Residual downgrade — method value not recorded; no code, link, seed, or recovery action appears.
14. Continuity, backup, last-administrator, and escalation state: Blocked — last administrator until backup authority and a non-secret continuity path are approved.
15. Decision, exception, residual risk, and completion evidence: no final selection; Candidate A remains preferred only for further evidence review, while accessibility, fallback, and last-administrator gaps remain open.
16. Expiry or review trigger: reopen when provider documentation, supported methods, fallback, recovery, administrator coverage, accessibility constraints, or evidence changes.

The example deliberately does not declare a winner. It demonstrates how a stronger primary property can remain unusable or incomplete when fallback, accessibility, and continuity are unresolved.

Know what completion means

A bounded decision is complete only when the real mechanism, evidence basis, effective fallback, accessibility and availability constraints, enrollment/replacement boundary, continuity ownership, residual risk, exception, completion evidence, and review trigger are recorded truthfully.

Completion does not prove the provider implements its documentation correctly, the selected method is universally best, recovery will work, endpoints are safe, users cannot be phished, or the account is secure. Review the decision whenever provider support, authenticator behavior, device availability, fallback, recovery, roles, accessibility constraints, business impact, or threat guidance changes.