How MFA and passkeys protect sign-in

More than one proof

Multi-factor authentication requires evidence from different factor types, such as something known, possessed, or inherent. It reduces the value of a stolen password, but the protection depends on the method. A code can be phished or relayed. Push prompts can be abused through fatigue or deceptive support contact.

What passkeys change

Passkeys use public-key cryptography and bind the credential to the legitimate site or app. The user does not type a reusable secret that a fake login page can collect. That makes passkeys and other phishing-resistant methods meaningfully different from one-time codes.

The whole account still matters

Enrollment, device security, recovery, session management, and removal of old factors remain important. For high-impact accounts, review who can add a factor, how recovery is approved, how sessions are revoked, and whether legacy login paths can bypass the stronger method.

Example: the code is relayed in real time

A fake sign-in page asks for a password and one-time code, then immediately submits both to the real service. The second factor existed, but the attacker relayed it before expiry. A domain-bound passkey would not create the expected proof for the fake origin. The example explains phishing resistance without claiming that every account, device or recovery path automatically supports it.

Roll out with support and fallback data

Track successful enrollment, sign-in failures, recovery requests and use of weaker fallbacks. Help people register more than one approved authenticator where policy allows. Support staff need a clear process that cannot be bypassed by urgency or status. The strongest method on a diagram has little value if users cannot recover safely or administrators quietly exempt the highest-consequence accounts.