Most account takeovers are not clever. They are the result of a setting left at its default. Exchange security settings decide how much damage a stolen password can do, and the difference between an account that survives a leak and one that does not is usually four switches that take a single sitting to configure.
The useful way to think about exchange security settings is in layers: something you know, something you hold, and a rule about where money is allowed to go. A password is one layer, and it is the layer most likely to leak through reuse or a convincing login page. The settings below add layers that still hold when the password does not.
- A withdrawal allowlist is the only setting that still protects you after an attacker has your password and your 2FA code.
- SMS codes are the weakest second factor in common use, because a phone number can be moved to another device.
- An anti-phishing code turns a fake login page into an obviously broken one.
- Settings only help if you review them; an allowlist from two years ago is a liability, not a control.
The four exchange security settings that carry the load
These four cover the realistic attack paths: credential stuffing, phishing, SIM swap, and session theft. Everything else is refinement.
1. Withdrawal address allowlist
Also called a whitelist, this restricts withdrawals to addresses you have pre-registered. An attacker who has taken over your account can trade, but cannot send funds anywhere new. That single constraint changes the outcome from “lost everything” to “inconvenient afternoon”.
Two details decide whether it works. First, the list must cover every destination you actually use, or you will disable it in frustration at the worst possible moment. Second, changes to the list should be subject to a holding period and confirmed by email, so an attacker cannot simply add their own address and wait.
2. Two-factor authentication that is not SMS
Use an authenticator app or a hardware security key, and keep SMS as a fallback only if the venue forces it. Codes tied to an app are generated on a device the attacker does not control; codes sent by text are generated by a phone number that can be reassigned.
Store the recovery codes for the authenticator somewhere offline. The most common way people lose access to their own account is losing the second factor, not being robbed of it.
3. Anti-phishing code and withdrawal emails
An anti-phishing code is a word or phrase you choose, which the venue then displays in every genuine email and on the login screen. If a message arrives without it, the message is fake, regardless of how convincing the rest of it looks.
Turn on email confirmation for withdrawals as well, on an address that is not your everyday inbox. The point is a second channel the attacker has to compromise, not a second password.
4. Device and session review
Every venue keeps a list of devices and active sessions. Open it monthly. Anything you do not recognise should be terminated immediately, along with a password change from a device you trust.
Session review catches the quiet case: an attacker who logged in, changed nothing, and is waiting. It also catches the mundane case, which is you, logged in on a laptop you no longer own.
| Setting | What it actually blocks | Effort to enable | Where it commonly fails |
|---|---|---|---|
| Withdrawal allowlist | Sending funds to a new address, even with full account access | Ten minutes, plus a delay per new address | Users disable it to make one urgent transfer and never re-enable it |
| Authenticator app 2FA | Login with a stolen password | Five minutes | Recovery codes stored in the same password manager as the password |
| Anti-phishing code | Credential capture on a lookalike domain | Two minutes | Users ignore the missing code because the page looks right |
| Device and session review | Persistent access after a compromise | Monthly, five minutes | Never opened after setup |
| Separate email address | Reuse of a leaked inbox against the exchange | Twenty minutes | Forwarded back to the main inbox, which defeats the point |
Exchange security settings that look stronger than they are
SMS two-factor authentication is the weakest link in the standard set, and it is the one most venues still offer first. The mechanism is the phone number itself: it can be ported to a new SIM by an attacker who convinces a carrier, and once it moves, every code goes to them.
This is not a theoretical attack. SIM swap fraud is common enough that carriers in many countries have added transfer locks and delays, and it still happens because the value of a compromised exchange account justifies the effort. If SMS is your only second factor, treat your account as protected by a password and a phone number, which is to say by one factor and a customer service desk.
Other settings flatter more than they protect. Login alerts are useful but reactive; they tell you something already happened. Long passwords without a manager encourage reuse. “Remember this device” checkboxes convert a two-factor login into a one-factor login on any machine you once used, which is precisely the machine an attacker may also use.
A setting you have not reviewed in a year is not a control. It is an assumption wearing the clothes of a control.
Settings that limit blast radius rather than access
Access controls stop someone getting in. Blast-radius controls decide how much they can reach if they do, and they are usually the settings retail users never touch.
A separate email address for exchange accounts is the cheapest of these. It keeps exchange correspondence out of an inbox that appears in breached marketing lists, and it makes a phishing attempt easier to spot because genuine mail never arrives at your everyday address.
Sub-accounts isolate risk in a way that feels bureaucratic until it matters. Keeping long-term holdings in an account with withdrawals locked and no API keys, while trading from a separate account with a small balance, means a compromise of the active account has a defined ceiling. API keys deserve the same treatment: grant read-only unless trading is required, disable withdrawals on every key, and set an IP allowlist so the key is useless anywhere except your own machine.
A setup order that takes one sitting
Do these in sequence, because each step assumes the one before it. The order matters more than the speed.
- Create the dedicated email address and change the exchange login to it, using a unique password from a manager.
- Enable authenticator-based 2FA, then store the recovery codes offline, on paper, in a different location from your devices.
- Set an anti-phishing code and turn on email confirmation for withdrawals.
- Register every withdrawal address you genuinely use, in advance, so the allowlist is never an obstacle.
- Review devices and sessions, terminate anything unfamiliar, then enable the allowlist and the delay on changes.
- Move long-term holdings to a sub-account with withdrawals and API keys disabled; audit API keys on the active account.
- Put a monthly reminder in your calendar to reopen all of it. Fifteen minutes, same day each month.
0 comments
No comments yet — ask a question and we will answer it here.