What should security teams do first when a phone number may have been swapped?

Stop the reset or recovery action and verify whether the number was recently ported or moved to a new SIM. If it was, treat the channel as compromised and move verification to an authoritative source that does not depend on the phone. Completing the request first and reviewing later gives the attacker the account before anyone can intervene.

Why a Swapped Number Becomes a Trust Problem, Not Just a Telecom Problem

When a phone number may have been swapped, the issue is not simply whether the number still rings. The real risk is that a recovery or reset path may now trust a channel the user no longer controls. That matters because many account recovery flows treat SMS or voice as proof of possession, even though a port-out, SIM swap, or number recycling event can break that assumption without warning.

Security teams should treat the number as a potentially compromised authentication factor until they confirm otherwise, and they should pause any workflow that would hand control to whoever receives the next code. The right question is whether the recovery step still binds to the intended person, not whether the phone service appears active. OWASP Non-Human Identity Top 10 is not a direct telecom guide, but it is useful where teams also need to think clearly about trusted identities and secrets that should not be treated as durable proof of control. In practice, many teams discover the swap only after a reset has already been completed and the attacker has used the new access to lock everyone else out.

How Teams Should Re-route Verification After a Number Swap Is Suspected

The first operational move is to stop any pending reset, recovery, or step-up request that depends on that phone number. If the number has been ported, reassigned, or moved to a new SIM, the message or call path can no longer be treated as a reliable control point. At that moment, the team should switch to an authoritative verification path that is independent of the affected number, such as an in-person check, a previously enrolled high-assurance factor, or a documented help desk process with strong identity proofing.

What often goes wrong is that teams focus on proving whether the phone still belongs to the user in the abstract, instead of protecting the account session that is already in motion. That distinction matters because a live fraudster can exploit delay, and recovery flows are usually time-sensitive. The safest operational posture is to preserve the current state, verify the ownership change separately, and only then decide whether to restore the number as a trusted contact point.

Freeze the recovery request before any new credential is issued.
Check for porting, SIM replacement, or recent carrier change signals.
Move the user to a non-phone verification path if available.
Record the event as a trust failure, not only a telecom event.

This guidance breaks down when the organisation has no alternative authoritative channel, because then the team is forced into a slower exception process that must be designed in advance.

Where the Usual Playbook Breaks Down

Tighter recovery controls often increase support burden, requiring organisations to balance account safety against user friction and help desk throughput.

The standard approach becomes weaker when the number is used as both a contact method and a recovery factor, because a single compromise can affect multiple workflows at once. It also breaks down where the account is high value and attackers are likely to act quickly after the swap, since even a short delay can be enough to complete takeover. Guidance versus consensus is still unsettled on whether SMS should ever be accepted as a primary recovery trust anchor for sensitive accounts, but there is broad agreement that it should not be the only path when stronger options exist.

Teams should also be careful not to confuse “the user still has the same number” with “the user still controls the channel.” Number recycling, rerouting, and forwarding can all create false confidence. The practical edge case is a number that appears valid in logs but is no longer valid as an identity signal, which is why the verification decision should depend on trust, not just on connectivity. For teams handling identity recovery at scale, the most common failure is not missing the swap itself, but allowing a familiar phone number to override stronger evidence of compromise.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6.3 — Account Access Control Management	A swapped number can defeat account recovery and access control checks.
Recommendation — Remove phone-based recovery paths from sensitive accounts and require stronger verification.
NIST CSF 2.0	PR.AA-1 — Identity and Access Management	The question is about preserving trustworthy access decisions after a factor swap.
	PR.DS-4 — Data is Protected	Recovery abuse can expose credentials and protected account data.
Recommendation — Revalidate access assumptions before allowing recovery to proceed. Protect recovery workflows so a compromised channel cannot disclose protected information.
MITRE ATT&CK	T1636 — Modify Authentication Process	Attackers abuse weak recovery channels to redirect authentication.
Recommendation — Hunt for authentication changes that reroute recovery to attacker-controlled channels.
OWASP Non-Human Identity Top 10	NHI-01 — Inventory and Ownership	A phone number used in recovery can become an unmanaged trust dependency.
Recommendation — Inventory recovery dependencies and revoke trust when ownership changes are suspected.

Practitioner Guidance

What to prioritise: Put the recovery request on hold first, then decide whether the phone number is still a trustworthy factor. If the answer is uncertain, treat it as untrusted until a separate proofing path clears the user.

Decision rule: If there is credible evidence of porting, SIM replacement, or sudden loss of control, do not continue the same recovery flow. Escalate to a higher-assurance process and require confirmation from a channel that the swap could not affect.

What practitioners underestimate: The operational risk is often not the swap itself, but the speed of account takeover after the swap. The shorter the recovery window, the more important it is to stop first and verify later.

Practitioner takeaway: Treat a suspected number swap as a trust reversal event, not a minor verification anomaly, because once the recovery path is compromised the attacker can often use the organisation’s own workflow to complete the takeover.