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 it is where each individual theft in this guide began.

Scam Sniffer's count of what phishing drainers took from wallets in 2025 is on our wallet drainer and phishing defence guide, linked below, and is not repeated here. The largest single drainer theft in Scam Sniffer's report of 3 January 2026 was $6.5 million in September 2025, taken through one malicious Permit signature: not a broken hardware wallet, not a cracked seed, but a holder approving a token permission. On 19 December 2025 a single trader sent 49,999,950 USDT to an address-poisoning lookalike copied from their own transaction history (on-chain record; CoinDesk, 20 December 2025). In each case the key was safe. The behaviour around the key was not.

The first half of 2026 concentrated the losses rather than reversing them: CertiK's H1 2026 report, published on 6 July 2026, counted 63 phishing incidents against 132 in the first half of 2025, a 52% fall in volume, while losses fell only about 11%, to $366.3 million, and four incidents accounted for about 85% of them. Fewer nets, bigger fish. CertiK's phishing count includes targeted social-engineering thefts, so its figures are not one series with the drainer-only count on our drainer guide; read together they say mass-market draining continued through 2025, while targeted social engineering was where the largest losses sat in early 2026. Neither trend is answered by better hardware.

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 what the hardware cannot do for you: 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 throughout it, 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 on the device, in current models inside a secure element, and 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 door behind the signature and address-poisoning thefts this guide describes.

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 hypothetical case built on the Permit, which Scam Sniffer's report of 3 January 2026 found remained the primary signature type in drainer thefts during 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 fall in drainer losses Scam Sniffer reported for 2025 is reassuring but not a reason to relax: the mechanism did not change, and what stops it is recognising the lure and refusing to sign, not the hardware. 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 list 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 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 the signature and address-poisoning thefts in this guide happened, and it is 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. Each item below closes one of the doors the following sections describe.

• 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 port-out PIN where your carrier offers one, 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 takes the search advert, the emailed link and the QR code out of your route to the service.
• 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 legitimate hardware-wallet vendor will ever ask for your recovery phrase, by any channel, for any reason. On 5 January 2026 Global-e, the seller for purchases on Ledger.com, told affected customers that an unauthorised party had accessed their order data (names, postal and email addresses, phone numbers; no payment information), and Ledger, which says its own systems were not involved, worked with Global-e to help notify them (Ledger support, updated 13 May 2026). By the vendor's account the breach exposed order data, not keys; the danger is the phishing that uses such details, so treat any unsolicited request to enter, validate or migrate your seed as hostile by default, however authentic the branding looks.

Wallet Drainers and Phishing: Recognise the Lure Before You Sign

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: less technical scammers rent pre-built kits for a cut of the proceeds, which is why the same lures spread across unrelated fake sites. The economics are industrial, and the recognition skills that defeat drainers are the highest-leverage habits in this guide.

The kill chain: lure, connect, prompt, drain

A drainer attack runs four steps: the lure, the wallet connection, the signing prompt and the drain. Connecting reveals your address but moves nothing; only the third step hands over a permission, when the site asks you to sign a token approval, a Permit or a setApprovalForAll dressed up as a routine "claim" or "verify" step. Our wallet drainer and phishing defence guide walks the chain step by step; 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 or a one-time transfer. The user signs a message, pays nothing, and feels nothing has happened, while the attacker now holds a signed permission they can execute at will. The largest drainer theft in Scam Sniffer's 2025 report, $6.5 million in September 2025, was exactly this: one malicious Permit signature. After the Pectra upgrade of 7 May 2025, attackers also turned its EIP-7702 account-abstraction feature to the same purpose, bundling several malicious operations into a single signature. Scam Sniffer's report puts the largest EIP-7702 cases in August 2025: two thefts totalling $2.54 million.

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 physical-mail impersonation letters reported in early 2026, 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. That page also carries Scam Sniffer's 2025 drainer figures, and how they differ from CertiK's phishing count. Scams that never reach a signing prompt, from fake trading platforms to impersonated support agents, are covered in our crypto scam protection guide, with what to do in the first hour if you have already paid.

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: in the US, the FBI's IC3 received 3,028 SIM-swap complaints with about $92 million in reported losses across 2023 to 2025, including 971 complaints and $17.4 million in 2025 (IC3 2025 Internet Crime Report, read 5 October 2026). A $33 million arbitration award against T-Mobile over a SIM-swap that led to a large crypto theft, heard in autumn 2023 and already paid, became public in March 2025 when the claimant's lawyers asked a Los Angeles court to confirm it (Greenberg Glusker, 20 March 2025).

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 where your carrier offers one. 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

Wallets abbreviate long addresses to their first and last few characters, and address poisoning exploits that: the attacker plants a lookalike matching those characters in your own transaction history, so that you copy the wrong one later. It is a recognition trap, not a key compromise; the mechanics and the measured scale are on our wallet drainer and phishing defence guide.

On 19 December 2025 a trader sent a 50 USDT test to the intended address, then, 26 minutes later, copied the address from their history and sent 49,999,950 USDT to a poisoned lookalike (on-chain record; CoinDesk, 20 December 2025). 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.

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 outside this hub's scope; it 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: coins whose keys die with their holder never move again, and continuity planning is what keeps your portfolio from joining them.

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

This guide's thefts are repetitive in a useful way: the same handful of mistakes recur across cases that otherwise differ. The list below maps each common mistake to its consequence, the fix, and the satellite that covers the fix in depth; two entries name a dated theft from earlier in this guide. Reading it is the fastest way to find the gap in your own setup.

• Approving a signature without reading it — consequence: the $6.5 million September 2025 Permit theft, and smaller drains like it. 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: anyone who reaches the image or the account holds the key, so any device or account compromise becomes total loss. 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 port-out PIN where your carrier offers one. 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 impersonation letters: a 2026 worked example

Letters reported in February 2026 show how these mistakes get triggered by a polished lure. In February 2026 BleepingComputer reported printed letters, sent by post, on fake letterhead from hardware-wallet makers' security teams. The letters said an "Authentication Check" or a "Transaction Check" was becoming mandatory and that owners had to scan a QR code before a deadline. The QR codes led to copies of vendor setup pages whose last step asked for the recovery phrase. Both impersonated vendors' own scam-warning pages, read on 5 October 2026, say to treat a letter claiming to come from them as phishing. The defence is the single unbreakable rule: no vendor ever needs your recovery phrase, however authentic the letter looks.

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: in each 2025 theft it describes, the money did not leave through broken hardware or cracked cryptography, it left through behaviour. The September 2025 $6.5 million Permit theft and the December 2025 $50 million address-poisoning loss each began with a holder whose keys were, in the technical sense, 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 the drainers used. 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 each individual theft in this guide 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 (published 3 January 2026): backs the largest single drainer theft of 2025, $6.5M through a Permit signature in September, the Permit as the primary drainer signature type, the two EIP-7702 thefts of August 2025 and the link between drainer losses and market activity; the report's annual totals are cited on our wallet drainer and phishing defence guide.
• CertiK Hack3D — H1 2026 report (published 6 July 2026): backs the 63 phishing incidents in the first half of 2026 against 132 in the first half of 2025, the $366.3M in phishing losses, the roughly 11% fall in losses against a 52% fall in incident count, and the concentration of about 85% of those losses in four incidents.
• CoinDesk — $50M address-poisoning loss, December 2025 (20 December 2025): backs the 49,999,950 USDT loss after a 50 USDT test send and a lookalike copied from transaction history; the on-chain transfer is dated 19 December 2025.
• FBI IC3 — 2025 Internet Crime Report (read 5 October 2026): backs the SIM-swap complaint and loss figures for 2023 to 2025, from its three-year comparison tables.
• FBI IC3 — SIM-swap public service announcement (I-020822-PSA, 8 February 2022): how SIM-swap schemes work, through social engineering, insider threat or phishing at the carrier, and the FBI's advice to use standalone authentication applications or physical security tokens.
• revoke.cash — token-approval tool FAQ (read 5 October 2026): inspecting approvals is free, revoking them one by one costs only the network's gas fee, and disconnecting a wallet does not revoke them.
• Ledger support — Global-e Incident to Order Data, January 2026 (last updated 13 May 2026): Global-e's notification of 5 January 2026 that order data was accessed, with no payment information, and Ledger's work with Global-e to notify affected customers; the page also repeats that Ledger never asks for the recovery phrase.
• BleepingComputer — physical phishing letters to hardware-wallet owners (14 February 2026): backs the letters' "Authentication Check" and "Transaction Check" lures, the QR codes and the final page that asked for the recovery phrase.
• MetaMask Support — security alerts (read 5 October 2026): its security alerts, on by default in the extension and mobile app, simulate a transaction or signature request to check whether it could lose you funds, without catching every threat; backs the simulation step in the behaviour layer.

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. None of the individual thefts this guide describes came from broken hardware: each came from a malicious signature, a poisoned address or a SIM-swapped phone number. 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 run through the losses and risks this guide describes. 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?

It depends on what is counted, so no single number answers it. Scam Sniffer's 2025 totals and their scope are on our wallet drainer and phishing defence guide rather than repeated here, and its report of 3 January 2026 found that drainer losses rose and fell with market activity and that new drainer kits replaced the ones that shut down. CertiK's phishing count includes targeted social-engineering thefts: its H1 2026 report, published on 6 July 2026, recorded $366.3 million taken in 63 incidents in the first half of 2026. Treat any 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. Before you confirm anything, three checks help: 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 recovery phrase. Phishing also arrives by physical post: in February 2026, BleepingComputer reported printed letters on fake hardware-wallet letterhead with QR codes that led to pages asking for the recovery phrase. 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 port-out PIN or number lock where your carrier offers one. 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. Checking reads your public address only; each revoke is an on-chain transaction you sign in your own wallet and pay gas for, and the site never receives 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 adviser before making investment decisions.