Crypto Operational Security: The Complete Guide

Introduction

Buying a hardware wallet and moving funds into multisig are the two upgrades most self-custody guides treat as the finish line. They are not. They are the start of a longer discipline, because the device and the architecture only close two specific doors: a hardware wallet stops an attacker from lifting your private key off an internet-connected machine, and multisig stops any single key, device or person from being a single point of failure. Everything else sits outside what the hardware can do for you: how you verify a transaction before you sign it, how you recognise a phishing message that looks exactly like your wallet vendor, how you back up the seed so a house fire does not erase the portfolio, how you pass it on if you die. That outside layer is operational security, and in 2025 it is where the money actually left.

The evidence is consistent across every dataset that tracks self-custody losses. Scam Sniffer's 2025 annual report recorded roughly $83.85 million drained from wallets through phishing across about 106,000 victims. That is a steep 83% fall from the nearly $494 million lost in 2024, but still tens of millions taken from people who, in most cases, owned perfectly good hardware. The largest single incident of the year was a $6.5 million theft in September tied to one malicious Permit signature: not a broken Ledger, not a cracked seed, but a holder approving a token permission they had not read. In December 2025 a single trader lost $50 million in USDT to address poisoning, having copied a lookalike address out of their own transaction history. In each case the key was safe. The behaviour around the key was not.

This guide treats operational security as a stack you assemble deliberately, from the bottom up, and from your own situation rather than a one-size template. The bottom layer is the device, which our hardware wallet device baseline covers in full. The next layer up is architecture (whether a single key is enough or the portfolio has outgrown it), which our multisig architecture layer handles. This hub owns the layer above both of those: behaviour and process, the daily decisions that turn good hardware into a portfolio that survives contact with a determined attacker.

What follows is structured to be read in order. First, a working definition of operational security and why it is the layer that fails. Then a four-question framework for building a personal threat model, because the right amount of security for a £2,000 hot wallet differs from the right amount for a £400,000 cold portfolio. Then the four-layer OpSec stack itself, the spine of this cluster, each layer summarised with a link to the satellite that takes it deeper. After that, three sections on the threats that dominated 2025: wallet drainers and phishing, the account-level attacks that bypass the keys entirely, and the recovery and continuity choices that decide whether your heirs ever see the funds. The guide closes with the common mistakes that recur across every loss post-mortem, and how to design them out.

What Is Crypto Operational Security, and Why Is It the Layer That Fails?

Crypto operational security is the set of daily processes and decisions that protect self-custodied assets once the hardware and the wallet architecture are already in place. It is not a product you buy. It is the discipline you run: verifying every signature before you approve it, recognising hostile contact before you act on it, separating spending money from savings, backing up the seed so a single accident cannot erase it, and planning for the day you are no longer around to manage it. The term borrows from military practice, where operational security means controlling the small observable behaviours that let an adversary piece together an attack. In self-custody the adversary is usually automated and the behaviour is usually a single click, but the principle is identical: the system is only as strong as the routine around it.

The cleanest way to see why this layer matters is to separate the three things that can protect crypto, because each closes a different door and none closes all of them. The device layer, a hardware wallet, keeps the private key inside a secure element that never exposes it to an internet-connected computer, defeating remote key extraction and most malware. The architecture layer (single key versus multisig) decides how many independent approvals a transaction needs, defeating single-point-of-failure scenarios where one stolen seed or one compromised device ends the game. The behaviour layer, operational security, governs what actually gets approved, recognised, stored and inherited.

An attacker who cannot reach your key and cannot beat your threshold can still win by persuading you to sign their transaction yourself. That is the door OpSec closes, and it is the one that stayed open in almost every large 2025 loss.

The chain: device, architecture, behaviour

These three layers form a chain, and the chain is only as strong as its weakest link. A holder can spend hundreds of pounds on a top-tier device and tens of hours configuring a multisig, then lose everything by pasting a poisoned address or signing a malicious approval, defeating both lower layers from the top. The reverse is also true: excellent behaviour cannot fully compensate for keeping a fortune in a browser-extension hot wallet. No amount of verification discipline survives a device-level malware infection on a key that lives on a networked machine. The layers are complementary, not substitutes. This guide leads with behaviour not because the device and architecture matter less (they matter enormously, which is why each has its own complete hub) but because behaviour is the layer most holders neglect once the satisfying one-time purchases are done.

A worked failure: the $6,500 Permit signature

Consider a concrete example that recurred thousands of times in 2025. A holder keeps a six-figure portfolio on a hardware wallet, connected through a browser wallet for occasional decentralised-finance use. They receive a message — on a social platform, by email, or as a pop-up on a cloned site reached through a search advert — saying they can claim an airdrop or that their wallet needs validating. They connect, and a signing request appears. It is not a transfer; it is an off-chain Permit signature, gasless, so the instinct that "this costs gas, so it must be real" does not fire.

The hardware wallet shows a request to sign, the holder approves, and within minutes a relayer submits the signed permit on-chain and moves $6,500 of a stablecoin to the attacker. The device worked perfectly. It signed exactly what the holder told it to sign. The failure was entirely operational: an unexpected request was treated as legitimate, and the permission it granted was never read.

That pattern — the device faithfully executing a malicious instruction the human approved — is the signature of an operational-security failure rather than a technical one. It is why the headline figure of falling drainer losses is reassuring but not a reason to relax: the dollar total fell 83% year on year, but the mechanism did not change, and the holders who avoided loss did so by recognising the lure and refusing to sign, not because their hardware saved them. The remaining sections of this guide are, in effect, a structured tour of the doors this layer has to keep shut, and the satellite guides that show you exactly how to shut each one.

How to Build a Personal Crypto Threat Model

Security advice that ignores your situation is usually either wasteful or dangerous. A threat model fixes that by forcing four honest questions before any defence is chosen, so protection scales with what you actually hold and who can realistically reach it rather than with how frightening an attack sounds. The questions are simple, and answering them takes an afternoon rather than a degree in security. They are the foundation our personal threat-modelling deep dive develops into a full personal security plan, including the physical-coercion branch and the attack-surface inventory; this hub establishes the framework.

The four questions

The framework reduces to four prompts, and the order matters because each answer constrains the next.

• What am I protecting, and what is it worth? Not the dollar figure in isolation, but the figure relative to your life. A sum whose loss would change where you live, when you retire, or whether your children study is a different protection problem from a sum you could replace from salary within a year.
• Who realistically wants it? For most holders the honest answer is an automated, remote adversary: a drainer kit or a phishing campaign that does not know or care who you are. A smaller group attracts a targeted remote attacker who has identified them as a holder. A smaller group still, typically the visibly wealthy or publicly doxxed, has to consider a physical adversary.
• How could they actually reach me? The realistic paths are a malicious signature you approve, a phishing message you act on, a SIM-swap on your phone number, malware on a device that holds a hot-wallet key, or a seed phrase stored somewhere readable. Each path maps to a specific defence and a specific satellite in this cluster.
• What does each defence cost in friction? Security that is too painful gets abandoned, and an abandoned defence is worse than a modest one you actually keep. The right model is the strongest regime you will genuinely sustain over years, not the strongest one that exists.

Match protection to holding size, not to fear

The single most useful output of a threat model is a posture tiered to value. The table below maps three representative holding sizes to a proportionate posture. The figures are illustrative inflection points, not prescriptions. Your own crossover may sit higher or lower depending on income, jurisdiction and public footprint.

• Around $1,000: operational tier. A reputable hot or mobile wallet is acceptable, treated as a spending account rather than a vault. The realistic threat is automated phishing and clipboard malware; the defences are recognition habits, two-factor that is not SMS, and not storing more here than you can afford to lose overnight.
• Around $50,000: core tier. A single hardware wallet is the baseline, with a metal seed backup geographically separated from the device, SMS removed from any account gating funds, and a disciplined signing routine. The realistic threat broadens to targeted phishing and SIM-swap; physical risk is still low unless the holding is publicly known.
• $500,000 and above: vault tier. The portfolio has outgrown a single key. Multisig removes the single point of failure, inheritance planning becomes mandatory rather than optional, and for visibly wealthy or doxxed holders the physical-coercion branch becomes a real design input. Friction is high but justified by the value at risk.

Remote versus physical adversaries

The most important distinction a threat model draws is between an adversary who can only reach you over the network and one who can reach you in person. The remote attacker — the dominant case by orders of magnitude — is defeated by hardware, signing discipline, and phishing recognition: they cannot take what they cannot trick you into signing, and they cannot physically compel you. The physical adversary changes the calculus entirely, because a defence that depends on you keeping a secret stops working when someone can apply pressure to extract it.

This is why multisig with a geographically separated key, and the decoy-wallet and duress patterns covered elsewhere in the cluster, exist: they make the threshold impossible to meet under local coercion. Critically, the physical branch is a minority concern. Loading a casual holder's threat model with anti-coercion measures designed for a doxxed whale is the classic over-engineering mistake. Protection should answer the adversary you actually face.

The Crypto OpSec Stack: Four Layers

Operational security is easiest to reason about as a stack of four layers, each building on the one below, each with a clear failure mode and a clear owner in this cluster. The diagram below shows them as they stack: device at the base, then architecture, then the behaviour layer this hub owns, then recovery and continuity wrapping the whole so the system survives loss, death and time. The governing principle is that an attacker need defeat only one layer to win, so a strong layer cannot rescue a neglected one. A perfect signing routine does not help if the seed is photographed in a cloud backup; a perfect backup does not help if you blind-sign a drainer's transaction. The stack is built bottom-up but attacked top-down, which is why behaviour deserves the attention this guide gives it.

Layer 1: Device — the key never touches the internet

The base layer is the hardware that holds the private key. A hardware wallet stores the key in a secure element and signs transactions inside the device, so the key is never exposed to an internet-connected computer where malware could read it. This defeats remote key extraction, the attack that ruins anyone keeping serious value in a browser-extension or exchange-linked hot wallet. The device layer also introduces the verification primitive the behaviour layer depends on: a screen the holder can read before approving. The full treatment (device selection, secure-element generations, supply-chain and tamper checks, clear-signing capability) lives in our hardware wallet security: the device layer in depth.

Layer 2: Architecture — how many keys must agree

The second layer decides how many independent approvals a transaction requires. A single hardware wallet is one key: lose it without a backup, or have its seed compromised, and the game is over. Multisig requires M of N independent keys (typically two of three), so no single device, seed or person can move funds alone. That removes the single point of failure that defines the single-key model. Architecture is a deliberate upgrade rather than a default, justified once the portfolio is large enough that a single tail-risk event would be catastrophic. The decision framing, the Bitcoin-versus-EVM mechanics, and the signer-selection discipline are covered in our multisig wallets: the architecture layer in depth.

Layer 3: Behaviour — what actually gets approved and recognised

The third layer is where most losses occur and the layer this hub owns. It splits into two complementary disciplines. Signing hygiene is understanding exactly what a transaction does before approving it, simulating it to see the real asset changes, and revoking permissions you no longer use; our transaction signing hygiene and approvals covers the approval types, the verify-before-sign procedure, simulation tools, and revoking. Recognition is spotting the hostile contact before you ever reach a signing screen; our wallet drainer and phishing recognition covers the lures, address poisoning, clipboard hijacks and the daily anti-phishing routine. Mobile wallets, which are hot wallets by definition, get their own hygiene treatment in our mobile wallet hot-wallet hygiene.

Layer 4: Recovery and continuity — surviving loss, death and time

The outermost layer ensures the system survives accidents, the holder's death, and the simple passage of time. It covers how the seed is backed up so that fire, flood or a misplaced sheet of paper does not erase the portfolio, and how access passes to heirs without exposing the keys while you are alive. Backup mechanics (metal storage, geographic distribution, the BIP-39 passphrase, and the Shamir-versus-multisig redundancy choice) live in our seed phrase backup and recovery OPSEC. The handoff to heirs (separating the legal claim from the technical key, sealed instructions, and dead-man's-switch patterns) is covered in our crypto inheritance and estate planning.

The minimum viable stack

Before any of the deeper material, a holder with even a modest portfolio can put a defensible stack in place in an afternoon. The checklist below is the floor, not the ceiling. Every item below is the thing whose absence shows up most often in loss post-mortems.

• Move savings off hot wallets onto hardware. Keep only a small operational float on any internet-connected wallet; graduate the bulk to a hardware device where the key never touches a networked machine.
• Back up the seed on metal, in two separated locations. Paper burns and photographs leak. A fire-and-corrosion-resistant metal backup, with a second copy in a different building, survives the accidents that erase single-location backups.
• Remove SMS two-factor from anything that gates funds. Move to an authenticator app or a hardware security key, and add a carrier port-out PIN, so a SIM-swap cannot intercept your codes.
• Verify every signature before approving it. Read what the request grants, check the device screen matches the website, and decline anything unexpected or anything the device cannot render in human-readable form.
• Bookmark the services you use and reach them only through the bookmark. Never through a search advert, an emailed link, or a QR code in an unsolicited message. That single habit defeats most phishing before it starts.
• Write a sealed recovery plan. Even a single page naming what exists and where it is, opened only after death, turns an inevitable total loss into a recoverable estate.

One safety note belongs with any mention of these devices, because the attack that targets their owners is operational rather than technical. No hardware vendor — not Ledger, not Trezor, not Tangem — will ever ask for your 24 recovery words, by any channel, for any reason. In January 2026 a breach at a third-party logistics provider exposed names and postal addresses of Ledger customers, and within weeks holders received convincing phishing playing on a fake "Ledger–Trezor merger", urging them to "migrate" their wallets. The keys and funds were never at risk from the breach itself; the danger was entirely the phishing wave that followed. Treat any unsolicited request to enter, validate or migrate your seed as hostile by default, regardless of how authentic the branding looks.

Wallet Drainers and Phishing: The Dominant 2025 Vector

If operational security has a single headline threat, it is the wallet drainer: malicious infrastructure designed not to steal your key but to trick you into signing a transaction that hands over your funds. Drainers are sold as a service — pre-built kits that less technical scammers rent for a cut of the proceeds — which is why they spread across thousands of fake sites impersonating hundreds of legitimate brands. The economics are industrial, and they explain why this category dominated self-custody losses through 2025 even as the absolute numbers fell. The recognition skills that defeat drainers are the highest-leverage habits in this guide.

The kill chain: lure, connect, prompt, drain

Almost every drainer attack follows the same four-step chain, and understanding it tells you exactly where to break it. First comes the lure: an unsolicited message, a cloned website reached through a search advert or a poisoned link, or a fake airdrop or "wallet validation" prompt designed to manufacture urgency. Second, the victim connects their wallet to the malicious site, which on its own is harmless. Connecting reveals your address but moves nothing. Third, the site presents a signing request, the decisive moment: a token approval, a Permit signature, or a setApprovalForAll that grants the attacker permission to move assets, often dressed up as a routine "claim" or "verify" step. Fourth, the moment the victim approves, the drain executes. The chain only completes if the human approves at step three, so every defence here is about recognising that you are at step three and declining.

Permit and EIP-7702: why "no gas" is no comfort

The defining drainer technique of 2025 exploited signature types that do not look like spending money. A Permit (the EIP-2612 and Permit2 family) is an off-chain, gasless signature that grants a spender an allowance. The user signs a message, pays nothing, and feels nothing has happened, while the attacker now holds a token approval they can execute at will. The September 2025 $6.5 million single-incident loss was exactly this: one malicious Permit signature. Later in the year, the Pectra upgrade's EIP-7702 account-abstraction feature was turned to the same purpose, letting attackers bundle several malicious operations into a single signature.

The lesson for the behaviour layer is that the old instinct — "real transactions cost gas, so a free signature is safe" — is precisely backwards. A gasless signature can be the most dangerous prompt you ever approve. The mechanics of reading each signature type, and which ones grant standing permission versus a one-off transfer, are the subject of the cluster's signing-hygiene satellite, covering Permit and setApprovalForAll in depth.

Recognition is the defence

Because a hardware wallet will faithfully sign whatever the holder approves, defence against drainers is overwhelmingly a matter of recognition rather than technology. The reliable red flags are consistent across campaigns: contact you did not initiate, manufactured urgency, and any request to validate, sync, migrate or verify a wallet. The unbreakable rule sits underneath all of them: no legitimate service ever needs your recovery phrase, and any prompt that asks for it is hostile without exception.

The full lure catalogue, the channel-by-channel breakdown including the early-2026 wave of physical-mail impersonation letters, and the daily default-hostile routine are the subject of the cluster's wallet-drainer and phishing-defence satellite, on recognising the lure before you sign. The numbers underline why this matters: even after an 83% year-on-year fall, roughly $83.85 million was drained from about 106,000 victims in 2025, and the drainer ecosystem remains active as old kits are replaced by new ones.

Beyond the Keys: SIM-Swaps, Address Poisoning, Account Takeover

Not every attack goes through a signing prompt. A whole class of threats bypasses the keys entirely by targeting the accounts and habits around them — the phone number that resets your email, the transaction history you copy addresses from, the exchange login that still trusts an SMS code. These attacks matter precisely because a hardware wallet does nothing to stop them: the key is safe, but the value can leave through a door the device was never guarding. A complete OpSec posture has to account for this perimeter, not just the cold storage at its centre.

SIM-swaps and the phone-number root of trust

A SIM-swap is the transfer of your phone number to an attacker's device, achieved by social-engineering or bribing a carrier employee. Once they hold your number, they intercept SMS two-factor codes and password-reset links, which lets them take over any account that trusts your phone: email first, then exchanges and SMS-protected wallets. The scale is not trivial: the FBI's IC3 complaint unit has logged thousands of SIM-swap reports in recent years with tens of millions in associated losses, and a 2023 arbitration ruling — made public in March 2025 — ordered T-Mobile to pay roughly $33 million over a SIM-swap that led to a large crypto theft.

The defence is to demote SMS from a root of trust: remove it from anything that gates funds, move two-factor to an authenticator app such as Aegis or 2FAS or a hardware key like a YubiKey, and lock the carrier account with a port-out PIN. A self-custodied cold wallet is not directly exposed to a SIM-swap, but everything you reach through your phone number is.

Address poisoning: the $50 million copy-paste

Address poisoning weaponises a user-interface convenience. Wallets abbreviate long addresses to their first and last few characters. An attacker generates a lookalike matching those visible characters, then sends a tiny or zero-value transfer to your wallet so the lookalike appears in your transaction history. Later, when you copy "your" address out of that history to reuse it, you paste the attacker's. The mechanism is a recognition trap, not a key compromise, and it scales. By late 2025 researchers had recorded hundreds of millions of poisoning attempts across chains.

It produced the year's most spectacular single self-custody loss: in December 2025 a trader sent a $50 test transaction to confirm a destination, then copied the address from history and transferred $49,999,950 in USDT straight to a poisoned lookalike. The habit that defeats it is absolute: never copy an address from transaction history, always verify the full string rather than the abbreviated ends, and confirm the destination on the hardware screen. The full mechanics are covered in our phishing-defence satellite, alongside signing hygiene.

What a hardware wallet does and does not protect

The cleanest way to hold all of this in mind is a two-column boundary, because the most dangerous misconception in self-custody is that the device protects everything.

• What a hardware wallet protects: the private key against remote extraction; signing performed inside a secure element off any networked computer; the integrity of the transaction it renders, so you can verify destination and amount on the device screen before approving.
• What a hardware wallet does not protect: a transaction you approve yourself, malicious or not; an account secured only by your phone number against a SIM-swap; an address you copied from a poisoned history; an email or exchange login taken over through password reset; or a seed phrase someone reads off a photo, a cloud note, or a sheet of paper.
• What it protects only if you do your part: the device renders the destination and amount on its own screen, but that defence is conditional: it works against a swapped recipient or a malicious approval only when you actually read the screen and decline a request that does not match. A device you blind-sign on protects nothing the second column does not already list.

Account takeover sits in that second column. An attacker who controls your email controls the reset path to most of your other accounts. That is why email is the highest-leverage thing to protect after the keys themselves: a unique strong password, app-based or hardware two-factor, and no SMS fallback. The broader catalogue of scam families behind these account-level attacks (fake support, romance and investment cons, malicious browser extensions) is reserved for a forthcoming guide mapping the scam taxonomy in full; this hub keeps the focus on the operational defences that cut across all of them.

Recovery and Continuity at a Glance

The outer layer of the stack is the one holders defer longest and regret most, because its failures are silent until they are total. A perfect signing routine and a hardware wallet protect funds while the holder is alive and attentive. Recovery and continuity protect funds against the holder's own accidents — a lost backup, a forgotten passphrase — and against death. This section summarises the three redundancy choices and the recovery-by-holding-size question at a glance; the mechanics belong to the satellites that own them, because each is genuinely deep.

Three redundancy mechanisms, one line each

The recovery layer offers three distinct tools, often confused because they all touch the seed. Kept separate, the choice is straightforward.

• BIP-39 passphrase. An extra secret added to the seed words that derives an entirely separate wallet, so the written words alone are incomplete; it is never stored with the words, and forgetting it means permanent loss. It defends against a backup being found, at the cost of a new single point of failure in your memory.
• SLIP-39 Shamir backup. Splits one key into several shares, a chosen number of which reconstruct it once when recovery is needed. It defends the backup against loss or compromise of any single share, without introducing an ongoing multi-party signing process.
• Multisig. Requires several independent keys to approve every transaction on a continuing basis, so no single device, backup or person is a single point of failure. It is an architecture choice, not a backup format, and it changes daily operation rather than just recovery.

Passphrase and Shamir protect one key's backup; multisig removes the single key altogether. The derivation mechanics, the metal-storage and geographic-distribution discipline, and the decision rule between Shamir and multisig are the subject of the cluster's seed-backup satellite, covering passphrase and Shamir in depth.

Recovery posture by holding size

The right recovery model scales with the portfolio, just as the protection regime does. A small operational holding needs little more than a single tested metal backup of the seed, stored away from the device. A core holding warrants two geographically separated metal backups and a decision about whether a passphrase is worth its memory risk. A vault-tier holding moves into multisig and Shamir territory and, critically, into mandatory inheritance planning, because at that scale dying without a plan is not an inconvenience but the permanent loss of a life-changing sum. The reference point is grim: millions of the Bitcoin ever mined are considered permanently lost, much of it to holders who died or lost access with no recovery path. Continuity planning is what keeps your portfolio out of that figure.

Passing it on without exposing the keys

Inheritance is the continuity case holders avoid because it forces an uncomfortable subject, yet it is purely an operational problem: how does access pass to your heirs without exposing the keys while you are alive, and without writing a seed into a document that goes through public probate. The general single-key handoff separates the legal claim from the technical key, uses sealed dated instructions, and can lean on dead-man's-switch patterns. For holders who have already moved to multisig, the inheritance problem is harder (more keys, more locations, more documentation) and is covered specifically in our multisig inheritance and key-distribution planning. Whichever path you run, the cold-storage seed it all depends on has to be backed up first: the backup discipline is the prerequisite for every continuity plan that follows.

Common OpSec Mistakes

Loss post-mortems are repetitive in a useful way: the same handful of mistakes recur across cases that otherwise share nothing. The list below maps each common mistake to the concrete consequence it produced, the fix, and the satellite that covers the fix in depth. Reading it is the fastest way to find the gap in your own setup, because every entry is something a real holder actually did.

• Approving a signature without reading it — consequence: the $6.5 million September 2025 Permit theft, and countless smaller drains. Fix: treat every signing request as hostile until verified, and read what it grants on the device screen. Depth: the cluster's verify-before-sign procedure.
• Copying an address from transaction history — consequence: the $50 million December 2025 address-poisoning loss. Fix: never reuse an address from history; verify the full string and confirm it on the device screen. Depth: the cluster's address-poisoning recognition guide.
• Storing the seed as a photo or cloud note — consequence: any device or account compromise becomes total loss; a 2026 photo-leak case exposed exactly this. Fix: metal backup, offline, in two separated locations, never photographed. Depth: the cluster's seed-backup regime guide.
• Leaving SMS two-factor on accounts that gate funds — consequence: a SIM-swap intercepts codes and resets, draining exchange and SMS-protected wallets. Fix: authenticator app or hardware key plus a carrier port-out PIN. Depth: the cluster's mobile-wallet SIM-swap defence guide.
• Keeping savings in a hot or mobile wallet — consequence: a single malware infection or malicious approval drains the lot, because the key lives on a networked device. Fix: graduate the bulk to hardware cold storage; keep only a spending float hot. Depth: the cluster's hot-and-cold separation guide.
• Never revoking old token approvals — consequence: a dormant unlimited allowance to a later-exploited contract drains tokens you forgot you exposed. Fix: review and revoke quarterly and after new contracts, at the canonical revoke.cash. Depth: the cluster's guide to revoking risky allowances.
• Holding crypto with no inheritance plan — consequence: a life-changing sum becomes permanently unrecoverable on death, even with intact keys. Fix: a sealed, dated recovery plan naming what exists and where, opened only after death. Depth: the cluster's inheritance-planning guide.

The Ledger–Trezor merger letter: a 2026 worked example

One early-2026 campaign shows how these mistakes get triggered by a polished lure. After a January 2026 breach at a third-party logistics provider exposed Ledger customers' names and postal addresses, holders began receiving printed letters — physical post, not email — impersonating Ledger and Trezor and announcing a fake merger that supposedly required them to "migrate" their wallets. The letters carried holograms, forged signatures, and QR codes leading to a wallet-validation page that requested the recovery phrase. The branding was convincing precisely because the attacker knew the recipient's real name and address. The keys and funds were never exposed by the breach itself; the entire risk was the phishing that followed, and the holders who lost nothing did so by applying the single unbreakable rule — no vendor ever needs your 24 words — regardless of how authentic the letter looked.

The never-do-this checklist

If the positive guidance above reduces to one negative list, this is it.

• Never type, photograph, or upload your recovery phrase anywhere, for any reason, in response to any request.
• Never approve a signing request you did not initiate, or one the device cannot render in human-readable form.
• Never copy a wallet address from transaction history; always verify the full string from the original source.
• Never keep more on a hot or mobile wallet than you can afford to lose overnight.
• Never use SMS as the two-factor on an account that controls funds.
• Never reach a crypto service through a search advert, an unsolicited link, or a QR code. Use a bookmark you saved yourself.

For the full decision matrix on which security stack fits which holding size and threat tier — hot wallet, single hardware key, or multisig, with costs, friction and failure modes side by side — see our crypto security stack decision matrix.

Conclusion

The central claim of this guide is simple and well-evidenced: in 2025 the money did not leave through broken hardware or cracked cryptography, it left through behaviour. The $6.5 million Permit theft, the $50 million address-poisoning loss, the SIM-swaps and the seed photographs — each was an operational failure committed by a holder whose keys were, in the technical sense, perfectly safe. Hardware closes the remote-key-theft door and multisig closes the single-point-of-failure door, but neither stops you signing an attacker's transaction yourself, and that is the door that mattered most. Operational security is the discipline of keeping that door shut, every day, across years.

Three principles carry the whole cluster. First, build from a threat model, not from fear: match protection to what you hold and who can realistically reach you, because a £2,000 hot wallet and a £400,000 cold portfolio are different problems with different right answers. Second, think in layers — device, architecture, behaviour, recovery — and remember that an attacker needs to beat only one of them, so a strong layer cannot rescue a neglected one. Third, treat every unexpected signing request and every unsolicited contact as hostile until you have verified it yourself; the single highest-impact habit in self-custody is the willingness to slow down and decline, because no legitimate service loses anything when you do.

The encouraging part is that the highest-leverage defences are also the cheapest. Bookmarking your services, removing SMS from accounts that gate funds, reading every signature before you approve it, never reusing an address from history, and backing up the seed on metal in two places — none costs more than an afternoon, and together they close the doors through which most 2025 losses actually occurred. The hardware purchase is the easy part; the routine around it decides whether the portfolio survives.

Operational security is not a weekend project with a finish line; it is a standing routine that grows with the portfolio. Start with the minimum viable stack, work outwards through the layers as the value at risk rises, and revisit the model whenever your holdings, public footprint, or jurisdiction change. The six satellites and the decision matrix linked throughout take each layer into the depth it deserves: read the one that addresses the gap you found first.

Sources

• Scam Sniffer — 2025 annual phishing report: backs the $83.85M total, ~106,000 victims, 83% year-on-year fall from ~$494M, and the $6.5M September Permit incident.
• CoinDesk — $50M address-poisoning loss, December 2025: backs the $50M USDT loss after copying a lookalike address from transaction history following a $50 test send.
• FBI IC3 — federal internet-crime reporting portal: federal source for SIM-swap complaint volumes and associated crypto-fraud loss figures.
• FBI — SIM-swap public advisories: law-enforcement guidance on SIM-swap technique and prevention, supporting the carrier-PIN and authenticator-app advice.
• Chainalysis — crypto crime and lost-coin research: independent context for the share of losses hitting hot wallets and the scale of permanently lost Bitcoin.
• revoke.cash — token-approval revocation tool (canonical): the canonical tool for listing and revoking active token allowances by value at risk, reading the public address only.
• Ledger — official security and data-incident advisories: backs the never-share-your-24-words rule and the January 2026 third-party logistics breach exposing customer names and addresses (keys and funds unaffected).
• MetaMask Support — built-in transaction security: documentation for the no-install transaction-security alerts that flag malicious signatures and show simulated balance changes.

Frequently Asked Questions

What is crypto operational security, and how is it different from owning a hardware wallet?

Operational security is the daily process layer that protects self-custodied crypto after the hardware is bought and the architecture is set. A hardware wallet keeps the private key off an internet-connected machine, which stops remote key theft. OpSec is everything you do around that key: how you verify a transaction before signing, how you recognise a phishing message, how you back up and pass on the seed, how you separate a hot spending wallet from cold savings. Most 2025 losses did not come from broken hardware. They came from holders being tricked into approving a malicious signature, pasting a poisoned address, or storing a seed where it could be read. The device protects the key; OpSec protects the behaviour around the key.

How do I build a crypto threat model without security expertise?

A usable threat model answers four plain questions. What am I protecting, and how much is it worth in a way that would change my life if lost? Who realistically wants it: a remote phisher running automated drainers, opportunistic malware, or someone who knows I hold crypto and could apply physical pressure? How could they actually reach me: a malicious signature, a SIM-swap on my phone number, a seed stored somewhere readable? And what does each defence cost me in friction? You then match protection to holding size rather than to fear. A £2,000 hot wallet does not warrant the same regime as a £400,000 cold portfolio. You do not need expertise to do this, only honesty about what you hold and who can reach it.

What are the most common mistakes that cause crypto losses?

Four mistakes account for most preventable self-custody losses. Approving a malicious signature without reading what it grants, which is how the September 2025 $6.5 million Permit theft happened. Copying a wallet address from transaction history rather than the original source, which is how a trader lost $50 million to address poisoning in December 2025. Storing a seed phrase as a photo, a cloud note, or paper in a single location, which turns any device compromise or house fire into total loss. And leaving SMS-based two-factor authentication on accounts that gate funds, which a SIM-swap defeats. None of these is a hardware failure. Each is a behaviour that a hardware wallet alone does not fix.

Does owning a hardware wallet stop wallet drainers?

No, not on its own. A hardware wallet stops an attacker from extracting your private key remotely, because the key never leaves the device. A drainer does not try to steal the key. It tricks you into signing a transaction or token approval that gives the attacker permission to move your funds, and a hardware wallet will sign whatever you approve. The device only helps if you read what it renders on its screen before confirming, and if it can show the transaction in human-readable form rather than an opaque hash. Hardware closes the remote-key-theft door; it leaves the approve-a-malicious-signature door open unless you verify every signing request yourself.

How much is lost to crypto phishing and wallet drainers each year?

Wallet-drainer phishing losses fell sharply in 2025. Scam Sniffer's 2025 annual report recorded roughly $83.85 million stolen across about 106,000 victims, an 83% drop from the nearly $494 million lost in 2024. The largest single incident was a $6.5 million theft in September 2025 tied to a malicious Permit signature. The decline is real, but the report is explicit that the threat has not gone away: as old drainer kits shut down, new ones replace them, and losses still spiked alongside market rallies. Treat the falling headline figure as a reason to keep good habits, not abandon them.

What is the single highest-impact security habit?

Treat every unexpected signing request as hostile until you have verified it yourself. The majority of large 2025 losses came down to someone approving a transaction they had not read. Before you confirm anything, three checks catch most attacks: did I initiate this action, do I recognise the contract or destination, and does the device screen match what the website is telling me. If a request arrives unsolicited, or asks you to validate, sync or migrate your wallet, or the on-device rendering is an opaque hash you cannot read, the safe answer is to decline and walk away. No legitimate platform loses anything when you slow down to verify.

How do I spot a crypto phishing message?

Phishing relies on unsolicited contact plus urgency. The reliable red flags are a message you did not initiate, pressure to act immediately, and any request to validate, sync, migrate or verify your wallet by entering your recovery phrase. The unbreakable rule is that no legitimate hardware vendor, wallet or exchange will ever ask for your 24 words. Phishing now arrives by physical post as well as email: in early 2026, holders received printed letters impersonating Ledger and Trezor, complete with holograms and QR codes, after a third-party breach exposed customer names and addresses. Reach services through a bookmark you saved yourself, never through a link, a search advert, or a QR code in an unsolicited message.

What is the difference between a passphrase, Shamir backup and multisig?

They solve different problems. A BIP-39 passphrase is an extra secret added to your seed words that derives a completely separate wallet, so the written words alone are incomplete without it; forget the passphrase and the funds are gone. SLIP-39 Shamir backup splits one key into several shares where a chosen number reconstruct it once when needed, which protects the backup against loss of any single share. Multisig is different again: it requires several independent keys to approve every transaction on an ongoing basis, so no single device, backup or person is a single point of failure. Passphrase and Shamir protect one key's backup; multisig removes the single key entirely. They can be combined.

Is a SIM-swap still a threat if I use a hardware wallet?

Yes, but the target shifts. A SIM-swap moves your phone number to an attacker's device, letting them intercept SMS codes and password resets. It cannot reach the key inside a hardware wallet, so your self-custodied cold storage is not directly exposed. What it does threaten is everything still gated by your phone number: exchange accounts, email, and any wallet or service using SMS two-factor authentication. The fix is to remove SMS from anything that controls funds, move two-factor to an authenticator app such as Aegis or 2FAS or a hardware key like a YubiKey, and add a carrier port-out PIN or number lock. Hardware protects the key; the SIM-swap goes after the accounts around it.

How often should I revoke token approvals?

Review your approvals on a regular schedule, such as quarterly, and immediately after interacting with any new or unfamiliar contract. Every time you use a decentralised application you may grant it permission to move specific tokens, and many requests default to an unlimited allowance that persists indefinitely until you revoke it. A dormant unlimited approval to a contract that is later exploited can drain those tokens long after you forgot the approval existed. Use the canonical revoke.cash to list active allowances, sort by value at risk, and revoke anything you no longer use. Revoking reads your public address only and never touches your keys.

Related Resources

• Crypto threat modelling: a personal security plan — map your adversaries, tier protection to holding size, and plan for phishing, physical coercion and insider risk before choosing any defence.
• Wallet drainer and phishing defence — recognise the lures, address poisoning, and clipboard hijacks before they cost you, with the daily default-hostile routine that defeats them.
• Transaction signing hygiene and approvals — read what each approval grants, simulate transactions, spot blind-signing on hardware, and revoke risky allowances at revoke.cash.
• Seed phrase backup and recovery OPSEC — metal storage, geographic distribution, the BIP-39 passphrase, the Shamir-versus-multisig choice, and the decoy-wallet pattern.
• Crypto inheritance and estate planning — leave self-custodied crypto to your heirs without exposing keys, using sealed instructions, dead-man's-switch patterns and a probate-safe will.
• Mobile wallet security guide — hot-wallet hygiene for 2026: hot and cold separation, SIM-swap defence, app-store checks, and when to graduate the bulk to hardware.
• Crypto security stack: which setup for your holding size — the decision matrix choosing hot wallet, single hardware key, or multisig by holding size and threat tier, with costs and failure modes side by side.

Financial Disclaimer

This content is not financial advice. All information provided is for educational purposes only. Cryptocurrency investments carry significant investment risk, and past performance does not guarantee future results. Always do your own research and consult a qualified financial advisor before making investment decisions.