Protect the number, but also inspect every account path that treats the number as proof of identity.
A SIM swap transfers control of your phone number to an attacker-controlled SIM or eSIM. If a messaging account accepts SMS as sufficient proof for registration, login or recovery, the attacker may be able to exploit that path.
The outcome is not identical in every messenger. An additional registration lock, passkey, password or independent recovery secret can change what the attacker can do. Taking over a number also does not automatically decrypt every old conversation stored on your devices.
How number control becomes account control
The US Federal Trade Commission's SIM-swap guidance describes attackers persuading a carrier to activate a victim's number on another SIM. Incoming verification texts and calls can then reach the attacker.
The relevant weakness is the account's decision to trust that number. A service might use it for initial registration, an extra verification step or a password reset. These are different capabilities. Review all of them, including fallback options, rather than checking only the normal sign-in screen.
A sudden loss of cellular service or unexpected SIM-activation notice can be a warning sign, although outages and ordinary account problems can look similar. Confirm with the carrier through a known official route.
Separate impersonation from historical message access
A newly registered attacker-controlled device may be able to impersonate you or receive future communications, depending on the app's rules. Old history requires an additional explanation: a readable server copy, access to an encrypted backup and its key, a linked device, or a local copy.
| Asset | Does control of the number alone necessarily provide it? |
|---|---|
| Incoming SMS verification codes | Potentially, once the number has been transferred |
| Account registration or reset | Only if the service accepts that path without an independent requirement |
| Existing device sessions | Not automatically; session-management rules matter |
| Old E2EE chat history | Not automatically; the attacker still needs an accessible copy and the required keys |
| Future messages addressed to a newly accepted identity | A risk that depends on identity verification and account behaviour |
Key-change warnings and independently checking a contact's identity can help detect an unexpected new endpoint. They should not be dismissed simply because the familiar phone number remains the same.
What SRP contributes, and what it cannot promise
SRP authenticates knowledge of a password without sending that password in the intended exchange. If login genuinely requires an independent password and no SMS fallback bypasses it, stealing the number alone does not satisfy that requirement.
SRP itself does not specify the app's phone-number policy, reset process or support procedures. It does not make a weak password strong or prevent phishing code from reading text entered on a malicious page. The server's verifier also remains sensitive: RFC 5054 section 3.3 describes password guessing after verifier theft.
Passkeys and security keys are other possible ways to reduce dependence on SMS, where the service supports them. The FIDO Alliance's passkey explanation describes public-key credentials and phishing resistance. The actual account-recovery route still needs review, whichever normal login method is used.
Livara's documented separation
Livara's security page describes SRP login separately from its encrypted identity backup. Version 7 seals identity material before upload under a distinct recovery key and restores identity, not chat history. The threat model says a stolen password alone cannot restore those encryption keys.
These boundaries help distinguish authentication from decryption. They do not justify a promise that every account takeover route has been audited or that a carrier incident can have no effect. Check the current login and recovery options in the client; do not infer undocumented behaviour from a protocol name.
Post-quantum key establishment addresses a different problem: future attacks on captured encrypted traffic. It does not stop a carrier from moving a phone number or prevent an account from trusting an intercepted SMS.
Reduce the risk before an incident
- Protect the mobile-carrier account with a distinct PIN or password and available port-out controls.
- Prefer strong non-SMS authentication where supported, and retain recovery options safely.
- Review whether account recovery silently falls back to the phone number.
- Keep passwords unique and protect the email account used for recovery.
- Learn how the messenger displays linked devices, registration changes and peer-key changes.
If you suspect your number was taken
- Contact the carrier immediately using a verified channel and request investigation and recovery of the number.
- From a trusted device, secure affected accounts and review unknown sessions. Regaining the number does not necessarily terminate an attacker's existing session.
- Check recovery settings for changes and reset compromised credentials through official flows.
- Warn important contacts through another trusted route if impersonation is possible. Reverify cryptographic identities where they changed.
- Keep relevant notices and timestamps for support or reporting. Never send an OTP, password or recovery phrase to someone offering to “fix” the issue in a message.
The useful protection is an account design that does not let one stolen factor bypass every other control, combined with a clear recovery and session-response plan.
