Choose the Right MFA Factor — UprootSecurity Bootcamp

Knowing the technical properties of each MFA factor is necessary but not sufficient. A GRC Engineer must translate that knowledge into policy decisions for real organizations with real constraints — budget, user populations, device management capabilities, and varying risk profiles across different roles.

For each scenario below, choose the most appropriate MFA factor. Every scenario has one best answer, but the explanations walk through the tradeoffs and why the alternatives fall short. This is the kind of reasoning you will use when writing MFA policies, advising security teams, and evaluating whether an organization's MFA deployment matches its actual risk profile.

Scenario 1: Cloud infrastructure engineer

Quick check

A cloud infrastructure engineer manages production AWS accounts, including IAM roles with administrative access. They deploy infrastructure via Terraform and regularly access the AWS console for incident response. What MFA factor should be required for this role?

TOTP via an authenticator app — it is more secure than SMS and works offline

Push notification with number matching — good balance of security and usability

FIDO2 hardware key (e.g., YubiKey) — phishing-resistant MFA required for the highest-privilege accounts

SMS OTP — simple to deploy and the engineer always has their phone

Scenario 2: Shared workstation call center

Quick check

A 500-person call center where agents share workstations in shifts. Agents do not have company-issued phones. Personal phone use is restricted on the call floor for data protection reasons. Agents access a CRM system and an internal knowledge base. What MFA factor is most appropriate?

Push notification via personal phone — agents can keep their phones in a locker and check when needed

TOTP app on a shared tablet at each workstation — one device per station

FIDO2 hardware key — each agent carries their own key and taps it at any workstation to authenticate

SMS OTP to personal phone numbers — every agent has a personal phone

Scenario 3: Remote sales team

Quick check

A remote sales team of 40 people uses company-issued laptops. Their primary tools are Salesforce, email (Google Workspace), and Zoom. They work from home offices and coffee shops. They are not technical users. What MFA factor provides the best balance of security and usability?

FIDO2 hardware key — maximum security for any user population

Push notification with number matching — secure against MFA fatigue, intuitive for non-technical users, leverages the phone they already carry

SMS OTP — the simplest option that requires no app installation

TOTP via authenticator app — standard across all enterprise deployments

Scenario 4: Contractors with personal devices

Quick check

Your company hires 20 contractors for a 6-month project. They use personal laptops and personal phones. They need access to a project management tool (Asana) and a shared document repository (Google Drive folder). Your company does not manage their devices. What MFA factor is most practical?

FIDO2 hardware key — issue each contractor a YubiKey and collect it when the contract ends

Push notification — install Okta Verify on their personal phones

TOTP via authenticator app — no device management required, contractor installs any standards-compliant TOTP app on their own device

SMS OTP — just use their personal phone number, no app needed

Scenario 5: Frequently traveling CEO

Quick check

The CEO travels internationally 40% of the time, frequently loses phones, and needs access to email, financial dashboards, board documents, and the company's banking platform. They have an executive assistant who handles IT issues. What MFA strategy is most appropriate?

TOTP app — they can restore the app from backup when they get a new phone

SMS OTP — it works internationally on any phone and requires no setup

FIDO2 hardware key (two keys — one on keychain, one backup with executive assistant) plus passkeys synced to their Apple/Google account as a secondary method

Push notification — the CEO can approve from any device signed into the authenticator app

Scenario 6: Hospital shared tablets

Quick check

Nurses at a hospital access electronic health records (EHR) on shared tablets throughout their shift. They move between patient rooms every 10-15 minutes and need to authenticate at each tablet. They carry personal phones and hospital ID badges. Access to patient records is regulated under HIPAA. What MFA approach works best?

FIDO2 hardware key — nurses tap a YubiKey at each tablet for maximum security

TOTP app — nurses type a code each time they access a new tablet

Push notification to personal phone — nurses approve a push each time they access a new tablet, balancing security and speed for frequent re-authentication

SMS OTP — simple and works on any phone

Scenario 7: Developer with CI/CD access

Quick check

A developer on the platform engineering team accesses GitHub repositories containing application source code, the CI/CD pipeline (GitHub Actions), and a secrets manager (HashiCorp Vault). They sign commits with their GPG key. Compromise of their account could allow an attacker to inject malicious code into production deployments. What MFA factor should be required?

TOTP app — standard for developer tooling and works with GitHub

Push notification with number matching — good usability for frequent authentication

SMS OTP — in case the developer is traveling and cannot access their authenticator app

FIDO2 hardware key or passkey — phishing-resistant MFA for access to the software supply chain

Scenario 8: Manufacturing floor kiosk

Quick check

A manufacturing plant has a shared kiosk on the factory floor where production workers log safety incidents, check shift schedules, and view standard operating procedures. Workers do not carry personal phones on the floor (safety policy). The kiosk is in a physically secured area that requires badge access to enter. The data on the kiosk is operational, not sensitive. What authentication approach is most appropriate?

FIDO2 hardware key — each worker carries a YubiKey on their lanyard

Badge tap plus PIN — workers use their existing facility badge (something they have) and enter a personal PIN (something they know) at the kiosk

TOTP app on a phone — workers check their phones in the break room and retrieve codes

No MFA required — the physical badge access to the area is sufficient

How to use this reasoning in practice

The eight scenarios above represent the real decision space you will navigate as a GRC Engineer. The right MFA factor is never universal — it depends on four variables:

Risk profile of the account — What can an attacker do if they compromise this identity? The higher the blast radius, the stronger the factor required.
User population characteristics — Are they technical or non-technical? Do they have company devices or personal devices? How frequently do they authenticate?
Operational constraints — Can they carry phones? Are they at shared workstations? Do they work in physically restricted environments?
Deployment feasibility — Can you distribute and manage hardware keys? Is there an MDM for push notification apps? What is the help desk capacity for MFA support?

A well-written MFA policy does not mandate one factor for the entire organization. It tiers the requirements: phishing-resistant MFA for privileged and high-risk accounts, strong MFA (push with number matching or TOTP) for the general workforce, and practical MFA for constrained environments where the alternative to a pragmatic choice is no MFA at all.

Document the rationale for each tier. When an auditor asks why the call center uses hardware keys but the sales team uses push, the answer should be a risk-based justification, not "that is what IT picked." That risk-based justification — written by you, the GRC Engineer — is what turns a collection of MFA configurations into a defensible, auditable security program.