Advice about crypto security concentrates on keys and wallets, which is where the value sits and not where the attacks start. The realistic path into a trading account runs through an email address, a reused password, or a device that also does everything else, and none of those are improved by better custody.
Every account you hold has a recovery path, and almost all of them terminate at an email address. Somebody who controls that address can reset passwords on platforms, on the password manager, on the phone account, and on the services those depend on in turn. It is the root of the tree, and it is usually protected considerably worse than the accounts hanging off it.
The asymmetry is worth stating because it is so consistent. Traders who use a hardware wallet, a unique password on every venue, and an authenticator app frequently protect the email account with a password they have had for years and a recovery phone number. An attacker does not need to defeat any of the good protections; they need the weakest thing in the chain, and the chain terminates at the mailbox.
The fix is unglamorous and it is the single highest-value change available. Put the strongest available second factor on the email account, preferably a physical security key rather than an application. Remove the phone number from its recovery options. And use an address for financial accounts that is not the one you give to anybody, which removes it from every breach list and every phishing target list at once.
Your exchange account is as secure as your email account, whatever you did to the exchange account.
When you log in, the service issues a session token to your browser so it does not have to ask again on every page. That token is a credential in its own right: anybody holding a copy is logged in as you, and crucially, changing your password does not necessarily invalidate it. Many services keep existing sessions alive after a password change, which means the standard response to a suspected compromise leaves the attacker exactly where they were.
This is how a substantial share of account takeovers persist after the victim believes they have fixed the problem. Malware that steals browser data takes tokens rather than passwords, precisely because tokens skip the second factor entirely. There is nothing to phish and no code to intercept; the session is already authenticated.
The practical response is to know where the log out of all sessions or terminate all devices control is on every platform you use, and to use it as the first step of any security response rather than the password reset. Reviewing the active session list periodically is also worth the minute it takes: unfamiliar locations and devices in that list are the earliest visible signal of a problem.
Credential stuffing is the most common attack on financial accounts and it involves no cleverness at all. Large collections of email addresses and passwords from breaches at unrelated services are tried, automatically, against every platform worth trying. It succeeds whenever somebody used the same password twice, and enough people do that the approach remains economically worthwhile at industrial scale.
The defence is a unique password per service, which is only practical with a password manager, and the objection people raise is that the manager becomes a single point of failure. That objection is correct and the alternative is worse: a manager with a strong master password and a second factor is a much smaller target than a dozen services sharing one password, and the failure mode of reuse is not hypothetical, it is running continuously against every login form on the internet.
It is also worth checking whether your addresses appear in known breaches, which several public services will tell you. An address that appears in a breach list is receiving targeted attempts whether or not anything has succeeded, and knowing that changes how much the protections on it matter.
A computer that trades is also, for most people, a computer that browses, installs things, opens attachments, and is occasionally used by somebody else. Every one of those activities is a path onto the machine, and the machine has your sessions, your clipboard, and whatever your browser has stored.
The argument for separation is stronger than it sounds and cheaper than people expect. A separate browser profile used only for financial accounts, with no extensions and no other browsing, removes most of the exposure at zero cost and thirty seconds of setup. A separate user account on the same machine is better. A separate machine is better still and is genuinely worth it above a certain balance, which each person can decide for themselves.
The specific risk worth naming is browser extensions, because they are the one thing people install casually that has permission to read and modify every page they open. Extensions change ownership, receive updates written by somebody other than the original author, and do so silently. Any extension on a profile that touches financial accounts should be one you actively need, reviewed periodically, and the list should be short enough to review in a minute.
Take a piece of paper and write down, for each account that matters, what would let somebody else get into it. The password, then what resets the password, then what protects that. Follow each branch until it terminates at something physical: a device you hold, a key in a drawer, a phone in your pocket.
The exercise takes twenty minutes and it always finds something. The usual discoveries are an email address protected only by a password, a phone number that can reset three separate things, a password manager whose recovery goes back to the email, or a second factor whose backup codes are stored in the account they protect. Each of those is a loop or a single point that the individual protections were hiding.
There is a second question the same diagram answers, and it is the one people postpone. If you were not available, who could reach these accounts, and how. A chain that terminates only in your head is secure against everybody including your family, and that is a decision worth taking deliberately rather than by default.
Every account has a chain that ends somewhere physical. Nobody draws it, and drawing it always reveals one link doing far more work than the others.
Automated trading requires an API key, and an API key is a login that never expires, never prompts for a second factor, and sits in a configuration file. It survives every password change and every new device, and it is invisible in most account security screens unless you go looking for it.
The three settings that make it manageable are all available and rarely used. Restrict the key to specific network addresses, so that a copy of it is useless from anywhere else. Never grant withdrawal rights unless something genuinely requires them, because trading rights alone cannot move funds off the platform. And delete keys nothing is using, which is most of them after a year.
The same reasoning covers anything else with standing access: connected applications, portfolio trackers with read access, tax tools, and anything that once asked for a key and was never revisited. Each of them is a credential you issued, held by somebody whose security you do not control, and the list is longer than anybody remembers.
The order matters more than the individual steps, because doing them in the wrong sequence leaves the attacker in place. Terminate all sessions first, on the affected platform and on the email account, because that removes access that a password change would not. Then change the password. Then rotate the second factor if it could have been compromised. Then review and revoke API keys and connected applications.
Only after that is it worth investigating what happened, and it is worth doing rather than skipping. Check the login history for locations and devices, check whether withdrawal addresses were added, and check whether email forwarding rules or filters were created, which is a common step attackers take to hide the alerts that follow.
The one action to take before any of it, if funds are at risk and the platform supports it, is to lock withdrawals or freeze the account. Most venues provide a way to do this instantly, it is reversible, and it buys the time that everything else requires.
Nothing above needs doing continuously, and all of it decays. Once a year, or after any incident anywhere in your accounts, walk the list. Active sessions on every platform. API keys and connected applications, deleting what is unused. Recovery options on the email account, confirming the phone number is not among them. Withdrawal address whitelists. And the backup codes for every second factor, confirming they exist and are not stored inside the account they protect.
The reason to schedule it rather than react is that the failures accumulate quietly. A key created for a tool abandoned eight months ago, a session on a laptop that was sold, an application authorised once and forgotten: none of these announce themselves, and each is a standing credential held by somebody. An hour a year removes them, which is a better return than almost anything else on this list.
The email address your accounts recover to. It sits at the root of nearly every recovery chain, so somebody controlling it can reset the platforms, the password manager, and the services those depend on. It is also usually protected worse than the accounts hanging off it.
Because session tokens frequently survive a password change. A token is a credential in its own right and it skips the second factor entirely, which is why malware steals tokens rather than passwords. Terminate all sessions first, then change the password, not the other way round.
Yes, and the alternative is worse. A manager with a strong master password and a second factor is a much smaller target than a dozen services sharing one password, and credential stuffing against reused passwords runs continuously and at industrial scale against every login form.
A separate browser profile with no extensions removes most of the exposure at no cost and thirty seconds of setup. A separate user account is better, a separate machine better still. Where the line sits depends on the balance at risk, and the cheap version captures most of the benefit.
Because they have permission to read and modify every page you open, and they are installed casually. Extensions change ownership and receive updates written by somebody other than the original author, silently. Any profile that touches financial accounts should carry a list short enough to review in a minute.
Lock withdrawals or freeze the account if the platform allows it, since that is instant and reversible. Then terminate all sessions on the platform and on your email. Then change passwords, rotate the second factor, and revoke API keys and connected applications. The order matters because a password change alone leaves sessions alive.
As logins that never expire and never prompt for a second factor. Restrict each to specific network addresses, never grant withdrawal rights unless something genuinely needs them, and delete the ones nothing is using, which is most of them after a year. They are invisible in most security screens unless you look.
Anywhere except inside the account they protect, which is the most common mistake. Printed and stored physically is the ordinary answer. Storing them in an email account that the same second factor protects creates a loop that fails exactly when you need them.