2FA and MFA for systems analyst interviews

Why interviewers ask about 2FA

When a systems analyst loop reaches the security round, the interviewer wants you to reason about trust boundaries, phishing resistance, and recovery flows — not recite acronyms. The 2FA question is load-bearing because almost every product touches login: a banking app, an admin console, an OAuth-protected API, a B2B SaaS dashboard.

The trap candidates fall into is treating 2FA as a single concept. TOTP, SMS, push, and WebAuthn differ wildly in security properties, and the senior bar at companies like Stripe, Microsoft, or Google is describing the trade-offs in business terms: hardware cost, user friction, phishing-resistance, support load. Knowing the RFC numbers is decoration; knowing when to pick each method is the answer.

The three factor categories

Authentication factors fall into three categories you need to name explicitly in an interview.

The knowledge factor is something the user knows — a password, a PIN, a security question. It is the cheapest to deploy and the weakest in isolation, because it can be phished, reused across sites, or extracted from a breach dump.

The possession factor is something the user has — a phone with an authenticator app, a YubiKey, or a registered device with a private key in its secure enclave. This is where 2FA usually lives, because possession is hard to replicate and easy to verify cryptographically.

The inherence factor is something the user is — a fingerprint, a face scan, a voice pattern. In practice, biometrics on consumer devices (Face ID, Touch ID, Windows Hello) act as a local unlock for the possession factor, not as a network-transmitted credential. The server never sees the fingerprint, only the signed attestation.

By convention, 2FA = exactly two factors from different categories, MFA = two or more. A password plus a security question is not 2FA — both are knowledge.

TOTP — the workhorse

Time-based One-Time Passwords, defined by RFC 6238, are the default 2FA method for most consumer products. The server and the client share a secret (typically a 160-bit value, Base32-encoded into a QR code at enrollment). The client runs HMAC-SHA1 over the secret and the current Unix time divided by 30 seconds, then truncates the result to 6 digits.

T = floor(unix_time / 30)
TOTP = truncate(HMAC-SHA1(secret, T)) mod 10^6

Apps that implement this: Google Authenticator, Authy, 1Password, Microsoft Authenticator. The server accepts a small window (usually current ±1 step) to absorb clock skew.

TOTP is the workhorse because of cost: no SMS bill, no hardware, works offline, the secret never crosses the wire after enrollment. It is not the gold standard because TOTP codes are phishable — a fake login page can collect both the password and the code in real time and replay them in under 30 seconds.

SMS and email codes

SMS sends a 6-digit code over the cellular network; email codes do the same over SMTP. The upside is zero onboarding friction — every user already has a phone number or an email — and that lift in adoption is why SMS 2FA is still the default at most banks and consumer apps.

The downsides are documented well enough that NIST SP 800-63B deprecated SMS as a primary out-of-band authenticator. SIM-swap attacks let an attacker port the victim's number by social-engineering a carrier rep. SS7 protocol weaknesses let attackers intercept SMS without touching the victim's phone. Email accounts are themselves a recovery target — own the email, own every reset link sent to it.

"Would you ever use SMS 2FA today?" The defensible answer is yes — as a fallback or step-up for low-value operations on consumer accounts where TOTP adoption would tank your funnel. For an admin console or a treasury app, SMS belongs nowhere in the threat model.

Push approvals

Push-based 2FA — Duo, Okta Verify, Microsoft Authenticator's number-match flow — sends a notification to the user's registered device: "Approve sign-in from Seattle, WA?" The user taps Approve or Deny. From a UX standpoint this is the friendliest method: no code to type, no SMS to wait for, single tap.

The attack that broke push-based 2FA in production (notably at Uber in 2022) is MFA fatigue or push bombing. The attacker, already in possession of the password, fires push notifications repeatedly until the user taps Approve to make them stop. The fix is number matching: the login screen shows a 2-digit code that the user must select on their device, so a blind tap doesn't authenticate. Most enterprise IdPs enabled number matching by default in 2023.

Push also requires connectivity on the second device. If the user's phone is on airplane mode or roaming, the push doesn't arrive, and your support queue fills up with "I can't log in" tickets. This is also why every push deployment ships with a TOTP fallback enabled in the same app.

Hardware keys and WebAuthn

The current state of the art is WebAuthn (the W3C standard that powers passkeys and hardware security keys). At enrollment, the client generates a public/private keypair bound to the relying party's origin. The private key never leaves the secure element — on a YubiKey, an iPhone's Secure Enclave, an Android device's StrongBox, or a TPM on a Windows laptop. At login, the server sends a challenge; the client signs it with the private key after a local user gesture (touch, fingerprint, PIN), and the server verifies the signature against the registered public key.

Because the signature includes the origin, WebAuthn is phishing-resistant by construction. A fake g00gle.com login page cannot trick the key into signing for google.com — the browser refuses. This is the property neither TOTP nor SMS nor push can match.

The hardware key form factors are dominant in enterprise: YubiKey 5 series, Google Titan, Feitian. For consumers, platform authenticators built into the device do the same job for free — Face ID + Secure Enclave on iPhone, Windows Hello + TPM on PC. The trade-off is portability: a platform passkey is tied to that device family (synced via iCloud Keychain or Google Password Manager), while a roaming hardware key works on anything with a USB-C port.

Cost is the only real downside. YubiKeys run $30-70 per key plus shipping and re-issuance for losses, which is why most companies mandate hardware keys only for privileged accounts: admins, on-call engineers, finance, anyone with production access.

Backup codes and recovery

Every 2FA design ships with a recovery path or it doesn't ship at all. The standard pattern is single-use backup codes: generate 10 codes (typically 8-10 alphanumeric characters each) at enrollment, ask the user to download or print them, mark each as consumed when used. They sit in a desk drawer or a password manager and only come out when the primary factor is unrecoverable.

The alternative is "contact support to verify your identity", and the cost of that flow is the reason backup codes exist. A human-mediated reset is slow (24-72 hours at most companies), socially engineerable, and expensive to staff. A well-designed backup code flow cuts your account-recovery support tickets by an order of magnitude.

Two design questions to be ready for. First, storage: backup codes should be hashed at rest, just like passwords — never stored in plaintext, never logged. Second, rotation: when a user consumes a backup code, you should prompt them to regenerate the remaining set, because a partially-used set leaks information about how many lives the user has left.

Method comparison

A table to anchor the trade-offs you should have at the tip of your tongue.

The pattern that comes out of this table: phishing-resistance is binary, and WebAuthn is the only row where it's yes. For an admin or production-access account, that single column should override every other consideration.

Common pitfalls

When discussing 2FA in an interview, the most common pitfall is conflating 2FA with strong authentication. A password plus an SMS code is technically 2FA, but it is no longer considered strong against a motivated attacker who can SIM-swap or phish in real time. If you're designing auth for a fintech or a healthcare app, name the threat model explicitly: SIM-swap, phishing, credential stuffing, session hijack. Then map each factor to which threat it actually blocks.

A second pitfall is forgetting the enrollment flow is the weakest link. If a user can enroll a TOTP device by clicking a link in an email, the email account becomes the de-facto root of trust. Senior interviewers will probe this: "how do I add a YubiKey to my account?" The defensible answer requires step-up authentication at enrollment — verify the existing factors, and ideally re-enter the password — and an audit log entry that the user can review after the fact.

The third trap is treating recovery as an afterthought. Candidates spend twenty minutes describing the happy path and then wave their hands at "and if they lose their phone, support helps them". That's where social engineering attacks land. The fix is to design the recovery flow with the same rigor as the primary flow: documented identity proofing, rate limits, mandatory cool-down periods on sensitive changes, and an immutable audit trail.

A fourth pitfall, specific to push-based methods, is not rate-limiting prompts. The Uber-style push-bombing attack works precisely because the attacker can fire dozens of prompts in seconds. A cap of three prompts per hour with exponential backoff, plus number matching, plus an explicit deny-and-lock flow, makes the attack uneconomical. The same logic applies to storing TOTP secrets in plaintext — encrypt them at rest with a KMS-managed key, separate from the database, and rotate the encryption key on a schedule.

Related reading

• Authentication vs authorization for systems analyst interviews
• SQL injection and XSS for systems analyst interviews
• Case interview for systems analyst
• Systems analyst resume guide

If you want to drill systems-analyst interview questions like this every day, NAILDD is launching with hundreds of auth, system design, and SQL problems mapped to real loops.

FAQ

Is this article based on official specifications?

Yes. The technical claims here trace back to RFC 6238 for TOTP, the W3C WebAuthn Level 3 specification for passkeys and hardware keys, and NIST Special Publication 800-63B for authenticator assurance levels. If your interviewer wants citations, those three documents cover the full surface area of consumer 2FA.

What's the difference between 2FA and MFA in practice?

The terminology shift is mostly marketing. 2FA historically meant "password plus one other factor"; MFA is the broader term that allows two or more factors, often with adaptive logic (require an extra factor only when the risk score is high). In a 2026 interview, expect the interviewer to use them interchangeably and prepare to clarify which factors count as separate categories.

Are passkeys the same as WebAuthn?

Passkeys are a user-facing branding built on top of WebAuthn. Technically, a passkey is a discoverable, synced WebAuthn credential stored in a platform keychain (iCloud, Google Password Manager, 1Password). The underlying cryptographic protocol — public-key challenge/response, origin binding, attestation — is identical to a YubiKey. The difference is portability and recovery: passkeys sync across your devices, hardware keys do not.

What 2FA method should a new product ship with?

For a consumer product, ship TOTP and email-code fallback at launch, then add passkeys as the third option once you have iOS/Android coverage. For a B2B SaaS, ship SSO via the customer's IdP as the primary path, with TOTP and WebAuthn as backups for owner accounts that need to bootstrap the tenant. SMS as a primary factor in 2026 is a regression — defensible only when adoption requires it.

How do you handle 2FA for service accounts and API tokens?

Service accounts shouldn't use 2FA — they can't receive a push or type a code. The pattern is scoped, short-lived API tokens stored in a secrets manager, rotated automatically, with mutual TLS or OAuth client credentials for service-to-service traffic. Human and non-human authentication require entirely different primitives.

What if a user loses both their phone and their backup codes?

This is where the recovery design earns its keep. The standard escalation is a support-mediated identity proofing flow: government ID upload, video selfie, a 72-hour cool-down before the reset takes effect, and notifications to all the user's registered channels. The cool-down exists so a real owner who notices the recovery email has time to cancel before the attacker completes it.