Prompt and context
Your B2B SaaS suffered an administrator account takeover through phishing. Administrators can export customer data, change identity policies, and invite members. The team is considering mandatory passkeys or FIDO2 security keys but worries about migration cost, lost devices, and support volume.
Decide whether to mandate it, which users go first, how migration and recovery work, how exceptions expire, and how the business will prove security value. This is a product decision; do not start by choosing a vendor.
What the interviewer tests
The interviewer wants one decision that accounts for threat severity, affected users, reversibility, compliance commitments, and delivery cost. CISA advises organizations to move toward phishing-resistant MFA; NIST describes verifier name binding; OWASP recommends risk-based MFA or reauthentication for high-risk actions.
Strong candidates do not treat “force everyone today” as the only option. They tier administrators, create a safety baseline, design recovery, and use observed data to expand. They distinguish phishing-resistant methods from SMS and ordinary push, whose security and migration friction differ.
30-second answer
“I would move toward phishing-resistant MFA, starting with administrators ranked by privilege and exposure. Super-admins and data-export roles would first require a passkey or FIDO2 security key; other admins would receive a migration deadline. Before enforcement, I would test compatibility, second-authenticator registration, and recovery. Exceptions would be time-bound, least-privileged, approved, and monitored. I would measure account takeovers, phishing-resistant coverage, completion, support tickets, and high-risk-action blocks. If security value is clear and friction stays within guardrails, I would expand by role.”
Step-by-step analysis
Step 1: Define the decision and threat
Map administrator capabilities: reading customer data, exporting it, changing SSO, and inviting members have different impact. Establish a baseline from takeover events, attack paths, data sensitivity, and potential loss. The goal is a measurable reduction in high-impact takeover during a defined period.
Step 2: Compare authentication options
Phishing-resistant methods use verifier binding and public-key cryptography, so a fake site cannot easily obtain a reusable shared secret. Passkeys may rely on a platform or synced credential; security keys require hardware procurement and lifecycle management. SMS, knowledge questions, and ordinary email codes can be transitional or recovery methods, but should not be presented as equivalent protection.
Step 3: Segment users and privileges
Start with super-admins, billing and data-export admins, identity-policy admins, and high-privilege support tools. Read-only admins can receive migration tasks and risk education first. Privilege and reachable data are stronger prioritization signals than company size alone.
Step 4: Design migration and recovery
Collect browser, operating-system, and hardware compatibility data. Offer at least two enrollment paths and ask users to register a second authenticator or an organization-held security key. Lost devices require an audited recovery process approved by existing admins and business evidence; support must not become an unconditional reset backdoor.
Step 5: Handle exceptions and progressive enforcement
Define expiring exceptions for old devices, regions, or automation accounts. Bind each exception to least privilege, extra approval, a short validity period, and alerts. Progress from enrollment reminders, to challenges on risky actions, to restrictions on high-risk operations, and finally to login enforcement.
Step 6: Define outcomes and guardrails
Outcomes include administrator takeovers, phishing-resistant coverage, and high-risk-action blocks. Guardrails include enrollment completion, failure rate, recovery time, support volume, login conversion, and false-block rate. Segment by role, region, device, and customer size so averages do not hide a small group’s failure.
Step 7: Run a pilot with decision gates
Pilot with internal admins or willing customers and compare reminders, risky-action challenges, and forced enrollment. Do not expose a high-risk group to a long randomized experiment for conversion data; use pre/post baselines, staged rollout, and historical comparisons. Write expansion, pause, and rollback conditions before starting.
Step 8: Build long-term operations
Track authenticator enrollment, revocation, recovery, employee offboarding, and customer-admin changes. Product, support, security, and compliance should own the policy together. After a major incident, revisit segmentation, recovery evidence, and exception deadlines rather than adding another one-time prompt.
Trade-offs, boundaries, and information gain
Faster enforcement shortens exposure but increases compatibility and recovery pressure. Phased migration reduces interruption but requires monitoring through the transition. Passkeys can have less daily friction than hardware keys, while enterprises may need procurement, delivery, and offboarding controls.
Phishing-resistant MFA reduces credential capture by proxy sites; it cannot stop a malicious admin from authorizing an action and does not replace least privilege, approvals, anomaly detection, or export auditing. Automation accounts should use workload identity or short-lived credentials instead of a human login policy.
Model high-quality answer
“I would move forward with phishing-resistant MFA as a risk-tiered product program. First cover super-admins, data-export roles, and identity-policy roles because their takeover loss is highest. Passkeys and FIDO2 security keys can be target methods; SMS and ordinary push are explicitly labeled transitional or recovery options.
I would run an internal pilot to test platform compatibility, second-authenticator enrollment, and lost-device recovery. Then enforce in three stages: reminders and risky-action challenges, restrictions on high-risk actions before the deadline, and final enforcement. Exceptions need expiry, least privilege, approval, and alerting. Outcomes are takeover events, coverage, completion, and high-risk blocks; guardrails are recovery time, support volume, and false blocks. Expand only when preset security value and guardrails are met.”
Common mistakes
- Force every user on day one. Without compatibility and recovery rehearsals, this creates lockout incidents.
- Equate SMS, ordinary push, and phishing-resistant MFA. Their resistance to proxy phishing differs.
- Measure enrollment only. Coverage can rise while high-risk roles remain exempt.
- Skip a second authenticator and recovery evidence. Lost devices then force support backdoors.
- Make exceptions permanent. A growing exception list becomes the easiest attack path.
- Prioritize by customer size only. Privilege and data impact are more direct signals.
- Ignore automation accounts. Human MFA does not solve long-lived service credentials.
- Run a security experiment that exposes high-risk users. Protect pilot users and predefine stop conditions.
Follow-up questions and answers
Why not require SMS MFA for everyone first?
SMS improves baseline coverage but is not phishing-resistant. It can be a transition while high-privilege roles receive a firm migration deadline.
How do you prove enforcement did not harm the business?
Track outcomes and guardrails together: takeovers, high-risk blocks, and coverage should improve, while recovery time, tickets, and false blocks stay below thresholds. Segment results by role and region.
What if a customer refuses a second authenticator?
Make it a launch condition for high-privilege roles, offer an auditable organization recovery path, and give exceptions explicit expiry. Refusal should not become an unconditional support reset.
Do synced passkeys weaken security?
State the threat model and platform implementation rather than giving a universal answer. Extremely high-assurance roles may require hardware keys; most admins still need device management, revocation, and recovery controls.
When would you expand to ordinary admins?
After the high-privilege pilot reaches coverage, completion, and takeover-reduction goals with stable recovery and support guardrails. Expand by privilege and data impact, not by calendar alone.