What is the difference between SMS OTP and phishing-resistant passkeys for authentication security?

SMS OTP relies on a code that can be intercepted, forwarded, or socially engineered from the user, so it still depends on user judgment under pressure. Phishing-resistant passkeys bind authentication to the legitimate site and device, which makes credential replay and fake-login interception much harder. For most organisations, that difference is decisive for reducing phishing success.

Why SMS OTP and passkeys are not the same security control

SMS OTP and phishing-resistant passkeys both aim to prove that a user should be allowed in, but they do it through very different trust models. SMS OTP depends on a shared channel and on the user correctly spotting a suspicious prompt. Passkeys remove much of that human decision-making by using cryptographic binding to the legitimate site and the user’s device, which is why they materially change phishing risk rather than just adding another step.

That difference matters because authentication failures rarely begin with a broken password alone. They usually begin when an attacker can reuse a code, trick a user into entering one, or hijack a session after the code is accepted. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls treats authentication strength as a control-design issue, not just a user-training issue. For organisations that handle sensitive access paths, that distinction is operationally decisive. In practice, many teams discover the weakness only after a convincing phishing flow or help-desk social engineering event has already bypassed the SMS code.

How the two methods work in practice

SMS OTP is a one-time code delivered over the phone network. It is better than a static password alone, but it still relies on a separable secret that the user must read, trust, and enter under time pressure. That creates exposure to interception, SIM-swap abuse, SMS forwarding, adversary-in-the-middle phishing pages, and prompt fatigue. The control can reduce opportunistic compromise, but it does not strongly bind the authenticator to the origin being accessed.

Phishing-resistant passkeys use public-key cryptography. The private key stays on the user’s device or secure authenticator, and the browser will only sign a challenge for the legitimate site origin. That means the attacker cannot simply capture a reusable code and replay it elsewhere. The security gain comes from origin binding, device binding, and the fact that the user is not asked to manually transcribe a secret into a fake page.

SMS OTP is still a shared-channel factor, so the user becomes part of the control path.
Passkeys shift assurance to cryptographic proof tied to the intended service.
SMS OTP can be defeated by relaying or coercing the code in real time.
Passkeys are designed to make that replay pattern far harder to execute.

For identity teams, the practical question is not whether SMS OTP has value at all, but whether the residual phishing exposure is acceptable for the account class involved. The Ultimate Guide to NHIs — What are Non-Human Identities is useful here because it shows how stronger, cryptographically bound authentication becomes even more important when access is automated, delegated, or high-volume. These controls tend to break down in environments that still allow legacy fallback paths, because the weakest enrolled method often becomes the real recovery path.

Where the trade-off becomes visible

Tighter authentication usually increases enrolment, device, and recovery governance, so organisations must balance usability against the higher assurance they want. SMS OTP is easier to deploy widely, especially where users do not have compatible devices or where legacy systems still expect a phone-based second factor. Best practice is evolving, however, because ease of deployment does not equal resilience against phishing.

Passkeys work best when the service can enforce strong origin checks, the user’s device lifecycle is managed, and recovery does not quietly reintroduce weaker factors. If a platform supports passkeys but still lets users fall back to SMS for high-risk transactions, the security benefit is only partial. The question is therefore not “which method is simpler,” but “which method still holds when an attacker is actively trying to impersonate the site.” That distinction is why phishing-resistant methods are now preferred for administrative, privileged, and customer accounts that face meaningful fraud pressure. There is no universal standard for every rollout sequence yet, but the direction of travel is clear.

For teams comparing options, the most important edge case is account recovery. If recovery, support, or device replacement routes remain weak, a phishing-resistant primary factor can be undermined by a softer back door. Organisations should treat fallback design as part of the authentication decision, not as a separate help-desk detail.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-63	AAL2 — Authenticator Assurance Level 2	SMS OTP commonly maps to lower-assurance MFA flows.
	AAL3 — Authenticator Assurance Level 3	Phishing-resistant passkeys align with high-assurance authenticators.
Recommendation — Prefer stronger authenticators than SMS for accounts exposed to phishing. Require phishing-resistant authenticators for sensitive and privileged access.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	The question is about authentication strength and access control design.
Recommendation — Adopt authentication methods that resist replay, interception, and origin spoofing.
CIS Controls v8	6 — Access Control Management	SMS OTP versus passkeys is an access-control hardening choice.
Recommendation — Reduce reliance on weak fallback authenticators and enforce stronger access methods.
OWASP Non-Human Identity Top 10	NHI-01 — Inventory and Ownership	Passkeys are device-bound credentials that require lifecycle visibility and ownership.
Recommendation — Inventory and govern device-bound authenticators across their full lifecycle.

Practitioner Guidance

What to prioritise: Use passkeys first for accounts where phishing would create material business impact, then remove or tightly constrain SMS fallback rather than leaving both equal in practice.

What to verify: Confirm that the service enforces origin-bound verification, that recovery paths do not downgrade assurance, and that admins cannot silently re-enable weaker methods for convenience.

Decision rule: If a user can approve access from a fake login page by entering a code, the method should be treated as phishing-exposed; if the authenticator signs only for the real origin, it is materially stronger.

Practitioner takeaway: The real difference is not “one factor versus another,” but whether authentication still works when the attacker controls the page, the prompt, and the timing.