Passwordless MFA vs OTP-Based MFA: Retiring SMS and Codes for Workforce Passkeys

Most workforces still sign in with a password plus a one-time code from SMS, a voice call or an authenticator app, and that code can be phished, relayed or redirected as easily as the password it was meant to back up. Passwordless MFA built on passkeys or FIDO2 security keys removes the typed secret and binds sign-in to the genuine site, but replacing OTP across thousands of staff is a migration, not a switch. This guide compares OTP-based MFA and passkey-based passwordless MFA for workforce access, then concentrates on the move itself: how attackers defeat each method, what NIST SP 800-63B-4 says about restricted authenticators and recovery, how to retire SMS and codes without opening a weaker fallback, how the help desk changes, and the order to roll out. It is for identity, IAM and security operations teams planning the change. For the distinction between passwordless and phishing-resistant, see the Passwordless vs Phishing-Resistant MFA; for customer sign-in, see the Magic Links vs OTP Login vs Passkeys for Customers.

Key takeaways

• Short answer: OTP stops password reuse, passkeys stop phishing. Any code a person reads and types can be relayed by an adversary-in-the-middle page. NIST SP 800-63B-4 section 3.2.5 says authenticators that need manual entry shall not be considered phishing-resistant.
• SMS and voice are a restricted authenticator. Under SP 800-63B-4 section 3.2.9, an organisation that keeps PSTN codes must offer an unrestricted alternative, give users meaningful notice of the risks, assess the risk and keep a migration plan.
• The fallback sets your real strength. A passkey rollout that leaves SMS registered as a backup, or lets the help desk reset to a code, is still an OTP deployment as far as an attacker is concerned.
• Recovery and the help desk are the migration. Plan replacement credentials, recovery codes and caller verification before enforcement, because lockouts drive exceptions and exceptions become permanent.
• Roll out by risk, retire by method. Start with administrators, help desk staff and identity systems, then move populations in rings; remove SMS first, authenticator app codes last, and measure by method removed, not passkeys registered.

The two approaches in brief

OTP-based MFA adds a short-lived code to a password. SP 800-63B-4 covers three families: out-of-band codes over the public switched telephone network (SMS and voice, section 3.1.3), single-factor and multi-factor OTP devices such as authenticator apps using TOTP and hardware tokens (sections 3.1.4 and 3.1.5), and look-up secrets such as printed backup codes (section 3.1.2). PSTN codes must be at least six digits, valid for no more than 10 minutes and accepted only once. OTP keys need at least 112 bits of strength. All of these rely on the user typing a value into whatever page is in front of them.

Passwordless MFA here means a FIDO2 or WebAuthn credential, a passkey, unlocked by a local biometric or PIN. The private key never leaves the authenticator or the passkey provider, and the signature is bound to the relying party's identifier, which SP 800-63B-4 calls verifier name binding. The FIDO Alliance distinguishes synced passkeys, copied across a user's devices through an end-to-end encrypted provider, from device-bound passkeys that never leave one device, including those on security keys. Both are phishing-resistant at sign-in. Syncable authenticators are permitted at AAL2 but, under section 2.3.2, shall not be used at AAL3. For the internals, see the FIDO2 and WebAuthn Internals Guide.

Side-by-side comparison

Threat model: how OTP is defeated

Each attack below defeats OTP without breaking any cryptography, which is why stronger codes or shorter lifetimes do not fix the problem.

• Adversary-in-the-middle relay (ATT&CK T1557, T1111): a phishing link (T1566.002) leads to a reverse proxy that shows the real sign-in page. The user enters password and code, the proxy forwards both, and the attacker keeps the resulting session cookie (T1539). The code's 30 second or 10 minute lifetime is irrelevant because it is used immediately. The Twilio breach is the reference case: SMS lures to fake single sign-on pages captured credentials and one-time codes and relayed them in real time; Twilio moved employees to FIDO2 keys afterwards. See the AiTM Phishing Guide.
• SIM swap and number porting (ATT&CK Mobile T1451): the attacker persuades or bribes a carrier to move the victim's number, then receives the SMS codes. SP 800-63B-4 says verifiers should check risk indicators such as device swap, SIM change and number porting before sending a PSTN secret. See the SIM Swap Fraud Guide.
• Signalling interception: CISA's phishing-resistant MFA fact sheet names SS7 exploitation as a way to intercept text and voice codes. This is outside the enterprise's control. See the SS7 and Diameter Signalling Security Guide.
• Vishing for the code: a caller posing as IT asks the user to read out the code "to verify the account". No technical control in OTP prevents this.
• Help desk re-registration: the attacker calls the service desk as the user, asks for a new phone or app to be registered, then signs in with codes they control. The MGM Resorts breach began with a help desk call.

Threat model: how passkeys are attacked

Passkeys remove the relay and code-theft paths, so attackers move elsewhere. Planning for these is what makes the migration hold.

• Downgrade to a weaker method: the proxy page hides the passkey option or claims it is unavailable, pushing the user to "try another way" with a code. If OTP remains registered and allowed, the attack works. The fix is policy, not training: remove the weaker method for that population.
• Rogue registration: an attacker with a phished OTP session registers their own passkey (ATT&CK T1098.005 covers device registration persistence). Require a phishing-resistant or verified session to add credentials. See How to Detect MFA Method Registration Abuse.
• Recovery abuse: the passkey is strong, the reset is not. If recovery ends in an SMS code or an unverified help desk call, that is the effective authenticator.
• Session theft after sign-in: infostealer malware can still take a session cookie from an unmanaged device. Passkeys protect the sign-in ceremony, not the session after it; pair them with device compliance and token protection where your platform offers it.
• Synced passkey provider account takeover: a synced passkey is as safe as the provider account that holds it. For privileged roles, use device-bound keys.

What SP 800-63B-4 changes for the decision

The revision turns "SMS is weak" from opinion into specific obligations. The sibling page covers federal mandates; the points below are the ones that shape a migration plan in any organisation that aligns to NIST. For the full AAL model, see the NIST SP 800-63B-4 Authenticator Assurance Levels Guide.

Retiring OTP on common identity providers

Platforms are listed alphabetically. Each paragraph describes customer-side settings from the vendor's own documentation, checked on 14 November 2026.

• Google Workspace: 2-Step Verification enforcement offers three allowed-method options: "Any", "Any except verification codes via text, phone call" and "Only security key", and Google's documentation states that passkeys count under "Only security key". Google advises that users who rely on texts or calls are locked out after the change, and that the login_verification Login Audit event identifies them. A new user enrolment period of 1 day to 6 months can be set. Under "Only security key", backup codes are generated by an administrator, not the user. See the Google Workspace Security Guide.
• Microsoft Entra ID: methods are governed by the Authentication methods policy, which replaces the legacy MFA and SSPR policies through a reversible migration with "Migration in progress" and "Migration Complete" states. The legacy SSPR "Mobile phone" method maps to both Voice calls and SMS, so remove both from recovery as well as sign-in. Microsoft notes that SMS "Use for sign-in" is enabled by default under SMS settings, and that disabling a method in use may force users to register a new one. See the Entra Legacy MFA and SSPR Policy Migration and the Entra ID Security Guide.
• Okta: the Phone authenticator delivers SMS, voice or both, and can be allowed for authentication and recovery or for recovery only. Okta's documentation says phone OTP is not a guaranteed way to verify a user's identity and recommends stronger authenticators such as a passkey. To retire it, remove it from enrolment policies, then edit or delete the authenticator after updating the policies that reference it. Okta requires customers to connect their own telephony provider for phone authentication. See the Okta Security Hardening Guide.

Whatever the platform, retire in this order per population: stop new OTP enrolment, remove OTP from recovery, remove OTP from sign-in, then delete the registered methods.

Recovery and the help desk

Most failed passkey migrations fail here. Users lose phones, replace laptops and forget which provider holds their passkey, and every one of those events is a recovery request.

1. Two credentials per person before enforcement: a platform passkey plus either a second device's passkey or a security key. The FIDO Alliance notes that security keys can serve as a recovery credential if synced devices are lost.
2. Recovery codes designed to NIST parameters: saved codes with at least 64 bits of randomness, single use, stored hashed. Combine with a second factor or another code type for AAL2 recovery. See the MFA backup codes and recovery codes guide.
3. Verified help desk resets: no reset or new-method registration on knowledge questions or caller ID. Use a video check against an ID document, manager confirmation through a separate channel, or an in-person desk. Issue a temporary access pass that can only register a passkey, not sign in to applications. See the Help Desk Identity Verification Policy Template.
4. Notify on every change: send an alert for each recovery, new credential or removed credential, to a channel other than the one being changed, as section 4.2 requires for recovery.
5. Help desk staff first: service desk agents and their administrators move to device-bound keys in the first wave, because their accounts can reset everyone else's.

For the full recovery design, see the Account Recovery and Help Desk Security Guide.

Decision guidance

• Small organisations: one identity provider, admins on security keys in week one, everyone else on synced passkeys, SMS removed within a quarter. The cost is mostly time.
• Large organisations: ring-based rollout over several quarters, a funded hardware programme for privileged and frontline users, and an exception register with expiry dates. Telephony cost savings from SMS removal can offset hardware.

Worked scenario: a 6,000-person services firm

The firm uses SMS for MFA and SSPR, with an authenticator app optional. A phishing exercise captures sessions from 40 staff in an hour, including two IT administrators.

1. Weeks 1 to 4: administrators and the service desk receive two security keys each; OTP is removed from their accounts entirely. Identity provider admin roles require a phishing-resistant strength.
2. Weeks 5 to 10: passkey registration opens for all staff through a session already verified on a managed device. Registration events alert the SOC.
3. Weeks 11 to 16: SMS removed from SSPR and new SMS enrolment blocked. Users without a passkey are contacted directly using the identity provider's method report.
4. Weeks 17 to 26: passkeys required for remote access and email in rings of 10, 30 and 60 percent, with report-only mode before each ring. SMS deleted after each ring has been stable for two weeks.
5. Remaining exceptions: 120 warehouse staff use security keys on shared terminals; 15 legacy app users keep app codes behind a network restriction, with a replacement date.

The repeat exercise six months later captures no sessions from passkey users. The two capture attempts that succeed are against exception accounts, which is exactly what the register predicted.

Implementation and rollback

1. Inventory: export 30 days of sign-ins by authentication method and list every app that cannot use the identity provider.
2. Write the migration plan: populations, dates and the retirement order for SMS, voice and app codes, as section 3.2.9 expects for PSTN.
3. Pilot: IT and help desk staff first, as CISA recommends, using report-only or audit policies to see who would fail.
4. Enforce in rings by risk: identity systems, email, file servers and remote access before line-of-business apps.
5. Retire methods per population: block enrolment, remove from recovery, remove from sign-in, delete registrations.
6. Rollback: keep a time-limited exception group that allows app codes (never SMS) for a ring that hits a blocking issue, with an owner and expiry. Do not re-enable OTP tenant-wide.

Detection and measurement

• OTP sign-in share: percentage of interactive sign-ins completed with SMS, voice or app codes, trending to zero for each completed ring.
• Accounts with OTP still registered: the downgrade surface; target zero for privileged and completed populations.
• Recovery events per 1,000 users per month, and the share completed without help desk involvement.
• Unverified resets: help desk resets without a recorded verification step; target zero.
• Exception register age: number of exceptions past expiry.
• Alerts to monitor: new MFA method added shortly after an OTP sign-in from a new location, phone number changes, SMS sign-ins by users who already hold a passkey (possible downgrade), and recovery followed by mailbox rule changes.

See MFA Coverage Measurement for building the method report.

Common failure patterns

• Passkeys added, OTP left in place: enrolment rises, attackers downgrade, nothing changes. Measure method removal.
• SMS kept in SSPR: sign-in is phishing-resistant but password reset still trusts a phone number that can be swapped.
• Help desk outside the plan: agents reset to SMS to clear queues during the rollout. Give them a temporary pass that registers only a passkey.
• Synced passkeys for administrators: privileged accounts depend on a personal provider account. Use device-bound keys.
• Registration from any session: letting an OTP-authenticated session add a passkey lets a phished session plant persistence.
• Exceptions without expiry: legacy app exceptions outlive the app owner and become the easiest path in.

Framework mapping

Practitioner checklist

• Export sign-ins by method and record how many users depend on SMS, voice and app codes.
• Write a dated OTP retirement plan per population, covering PSTN as SP 800-63B-4 section 3.2.9 expects.
• Move administrators and help desk staff to two device-bound security keys each, with OTP removed.
• Require a verified or phishing-resistant session to register any new credential.
• Remove SMS and voice from password reset before or with sign-in, not after.
• Issue recovery codes that meet NIST parameters and notify users of every recovery.
• Replace help desk resets to SMS with verified checks and a registration-only temporary pass.
• Enforce in rings with report-only first, and delete OTP registrations once each ring is stable.
• Track OTP sign-in share and accounts with OTP still registered, not passkey enrolment alone.

Standards and references

• NIST: SP 800-63B-4 Digital Identity Guidelines, Authentication and Authenticator Management
• CISA: Implementing Phishing-Resistant MFA fact sheet
• FIDO Alliance: Passkeys
• Google Workspace Admin Help: Deploy 2-Step Verification
• Microsoft Learn: Migrate MFA and SSPR policy settings to the Authentication methods policy
• Okta Help: Configure the Phone authenticator

Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · Phishing-Resistant MFA Guide · Authenticator Apps and OTP Guide · MFA Fatigue and Bypass Guide · Help Desk Social Engineering Incident Playbook