DoorDash Security Architect Interview Preparation Guide - Junior Level

Authentication answers "who is calling?" and happens once, at the start of a request. Authorization answers "what is this caller allowed to do?" and gets checked on every action the caller attempts, even after authentication succeeds. In an API, a request must clear both gates, in that order, before it returns data.

Two ways to authenticate

JSON Web Token (JWT) bearer tokens. The server issues a signed token containing claims (who the user is, when it expires, sometimes their role). The client sends it as Authorization: Bearer <token>, and the server verifies the signature and expiry locally, without a database lookup. This is appropriate for stateless APIs and microservices where low latency and easy horizontal scaling matter more than instant revocation, for example a mobile app calling your own backend.

OAuth 2.0 Authorization Code flow. A standardized way for one application to get delegated access to a user's resources on another service, without ever seeing the user's password. The user is redirected to the authorization server's login page, authenticates there, and the calling app receives a short-lived code it exchanges (server-side) for an access token. This is appropriate when a third-party app needs to act on a user's behalf, for example a scheduling tool asking to read someone's calendar on a different platform.

Two ways to authorize

Role-Based Access Control (RBAC). Users are assigned roles, and roles carry a fixed set of permissions. It is simple to reason about and easy to audit ("who has the admin role?"). Appropriate for systems where permissions map cleanly onto job functions, for example an internal content tool with admin, editor, and viewer roles.

Attribute-Based Access Control (ABAC). The decision is computed from attributes of the user, the resource, the action, and the environment, evaluated against a policy at request time. Appropriate when access depends on runtime context a role alone can't express, for example "an employee may view a customer record only if that customer is in their assigned region."

Worked example

Request: GET /api/invoices/482 with a bearer JWT.

1. Authentication: the API verifies the JWT's signature against the issuer's public key and checks exp (the expiry timestamp). If either check fails, the response is 401 Unauthorized and processing stops here. If both pass, the caller's identity is established, say sub: "user_9fa2", role: "billing_viewer".
2. Authorization under RBAC: role billing_viewer carries the permission invoice:read. A naive RBAC check only asks "does this role have invoice:read?" and answers yes, it never asks whether invoice 482 actually belongs to user_9fa2.
3. Authorization under ABAC: the policy instead evaluates action == "read" AND resource.owner_id == subject.customer_id. If invoice 482 belongs to a different customer, resource.owner_id != subject.customer_id, and the policy returns deny, 403 Forbidden, even though the same user's billing_viewer role would pass a plain RBAC check.

This is the concrete difference between "can this role read invoices in general" (RBAC) and "can this specific caller read this specific invoice, right now" (ABAC).

Trade-offs and pitfalls

A common mistake is treating a passed authentication check as if it were also an authorization decision, that gap is exactly how broken-authorization bugs happen. RBAC is cheap to evaluate and simple to audit, but it is coarse: it cannot express "only your own records" without an added object-level check. ABAC is expressive enough to capture exactly that, but policies are harder to test exhaustively and can hide the real rule set inside a policy engine instead of a readable role list. Many production systems use both: RBAC for coarse feature access, ABAC (or a simpler ownership check) layered on top for record-level ownership.

Direct answer. A foundation model is a large general-purpose model trained by a vendor (for example, a large language model) that you build on. I would tell the regulator exactly what we can evidence (our use case, inputs, wrapper logic, tests, monitoring and oversight), what the vendor can evidence (documentation and assurances), and what neither of us can show (the training data itself). Then I would put in compensating measures that test the model's behavior from the outside, and share sensitive material through controlled review rather than handing it over or pretending it does not exist.

1. What we provide

• Our system: purpose, inputs and prompts, decision logic around the model (the wrapper logic: our own code that prepares inputs, calls the model and handles its outputs), output handling, human review points, and logs.
• Our own evaluation of the model on our data: accuracy, error patterns and fairness checks, with versions and reproducible runs.
• Vendor material: model or system card (the vendor's document describing what the model is for, how it was tested and its limits), published training-data summary or policy if one exists, security and assurance reports (independent audit reports about the vendor, such as a SOC 2 report), contract terms on data use.
• A gap register listing each regulator question we cannot answer from first-hand evidence and why. Example row (illustrative): Question: "Was the training data screened for personal data?" | Evidence we hold: vendor's published data summary | Missing: the data itself | Measure: output testing for personal-data leakage | Owner: security lead | Review date: next model version.

2. Compensating measures
A compensating control is a different safeguard that reduces the same risk when the ideal control is unavailable.

3. Protect IP and stay honest
Share through NDAs, a supervised review room, and summaries or hashes in place of source, weights or prompts. A hash is a fingerprint of a file: it reveals nothing practical about a large, high-entropy file such as model weights (a short or guessable text such as a one-line prompt could be confirmed by someone who guesses it, so do not rely on a hash to hide short secrets), but it lets the regulator confirm later that the file they review in the supervised room is the same one we fingerprinted today. Review of the contents themselves happens in the supervised room. Never answer a question with a statement we cannot back, such as saying the data was checked for bias when we only tested outputs. Say "we cannot verify this, here is what we do instead". Counsel decides what legal obligations the vendor has to the regulator and how to word disclosures.

What changes my call. If the use is high-impact and no compensating measure gives adequate confidence, the honest recommendation is to switch vendors or add a human decision step before shipping.

Direct answer. I would create a policy management lifecycle with a clear owner, a standard template, a defined approval path, a single published location and scheduled reviews. For about 10,000 people, the key is a central inventory and governance so each policy has one current version and one accountable owner, with authoring delegated to subject-matter experts.

Roles

• Policy program owner (often in the security or GRC team; GRC means governance, risk and compliance): runs the process, template and inventory.
• Policy owner: an executive or senior leader accountable for each policy's content and currency.
• Author: the subject-matter expert who drafts it.
• Policy committee: a cross-functional group (security, legal, HR, IT, engineering, privacy) that reviews and challenges.
• Approver: the executive authority for that tier of document.

Lifecycle

1. Intake and justification: a request says what risk, law or contract drives the need, and checks it is not already covered.
2. Draft on a standard template (purpose, scope, statements, roles, exceptions, related documents, owner, version).
3. Review: stakeholder comments, legal check, and a feasibility check with the teams who must follow it.
4. Approve per the approval matrix, and record the decision.
5. Publish to one authoritative location (an intranet policy hub), with version number and effective date; communicate to the affected groups.
6. Train and implement where needed, and map to standards and procedures.
7. Monitor adherence and exceptions.
8. Review and update annually or on a trigger; or retire and archive.

Fixing the starting mess first. Inventory every existing policy (who wrote it, last update, whether people use it). Triage: keep, merge, update or retire. Assign an owner to each policy you keep; any policy without an owner is flagged. Use the policy hub as the only official source so people stop relying on copies in email or drives.

What I would measure. Percentage of policies with a named owner and a review date; percentage past review date; time from request to publication; number of duplicate or conflicting policies found.

Scaling to 10,000 people. Tier the documents so only company-wide policies need executive approval, while team-level procedures use lightweight owner approval. Use a policy management tool or a well-controlled repository with workflow, so reminders and version history are automatic.

Illustrative approval matrix (tiers, not a mandate).

Triage worked example (illustrative figures). Suppose the inventory finds 120 documents. Sorting them with four questions (is anyone using it, is it current, does it overlap another, does it have an owner) might give 50 keep, 30 merge into 12 documents, 25 update, 15 retire, which is 50 + 30 + 25 + 15 = 120 and leaves 50 + 12 + 25 = 87 live documents. Start the review queue with the policies tied to legal or customer obligations, then the most-read ones.

First 90 days. Month 1: inventory, template, owner assignment and the single hub. Month 2: triage and the approval matrix, with the committee meeting on a fixed cadence. Month 3: first review batch published, metrics reported. Urgent policies use a short emergency path (CISO and legal approve an interim directive, the committee ratifies it afterwards) so people are not tempted to bypass the process.

Offices in several countries. Keep one global policy and add a short local addendum owned by local legal where a law differs, rather than forking the policy.

Pitfall. A heavy process that makes people write policies outside it. Keep it fast enough that going through the process is easier than avoiding it.

Direct answer

Fifty AWS accounts with inconsistent field names and occasional missing fields need a normalization layer that treats schema variation as an ONGOING, monitored condition rather than a one-time mapping exercise, since the accounts' own customizations will keep drifting after initial onboarding, and detection rules need explicit fallback logic so a missing field degrades a rule's confidence gracefully rather than silently breaking it.

Structured elaboration

Schema mapping: build a canonical field-mapping table per account (or per account TYPE, where accounts share a common provisioning template) translating each account's actual observed field names into the organization's normalized schema, rather than assuming a single fixed mapping applies uniformly across all 50.

Schema registry/versioning: track each account's mapping as a VERSIONED artifact, since an account's schema can itself change over time (a new service enabled, a logging configuration updated); a registry lets the pipeline know explicitly which mapping version applies to which account at which point in time, rather than assuming a static, one-time mapping stays correct indefinitely.

Field enrichment: after normalization, apply the same enrichment layer uniformly across all 50 accounts' now-normalized data, so enrichment logic does not need its own per-account special-casing on top of the schema-mapping layer's own complexity.

Fallback signatures for missing fields: for a detection rule that depends on a field missing from a specific account's schema variant, define an explicit FALLBACK behavior rather than letting the rule silently fail to evaluate: either substitute a lower-confidence proxy signal derived from other available fields, or explicitly flag that account's coverage for this specific rule as degraded, surfaced on a coverage dashboard rather than silently and invisibly absent.

Monitoring for schema drift: run an automated, periodic check comparing each account's currently-observed field set against its registered mapping, flagging any account where the actual incoming data no longer matches its registered schema, the earliest, cheapest point to catch drift, well before it manifests as a mysteriously broken detection rule discovered during an investigation.

Deployment strategy for normalization rules: deploy a new or updated mapping to a small subset of accounts first (a canary group), validate correct normalization against real data, then roll out broadly, applied here to normalization-layer changes specifically.

Worked example

A specific schema-drift scenario: Account 23's mapping was registered assuming a specific field name for the acting IAM principal, correct at onboarding time. Six months later, that account's team enables a new logging integration that changes how principal identity is represented in a subset of its events, silently breaking the previously-correct mapping for those specific event types. The schema-drift monitoring check (comparing observed fields against the registered mapping) flags Account 23 within its next scheduled comparison run, well before an analyst discovers, mid-investigation, that a correlation rule silently stopped matching events from this specific account months earlier. The account's mapping is updated to a new registry version reflecting the changed field, deployed first to a canary subset of Account 23's own traffic to confirm the fix, then rolled out fully, and the drift-monitoring dashboard's flag for Account 23 clears once the corrected mapping is confirmed producing consistent, expected normalized output again.

Trade-offs and pitfalls

• Common mistake: building the initial 50-account mapping carefully but with no ongoing drift-monitoring mechanism; the worked example's whole point is that a mapping correct AT ONBOARDING silently degrades as individual accounts' own configurations evolve independently, and without monitoring, this degradation is invisible until a detection rule's absence is discovered the hard way.
• Common mistake: letting a missing field cause a rule to silently fail closed (never evaluating, producing no output and no visible symptom) rather than explicitly flagging that account's coverage as degraded; the former looks identical to "nothing suspicious happened" from an analyst's perspective, while the latter at least surfaces the gap as a known, trackable condition.
• Per-account-type mapping templates reduce the maintenance burden significantly versus fully bespoke per-account mappings: many of the 50 accounts likely share a common provisioning template (accounts created via the same account-vending process tend to start with similar configurations), and grouping the mapping by TYPE rather than maintaining 50 fully independent mappings meaningfully reduces both the initial build effort and the ongoing drift-monitoring surface area.
• This is a distinct, harder problem than a single-account or greenfield cloud-telemetry-ingestion design: this answer's distinguishing content is specifically the ONGOING schema-consistency problem that emerges once many independently-managed accounts are involved, a genuinely different and harder operational challenge than initial ingestion design alone.

Approach (one-line)
Prioritize signals that validate identity, configuration, vulnerabilities, supply-chain integrity, and runtime behavior—collect them centrally (SIEM/observability) and map to risk scoring.

Key telemetry categories & examples

• Asset inventory (high priority)

  • Vendor-supplied SBOMs, hardware/software manifests, cloud account IDs, exposed services.
  • Why: baseline for what to monitor and patch.

• Vulnerability feeds (high priority)

  • CVE alerts, vendor security advisories, proof-of-concept exploit indicators, patch release dates.
  • Why: direct input to exposure and remediation SLAs.

• CI/CD pipeline signals (high priority)

  • Build provenance, commit hashes, code-signing results, dependency scanning output (SCA), pipeline run failures, artifact store checksums.
  • Why: detects introduction of malicious or vulnerable code early.

• Audit reports & attestations (medium priority)

  • SOC2/ISO reports, penetration test summaries, contractual security attestations, SLA compliance metrics.
  • Why: periodic assurance of controls and contractual obligations.

• Runtime logs & telemetry (high priority)

  • Authentication logs, anomalous API calls, container runtime events, network flow logs, EDR alerts, telemetry from vendor appliances.
  • Why: detects active compromise or misconfiguration.

Implementation notes

• Ingest into SIEM/UEBA, normalize, correlate (e.g., SBOM entry + CVE + unusual outbound traffic → elevated risk).
• Map signals to a continuous risk score and trigger automated remediation or escalation playbooks.
• High-priority: asset inventory, vuln feeds, CI/CD signals, runtime logs — these give timely, actionable risk indicators. Audit reports and attestations inform governance and acceptance decisions but are less real-time.

Direct answer

Contain based on where the attacker currently has the most leverage while scoping the full chain of hosts and accounts touched, remove every persistence mechanism across every affected platform (not just the one you found first), and only declare the incident closed once you've validated the attacker genuinely cannot re-establish access.

Structured elaboration

Prioritized containment with trade-offs. Early containment options include isolating the initial-access host, disabling the escalated-privilege account, or blocking the exfiltration destination; each has a different cost and speed. Disabling the compromised privileged account is usually fast and high-value since it removes the attacker's current leverage across everything that account can reach, while isolating individual hosts one at a time is slower and risks leaving other, undiscovered footholds active while you work through the list.

Scoping which hosts and accounts are affected. Living-off-the-land techniques (using built-in, legitimate system tools rather than custom malware) are specifically designed to blend in, so scoping requires correlating multiple weak signals rather than looking for one obvious indicator: unusual process parent-child relationships, authentication logs showing the escalated account's activity across hosts it doesn't normally touch, and network connections inconsistent with that host's normal baseline. Where lateral movement specifically uses SMB (moving between hosts via file-sharing protocols), look for unusual SMB session patterns between hosts that don't normally communicate directly.

Structured impact analysis. Work through initial-access vector (how did they get in), propagation mechanism (how did they move from there to everywhere else), and ultimate impact (what did they actually reach or take), in that order, since understanding propagation tells you where else to look for persistence, and understanding impact tells you what needs remediation versus what was merely reachable but untouched.

Removing cross-platform persistence. Living-off-the-land and custom-loader techniques often plant persistence across multiple mechanisms and platforms (a scheduled task on one host, a modified startup script on another, a backdoored account with unusual privileges), so eradication needs a checklist covering every platform in scope, not just the specific technique first discovered.

Validation before declaring closure. Confirm the attacker cannot re-establish access by checking that every credential they touched has been rotated, every persistence mechanism found has been removed and re-checked, and monitoring shows no further activity matching the original indicators over a meaningful observation window, not just the first quiet hour.

Worked example

An intrusion begins with a phishing email leading to initial access, followed by privilege escalation to a domain-level service account, lateral movement across a dozen hosts using SMB and a custom loader disguised as a legitimate process, and staged exfiltration to an external cloud bucket. Containment: the escalated service account is disabled first (fastest, highest-leverage action), followed by isolating the specific hosts showing the custom loader's process signature. Scoping: correlating authentication logs for the escalated account against SMB session logs reveals the full set of twelve affected hosts, more than the four initially suspected from EDR alerts alone. Persistence removal: the team finds scheduled tasks on Windows hosts and a modified cron entry on the two Linux hosts in scope, both removed and validated absent. Closure: the incident is only declared resolved after two weeks of clean monitoring specifically watching for the loader's known signature and the escalated account's original access pattern, not just the first 48 hours.

Trade-offs and pitfalls

Declaring victory after finding and removing the first persistence mechanism, without checking whether the attacker planted a second one on a different platform as a fallback, is a common and costly gap in multi-stage intrusions; sophisticated attackers frequently plant redundant persistence specifically anticipating that defenders will find and remove the first one. Underinvesting in the propagation-mechanism analysis (jumping straight from initial access to impact) also risks missing hosts the attacker reached that show no obvious damage yet but still carry a live persistence mechanism.

Direct answer. I would run two separate paths with different speed and authority. Exceptions are about accepting risk, so they need approval by the person who owns the risk, scaled by residual score (the risk left after compensating controls, which are alternative safeguards used when the standard control cannot be met). Incidents are about containing harm, so the on-call person in the affected region gets authority to act immediately and escalation follows severity.

Path 1: security exception. A request states what control is waived, why, compensating controls, owner and an expiry. Score it as likelihood x impact on 1-5 scales (1-25, illustrative bands). Worked example: a team cannot enforce multi-factor authentication on a legacy admin console. Unmitigated, likelihood 4 x impact 4 = 16. As a compensating control, admins may reach it only through a jump host (a hardened intermediate server) with all sessions logged, which lowers likelihood to 2, so the residual score is 2 x 4 = 8 and the security manager can approve it with a 90-day expiry, with the team's business owner accepting the residual risk.

Rules: expiry at most 90 days, renewal needs fresh approval, and a policy cannot waive a legal duty (those go to legal). Objective escalation triggers, regardless of score: potential financial loss above a threshold set by risk appetite (how much loss leadership is willing to take on, for example $250k in a year, illustrative), regulated data involved, or customer impact above a set count. Required record: ID, requester, score, compensating controls, approver, expiry.

Path 2: serious incident in another region.

• Regional on-call may contain at once (isolate systems, revoke credentials) without waiting for headquarters.
• Severity 1 (the highest incident level, for example confirmed customer data exposure or a full outage): acknowledge in 15 minutes, name an incident commander (the one person who runs the response and makes calls) in 30, notify executives within 1 hour.
• Customer and regulator notices need legal plus CISO. Under GDPR Article 33 the 72 hours run from becoming aware: aware Friday 17:00 means notice by Monday 17:00 (whether notification is required is counsel's call).
• If an approver misses the response time, the request auto-escalates to the next tier or a named deputy.

Testing that the paths work.

• Unannounced page drill each quarter, outside office hours, measuring time to acknowledge against the 15-minute target.
• Tabletop exercise (a talked-through scenario with no systems touched) for a cross-region incident, including a missing approver.
• Exception audit: test exceptions for correct approver, expiry and compensating-control evidence: all of them when there are fewer than 25 active, and when there are 25 or more, every exception scored 9 or above plus a random sample of at least 10 of the rest (illustrative rule; the point is that high-score exceptions are never sampled out); submit a synthetic request to time the response.
• Fix gaps and re-test.

Trade-off. Giving regions containment authority risks over-reaction; I accept that, because delay costs more.

Definition
Data classification is the process of categorizing data by sensitivity and business value (e.g., Public, Internal, Confidential, Restricted) to drive protection, handling, and lifecycle decisions.

Ownership & Governance

• Data owners: business unit leads (accountable for classification decisions).
• Data stewards: implementers (cataloguing, tagging).
• Central Data Governance Board: policy, taxonomy, exceptions approval, periodic reviews.

Mapping classifications → controls

• Public: no encryption required, standard retention.
• Internal: at-rest encryption, role-based access.
• Confidential: strong encryption (TLS + AES-256 at rest), MFA, DLP, stricter retention and audit.
• Restricted: HSM-managed keys, strict separation of duties, limited retention, privileged access logging.

Enforcement points

• API gateway: validate classification headers, inject policy decisions, deny/transform requests.
• Storage: metadata tags, encryption policies enforced by CSP IAM, automated quarantine.
• Messaging/Queue: end-to-end encryption, tag-based routing, redaction for lower tiers.
• Endpoint & DLP: prevent exfiltration, enforce watermarking.

Reclassification & Exceptions

• Reclassification flow: request → impact assessment by owner/steward → update metadata, propagate to controls, re-encrypt/retag if needed → audit log.
• Exceptions: time-boxed approvals by Governance Board with compensating controls (additional monitoring, segmentation), logged and reviewed.

Operational practices

• Automate tagging, scanning, and policy enforcement; integrate classification into CI/CD, data discovery, and IAM. Measure via coverage, incidents, and audit findings.

Overview / goals
Design a HIPAA-compliant multi-cloud architecture (AWS + Azure + GCP) that protects ePHI, enforces least privilege, provides auditable trails, contractual BAAs, secure backups, and demonstrates continuous compliance and breach readiness.

High-level architecture

• Separate tenants: VPC/VNet per environment; transit via encrypted interconnects (AWS Transit Gateway, Azure VNet Peering, interconnect/VPN).
• Dedicated sensitive workloads run in isolated accounts/projects with strict network ACLs and DMZs; non-ePHI services in separate compartments.

Identity federation & RBAC

• Central IdP (enterprise IdP: Okta or Azure AD) as source of truth; SAML/OIDC to cloud providers for short-lived credentials.
• Enforce MFA, device posture (ZD), conditional access policies.
• Implement attribute-based access control (ABAC) + role-based groups; map IdP groups to cloud IAM roles with least privilege and just-in-time elevation via AWS STS / Azure PIM / GCP IAM Conditions.

Encryption

• In transit: TLS 1.2+ with HSTS; mutual TLS for service-to-service where possible; VPN/IPsec for inter-cloud links.
• At rest: Customer-managed keys (CMKs) in each cloud KMS (AWS KMS, Azure Key Vault, Cloud KMS) with HSM-backed keys (FIPS 140-2/3). Enforce envelope encryption for databases, object storage, backups.
• Key lifecycle: key rotation policies, split knowledge for key administrators, centralized key policy orchestration, and audit logs of key usage.

Audit trails & monitoring

• Centralize logs to immutable, tamper-evident logging pipeline (CloudWatch/CloudTrail + Azure Monitor + GCP Audit Logs -> SIEM such as Splunk/QRadar / Elastic with WORM storage).
• Ensure logs include access to ePHI, key usage, admin actions; implement log integrity (hash chain) and 3-year retention by HIPAA risk assessment.
• Real-time detection: EDR, CSPM, CASB, cloud-native guardrails, and SOAR playbooks for automated containment.

BAAs & contractual controls

• Execute BAAs with each cloud provider and any third-party vendor handling ePHI before production use.
• Maintain vendor inventory, data flow diagrams, and proof of BAA coverage in compliance repository.

Secure backups & DR

• Encrypted, immutable backups stored in separate accounts/regions with cross-account replication; use object lock/WORM and retention policies.
• Perform periodic backup restores and runbook drills; test RTO/RPO per SLA.

Continuous compliance & demonstration

• Automated compliance-as-code: Terrascan/Cloud Custodian + IaC scanning + policy enforcement in pipelines.
• Evidence collection: automated attestations (config snapshots, access reports, key rotation logs), runbook of controls mapped to HIPAA administrative, physical, technical safeguards.
• Provide auditors a read-only portal with evidence bundles, SOC2 reports, BAAs, and access to redacted logs. Regular third-party penetration tests and annual risk assessments; publish summary reports to customers.

Breach readiness

• Incident response plan with defined roles, playbooks, breach notification timelines aligned to HIPAA Breach Rule.
• Tabletop exercises quarterly; tabletop outputs feed improvements.
• Forensics: preserve immutable snapshots, forensic logs, centralized chain-of-custody procedures; run legal/Risk communications templates.

Trade-offs

• CMKs per cloud increases operational overhead but reduces blast radius; cross-cloud KMS federation is possible but adds complexity.
• Immutable backups increase cost; balance via SLA-driven retention.

I would present architecture diagrams, sample IAM policies, evidence bundles, and a live demo of log-to-SIEM search and a mock incident drill to auditors/customers.

Direct answer

The four common multi-factor authentication (MFA, proving identity with more than one independent factor) methods trade off along the same two axes: how resistant the method is to phishing, and how much friction and cost it adds. Time-based one-time password (TOTP) apps and hardware-backed passkeys (WebAuthn/FIDO2) sit at the strong end, SMS one-time passwords sit at the weak end because the delivery channel itself can be hijacked independent of anything the user does wrong, and push-based approval sits in between: easy to use, but vulnerable to a specific social-engineering pattern (repeatedly prompting the user until they tap approve by habit or fatigue) that neither of the code-based methods share.

Structured elaboration

Why the phishing-resistance ranking holds. SMS and TOTP both ultimately depend on the user (or an attacker impersonating the site) having a code that a phishing page can capture and immediately relay to the real site in real time (an adversary-in-the-middle relay); TOTP is still meaningfully better than SMS because it removes the telecom-layer interception risk (SIM swapping, network-level interception) that has nothing to do with the user's own behavior at all. Push notifications remove the "type a code" step but introduce a different failure mode: repeated, low-friction approval prompts that a user can eventually tap through without reading. WebAuthn is qualitatively different, not just incrementally better, because the cryptographic protocol itself checks the requesting site's origin before it will produce a valid signature, so the phishing page cannot obtain a usable credential regardless of how convincing it looks to the human.

When to choose or avoid each, for a user-facing application. TOTP is a strong, low-cost default for a broad consumer audience: free to implement, no telecom dependency, and meaningfully better than SMS for a modest amount of added friction. SMS OTP should be avoided as the only factor for anything of real value; it is best reserved for a recovery or fallback path for users without a smartphone, not the primary method, since its weaknesses live in infrastructure the application does not control. Push-based approval fits an enterprise or internal workforce application where the user population is known and already carries a managed device; it should be paired with a context check (showing the requesting device, location, or a number the user must match, rather than a bare "approve or deny" prompt) specifically to blunt prompt-bombing. Hardware-backed WebAuthn is the right default for privileged or high-value accounts (administrators, executives, anyone likely to be individually targeted), where phishing resistance matters enough to justify the enrollment friction and hardware cost, even if it is not yet practical to require for every user in a large consumer base on day one.

Worked example

A consumer web application decides its MFA policy by user tier rather than one policy for everyone: ordinary users are offered TOTP as the default second factor (cheap to support, meaningfully better than nothing, and better than SMS) with SMS OTP available only as an account-recovery fallback for a user who cannot install an authenticator app. Administrative accounts with access to production data or billing are required to enroll a hardware-backed WebAuthn key, since those accounts are the ones most likely to be individually targeted with a convincing spear-phishing attempt, and the origin-binding property of WebAuthn is what actually stops that attack, not merely the account holder's own vigilance. Internal support staff, who already carry a company-managed phone, use push-based approval with number matching (the login page displays a two-digit number the user must enter into the push prompt), specifically to close the fatigue-attack path a bare "approve/deny" prompt would leave open.

Trade-offs and pitfalls

The recurring pitfall is treating "we require MFA" as a single fact rather than a spectrum: an application that lets every account, including administrators, satisfy MFA with SMS alone has not meaningfully raised the bar against a targeted attacker willing to attempt a SIM swap, even though it can honestly claim MFA is enabled. A second pitfall is deploying push-based approval without any context or number-matching step; a bare approve/deny prompt is exactly what makes prompt-bombing effective, since the user has no information to distinguish a legitimate login attempt from an attacker's repeated requests. A third pitfall is over-indexing on WebAuthn's security strength while under-investing in its recovery flow: a user whose only hardware key is lost or broken needs a well-designed, equally secure recovery path, or the strongest method in the table becomes the one most likely to lock a legitimate user out.

Design note: cloud console access versus service identities. The comparison above assumes a human is present to complete an interactive challenge. That assumption does not hold for automated API calls made by a service identity (a machine or workload credential, not a person), which cannot tap a push prompt or read a TOTP code. The right policy split is to require MFA, ideally hardware-backed, for interactive console access by human administrators, while protecting service identities through mechanisms built for non-interactive use instead: short-lived, automatically rotated credentials, or workload identity federation that lets a service prove who it is without a standing long-lived secret at all. Treating "no interactive MFA" as a gap to fill with a weaker human-facing method (like requiring a service account to somehow "complete" SMS OTP) is the wrong instinct; the equivalent protection for a service identity is a fundamentally different, non-interactive credential lifecycle.