Move product logins beyond SMS without weakening recovery

A product team choosing customer authentication should offer passkeys or an authenticator app before making SMS its default second factor. The difficult part is the transition: customers must still get into their accounts, while an old recovery route must not undo the stronger protection. Moving the button on the login page is only the beginning.

Looking back from November 2026, the July 2024 SMS investigation is useful because it exposed a dependency product teams rarely show to customers. The code can travel through organizations outside both the customer's phone and your application. Your authentication design inherits that route.

The intermediary is part of the login

On 11 July 2024, the Chaos Computer Club reported that researchers had live access to more than 200 million SMS messages associated with over 200 companies. The investigation concerned an exposed provider system, not proof that every mobile network or every SMS login had been compromised. It nevertheless showed that an attacker need not steal a phone to see a code.

A separate Twilio Authy alert described an unauthenticated endpoint through which attackers could identify account-associated information, including phone numbers. Twilio warned about social engineering and said it had no evidence of access to other sensitive data or its systems. This is a different failure: exposed phone numbers do not establish that authenticator secrets or generated codes were stolen.

The distinction matters when explaining the choice to customers. An authenticator app avoids delivering each code through an SMS provider. It does not make every surrounding account service immune to disclosure, and a manually entered code can still be phished.

Choose protection for the account's consequences

WebAuthn provides public-key authentication scoped to a relying party; the W3C Level 2 recommendation of 8 April 2021 predates this incident. That origin binding is an important difference from asking someone to type a code into a page. A passkey-based implementation still needs correct server verification and a clear policy for enrolling and replacing credentials.

For a product holding ordinary customer preferences, gradual enrollment may be proportionate. Accounts that can export customer records, change bank details or grant administrative access justify a stricter policy. Define those capabilities before choosing a universal login rule. A familiar phone-number field is not evidence that the same assurance is appropriate for every action.

The current NIST authentication guidance, published after the 2024 incident, treats telephone-network out-of-band authentication as restricted and calls for alternatives. It also distinguishes manually entered OTP methods from phishing-resistant authentication. This is a later technical reference, not a claim that every commercial product must implement a particular US government assurance level.

Recovery decides whether the improvement holds

Consider an illustrative account with a passkey and an SMS recovery button. If possession of the phone number alone lets someone remove the passkey and enroll a new one, the stronger everyday login has left a weaker takeover route. Rate limits can reduce guessing and message abuse. They cannot make a legitimately delivered code resistant to interception or deception.

Design recovery according to what the account can do. Offer recovery codes or another enrolled credential where appropriate, and explain how to store them. For sensitive accounts, require additional verification before replacing credentials or allowing consequential changes. Record the event and notify the account through an existing trusted channel. These are design recommendations, not a tested implementation recipe or a guarantee against takeover.

Human support needs the same attention. A support agent who can reset every factor after hearing a plausible story becomes part of the authentication boundary. Define which evidence staff may accept, who approves exceptional resets and what actions remain restricted afterwards. Do not ask staff to improvise identity checks while an impatient customer waits.

Migrate the people who already use the product

Start by finding the actual paths: sign-in, forgotten password, changed phone number, support reset and older mobile clients. Identify accounts that have never enrolled an alternative. A migration plan that covers only the latest browser flow may leave the old behavior available indefinitely.

Invite customers to add an alternative while they still have working access. Explain the change in terms of keeping their account available and protected, and let them confirm the new method before removing the old one. Provide instructions for a lost or replaced device. For business accounts, consider whether a second authorized administrator can help without receiving unlimited power over another person's identity.

Measure enrollment completion and recovery failures without logging secrets. Review support cases and abandonment before widening the change. A pilot should include the devices and accessibility needs represented in your customer base. Those observations establish whether this product's migration works; the source investigation does not supply conversion figures or support-cost estimates.

The strongest objection is reach. SMS works for people who cannot install an app or whose devices do not support the intended passkey experience. Removing it immediately can exclude legitimate customers. Keeping a constrained route can be reasonable when the account's consequences allow it. State the accepted risk and restrict sensitive actions rather than describing all methods as equivalent.

Start the next custom software authentication brief with one account journey, including the day the customer loses their phone. Ask the supplier to demonstrate enrollment, ordinary access and recovery under the same policy. The useful result is an account customers can recover without giving an attacker an easier entrance.