Passwords vs. Passkeys vs. MFA: How CVS Health Cut Account Takeover Fraud by 98%

Passwords vs. Passkeys vs. MFA: How CVS Health Cut Account Takeover Fraud by 98%

CVS Health rolled out passkeys across its platform and measured a 98% reduction in account takeover fraud. Around the same time, Microsoft ran a large-scale measurement study across Azure Active Directory accounts and found that simply turning on multi-factor authentication reduced the risk of account compromise by 99.22%, even when the user's password had already leaked. Two different companies, two different authentication strategies, both converging on the same conclusion: whatever you're doing with passwords alone, it isn't enough, and the fix isn't a stronger password policy.

These numbers point at a genuine shift happening in how backend and security engineers think about authentication. Passwords aren't disappearing overnight, but understanding exactly what a password alone can't protect against, and what passkeys and MFA each add on top of it, is quickly becoming a baseline expectation for anyone building or securing a login flow. This guide breaks down what each approach actually does, where these real numbers come from, and how they fit together, because the honest answer here isn't "pick one."

If auth fundamentals like hashing and tokens are still new ground, our Auth & Identity course covers what this comparison builds on.

This post originally appeared on the Ciphemic Academia blog.

The Short Version

• Passwords are a shared secret the user memorizes and the server verifies, typically against a hashed value. Simple, universal, and the weakest link in nearly every account takeover.
• Passkeys are a cryptographic key pair, generated and stored on the user's device, that replace the password entirely using the FIDO2/WebAuthn standard, phishing-resistant by design.
• MFA (multi-factor authentication) adds a second proof of identity on top of whatever the first factor is, typically a code, a push notification, or a hardware key, specifically to catch the cases where the first factor alone fails.

If you want one default: don't treat this as a single choice. Passkeys are the strongest long-term direction for the first factor itself. MFA remains essential wherever passwords are still in use, and ideally even alongside passkeys for your most sensitive accounts.

What All Three Are Actually Trying to Solve

Before the differences, the shared goal, since it's easy to lose in a "passwords vs. passkeys" framing:

• Proving identity: every approach exists to answer "is this really the account owner?" before granting access
• Resisting theft: a credential that can be stolen, guessed, or phished is a real liability, regardless of how it's implemented
• Staying usable: an authentication method nobody can actually use correctly gets worked around, which is its own security failure
• Scaling to real-world failure modes: lost devices, forgotten credentials, and account recovery all need real answers, not just a clean happy path

The actual decision isn't which one is "most secure" in the abstract. It's understanding exactly which attack each one blocks, and which ones it doesn't, which is exactly what both CVS Health's and Microsoft's numbers measured directly.

Passwords

What it actually is: a shared secret, chosen by the user, verified by the server against a stored hash. The user types it in, the server hashes the input and compares it to the stored hash, and access is granted on a match. No device, hardware key, or secondary factor is required by the method itself.

A small example (what the server stores, simplified):

user: [e-mail]
password_hash: $2b$12$KIXxPfn...  (bcrypt hash, never the plain password)

Where it shines:

• Universal support: every system, every platform, and every user already understands how passwords work, with zero new infrastructure required
• Simple to implement at a basic level: a working password system is the lowest-effort way to add authentication to a new application
• No special hardware or device dependency: a password can be typed anywhere, on any device, without relying on a specific phone or key being present

Where it struggles:

• Phishable by design: a password can be typed into a fake login page just as easily as a real one, which is exactly the attack vector passkeys were built to eliminate
• Reused across services: when one service leaks a password database, the same password often works on other services, turning a single breach into many
• Guessable or crackable: weak or common passwords remain a major cause of account compromise, despite decades of password-strength guidance
• The clearest, most direct evidence against passwords alone: Microsoft's own Azure AD study found that accounts without MFA were compromised at a dramatically higher rate than those with it, even when the underlying password had already leaked, which is specifically a statement about the password's weakness as a standalone defense

Who this suits: nowhere, as a standalone, complete authentication strategy for anything that matters. Passwords remain a practical fallback or first factor, but not a sufficient defense on their own.

Passkeys

What it actually is: a cryptographic credential, built on the FIDO2/WebAuthn standard, where a device generates a public-private key pair during registration. The private key never leaves the user's device (or a synced keychain), and the server only ever stores the public key. Logging in means the device cryptographically proves it holds the private key, typically unlocked by a fingerprint, face scan, or device PIN, with nothing transmitted that a phishing site could steal and reuse.

A small example (the conceptual flow):

1. Registration: device generates a key pair, sends only the public key to the server
2. Login: server sends a challenge
3. Device signs the challenge with the private key (unlocked via Face ID/fingerprint)
4. Server verifies the signature using the stored public key, no secret ever crosses the network

Where it shines:

• Phishing-resistant by design: since there's no shared secret being typed in, a fake login page has nothing to steal, which is the core reason CVS Health's rollout drove such a large drop in account takeover fraud
• Nothing to remember or reuse: there's no password to forget, reuse across services, or leak in a breach, since the private key never leaves the device
• Real, measured adoption gains: Amazon reported 175 million passkeys created after rolling them out platform-wide, alongside a 30% improvement in sign-in success rates, a genuine usability win, not just a security one
• Reduces support burden: the State of Michigan's MiLogin system reported 1,300 fewer support calls after switching users to passkeys, since there's no password to reset

Where it struggles:

• Device and ecosystem dependency: losing access to the device or account holding your passkeys can complicate recovery, and synced passkeys require trusting the cloud provider syncing them
• Enterprise rollout is still genuinely slow: account recovery flows and legacy systems that assume passwords remain real blockers to full adoption, even where the technology itself is ready
• Not universally supported yet: while adoption is accelerating quickly, not every service or platform supports passkeys, so most users and systems still need a password-based fallback for now

Who this suits: any new login system being designed today, and a high-value upgrade path for existing systems protecting sensitive accounts, exactly the kind of account takeover problem CVS Health's rollout was built to solve.

MFA (Multi-Factor Authentication)

What it actually is: a second (or third) proof of identity required alongside the first factor, typically something you have (a phone, a hardware key) or something you are (biometrics), layered on top of something you know (a password) or something you hold (a passkey). Common implementations include authenticator app codes (TOTP), push notifications, SMS codes, or physical security keys.

A small example (a typical login sequence):

1. User enters password (first factor)
2. Server accepts the password and prompts for a second factor
3. User approves a push notification or enters a 6-digit code (second factor)
4. Access granted only after both factors succeed

Where it shines:

• Dramatic, well-measured risk reduction: Microsoft's Azure AD study found MFA reduced account compromise risk by 99.22% overall, and more than 99.99% of MFA-enabled accounts stayed secure over the study period
• Catches exactly what passwords alone miss: even when a password has already leaked, MFA reduced compromise risk by 98.56% in the same study, directly addressing the password's core weakness
• Flexible across authentication methods: MFA can layer on top of either passwords or passkeys, making it a genuinely complementary strategy rather than a competing one
• Widely adopted and increasingly expected: workforce MFA adoption reached roughly 70% by early 2025, according to identity platform telemetry, up from 64% the year before, and continues climbing

Where it struggles:

• Not all MFA is equally strong: the same research found authenticator apps outperforming SMS-based codes specifically, since SMS remains vulnerable to SIM-swapping and interception in ways app-based or hardware-key factors aren't
• Real usability friction: a second step at every login is genuine friction, and "MFA fatigue," users approving push notifications reflexively without checking them, is a documented, real attack vector
• Doesn't eliminate the weak first factor: MFA on top of a weak, reused password is far better than a password alone, but it's still not as strong as removing the phishable first factor entirely, which is exactly what passkeys do

Who this suits: essentially every account that matters, as a baseline layered on top of whatever first factor you're using, password or passkey alike.

Side-by-Side Comparison

	Passwords	Passkeys	MFA
What it is	A memorized shared secret	A device-held cryptographic key pair	A required second proof of identity
Phishing resistance	None	Strong, by design	Depends on the method (app/hardware key strong, SMS weaker)
Measured real-world impact	N/A, the baseline being improved on	98% reduction in account takeover fraud (CVS Health)	99.22% reduction in compromise risk (Microsoft)
User experience	Familiar, but prone to reuse and forgetting	Fast, biometric-based, nothing to remember	Adds a step, but increasingly expected
Adoption maturity	Universal	Growing quickly, not yet everywhere	Mainstream, roughly 70% workforce adoption
Best role today	Fallback only, not a standalone defense	Primary credential for new and high-value systems	Required layer on top of either of the above

How This Fits a Career Path

• Backend Engineer (general): implementing secure password handling (proper hashing, never storing plaintext) and understanding why it's insufficient alone is a baseline expectation in nearly every real codebase
• Security-focused or Auth-focused roles: passkey implementation (WebAuthn) and MFA design are increasingly central, not optional extras; our Cryptography course covers the underlying mechanisms that make passkeys phishing-resistant
• Full-stack or product engineer: you'll likely be the one implementing the actual login flow, so understanding the real usability trade-offs (Amazon's 30% sign-in improvement, MiLogin's support-call reduction) matters directly for product decisions
• System design interviews: be ready to design a login flow that layers these appropriately, not just name-drop all three, since interviewers are specifically testing whether you understand what each layer actually defends against

How to Choose Without Overthinking It

1. Never ship passwords as a standalone defense for anything sensitive. The evidence here isn't subtle, Microsoft's own measurement found MFA cutting compromise risk by over 99%, specifically because passwords alone fail so often.
2. Add passkeys as the primary option wherever you can. For new systems, offer passkeys first and relegate passwords to a fallback. For existing systems, a phased passkey rollout targeting your highest-risk accounts first mirrors how real companies like CVS Health approached it.
3. Layer MFA regardless of your first factor. Even with passkeys, MFA remains valuable for especially sensitive actions (admin access, financial transactions), and it's essential wherever a password-based fallback still exists.
4. Prefer app-based or hardware-key MFA over SMS when you can. The research is specific here: phishing-resistant methods meaningfully outperform SMS, which remains vulnerable to interception and SIM-swapping.

A note on honesty: CVS Health's 98% and Microsoft's 99.22% are both real, measured numbers, but they come from different studies, different systems, and different threat models. They aren't directly comparable as a head-to-head "passkeys vs. MFA" scorecard. What they both demonstrate, independently, is the same underlying point: moving beyond a password alone produces a dramatic, measurable security improvement, however you implement it.

Common Mistakes When Learning Authentication

• Treating MFA as a checkbox instead of a layered defense. Not all MFA is equal; SMS-based codes are meaningfully weaker than app-based or hardware-key methods, and the choice matters.
• Assuming passkeys solve account recovery for free. Losing device access remains a real, unsolved friction point in passkey systems; a thoughtful recovery flow is still required engineering work.
• Rolling out passkeys without a password fallback for unsupported platforms. Adoption is accelerating, but it isn't universal yet, so most real systems still need to support both during the transition.
• Underestimating MFA fatigue as a real attack vector. Push-notification approval fatigue is a documented way attackers bypass MFA; it needs active design consideration, not just assuming the second factor is inherently safe.
• Storing passwords insecurely. Even as a fallback, proper hashing (bcrypt, Argon2) remains non-negotiable; this is a different failure mode than the ones passkeys and MFA address, and it's still entirely your responsibility to get right.

Frequently Asked Questions

Should a beginner learn password-based auth before passkeys?

Yes. Understanding how password hashing and verification actually work is foundational, and it's also what most existing production systems you'll work on still use, alongside an increasing passkey option.

Do passkeys replace the need for MFA?

Not entirely. Passkeys are inherently strong as a first factor, but MFA remains a valuable additional layer for especially sensitive actions, even on top of a passkey-based login.

Is SMS-based MFA still worth implementing?

It's meaningfully better than no MFA at all, the research shows even SMS blocking the bulk of automated credential attacks, but app-based or hardware-key MFA is a stronger choice where you can offer it.

Why did CVS Health see such a large reduction with passkeys specifically?

Because passkeys eliminate the phishable shared secret entirely; a fake login page simply has nothing to capture, which directly targets the attack vector responsible for a large share of real-world account takeover.

Can I implement passkeys without replacing my entire authentication system?

Yes, and most real rollouts work this way, offering passkeys as an additional login option alongside existing passwords, then gradually encouraging adoption rather than forcing an all-at-once cutover.

How do interviewers evaluate this topic in interviews?

Usually by asking you to design a real login flow and justify your choices, rather than testing whether you can name all three. Explaining specifically what each layer defends against, and why passwords alone fail, is what signals real understanding.

Build Authentication That Reflects the Real Numbers

The lesson from CVS Health's 98% and Microsoft's 99.22% isn't "pick the single best method," it's that moving beyond a password alone, through passkeys, MFA, or both, produces a measurable, serious security improvement. Explore the Auth & Identity course to build login flows that reflect what the evidence actually shows.