Account Security and SIM-Swap Risk

Reviewed and updated September 18, 2026 by the SmartCryptoEarnings editorial team · editorial policy

Self-custody protects you from an exchange failing, but most people still hold accounts at exchanges and email providers. Those accounts are attacked through the phone number and the email address far more often than through the password.

How a SIM swap works

An attacker gathers enough personal information to convince a mobile carrier to transfer your number to a SIM they control, sometimes with help from a bribed or careless employee. Your phone loses service; their device starts receiving your calls and SMS codes.

With the number, they reset your email password, then use the email account to reset everything else. The Federal Communications Commission has adopted rules requiring carriers to authenticate customers before transferring a number, but the risk has not been eliminated.

Harden the accounts, in this order

Replace SMS two-factor authentication with an authenticator app or, better, a hardware security key wherever the service supports it.
Secure the email address behind those accounts first — it is the master key to everything else.
Add a carrier-level port-out PIN or account lock with your mobile provider.
Use a unique, long password per service, stored in a password manager.
Enable withdrawal address whitelisting and a withdrawal delay on exchanges that offer them.
Turn on login and withdrawal notifications so an unexpected attempt is visible immediately.

Never use SMS as the only recovery method on an account that controls money.

Reduce what an attacker can learn about you

Avoid posting about holdings, gains or platform use under an identity linked to your real name.
Keep the email used for exchanges separate from your public or everyday address.
Be cautious with answers to security questions that are discoverable online.
Treat unexpected password-reset emails as a live warning, not noise.

Passwords and the password manager

Every financial account needs a password used nowhere else. Reuse is what turns someone else's breach into your loss, because credential-stuffing tools try leaked pairs across hundreds of sites automatically.
A password manager exists so that unique, long, random passwords are practical. Federal guidance has moved away from forced periodic changes and complexity rules toward length and uniqueness, with changes made when there is evidence of compromise.
The manager's own master password must be long, unique and memorised, with its two-factor protection enabled. Never store a wallet recovery phrase in it — a password manager protects logins, not self-custody secrets.
Keep the email address behind financial accounts separate from your public one, and secure it first: whoever controls the mailbox controls password resets everywhere else.

Passkeys and what they change

Fact: a passkey is a FIDO2/WebAuthn credential stored on your device or in a synced keychain, unlocked by your device biometric or PIN. There is no shared secret to type, to read aloud or to intercept, and the credential is bound to the site's real domain — so a look-alike login page cannot use it.

That domain binding is the substantive improvement over codes. A code can be relayed to a phishing page in real time; a passkey cannot, because the browser will not release it to the wrong origin.

Limits worth knowing before you rely on one. A synced passkey is only as protected as the account and device that hold it, so that account needs its own strong protection. A device-bound passkey is lost with the device unless a second credential or backup code exists. And where a platform still allows SMS as a fallback for the same account, the weaker route remains available to an attacker — passkeys do not remove a recovery path you leave open.

Support varies: some exchanges offer passkeys as a full second factor, some as a password replacement only, and some not at all. Editorial guidance: check what your specific platform implements rather than assuming, and never treat any single method as preventing account takeover on its own.

Authentication methods compared on the properties that matter in practice.
Method	Resists phishing of the code?	Survives a SIM swap?	Main limitation
Passkey (FIDO2/WebAuthn)	Yes — bound to the real domain.	Yes.	Platform support is uneven; recovery depends on sync account or backup credentials.
Hardware security key	Yes — bound to the real domain.	Yes.	Costs money; you need a second key or backup codes in case one is lost.
Authenticator app (TOTP)	No — a code can be relayed to a phishing page.	Yes — not tied to a phone number.	Codes can be socially engineered out of you; back up the seeds you enrol.
Push approval	Partially — no code to steal, but prompts can be spammed until accepted.	Usually, if tied to an app rather than a number.	Approval fatigue. Approve nothing you did not personally trigger.
SMS code	No.	No — the code follows the number.	The weakest option; avoid as a sole factor or recovery route where anything better exists.

Second factors, ranked

Hardware security key (FIDO2/WebAuthn) — strongest available to consumers, because the key checks the site's real domain and therefore cannot be handed to a phishing page.
Authenticator app — codes generated on your device, not tied to a phone number, so a SIM swap does not capture them. A large improvement over SMS.
Push approval — convenient, but vulnerable to fatigue attacks where an attacker sends repeated prompts until one is accepted. Approve nothing you did not personally trigger.
SMS — the weakest, because the code follows the phone number rather than you. Use it only where nothing better is offered, and never as the sole recovery route.
Save the recovery or backup codes issued at enrolment, offline and away from the device itself. Losing the second factor without them can lock you out permanently.

Platform settings that limit the damage

Withdrawal address allowlisting — restricts withdrawals to addresses you pre-approved, usually with a waiting period before a new one becomes usable. That delay is often the only window in which a takeover can be stopped.
Withdrawal and login notifications — an unexpected alert is your earliest warning.
API keys — created for automated trading, they are also a quiet way to drain an account. Issue the narrowest permissions needed, never enable withdrawal permission unless it is genuinely required, restrict to known IP addresses where supported, and delete keys you no longer use.
Active sessions and trusted devices — review the list periodically and revoke anything unfamiliar, then change the password afterwards so the removed session cannot simply return.
Anti-phishing codes — where an exchange offers one, it puts a phrase only you know into their genuine emails, making spoofed messages easy to spot.

Phishing, fake support and browser extensions

Reach the platform through your own bookmark, always. Search advertising is a routine delivery route for cloned login pages, and a look-alike domain is unremarkable at a glance.
Real support never contacts you first asking for a code, a password, a recovery phrase or remote access to your computer. Treat any inbound 'support' contact — chat, phone, social media reply — as hostile until you have opened a ticket yourself from inside your account.
A code read aloud or typed into a page is a code given away. Legitimate staff never need it.
Browser extensions can read and alter every page you open, including account pages. Install as few as possible, only from official listings, and review what is installed periodically — extensions can change hands and become malicious after an update.
Do not sign into financial accounts from shared or public computers, and be deliberate about which browser profile you use for them.

Social engineering targets urgency. A message that requires you to act within minutes is applying the pressure on purpose; verifying independently costs nothing.

If your phone suddenly loses service

Contact your carrier immediately from another line and report a suspected unauthorized port.
From a different device, change your email password and revoke active sessions.
Remove SMS-based two-factor authentication and re-enroll an authenticator app or security key.
Check exchange accounts for new withdrawal addresses, new API keys and pending withdrawals.
File a report with the FBI's Internet Crime Complaint Center if funds were taken.

If you suspect an account is already compromised

Work from a device you have reason to trust, not the one you suspect.
Change the email password first and sign out all sessions there, then do the same on the platform account.
Re-enrol two-factor authentication from scratch so any attacker-controlled factor is removed, and store the new backup codes offline.
Delete every API key and review withdrawal allowlist entries, removing anything you did not add.
Check for altered account email, phone number, notification settings or mail forwarding rules — these are commonly changed to hide activity.
Contact the platform through its official site, from inside your account where possible, and record ticket numbers, timestamps and transaction hashes.
Report to the FBI's Internet Crime Complaint Center and the FTC if funds were taken, and keep the reference numbers.
Never engage anyone offering paid recovery afterwards; follow-up scams target people who have just been hit.

Frequently Asked Questions

Are passkeys better than an authenticator app?

For phishing resistance, yes: a passkey is tied to the real domain, so it cannot be handed to a cloned login page, while a one-time code can be. It is not a complete defence — recovery routes, a synced keychain account and any SMS fallback left enabled are all still part of the attack surface, and support differs by platform.

Is an authenticator app enough?

It is a large improvement over SMS because the codes are not tied to your phone number. A hardware security key is stronger still, since it also resists phishing of the code itself.

Does holding crypto in self-custody remove this risk?

It removes the exchange account from the attack path, but your email and any cloud backups remain sensitive — which is one more reason a recovery phrase must never be stored in either.

Are password managers safe to use for exchange accounts?

For logins, yes — they make unique, long passwords practical, and reuse is a far larger real-world risk than the manager itself. Protect the master password with its own strong second factor, and never keep a wallet recovery phrase inside it.

Should I enable API keys on my exchange account?

Only if you actually need automated access. Give the key the narrowest permissions possible, avoid withdrawal permission, restrict it by IP address where the platform allows, and delete keys you stopped using.

What is a withdrawal allowlist and is it worth enabling?

It limits withdrawals to addresses you approved in advance, usually with a delay before a newly added address can be used. That delay is frequently the only thing that stops an account takeover from becoming a loss.

Sources

Spotted something out of date? See our corrections policy and fact-checking policy.

Continue reading

Educational information only. Nothing here is financial, legal or tax advice.