Firebase Phone Verification Is Moving Beyond SMS OTP

For years, phone number verification has followed almost the same pattern: enter your phone number, wait for an SMS, find the OTP, enter it, and continue. Although this approach works, it introduces friction into a relatively simple process. SMS delivery can be delayed, users can enter the wrong code, and attackers can trick users into sharing their OTPs through phishing.

Firebase is taking a different approach with Firebase Phone Number Verification (PNV). Instead of sending an SMS and asking users to enter a code, it retrieves the phone number assigned to the SIM directly from the connected mobile carrier, with the user's consent.

The interesting part isn't just the faster experience. Firebase is changing the verification model itself.

From SMS verification to carrier-based verification

The traditional SMS OTP model relies on a simple assumption: if a user can receive a message sent to a phone number, they probably have access to that number. The application sends a message, waits for successful delivery, and asks the user to enter the code.

Firebase PNV takes a different approach by working with the carrier to obtain the phone number associated with the SIM in the device. Instead of relying on SMS delivery, the verification process uses the carrier as the source of the phone number. Firebase Phone Number Verification documentation

At a high level, the flow looks like this:

Firebase reports that verification typically completes within 1–3 seconds after user consent. There is no SMS to wait for and no OTP to enter. The Android SDK handles the verification flow, including obtaining consent and requesting the number from the carrier. Android implementation guide

The backend still matters

Firebase returns a signed token containing the verified phone number. If your application needs to use that number on the backend, send the token rather than trusting a phone number supplied by the client.

Your backend should validate the token's signature, issuer, audience, expiration, and other required claims before trusting the number. For implementations that use a nonce, the backend should also verify that it generated the nonce and that it hasn't expired or been used already. This helps prevent a previously issued token from being replayed in an unintended context. Firebase PNV token verification guidance

PNV also changes the security considerations around OTPs. Because it doesn't send an SMS containing a one-time code, it removes the opportunity for attackers to phish users for that particular OTP. However, it doesn't eliminate every risk associated with phone-based authentication, account recovery, or compromised devices.

PNV doesn't mean SMS OTP is going away

There is an important limitation to consider before designing an authentication flow around PNV: availability depends on compatible devices and participating carriers. Firebase provides a compatibility check so applications can determine whether PNV is available and fall back to another verification method, such as SMS, when necessary. Carrier support is expanding over time. Firebase carrier compatibility and fallback guidance

For production applications, a hybrid approach makes more sense than immediately replacing SMS everywhere. Use PNV when the device and carrier support it, and retain SMS verification as a fallback. This lets you adopt carrier-based verification without making the entire onboarding experience dependent on its availability.

There is also an important Firebase Authentication consideration. As of the current documentation, direct Firebase Authentication support for PNV is still under development, and the PNV token cannot be used directly as a Firebase Authentication sign-in token. To integrate the two, Firebase documents a custom authentication flow in which your backend exchanges the verified PNV result for a Firebase Authentication token. Firebase PNV and Authentication integration

This distinction matters when choosing an implementation. If your application already has its own authentication backend, you can integrate PNV into that system. If you rely on Firebase Authentication, account for the additional custom authentication step.

What makes this change interesting?

I've worked with Firebase and mobile development for years, and phone verification has long been closely associated with SMS OTP. Most improvements have focused on making the existing flow better through features such as OTP auto-fill, retry handling, and improved user interfaces.

Firebase PNV asks a different question: Do we need to send an SMS at all?

That is what makes this feature worth paying attention to. Rather than improving the process of delivering and entering a code, it changes how the phone number is verified in the first place.

PNV still has practical limitations, including carrier availability, device compatibility, and the additional integration required for Firebase Authentication. Production use also requires project setup, billing, and the necessary verification steps. Firebase PNV production setup guide

For developers building Android applications, PNV is worth evaluating alongside the existing SMS flow. Start by checking carrier compatibility, implement the fallback, and validate the backend token before trusting the result.

The interesting part isn't that Firebase has found a faster way to deliver an OTP. It's that phone verification may no longer need one.