Consultation status
Open for feedbackStatus checked on .
Last updated: 2026-09-08
A phone number can change hands while online accounts still treat it as belonging to the same person. If a service sends login or password-reset codes to that number, its new subscriber may receive credentials intended for the previous user.
That is the account-takeover risk behind phone number recycling: a change in who receives calls and messages can become a change in who controls an account.
Oman’s Telecommunications Regulatory Authority announced a consultation on numbering-rule amendments on 2 September 2026. It proposes a longer recovery period for ordinary numbers and safeguards concerning linked social-media accounts. As of 8 September 2026, the consultation remains open, with responses due by 2 October 2026. These amendments are proposals, not final regulation.
For SaaS companies, financial services and other digital businesses, the practical lesson applies beyond Oman: receiving a code proves access to a communication channel at that moment. It does not, by itself, establish continuity with the person who originally registered the account.
A longer window to recover ordinary numbers, alongside proposed safeguards for linked social accounts.
Status checked on .
Proposed extension of the recovery period after service disconnection.
The consultation deadline is not an implementation deadline.
Scope matters. The proposed 180 days do not apply universally: special numbers have a different period, and the draft excludes prepaid IoT numbers in the “4” range from the stated waiting periods.
Telephone numbers are a finite resource. When a subscription ends, operators can eventually return its number to an available pool and assign it to another subscriber. This helps keep numbers available for new customers.
The security problem arises when the telecom subscription and the online account follow different lifecycles. A mobile service may end while an email account, shopping profile or recovery setting continues to reference the old number.
An illustrative failure looks like this:
This differs from a fraudulent SIM swap, where someone takes control of an existing subscriber’s number through an unauthorized SIM replacement or transfer. Recycling can create exposure following an otherwise legitimate reassignment.
The announcement highlights an increase from 90 to 180 days for recovering ordinary numbers after service disconnection. The attached Arabic draft provides additional detail that matters when interpreting the proposal.
Draft Article Four would amend the relevant provision to specify two years for special numbers and 180 days for other numbers. It also describes priority for the previous subscriber to recover a number after that period if it remains available, under the applicable allocation mechanism.
The draft expressly excludes prepaid IoT numbers in the “4” range from the stated time periods, with a further provision addressing that exception.
It would therefore be inaccurate to describe this as a universal 180-day protection for all Omani numbers. It is also a telecom-number recovery period, not a deadline for recovering an online account or a guarantee that old account links disappear afterwards.
Draft Article Six would require licensees to avoid reallocating a number until they have confirmed that it is not linked to social accounts using public telecommunications numbers as identifiers.
Draft Article Seven goes further than the news summary. It proposes duties for social platforms that use or link Omani numbers for account identification or verification. Its wording calls for immediate cancellation of the relevant accounts when number service is stopped or terminated, and refers to reassignment to the new beneficiary on reactivation.
This wording needs clarification. The draft does not supply an operational distinction between cancelling an account, removing its telephone-number association and registering a new account for a subsequent subscriber. It should not be presented as permission to transfer the previous user’s profile, messages or other data.
Platform participation is therefore contemplated in the proposed text. An agreed technical integration or implementation arrangement is not established by that wording alone.
The attached draft states the intended outcome but does not specify a checking method, platform interface, evidence standard or process for handling an inconclusive result.
That leaves practical questions for the consultation:
Our assessment is that implementation needs a privacy-preserving way to establish whether a relevant association remains. A broad account-search exercise could itself expose which services someone uses. Checking must also be distinguished from trying to access an account.
As design recommendations, any operator–platform process should disclose only the minimum necessary result, restrict access, limit retention and provide a dispute route. A missing response should remain distinguishable from a confirmed absence of links.
The draft separately proposes restrictions concerning broad collection or processing of contact data and an Authority-approval requirement for the activities it describes. That provision is not a ready-made authorization for account discovery.
The proposed account-linking provisions expressly address social platforms. They do not establish an equivalent bank- or fintech-account checking process. Financial services should assess their own exposure without assuming that a social-platform check would protect their customers.
The operator-facing clause proposes a regulatory obligation. It does not settle automatic compensation or civil liability for every subsequent takeover. The draft also proposes sanctions tied to its specified platform and contact-data provisions; those should not be described as a universal operator-liability rule. Specific liability questions require the wider applicable framework and Omani legal advice.
The attached draft does not set out a transition process for numbers already in available pools or waiting periods. There is no final text to confirm retention of the proposed 180 days. Operators should monitor the adopted wording, commencement provisions and implementation guidance before treating a particular migration timetable as settled.
Risk depends on what a code allows someone to do.
Where SMS is the only login method, a recycled number can become a direct access route. Where login requires both a password and an SMS code, possession of the number alone may be insufficient. Exposure increases if the password is also compromised, or if recovery allows the password or second factor to be replaced using that same number.
The review must therefore cover login, password reset, MFA reset and support-assisted recovery together. A strong normal login can be undermined by a weaker fallback.
Short-lived codes and attempt limits remain useful, but they do not fix delivery to the wrong subscriber.
For messaging services, distinguish number registration, access to an existing account, historical messages and future communications. These are different outcomes.
WhatsApp’s guidance recognizes recycled numbers and provides a Change Number feature. Users changing numbers should follow that process; simply inserting a new SIM does not update the number associated with the account.
Reassignment alone should not be described as giving someone a copy of the previous subscriber’s chat history. Platform registration, recovery, device and backup protections affect what can actually be accessed. Remaining associations can nevertheless create account confusion and risks around future communications.
For financial products, a useful review follows the complete route from account recovery to movement of funds. Can a number-based reset also enable a new device, change security settings or authorize a payment?
As a security recommendation, recovery should not automatically authorize a high-risk transaction. Separate transaction approval, an established device or another independent verification step can help contain the consequences of a compromised recovery channel.
Even without a successful takeover, messages sent to a former customer’s number can disclose financial activity or other personal information. Message content and destination accuracy deserve attention alongside authentication.
These are security recommendations, not requirements created by Oman’s consultation.
Use a stable internal account identifier and manage telephone numbers as changeable attributes. Record whether a number is used for contact, login, recovery or transaction approval.
A useful review artifact is a list of every workflow that reads the phone-number field. It often reveals that updating a profile leaves recovery settings or messaging systems unchanged.
Prioritize passkeys or security keys where suitable. Authenticator-app codes also avoid dependence on number assignment, although manually entered codes are not phishing-resistant.
Review fallback paths at the same time. Offering stronger authentication provides limited protection if an SMS-only reset can remove it.
Current NIST guidance treats telephone-network delivery of authentication secrets as restricted and treats setting or changing a registered number as binding a new authenticator. These are technical guidelines, not an Omani legal ban on SMS.
Require appropriate reauthentication using an existing enrolled factor. Verify receipt at the new number separately: that demonstrates reachability, not ownership of the existing account.
Notify the customer through an established independent channel. Consider additional checks or proportionate delays for sensitive accounts. Customers who have lost their old number need a controlled recovery route that does not assume whoever now receives its codes is the original user.
After a verified change, remove the old number from active authentication and recovery routes. Address pending reset challenges and synchronize relevant downstream systems.
Historical records may need retention for defined purposes. Retaining an audit record should not leave the historical number usable for login, recovery or operational messaging.
Test a new-number holder, a returning dormant customer, a lost-number report and a number already associated with another account. Use authorized test accounts and controlled numbers.
Protect reset endpoints against automated discovery and repeated requests. Keep public responses generic enough to avoid revealing another customer’s account. Give support teams a documented dispute process rather than allowing them to resolve conflicting claims solely through an SMS code.
Review the whole change: verify the customer, connect the new number and retire the old access routes.
Reauthenticate with an existing enrolled factor. A code to the new number alone does not establish account ownership.
Confirm receipt at the replacement number before enabling it for its intended account functions.
Use an established independent channel, with clear instructions for reporting an unauthorized change.
Remove the old number from active login and recovery. Invalidate pending challenges tied to it.
Update relevant identity, support and messaging systems so they stop relying on the former number.
Test controlled recovery for customers who cannot access their old number, including disputed associations.
Use this checklist to guide a product review. These recommendations are not a compliance certification or requirements created by Oman’s consultation.
Where possible, complete account changes while the old line remains under your control:
For company-issued numbers, make this part of staff offboarding and device reassignment. Maintain a record of business systems linked to each number so a returned SIM does not silently become another employee’s access credential.
If the old number has already been reassigned, use each service’s official recovery channel. Asking the new subscriber to forward security codes is not a reliable recovery process.
Oman’s proposal places an important dependency under scrutiny: digital accounts can outlast the telecom subscriptions on which their security relies.
Operators and platforms responding by 2 October 2026 should focus on workable verification, proportionate account handling, disputed associations, IoT scope and treatment of existing number pools. The consultation deadline is not an implementation deadline.
Product teams can already examine a concrete question: What could someone do in our service if they legitimately received a former customer’s phone number?
Answering it across login, recovery, support and transaction approval produces a more useful remediation plan than checking whether the product merely “has MFA”. For wider jurisdictional context, see our guide to Middle East data protection laws.
Kooch’s ongoing privacy and compliance operations support helps teams connect privacy controls with operational responsibilities and remediation evidence. Talk to Kooch about reviewing how number changes and account recovery fit into your privacy and security processes.
Primary materials checked on 8 September 2026:
