Exchange account security: four settings, in this priority order
Everyone knows the list. Almost nobody knows why it is in that order, which is why people do the easy three and skip the one that matters.
In one line: app-based two-factor, then a withdrawal whitelist, then an anti-phishing code, then session hygiene. In that order, because each one closes a different door and the first two close the ones that actually get used.
The thing most lists get wrong: SMS two-factor is not the good version of two-factor. It is the version with a known, cheap, widely-used bypass.
1. App-based two-factor, not SMS
If you only ever change one setting, change this one.
SMS-delivered codes have a failure mode that has nothing to do with your phone's security: SIM swap. An attacker persuades a mobile carrier to move your number to a SIM they control — through social engineering, a bribed employee, or a weak identity check at a retail counter. Your handset does not need to be touched. It simply stops receiving service, and every code sent to that number arrives somewhere else.
This is not a theoretical concern. The US National Institute of Standards and Technology treats out-of-band authentication over the public switched telephone network as a restricted authenticator in its digital identity guidelines — a formal designation meaning it carries risks that make it unsuitable as a general recommendation. That position has been in place since the 800-63-3 generation and is carried forward in the current NIST SP 800-63B-4 revision.
An authenticator app generates codes on your device from a seed that never travels over the phone network, so the SIM-swap path simply does not apply. A hardware security key is stronger again, because it also refuses to authenticate to a look-alike domain — which defeats the phishing case as well as the SIM case.
Where the platform requires SMS as a mandatory factor, keep it, but add an app-based factor as well and make sure withdrawals require the app one. The goal is not to have no SMS; it is to have nothing valuable protected by SMS alone.
2. The withdrawal whitelist
A whitelist restricts withdrawals to addresses you have pre-approved, and imposes a waiting period before a newly added address can be used.
Understand what it actually buys you, because it is not what people assume. It does not stop an account compromise. What it does is convert an instant total loss into a delayed one, and put a window between the two. An attacker who gets in cannot send funds anywhere immediately; they have to add an address and wait. That waiting period is your entire opportunity to notice the notification, log in, and stop it.
That is the whole value proposition, and it is enough. Most account drains succeed because they complete in minutes, before the owner sees anything.
The practical cost is real: you cannot withdraw to a new address on impulse. Our position is that this is a feature, not a bug — the withdrawals people most regret are the impulsive ones, and a mandatory delay is the cheapest protection against your own bad afternoon that exists.
3. The anti-phishing code
You choose a short string; the platform includes it in the emails it sends you. Simple, and more useful than it looks.
Its power is that it is a negative test. A phishing email can copy the layout, the logo, the sender name and the tone perfectly — all of that is public. It cannot know a string that exists only between you and the platform. So the rule becomes mechanical: no code, not genuine. You do not have to assess how convincing the email looks, which is good, because assessing that is exactly what humans are bad at under time pressure.
Two things to hold to. Pick something that is not guessable from your public life — not your username, not your dog. And apply the rule even when the email is alarming, because alarming is the point of it.
4. Devices, sessions and API keys
Lower priority, still worth ten minutes.
- Review the active session and device list. The value is baseline knowledge: if you know what is supposed to be there, an unfamiliar entry means something. If you have never looked, it means nothing.
- Revoke API keys you are not using. Every live key is a credential that can act without your password or your second factor. If you experimented with a bot or a portfolio tracker once, that key is probably still there.
- Never grant withdrawal permission to an API key unless you genuinely require it, and if you do, bind it to an IP address. A trading-only key that leaks is a bad day; a withdrawal-enabled key that leaks is the end of the account.
- Sign out of devices you no longer have. Old phones, work laptops, a friend's computer.
The back door nobody hardens
Here is the part that undoes everything above: your email account.
Account recovery flows generally run through email. Password resets, two-factor resets, security-setting changes — all of them tend to be confirmable from the mailbox. So an attacker who controls your email does not need to defeat your authenticator app; they can often ask politely for a new one.
Which means the exchange account's real security level is the minimum of its own settings and your email's settings. Hardening one and ignoring the other achieves nothing. Put app-based or hardware two-factor on the email too, use a unique password, and check its forwarding rules and recovery addresses — silently adding a forwarding rule is a standard move precisely because nobody ever looks.
The same applies if you signed up using a Google, Apple or Telegram account. That account is now a key to this one, and it needs the same treatment.
Why this order, and what each one does not do
Security advice usually arrives as a list of equals. It is not a list of equals. Each of these four settings blocks a different attack, and three of them are useless against the attack the fourth one stops. Knowing which is which is what lets you stop at the right point rather than either doing nothing or buying a hardware key you will not use.
| Setting | Stops | Does nothing against |
|---|---|---|
| App-based two-factor | Credential stuffing, a leaked password, SIM swap | You typing the code into a phishing page yourself. The code is a one-time secret, and handing it over in real time defeats it entirely. |
| Withdrawal whitelist | An attacker who is fully inside the account draining it immediately | You adding a bad address yourself, or a clipboard swap at the moment you add one. The delay protects the account, not your attention. |
| Anti-phishing code | Fake emails, because a genuine one carries the string and a fake one cannot | Phishing that arrives by SMS, phone call or messaging app, where there is no email to inspect. |
| Device and session review | Nothing, on its own | Everything, on its own. Its value is detection: it tells you an intrusion happened. That is worth something only if you look. |
Read the right-hand column carefully, because it contains the actual lesson: every one of these fails against a person who is persuaded. That is why the last section of this page is about the conversation rather than the configuration. The settings raise the cost of attacking you from outside. Nothing in a settings menu defends against you being talked into it.
What we would add if you want a fifth thing
A hardware security key, if the account and the platform support one. It is the only widely available factor that resists real-time phishing, because the key checks the domain it is talking to before it will respond — which is precisely the check a human under time pressure fails. It costs money and it needs a backup key, so we put it fifth rather than first. But if you have worked through the four above and want the next real step, this is it, and everything else on the usual list is decoration next to it.
API keys, if you ever create one
Most people never will, and if that is you, skip this. For everyone else it deserves more than a line, because an API key is the one thing on an exchange account that can drain it without any login, any two-factor prompt or any interaction from you at all.
- Never enable withdrawal permission. Trading permission and withdrawal permission are separate switches, and almost no legitimate use case needs the second. A key with trade-only permission that leaks costs you a bad trade; a key with withdrawal permission that leaks costs you the balance.
- Bind the key to an IP address where you can. This turns a leaked key into a useless string for anyone not sitting on that address.
- One key per purpose, and delete the ones you have stopped using. Old keys attached to a tool you abandoned two years ago are pure exposure with zero benefit.
- Treat a key like a password, because it is one. Not in a chat message, not in a screenshot, not in a repository, not pasted into a website that offers to analyse your portfolio.
- Any site or app asking for an API key from another platform deserves suspicion by default. Some are legitimate. The question to ask is what permissions it wants, and if the answer includes withdrawal, the conversation is over.
Why this order, and what each one does not do
Security advice usually arrives as a list of equals. It is not a list of equals. Each of these four settings blocks a different attack, and three of them are useless against the attack the fourth one stops. Knowing which is which is what lets you stop at the right point rather than either doing nothing or buying a hardware key you will not use.
| Setting | Stops | Does nothing against |
|---|---|---|
| App-based two-factor | Credential stuffing, a leaked password, SIM swap | You typing the code into a phishing page yourself. The code is a one-time secret, and handing it over in real time defeats it entirely. |
| Withdrawal whitelist | An attacker who is fully inside the account draining it immediately | You adding a bad address yourself, or a clipboard swap at the moment you add one. The delay protects the account, not your attention. |
| Anti-phishing code | Fake emails, because a genuine one carries the string and a fake one cannot | Phishing that arrives by SMS, phone call or messaging app, where there is no email to inspect. |
| Device and session review | Nothing, on its own | Everything, on its own. Its value is detection: it tells you an intrusion happened. That is worth something only if you look. |
Read the right-hand column carefully, because it contains the actual lesson: every one of these fails against a person who is persuaded. That is why the last section of this page is about the conversation rather than the configuration. The settings raise the cost of attacking you from outside. Nothing in a settings menu defends against you being talked into it.
What we would add if you want a fifth thing
A hardware security key, if the account and the platform support one. It is the only widely available factor that resists real-time phishing, because the key checks the domain it is talking to before it will respond — which is precisely the check a human under time pressure fails. It costs money and it needs a backup key, so we put it fifth rather than first. But if you have worked through the four above and want the next real step, this is it, and everything else on the usual list is decoration next to it.
API keys, if you ever create one
Most people never will, and if that is you, skip this. For everyone else it deserves more than a line, because an API key is the one thing on an exchange account that can drain it without any login, any two-factor prompt or any interaction from you at all.
- Never enable withdrawal permission. Trading permission and withdrawal permission are separate switches, and almost no legitimate use case needs the second. A key with trade-only permission that leaks costs you a bad trade; a key with withdrawal permission that leaks costs you the balance.
- Bind the key to an IP address where you can. This turns a leaked key into a useless string for anyone not sitting on that address.
- One key per purpose, and delete the ones you have stopped using. Old keys attached to a tool you abandoned two years ago are pure exposure with zero benefit.
- Treat a key like a password, because it is one. Not in a chat message, not in a screenshot, not in a repository, not pasted into a website that offers to analyse your portfolio.
- Any site or app asking for an API key from another platform deserves suspicion by default. Some are legitimate. The question to ask is what permissions it wants, and if the answer includes withdrawal, the conversation is over.
What the attack actually looks like
Almost nothing in this space involves breaking cryptography. It involves persuading you to do something. The US Federal Trade Commission's consumer guidance on crypto scams describes the same small set of patterns that show up again and again, and they are recognisable once you know the shape:
- Urgency. Your account will be suspended, your funds are at risk, act now. Manufactured time pressure exists to stop you checking. Genuine security processes do not need you to hurry.
- A different channel. Someone claiming to be support who reaches you first, on a messaging app. Real support does not contact you out of nowhere and does not move you to Telegram.
- Asking for a credential. A password, a verification code, a seed phrase, a private key, an API key. No legitimate party asks for any of these, ever, for any reason. Read a request for one as proof of fraud and stop reading.
- A guaranteed return. Anything promising a fixed, risk-free yield. The claim itself is the tell, regardless of who is making it.
- Screen sharing or remote access. "Let me help you fix it." Nothing that requires remote access to your device is help.
Two habits close most of it. Never reach an exchange through a link you were sent — type the address or use your own bookmark. And when something feels urgent, take the thirty seconds to log in independently and check whether the alarming thing is actually there. It almost never is.
What the good version sounds like
The scripts that work are not the badly spelled ones. A competent approach opens with something true — a real recent login from a real city, a real withdrawal you actually made — because a verifiable fact buys credibility for the false part that follows. It is polite, it is patient, and it never asks for anything on the first contact.
Then it produces the pivot. There is a security problem with your account; a specialist will call; the specialist will help you move your funds to a "secure address" while the investigation runs. Every step sounds like protection, and the last step is the theft. The single structural tell is the direction of travel: a genuine security process never ends with your money in a new place. If the resolution of a security incident involves you moving funds anywhere, you are not in a security incident.
The three-second rule for any inbound contact
You do not have to be clever about this, and you should not try to be. Whatever arrives — email, SMS, call, message, in-app notice — do not act on it in that channel. Close it. Reach the platform yourself, the way you always do, and see whether the thing exists. That single habit does not require you to judge whether the message was real, which is the judgement people reliably get wrong under pressure.
Our position on the popular advice to "verify the sender's address": it is weak, and we do not lead with it. Display names are trivially forged, addresses can be near-identical, and inspecting headers is not something anyone does at eight in the morning. Do not authenticate the message. Authenticate the channel, by choosing it yourself.
Sources
- US National Institute of Standards and Technology, SP 800-63B, Digital Identity Guidelines: Authentication and Authenticator Management — linked in the two-factor section above; the basis for preferring an authenticator app or hardware key over one-time codes sent over the public telephone network.
- US Federal Trade Commission, What to know about cryptocurrency and scams — linked in the section on scam patterns above; consumer guidance describing the recurring patterns summarised there.
- Binance, official help centre — for how a specific setting behaves on your account, which differs by region and changes.
Nothing on this page is specific to one platform except where it names one. The reasoning is about authentication and social engineering generally, and it applies unchanged to any account holding money.