Consider a hypothetical home-maintenance booking service for customers with Saudi mobile numbers. Amal wants to reschedule a visit, but the sign-in code goes to a number she stopped using. Her booking and saved address remain in the account. Returning a valid code sent to her replacement number would provide evidence of access to that destination; it would not establish her right to open the existing account.

A business using phone-based verification needs a process for this ordinary change in a customer’s life. Someone who can still authenticate should have a clear way to update their number. Someone who has lost the means to authenticate needs account recovery. Combining those situations into a single “enter your new number” form leaves the business without a clear basis for deciding who gets access.

Three decisions behind one phone field

A one-time password, or OTP, can help check access to a phone number. The business must also decide what that check is allowed to authorise. These are three different tasks:

NIST’s authentication guidance treats replacing a phone number used for authentication as attaching a new authentication method to the account. For a business owner, the implication is straightforward: this setting determines how someone will get into the account next time.

When the customer is still signed in

Suppose Amal still has a signed-in session on her laptop. The settings page can offer “Change sign-in number”, explain its effect and ask for fresh confirmation using a method already associated with her account. OWASP’s Authentication Cheat Sheet recommends reauthentication for sensitive changes because an active session can be used by someone other than the legitimate customer.

If this fictional service offered passkeys and Amal registered one earlier, it could provide the confirmation the service requires. If she cannot complete the required check, reaching the settings page should lead her to the recovery route, not waive the check. A method registered only during the current change request does not provide the same established connection to the account.

The service should complete the change only after both account authorisation and confirmation of the replacement number succeed. Until then, show the request as pending. If the connection drops after Amal enters a code, the next screen should tell her the actual state of the request and which sign-in number is active.

Before she confirms, explain whether the change affects sign-in, recovery contacts, appointment reminders or several of these. They serve different purposes even when they use the same number. Once the authorised change is complete, remove the old number from the roles it replaced, including any recovery route that would otherwise continue to accept it.

When the usual account checks are unavailable

If Amal cannot use any method that meets the account’s authentication requirements, another code to the old number is a dead end. The sign-in screen needs a visible “I cannot use this number” option. Losing a number does not necessarily require recovery, however: another previously registered method may still let her authenticate and follow the normal change process.

NIST describes recovery options including saved recovery codes, previously arranged recovery contacts and, where applicable, repeating identity checks performed at enrolment. The appropriate route depends on the account and the evidence established earlier. A new number or email address supplied during the request has no such history merely because it can receive a message.

Suppose the fictional booking service issued a recovery code at setup and Amal stored it separately. Its recovery process can assess that code, together with any other checks its policy requires, before permitting a replacement number. If she has no acceptable evidence, staff need a defined escalation or refusal decision. Tomorrow’s appointment cannot substitute for account verification.

Collecting more personal information is not automatically a solution. If the business never checked identity documents when the account was opened, asking for a document now does not by itself connect its holder to the old account. Names, addresses and booking details may help locate a support request, but should not become improvised proof of ownership.

Give support a route it can actually follow

A help form available only after sign-in is useless to a locked-out customer. Put the recovery support route on the sign-in page and explain what happens after a request is submitted. If a review takes time, give a realistic expectation based on the business’s actual process. Do not promise an instant change simply because sending an OTP is quick.

Internally, document who may approve recovery, what evidence they may accept, how to handle an inconclusive case and when to involve a specialist. Collect only information needed for that decision through a protected submission route. Staff should record the outcome and its reason without copying OTP values, passwords or unnecessary personal details into tickets.

Support also needs instructions for suspected unauthorised changes. Automatically restoring the old number may be inappropriate if the customer has lost control of it. The procedure should address any potentially compromised sessions as well as the replacement number; changing the contact record alone does not resolve every form of unauthorised access.

Explain the next step without exposing the account

Clear instructions do not require revealing who owns an account. OWASP recommends consistent public-facing authentication and recovery responses that avoid exposing whether an account exists. For the booking service, that means keeping names, saved addresses and appointment history off the public recovery screen.

An illustrative instruction could read: “Use a recovery method you set up earlier. If you cannot use one, contact account support for a review.” Within a properly authenticated settings flow, masked number details can help Amal check the destination. Public-facing messages should not disclose another customer’s details when a number is entered incorrectly or is already associated with an account.

Be equally precise about progress. “New number confirmed” describes one completed check. It should not appear as “Account recovered” while the service is still deciding whether the requester is entitled to access. After an approved update, explain which number now works and whether the customer needs to sign in again.

Plan notifications before the number becomes unusable

NIST calls for independent notifications when an authentication method is added or an account is recovered, with instructions for reporting an unexpected event. Plan a suitable notification channel during account setup. An email address already established on the account is one possibility; an alert sent only to the replacement number cannot independently warn the original customer.

Keep the notice focused on what changed, when it happened and how to report a problem through the service’s official support route. Consider that an old number may now reach someone else. Including the full replacement number, home address or appointment details would create an unnecessary disclosure. Any alert to an uncertain channel should contain as little account information as possible.

Keep message delivery separate from the access decision

For delivering OTPs by SMS to Saudi mobile numbers, Tawked is one possible component. Its documentation describes OTP messages to Saudi mobile numbers using a set message format that includes the reviewed application name. The booking service would still need its own rules for authorising number changes, handling recovery and notifying customers.

A delivery status describes a messaging event according to the provider’s definitions. It is not proof of identity, successful code entry or completed recovery. Even successful validation of a code sent to the replacement number leaves the separate question of authority over the existing account unresolved.

The staff view should therefore distinguish the message outcome, the code-check result and the decision about the account. A delivery problem needs a different response from a recovery request with insufficient evidence. Mark recovery complete only after the service has completed its recovery process and restored the appropriate access.

Offer recovery options while access still works

At account setup, explain how the phone number will be used and offer an appropriate additional authentication or recovery option. Later, make those settings easy to review while the customer can still authenticate. Amal should not first discover that a backup method was available after losing the only method she had.