Building Hybrid Authentication in 2026: A Developer's Guide to Passkeys + Secure SMS Fallback

> "Passkeys are the future — but what about the users who can't use them yet?"

In March 2026, the authentication landscape is undergoing a fundamental shift. According to the FIDO Alliance, 48% of the top 100 websites now support passkey login, and nearly 70% of consumers hold at least one passkey. Enterprise adoption sits at a staggering 87%. Yet cross-platform interoperability remains clunky, device loss creates account recovery nightmares, and a significant portion of users still lack passkey-capable devices.

The answer isn't choosing between passkeys and SMS — it's building a hybrid authentication system that leverages passkeys as the primary method while maintaining a security-hardened SMS fallback for maximum accessibility.

This guide provides a comprehensive analysis and practical implementation strategy for 2026.

The State of Authentication in 2026

Passkeys: Impressive Progress, Incomplete Coverage

The good news is compelling:

| Metric | Value | Source | |--------|-------|--------| | Consumer passkey recognition | 75% | FIDO Alliance 2025 | | Authentication success rate (passkeys) | 93% | FIDO Alliance 2025 | | Authentication success rate (legacy auth) | 63% | FIDO Alliance 2025 | | Login speed vs password | 3x faster | Dashlane 2025 | | Login speed vs password + MFA | 8x faster | Dashlane 2025 | | Enterprise deployment rate | 87% | Dark Reading 2025 | | Password reset ticket reduction | 32% | FIDO Report 2025 | | Monthly passkey authentications | 1.3M+ | FIDO Alliance |

The challenges remain real:

• Cross-platform friction: Moving passkeys between Apple, Google, and Microsoft ecosystems is still problematic. Users switching from a Windows laptop to an iPhone face real usability hurdles.
• Device dependency: If your phone is lost, stolen, or bricked, passkey access may be lost entirely without proper recovery mechanisms.
• First-time creation UX: Most login flows still don't prominently surface passkey creation during signup, limiting organic adoption.
• Vendor lock-in concerns: Passkeys can become tied to specific platforms, making migration between ecosystems difficult.
• Technical complexity: Ensuring compatibility across thousands of OS/browser/passkey provider combinations is a significant engineering challenge.

SMS OTP: Known Risks, Continued Relevance

SMS-based OTPs face well-documented security threats:

Attack Vectors:

1. SIM Swapping — Attackers socially engineer mobile carriers to port a victim's number to their SIM. UK incidents jumped 1,055% in 2024, from 289 to nearly 3,000 cases.
2. SS7/Diameter Protocol Exploitation — Attackers exploit legacy telecom signaling protocols to silently intercept SMS messages.
3. eSIM Provisioning Attacks — The rise of eSIM technology has opened new attack surfaces where compromised carrier accounts enable over-the-air SIM profile downloads.
4. Phishing — Sophisticated fake security alerts trick users into voluntarily sharing OTP codes.

Regulatory Pressure:

• The UAE Central Bank mandated elimination of SMS/email OTPs by March 2026
• The USPTO discontinued SMS authentication in May 2025
• FINRA followed in July 2025
• The FBI and CISA issued formal warnings against SMS authentication

However, these regulations primarily target financial institutions and government agencies. For general consumer applications, e-commerce platforms, and startup MVPs, SMS remains a legitimate and often necessary authentication channel — provided it's properly secured.

The South Korea A2P messaging market reached $1.37 billion in 2024 and is projected to grow to $2.23 billion by 2033, underscoring the continued market demand for SMS-based services including OTP authentication.

Designing a Hybrid Authentication Architecture

The Authentication Priority Ladder

┌─────────────────────────────────────────┐
│  Tier 1: Passkeys (WebAuthn/FIDO2)      │  ← Phishing-resistant, fastest
├─────────────────────────────────────────┤
│  Tier 2: TOTP Authenticator Apps        │  ← Offline-capable
├─────────────────────────────────────────┤
│  Tier 3: Hardened SMS OTP               │  ← Maximum accessibility
└─────────────────────────────────────────┘

Core Design Principles

1. Passkey-first enrollment: Guide users toward passkey creation during signup, presenting it as the default option.
2. Progressive migration: Nudge existing users toward passkeys through UX incentives ("Log in faster with passkeys"), never forced migration.
3. Hardened SMS fallback: When SMS is the fallback, wrap it in multiple security layers.
4. Risk-based authentication: Dynamically adjust required authentication strength based on context.

Implementation Guide: Next.js Hybrid Authentication

Step 1: Passkey Registration & Authentication

Using the @simplewebauthn package — the most widely recommended library for WebAuthn implementation in 2026:

// lib/passkey.ts
import {
  generateRegistrationOptions,
  verifyRegistrationResponse,
  generateAuthenticationOptions,
  verifyAuthenticationResponse,
} from '@simplewebauthn/server';

const rpName = 'MyApp';
const rpID = 'myapp.com';
const origin = `https://${rpID}`;

export async function createRegistrationOptions(user: User) {
  const options = await generateRegistrationOptions({
    rpName,
    rpID,
    userID: user.id,
    userName: user.email,
    authenticatorSelection: {
      residentKey: 'preferred',
      userVerification: 'preferred',
    },
  });

  // Store challenge for verification
  await storeChallenge(user.id, options.challenge);
  return options;
}

export async function createAuthenticationOptions(userID?: string) {
  const options = await generateAuthenticationOptions({
    rpID,
    userVerification: 'preferred',
    // Omit allowCredentials for discoverable credential flow
  });

  await storeChallenge(userID ?? 'anonymous', options.challenge);
  return options;
}

Client-side integration:

// components/PasskeyLogin.tsx
import { startAuthentication } from '@simplewebauthn/browser';

export function PasskeyLogin() {
  const handlePasskeyLogin = async () => {
    try {
      const options = await fetch('/api/auth/passkey/options').then(r => r.json());
      const credential = await startAuthentication(options);
      const result = await fetch('/api/auth/passkey/verify', {
        method: 'POST',
        body: JSON.stringify(credential),
      }).then(r => r.json());

      if (result.success) {
        window.location.href = '/dashboard';
      }
    } catch (error) {
      // Passkey not available — show SMS fallback
      showSMSFallback();
    }
  };

  return (
    <div>
      
      
        Sign in with Passkey
      
      
        Use phone number instead
      
    </div>
  );
}

Step 2: Security-Hardened SMS Fallback

The key to a safe SMS fallback is layering multiple security controls:

// lib/sms-otp.ts
import crypto from 'crypto';
import Redis from 'ioredis';

const redis = new Redis(process.env.REDIS_URL!);

interface OTPConfig {
  length: number;
  ttlSeconds: number;
  maxAttempts: number;
  cooldownSeconds: number;
  maxDailyPerPhone: number;
  maxDailyPerIP: number;
}

const config: OTPConfig = {
  length: 6,
  ttlSeconds: 180,         // 3-minute expiry
  maxAttempts: 3,          // 3 verification attempts
  cooldownSeconds: 60,     // 60s between resends
  maxDailyPerPhone: 10,    // Max 10 OTPs per phone per day
  maxDailyPerIP: 20,       // Max 20 OTPs per IP per day
};

// Cryptographically secure OTP generation
function generateSecureOTP(): string {
  const buffer = crypto.randomBytes(4);
  const num = buffer.readUInt32BE(0) % Math.pow(10, config.length);
  return num.toString().padStart(config.length, '0');
}

// HMAC-based hashing — NEVER store OTPs in plaintext
function hashOTP(otp: string, salt: string): string {
  return crypto
    .createHmac('sha256', process.env.OTP_SECRET!)
    .update(`${otp}:${salt}`)
    .digest('hex');
}

export async function sendOTP(phoneNumber: string, ipAddress: string) {
  // Layer 1: Resend cooldown
  const cooldownKey = `otp:cooldown:${phoneNumber}`;
  if (await redis.exists(cooldownKey)) {
    throw new Error('Please wait before requesting a new code.');
  }

  // Layer 2: Daily phone number limit
  const dailyPhoneKey = `otp:daily:phone:${phoneNumber}`;
  const dailyPhoneCount = parseInt(await redis.get(dailyPhoneKey) || '0');
  if (dailyPhoneCount >= config.maxDailyPerPhone) {
    throw new Error('Daily verification limit reached for this number.');
  }

  // Layer 3: Daily IP limit (prevents SMS pumping)
  const dailyIPKey = `otp:daily:ip:${ipAddress}`;
  const dailyIPCount = parseInt(await redis.get(dailyIPKey) || '0');
  if (dailyIPCount >= config.maxDailyPerIP) {
    throw new Error('Too many requests. Please try again tomorrow.');
  }

  const otp = generateSecureOTP();
  const salt = crypto.randomBytes(16).toString('hex');
  const hashedOTP = hashOTP(otp, salt);

  // Store hashed OTP with auto-expiry
  const otpKey = `otp:${phoneNumber}`;
  await redis.setex(otpKey, config.ttlSeconds, JSON.stringify({
    hash: hashedOTP,
    salt,
    attempts: 0,
  }));

  // Set cooldown and increment daily counters
  await redis.setex(cooldownKey, config.cooldownSeconds, '1');
  await redis.incr(dailyPhoneKey);
  await redis.expire(dailyPhoneKey, 86400);
  await redis.incr(dailyIPKey);
  await redis.expire(dailyIPKey, 86400);

  // Send via EasyAuth API
  await fetch('https://api.easyauth.io/send', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${process.env.EASYAUTH_API_KEY}`,
    },
    body: JSON.stringify({ phoneNumber }),
  });

  return { success: true, expiresIn: config.ttlSeconds };
}

export async function verifyOTP(phoneNumber: string, inputOTP: string) {
  const otpKey = `otp:${phoneNumber}`;
  const stored = await redis.get(otpKey);

  if (!stored) {
    throw new Error('Code expired. Please request a new one.');
  }

  const { hash, salt, attempts } = JSON.parse(stored);

  if (attempts >= config.maxAttempts) {
    await redis.del(otpKey);
    throw new Error('Too many attempts. Please request a new code.');
  }

  const inputHash = hashOTP(inputOTP, salt);

  if (inputHash !== hash) {
    await redis.setex(otpKey, config.ttlSeconds, JSON.stringify({
      hash, salt, attempts: attempts + 1,
    }));
    const remaining = config.maxAttempts - attempts - 1;
    throw new Error(`Invalid code. ${remaining} attempt(s) remaining.`);
  }

  // Success — immediately delete OTP
  await redis.del(otpKey);
  return { success: true };
}

Step 3: Unified Hybrid Auth Flow

// app/api/auth/route.ts
import { NextRequest, NextResponse } from 'next/server';

export async function POST(req: NextRequest) {
  const { method, ...data } = await req.json();
  const ip = req.headers.get('x-forwarded-for') || 'unknown';

  switch (method) {
    case 'passkey':
      return handlePasskeyAuth(data);

    case 'sms-send':
      return handleSMSSend(data.phoneNumber, ip);

    case 'sms-verify':
      return handleSMSVerify(data.phoneNumber, data.code);

    default:
      return NextResponse.json(
        { error: 'Invalid authentication method' },
        { status: 400 }
      );
  }
}

Step 4: Risk-Based Fallback Decision Engine

// lib/risk-engine.ts
interface AuthContext {
  supportsWebAuthn: boolean;
  hasRegisteredPasskey: boolean;
  riskLevel: 'low' | 'medium' | 'high';
  operation: string;
}

function determineAuthRequirements(ctx: AuthContext) {
  // High-risk operations (payments, PII changes) → passkey required
  if (ctx.riskLevel === 'high') {
    return {
      required: 'passkey',
      fallbackAllowed: false,
      message: 'This action requires passkey verification.',
    };
  }

  // User has passkey → prefer passkey, allow SMS fallback
  if (ctx.supportsWebAuthn && ctx.hasRegisteredPasskey) {
    return {
      required: 'passkey',
      fallbackAllowed: true,
      message: 'Sign in with your passkey for faster access.',
    };
  }

  // Default → SMS allowed
  return {
    required: 'sms',
    fallbackAllowed: true,
    message: 'Enter your phone number to receive a verification code.',
  };
}

SMS Fallback Security Hardening Checklist

| Security Control | Implementation | Priority | |-----------------|----------------|----------| | OTP Hashing | HMAC-SHA256 with per-OTP salt | Critical | | TTL Expiration | 60-180 second auto-expiry via Redis TTL | Critical | | Attempt Limiting | 3-5 attempts, then invalidate OTP | Critical | | Resend Cooldown | 60-second minimum between sends | Critical | | IP Rate Limiting | Max 10-20 requests per IP per day | High | | Phone Rate Limiting | Max 10 OTPs per phone per day | High | | Phone Validation | E.164 format + carrier validation | High | | SMS Pumping Detection | Monitor for anomalous patterns | Medium | | Logging & Alerting | Track failed attempts, unusual volumes | Medium |

Practical Migration Strategy

Phase 1: Start with SMS (Day 1 — MVP)

If you're building a side project, startup MVP, or any application where you need to ship fast, start with SMS authentication. Services like EasyAuth let you integrate SMS verification in under 5 minutes with just two API endpoints (POST /send and POST /verify) — no business registration documents required, no sender number pre-registration, and pricing starts at just 15-25 KRW per message. When you're in MVP mode, don't waste time on authentication infrastructure.

Phase 2: Add Passkeys (Post-PMF)

Once you have product-market fit and a growing user base, introduce passkey registration as an option. Frame it as a UX benefit ("Log in 3x faster"), not a security mandate. Use autoComplete="username webauthn" to enable browser passkey autofill.

Phase 3: Risk-Based Enforcement (Scale)

As your platform matures, implement risk-based authentication. Require passkeys for sensitive operations while maintaining SMS fallback for general login. Monitor adoption metrics and gradually increase passkey nudges.

Key Takeaways

1. It's not either/or — The optimal 2026 authentication strategy combines passkeys and SMS in a layered approach.
2. Passkeys are primary, not exclusive — With 93% success rates and phishing resistance, passkeys should be the default. But cross-platform gaps and device dependency mean fallbacks are still essential.
3. SMS fallback must be hardened — Plaintext OTPs with no rate limiting are unacceptable. Implement hashing, TTL, attempt limits, and IP-based rate limiting.
4. Start simple, evolve progressively — Launch with SMS, add passkeys, then layer risk-based routing. Don't let authentication complexity delay your launch.
5. Regulatory context matters — Financial apps may need to eliminate SMS entirely. General consumer apps have more flexibility.

The authentication landscape will continue evolving, but the hybrid approach — passkeys for security and speed, hardened SMS for accessibility and fallback — represents the most pragmatic strategy for developers shipping products in 2026.

---

Sources:

• FIDO Alliance Passkey Index 2025
• Passwordless Authentication in 2025 — Authsignal
• Authentication Trends in 2026 — C# Corner
• Why SMS MFA No Longer Cuts It in 2026 — Decypher Technologies
• OTP Best Practices — Prelude
• SIM Swap Fraud 2025 — Keepnet
• Passkey Implementation Pitfalls — Corbado
• Enterprise Passkey Adoption — Dark Reading
• Passkeys: Not Perfect but Getting Better — NCSC UK
• South Korea A2P Messaging Market — IMARC Group