How to Prevent Unauthorized Transfers From Company Crypto Wallets

If your company holds any amount of crypto on its balance sheet — treasury reserves, customer funds, payment float, or trading capital — the question is no longer whether someone will try to move it without authorization. It’s whether your controls can stop them when they try.

Unlike a fraudulent wire transfer, a crypto transaction cannot be reversed, clawed back, or disputed with a bank once it settles on-chain. That single fact is why “unauthorized transfer” sits at the top of every crypto risk register CFOs and treasury teams review — and why it deserves the same rigor as any other material financial control.

In February 2025, attackers stole roughly $1.4–1.5 billion from Bybit in a single cold-wallet transfer that was approved by legitimate signers who believed they were authorizing a routine transaction. No smart contract bug. No stolen password. Just a manipulated signing interface that showed the right numbers while executing the wrong ones. Around the same time, Kraken disclosed an insider-access incident that led to an extortion attempt from a former contractor. These weren’t outlier events — they’re a preview of the two failure modes every company with a crypto wallet needs to plan for: technical manipulation of the signing process, and human access that outlives the trust placed in it.

This guide breaks down why company wallets are targeted, the root causes behind most unauthorized transfers, and a practical control framework you can hold your treasury operations against.

Why Company Crypto Wallets Are a Prime Target

Company-controlled wallets are more attractive to attackers than individual retail wallets for a simple reason: concentration. One address can hold a treasury that took years to accumulate, and one successful transfer can extract all of it in a single transaction. Attackers generally go after one of these openings:

• Blind signing. Multisig and hardware wallet interfaces often show a simplified summary of a transaction rather than the raw calldata being signed. Attackers who compromise the interface — a website, a browser extension, a UI dependency — can display a legitimate-looking transaction while the signature actually authorizes something else entirely. This is exactly what happened in the Bybit incident: the destination address and contract logic shown to signers did not match what was executed.
• Compromised or coerced insiders. Anyone with signing rights, API key access, or admin control over wallet infrastructure is a target — through bribery, coercion, social engineering, or simply failing to revoke access after they leave. Kraken’s 2025 incident involved a former support contractor who retained inappropriate account access.
• Single points of failure in key management. A private key stored on one device, in one cloud secret manager, or known to one employee is one phishing email or one resignation away from becoming a liability.
• Social engineering of approvers. Fake “urgent” requests, spoofed executive communications, and fraudulent vendor payment instructions are used to pressure a signer into approving a transfer without following normal verification steps.
• Weak or absent transaction policies. Without hard rules on which addresses funds can move to, how much can move per transaction or per day, and how many people must approve, a single compromised credential is often enough to drain a wallet.

The Root Cause Most Companies Miss

Most postmortems land on a technical vulnerability — a compromised laptop, a malicious npm package, a phished admin. But the deeper root cause is almost always architectural: the organization relied on trust in a single actor, a single device, or a single interface, instead of building a system where no single point of failure could authorize an unauthorized transfer on its own.

That reframing matters, because it changes the fix from “hire more careful employees” to “build a system that stays safe even when an employee, device, or interface is compromised.”

A Practical Framework to Prevent Unauthorized Transfers

1. Eliminate the single private key

If one private key, one seed phrase, or one signer can move funds alone, you have a single point of failure by design — no amount of employee training fixes that. Two architectures solve this:

• Multi-signature (multisig) wallets, which require M-of-N independent signatures on-chain.
• Multi-Party Computation (MPC), which splits a single private key into encrypted key shares distributed across separate parties or devices. No complete key ever exists in one place, and no single party can reconstruct it or sign alone.

This is where platforms like Safeheron are built specifically for enterprise treasury and custody teams: its MPC architecture, hardened with a Trusted Execution Environment (TEE), ensures asset control is mathematically distributed rather than resting on any one employee, laptop, or backup file — closing off the single-point-of-failure problem before it becomes an incident.

2. Enforce policy-based approval workflows

Every transaction that leaves a company wallet should pass through rules your treasury or risk team defines in advance — not rules a signer improvises in the moment. A solid policy engine should let you control:

• Who can initiate a transaction (specific employees, roles, or API keys only)
• How much can move per transaction and per rolling 24-hour window
• How many approvers are required, scaled to transaction size (e.g., 1-of-2 for routine amounts, 3-of-5 for anything above a defined threshold)
• Which destination addresses are permitted at all

A well-designed system should also apply a “one veto, transaction blocked” rule — if any required approver rejects, the transaction should not go through regardless of how many others approved.

3. Lock down destination addresses with real whitelisting

Most catastrophic unauthorized transfers involve funds going to an address the company never intended to pay. Address whitelisting closes this gap — but only if adding or changing a whitelisted address itself requires multi-party approval, not a single admin click. Otherwise the whitelist just becomes the next single point of failure.

4. Solve the “what you see is what you sign” problem

The Bybit incident is the clearest evidence that approval workflows alone are not enough if the interface showing the transaction can lie. Look for infrastructure that cryptographically verifies transaction details independent of the display layer — validating the hash, destination, and parameters inside a secured, tamper-resistant environment rather than trusting whatever a web UI renders. Safeheron’s policy engine and TEE-based signature verification were built explicitly around this failure mode: transactions are checked against whitelists and hashed/validated inside a hardware-secured enclave, so a manipulated front end can’t quietly change what gets signed.

5. Segment hot, warm, and cold wallets — with real limits

Keep only operational-float amounts in hot wallets connected to applications or exchanges. Larger reserves belong in warm or cold storage with higher approval thresholds and, where practical, time-delayed withdrawals that give your team a window to catch anomalies before funds actually move.

6. Treat insider access like a lifecycle, not a one-time grant

Signing rights, API keys, and admin permissions should be reviewed on a fixed schedule and revoked immediately — not “at the next audit” — when someone changes roles or leaves the company. Kraken’s incident is a direct illustration of what happens when access outlives its justification. Pair this with role-based access control so no single individual holds enough privilege to move funds unilaterally.

7. Monitor, alert, and rehearse

Real-time transaction monitoring, anomaly alerts for unusual amounts or destinations, and a rehearsed incident-response plan (including who can freeze operations and who contacts exchanges/law enforcement) shrink the window between “something went wrong” and “we caught it.” Consider whether your provider carries institutional insurance — Safeheron, for example, backs its custody infrastructure with coverage placed through Lockton — as a backstop for the residual risk no control set can fully eliminate.

8. Get independent assurance, not just internal sign-off

Ask any custody or wallet infrastructure vendor for evidence of independent security assurance — SOC 2 Type II reports and ISO/IEC 27001 certification are reasonable baseline requirements for any provider handling company crypto assets, the same way you’d expect them from a banking or payments partner.

What This Looks Like in Practice

A finance team following this framework doesn’t rely on any single safeguard. A routine transfer might flow like this: an employee with defined initiation rights submits a request; it’s checked against a policy that caps the amount and destination; if it exceeds a threshold, it routes to two independent approvers; the destination address is validated against a whitelist that itself required multi-party approval to create; the transaction is cryptographically verified inside a secured environment before signing; and the whole sequence is logged for audit. No individual step is unbreakable — the strength comes from requiring several independent things to go wrong at once.

This is the operating model Safeheron’s MPC self-custody platform is built to support: institutional-grade key distribution, a configurable policy engine for approval workflows and whitelisting, and verified signing designed to defeat the exact “what you see ≠ what you sign” attack that hit Bybit — used today by exchanges, payment providers, OTC desks, and asset managers who need enterprise controls without giving up custody to a third party.

FAQ

Can a crypto transfer be reversed once it’s confirmed? No. Unlike traditional bank wires, confirmed on-chain transactions are final. Prevention, not recovery, is the only reliable control.

Is multisig enough, or do we need MPC? Multisig is a meaningful improvement over a single key, but it’s typically on-chain, more expensive per transaction, and less flexible for fast-scaling approval policies. MPC achieves a similar distributed-trust guarantee off-chain, generally with lower transaction costs and more configurable policy controls — which is why many institutional platforms, including Safeheron, are built on it.

How many approvers should a large transaction require? There’s no universal number, but a common pattern is to scale approval count with transaction size — a low threshold for routine operational transfers and a higher one (e.g., 3-of-5) for anything above a materiality threshold your finance team defines.

What’s the fastest thing we can do this quarter? Audit who currently holds signing rights or API keys, remove anyone who shouldn’t have them, and implement address whitelisting with multi-party approval to change it. Both are low-cost and close two of the most commonly exploited gaps.

Talk to Safeheron

If your team is evaluating how to move from a single-signer setup to institutional-grade MPC custody with configurable approval policies and verified signing, Safeheron’s team can walk through your current wallet architecture and show where the gaps are. Visit safeheron.com to learn more or request a demo.