Bitget Breach: $387.5M Lost to a Third-Party Zero-Day

The most expensive lesson in the Bitget breach is not about cryptography. Reporting so far says the attackers never needed to break a signature scheme or steal a cold-storage key. They reportedly went through two third-party security products, the very tools bought to protect the exchange, and used that foothold to reach the systems that decide which withdrawals get signed. About $387.5 million left the platform in under three hours.

That matters now because the pattern is repeating. Exchanges have hardened their key management, so attackers have moved one layer out, to vendors, administrators and the glue software that sits between a request and a signature. If your trust model stops at the key, you have defended the wrong boundary.

This is a systems analysis, not a news bulletin. It separates what has been publicly reported from what remains unconfirmed, then walks the architecture that failed and the controls that would have limited the loss.

What this covers: the reported timeline and its gaps, the likely attack path, why hot and warm wallets are the real attack surface, a layered custody and withdrawal-policy design, how reconciliation caught the theft, vendor-risk controls, trade-offs, and a practical checklist. This article is architectural analysis only and is not financial, investment or legal advice.

Context and Background

Centralized exchanges hold customer assets in a tiered structure. A small share sits in hot wallets, which are online and sign automatically so users can withdraw within minutes. A larger share sits in warm wallets, which are online but gated by additional approvals. The majority sits in cold storage, where keys are offline and signing needs deliberate human or hardware ceremony. This split is the oldest control in exchange security, and it works because an attacker who reaches a hot wallet can only take what the hot wallet holds.

The trouble is that “what the hot wallet holds” has grown. Withdrawal volume, market-making needs and the number of supported chains all push operators to keep more liquidity online. When an exchange supports a dozen assets across a dozen networks, it needs a float on every one of them, and each float is a target. In the Bitget case, reporting indicates the loss spanned 12 assets across 11 blockchains, which tells you the attacker’s tooling understood the wallet system’s multi-chain withdrawal logic rather than one chain’s quirks.

The wider backdrop is the 2025 Bybit theft of roughly $1.5 billion, which public analysis tied to a compromise of the signing workflow’s surrounding software rather than to a broken blockchain primitive, and which the FBI attributed to North Korean actors it tracks as TraderTraitor. Bitget reporting points at the same family of suspects, although, as discussed below, that attribution is described as suspected rather than proven. Treat the comparison as a pattern, not as proof that the two incidents are linked.

For readers new to custody design, our deep dive on MPC wallet custody and threshold signatures explains how signing keys are split so no single machine ever holds a complete key. That control is necessary, but this incident is a reminder that it is not sufficient: a threshold scheme faithfully signs whatever request the upstream system hands it. The primary news coverage used for this analysis includes The Hacker News report on the vendor zero-day, and I cite individual claims to that reporting where it matters.

Why third parties are the soft target

Security appliances are privileged by design. A web application firewall, a bastion, a secrets manager or a monitoring agent typically has network reach into many internal segments and often stores credentials. That makes it a high-value target, and it is also a black box the operator cannot patch on its own schedule. A zero-day in such a product hands the attacker the same reach the product was granted, usually without triggering the operator’s own detection because the activity looks like the appliance doing its job.

There is also an incentive asymmetry. A vendor’s product is deployed at hundreds of customers, so one working exploit pays off repeatedly, while each customer sees only its own slice of telemetry. This is why supply-chain thinking, familiar from software build pipelines and covered in our piece on SLSA and Sigstore for software supply chain security, applies equally to operational security tooling.

What Has Been Reported, and What Has Not

Facts in a fast-moving incident arrive in layers, and early numbers get revised. Here is the picture assembled from several outlets, with the disagreements left visible. I could not verify any of this against a final post-incident report from Bitget, so treat every figure as “as reported” until that report appears.

Reported with reasonable consistency

Amount. Total losses of roughly $387.5 million. One outlet notes this was revised upward from an initial figure near $351 million.
Window. Reporting places the theft on 24 to 25 September 2026. One timeline describes two small test transfers around 18:31 UTC on 24 September, followed by 17 large transactions across eight chains between roughly 18:58 and 20:09 UTC. Another describes the full drain as taking about 2 hours and 52 minutes. These are compatible only if the windows are measured differently, so I would not rely on either to the minute.
Breadth. Twelve assets on eleven blockchains, including Ethereum, XRP Ledger, Zcash, TRON, Arbitrum, Optimism, Base, BNB Smart Chain, Avalanche, Algorand and Celestia, per one report.
Cause. Bitget attributed the intrusion to a zero-day in third-party security products. Two products are referred to anonymously as Product A and Product B in the reporting I could read.
Wallet scope. Hot and warm wallets were affected. Bitget’s statements, as relayed, say private keys and cold wallets were not compromised.
Earliest activity. The investigating firm SlowMist is reported to have found malicious activity dating back to 31 August 2026, meaning the attacker may have been inside for weeks before the theft.

Conflicting or unconfirmed

Frozen funds. One report puts frozen recoveries at about $632,700 across Circle, Tether and NEAR Intents, while another says about $1.1 million. The amount is small against the loss either way, and I could not determine which figure is current.
Attribution. One outlet states North Korean involvement as confirmed, citing IP patterns and wallet overlap with earlier incidents. Another describes it as suspected and not officially confirmed. I treat it as suspected.
The vendor. The products have not been named in the sources I could access. Whether the underlying flaws are patched is also not established.
Customer impact. Bitget is reported to be covering losses from its protection fund, said to be $465 million as of 25 September, with a pledge to refill it to at least $300 million within a week. I could not verify that the refill happened.
Withdrawal resumption. One timeline lists a staged restart by network and asset between 28 September and 2 October. Confirm against Bitget’s own status page before relying on it.

The honest summary is that we know the shape of the incident well and its specifics poorly. That is enough to analyze the architecture, which is the part that generalizes.

The Reported Attack Path as a System

The reporting describes a chain with five links, shown in the figure below. None of the links, taken alone, is exotic. The danger lies in how little friction separated each from the next.

Figure 1: The reported Bitget breach chain, reconstructed from public reporting. Individual hops are as described by investigators and are not independently verified.

The long description of Figure 1: an attacker exploits a zero-day in a security appliance, harvests administrator credentials and database access, installs a web shell for persistence and command execution, pivots to the wallet job server that schedules and executes withdrawals, and submits forged withdrawal instructions that the downstream signing and broadcast path treats as legitimate.

Link 1 and 2: the appliance and the credentials

The first hop is the zero-day itself. According to the reporting, one product was abused to run a hidden script that extracted a database password, and the other to plant a web shell and inject commands. You cannot patch a vulnerability nobody has disclosed, so this hop cannot be prevented by hygiene alone. It can only be contained by what the appliance is allowed to reach.

The second hop, valid administrator credentials, is where architecture decides the outcome. Bitget’s own description, as relayed, says the attacker obtained valid administrator credentials and used them to write forged withdrawal instructions and delete traces. A credential that can both create a withdrawal job and erase the evidence of creating it is a design smell. Those two powers should never live in one identity.

Link 3 and 4: lateral movement to the wallet job server

Reports describe movement from the compromised security product to a “wallet job server”. Whatever Bitget calls it internally, this is the component that turns an approved withdrawal into a transaction to be signed. It sits in the most sensitive spot in the whole stack: downstream of customer-facing risk checks, upstream of the signer.

The reporting also says the attacker used a custom tool built around the wallet system’s withdrawal logic. That detail is the most worrying one. It implies reconnaissance over days or weeks, and it implies the attacker learned the format and semantics of internal job messages well enough to forge them. Tooling like that is expensive to build, which fits a patient, well-resourced adversary.

Link 5: the signer trusted the job

Finally, the funds moved. The hot and warm wallets signed what the job server presented. This is the crux. If the signing tier validates only that the request arrived over an authenticated internal channel, then compromising the sender equals compromising the funds, regardless of how strong the key protection is.

Core Argument: The Signer Must Not Trust the Sender

Direct answer: the lesson of the Bitget breach is that key custody is only as strong as the independent verification in front of the key. Splitting keys with MPC or storing them in a hardware security module protects the key, not the decision to use it. A resilient exchange validates every withdrawal at the signing tier against policy and balances the attacker cannot rewrite from the application layer.

This is an argument about trust boundaries. Most exchange stacks evolved as a pipeline: user request, risk checks, job creation, signing, broadcast. Each stage trusts the previous stage’s output. An attacker who controls an early stage inherits every later stage’s authority. The fix is to make the later stages distrust the earlier ones and verify from independent data.

Figure 2: A layered custody design. The policy engine, signing quorum and reconciliation monitor each hold independent state, so no single compromised service can both authorize and conceal a transfer.

Figure 2 shows the target shape. A withdrawal passes a policy engine that enforces limits, then optionally a review queue, then a signing tier that is a quorum of MPC nodes or HSM-backed signers. A cold storage reserve refills the hot float only through a separate, slow path. In parallel, an independent ledger feeds a reconciliation monitor that compares what the books say should have moved with what the chain shows, and it can trip a kill switch.

Separation of duties at the credential level

Start with identity. No single administrative identity should be able to create withdrawal jobs, approve them, modify the policy that governs them and delete the audit log. Four separate roles, backed by different authentication paths and ideally different teams, turn a credential theft into a partial event instead of a total one.

Audit logs deserve special treatment. Ship them off-host in near real time to a write-once store that the wallet system’s own administrators cannot alter. In the reported incident the attacker apparently deleted traces, which is exactly the capability an append-only, externally held log removes. If the attacker cannot erase the evidence, the detection and forensics timeline shrinks from weeks to hours.

The policy engine as an independent verifier

The policy engine is a small, boring service with one job: decide whether a withdrawal is permitted by rules, using data it owns. It should not read limits from the same database the application writes to. If the application layer can edit the limit table, a forged job can raise its own limit first.

Useful rules are simple and numeric. Per-asset hourly outflow caps. A cap on the number of distinct destination addresses first seen in a window. A ceiling on the share of any hot wallet that can leave in one interval. A requirement that large transfers wait out a delay during which a human or a second system can veto. None of these require machine learning, and all of them would have turned a three-hour drain across 11 chains into a hard stop after the first breach of a velocity threshold.

Consider the arithmetic. If a hot float is $400 million across all chains and the policy caps total outflow at 2 percent per hour, the maximum loss before a human is paged is $8 million per hour. That is a figure I chose to illustrate the mechanism, not Bitget’s configuration. The point is that the cap converts an unbounded loss into a bounded one and buys time for detection.

The signing tier verifies, not just signs

MPC and HSM deployments often sign any request authenticated by the calling service. A stronger pattern gives each signer an independent view. Each MPC node, or each HSM policy, checks the request against its own copy of the rules, its own balance snapshot and its own allowlist of destinations. A transaction is signed only when a threshold of independent checks agree.

The word “independent” carries the weight. If all signers read policy from one shared service, compromising that service compromises the quorum. Run different codebases or at least different deployment pipelines for some signers, store their policy in separate trust domains, and require that at least one verifier sits outside the exchange’s primary cloud account. For more on how threshold schemes partition keys, see our MPC wallet custody architecture guide.

Destination allowlists and address cooling

Most legitimate hot-wallet outflow goes to a bounded set of destinations: user withdrawal addresses that already exist in the system, cold storage, and a handful of liquidity partners. Forged jobs, by contrast, tend to target fresh attacker addresses. A signer that refuses to send more than a small amount to any address that is not on a pre-registered, time-delayed allowlist forces the attacker to take the slow path.

Withdrawal addresses added by customers can carry a cooling period of their own, so a compromised account cannot add and use a new address in one step. For treasury movements, the allowlist should be changeable only through a separate multi-person ceremony, not through the same admin console an attacker may already control.

Deeper Analysis: Detection, Reconciliation and Blast Radius

The reported timeline contains one genuinely encouraging detail. One account says the exchange’s ledger reconciliation system noticed a balance gap at about 19:05 UTC on 24 September, roughly seven minutes after the first large transaction, and withdrawals were frozen. If that is accurate, the detection control worked. The loss still reached hundreds of millions of dollars, which tells you something about the speed of the attack relative to the speed of the response.

Figure 3: Sequence view. The attacker works through the vendor appliance and the job server; the reconciliation monitor observes the gap only after transfers hit the chain.

Why reconciliation is a detective control, not a preventive one

Reconciliation compares two independent records: the internal ledger of customer balances and the on-chain state of the exchange’s wallets. When funds move without a matching ledger entry, the numbers diverge. It is among the strongest signals available, because a stealthy attacker can forge jobs but cannot easily make the blockchain agree with a ledger it did not touch. We cover the mechanics in our post on reconciliation engine architecture for payments and fintech.

But it runs after the fact. Transfers settle on chain in seconds to minutes, and on-chain transfers are irreversible. So reconciliation limits the damage only when it runs frequently enough and is wired to an automatic kill switch rather than a pager. A monitor that waits for a human to read an alert at 2 a.m. will lose the race against a tool that drained 17 large transactions in about 70 minutes.

The design implication is to shorten the loop in three ways. Reconcile per transaction and per block rather than on a batch schedule. Give the monitor authority to freeze outbound signing on its own when divergence passes a threshold. And keep the monitor’s data path independent of the systems it watches, so a compromised job server cannot feed it falsified inputs.

Blast radius by wallet tier

Because the incident hit hot and warm wallets, it is worth quantifying the tiers conceptually. The hot wallet’s loss ceiling is its float. The warm wallet’s ceiling is its float plus whatever its approval workflow lets through. Cold storage, if it stayed untouched as Bitget says, is bounded by a physical process the online attacker cannot reach.

Therefore the engineering question is how large each online float should be. Operators face a real tension: a smaller float means more frequent refills from cold storage, which means more human ceremonies, more latency for large withdrawals and more operational cost. A larger float is cheaper to run and more dangerous. A defensible approach sizes the hot float to cover a defined number of hours of normal peak outflow, no more, and sizes the refill path so it can keep up without manual shortcuts.

The long dwell time

SlowMist’s reported finding of malicious activity from 31 August implies roughly three and a half weeks between initial compromise and theft. Long dwell time is characteristic of patient intrusions. It also means detection opportunities existed and were missed or were invisible. The attacker’s early steps, a script on an appliance and a web shell, are exactly the artifacts that file-integrity monitoring and egress controls are meant to catch.

Egress control is underrated here. A web shell with command-and-control needs outbound connectivity. If security appliances and wallet servers can reach only an explicit allowlist of destinations, many command-and-control channels fail at the network layer. Our piece on Cilium and eBPF for service mesh networking, observability and security shows how identity-based network policy and flow logging make that kind of default-deny egress practical in container environments.

Vendor Risk: Treat Security Tools as Untrusted Infrastructure

The standard vendor-risk process asks whether a supplier is certified, audited and insured. Those questions matter for procurement, but they do not answer the question this incident raises: what can the product reach if it is fully compromised tomorrow? The better model is to treat every third-party security appliance as a component that will eventually be breached, and to design the network and identity fabric so that outcome is survivable.

Figure 4: Zoned isolation. Vendor appliances sit in an untrusted zone that can only push read-only telemetry; approved jobs flow one way into the money zone, and an independent verifier checks transactions after signing.

Figure 4 expresses the principle. Vendor products live in a zone that is explicitly untrusted. They may send telemetry inward through a read-only channel, and they receive nothing that grants reach into operations or money systems. The operations zone, with admin consoles and databases, passes approved jobs to the money zone through a one-way path. Inside the money zone, the job server and signing quorum are the only components that touch keys, and an independent verifier watches the output.

Inventory the privilege each product holds

Begin with an honest inventory. For every security appliance, agent and SaaS integration, list the credentials it stores, the network segments it can reach, the commands it can run and the data it can read. Most organizations discover that a monitoring or scanning tool holds standing administrative access somewhere it should not. The reported pattern, where one product exposed a database password and another gave a path to the wallet job server, is a textbook case of privilege accumulating in tooling.

Then remove standing privilege. Replace stored credentials with short-lived, scoped tokens issued per task. Use just-in-time access for administrators, with approval and session recording. If a product demands permanent domain-admin-equivalent access to do its job, that is a procurement finding, not an engineering detail.

Segment so a vendor compromise cannot walk to the wallets

Network segmentation sounds basic, yet incident after incident shows a flat path between a perimeter product and production systems. The target is that no vendor-managed host can open a connection to the wallet job server, the signing tier or the secrets store. Put these behind a policy layer that denies by default and permits only named flows between named identities.

A related control is an out-of-band path for the highest-risk change: anything that alters withdrawal logic or signing policy. Deployments to the money zone should require a build produced by a pipeline the vendor products cannot touch, with signed artifacts and provenance checks. Our overview of AI model supply chain security and provenance applies the same signed-artifact logic to another class of deployable assets, and the principle transfers directly.

Plan for the vendor you cannot patch

When the zero-day is public, you depend on the vendor’s patch cadence. Contracts should specify disclosure obligations, a maximum time to notify customers of a suspected compromise, and the right to receive indicators of compromise early. Equally important is the operator’s ability to disable the product’s functionality quickly. The reporting indicates Bitget disabled affected functionality pending vendor patches, which is the right instinct and only possible if the product can be turned off without taking the exchange offline.

Build for graceful degradation. Ask in advance: if this appliance is switched off, what protection do we lose and what compensating control covers it? If nobody knows, the product has become a single point of failure for security itself.

Detection that does not depend on the compromised tool

Security tools also generate the telemetry used to detect intrusions. If the tool is the thing compromised, its logs are suspect. Collect an independent signal: network flow records from the fabric, endpoint telemetry from a different vendor, and the cloud provider’s control-plane logs. When two independent sources disagree, that disagreement is itself an alert.

For agent-driven operations, which increasingly automate runbooks and tickets, add one more concern. Automation that can create or approve operational actions expands the set of identities an attacker can abuse. Our analysis of agentic AI security and prompt injection describes how to scope what such systems may do, and the same least-privilege rules apply to automation in a custody stack.

A Worked Model: What a Cap and a Delay Buy You

Abstract controls are easier to evaluate with numbers. The following is an illustrative model, not Bitget data, using round figures to show how policy parameters bound a loss. Assume an exchange keeps $400 million of liquid assets in online wallets, a forged-job attacker can issue transfers at up to 6 per minute, the average transfer is $5 million when unconstrained, and the detection-to-freeze loop takes 10 minutes.

With no policy cap, 10 minutes at 6 per minute is 60 transfers, or $300 million, before the freeze lands. That is the order of magnitude of what was reported, so the model is at least plausible as a stress case. Add a rule that caps total hourly outflow at 2 percent of online assets, and the same 10 minutes allows roughly $1.3 million, since 2 percent of $400 million is $8 million per hour and 10 minutes is one sixth of that. Add a per-destination cap of $250,000 for addresses not on the allowlist, and the maximum theft to unknown addresses within that window drops further, by an amount that depends on how many fresh addresses the attacker is willing to burn.

Now change the detection loop. If reconciliation freezes withdrawals automatically in 60 seconds instead of 10 minutes, the unconstrained loss falls from $300 million to $30 million, and under the 2 percent cap it falls to roughly $130,000. The two levers compound: caps reduce the rate of loss, and fast detection reduces the time over which that rate applies.

The model also shows what these controls cost. Legitimate whale withdrawals above the cap queue for review, and market makers who need rapid rebalancing may be frustrated. That friction is real, and it is the price of a bounded worst case. Exchanges can tier the policy by customer verification level, by account age and by historic behavior, which preserves experience for the bulk of users while holding the extremes.

Choosing parameters without guessing

Pick caps from data. Take the exchange’s historical hourly outflow distribution per asset, set the standard cap near a high percentile of normal behavior plus a margin, and route anything above to review. Revisit caps quarterly and after any market event that shifts withdrawal patterns. A cap that fires constantly on legitimate activity will be raised by tired operators until it means nothing, so measure the false-positive rate and tune it deliberately.

Trade-offs, Gotchas, and What Goes Wrong

No control here is free, and a few are easy to implement badly.

Independence is hard to keep. The “independent” policy store that starts as a separate database slowly acquires a sync job, then a shared service account, then a convenience API from the main application. Each step feels reasonable and erodes the separation. Audit independence the same way you audit access: periodically, with a test that tries to modify policy from the application layer and expects failure.

Kill switches cause outages. An automatic freeze on divergence is only as good as its false-positive rate. Reconciliation gaps can come from timing, chain reorganizations, delayed deposits or bugs. If the kill switch fires too eagerly, the exchange freezes withdrawals during benign blips and loses user trust. If it is too lax, it is useless. Tier the response: soft-throttle on small gaps, hard freeze on large ones, and rehearse both.

Cold storage is not a silver bullet. Reporting says cold wallets were untouched, which is a genuine success of the tiering model. But a refill process that lets a compromised hot tier request unlimited top-ups from cold would turn the cold tier into a reserve for the attacker. The refill path needs its own caps and human approval.

MPC shifts risk rather than removing it. Threshold signing defends against a single stolen key share. It does nothing about a legitimate quorum signing a forged request. If the request-validation logic sits in one shared component, you have moved the single point of failure from the key to the verifier.

Incident response can destroy evidence. In a panic, teams rebuild servers and rotate credentials in ways that erase forensic data. Pre-agree a containment playbook that snapshots memory and disks, preserves logs and involves outside responders early. Bitget reportedly engaged Mandiant and SlowMist, which is the pattern to follow.

Disclosure is a risk surface too. Publishing technical details of the vendor flaw before patches are available can help copycats. Operators walk a line between transparency and giving attackers a map. The incomplete public detail in this case likely reflects that tension rather than a lack of knowledge.

Do not over-learn from one case. Public reporting is partial, early figures change and attribution is contested. Design for the general pattern, a compromised trusted component forging a trusted instruction, rather than for the specific chain of products in this incident.

Practical Recommendations

If you run or build exchange, custody, wallet or payment infrastructure, the work splits into things to do this month and things to design this year. This is general engineering guidance and not advice about any specific platform or asset.

The near-term work is verification and containment. Confirm which third-party products have standing access to production networks and credentials, and remove what they do not strictly need. Move audit logs to an append-only external store. Put hard velocity and destination caps in front of every signer, stored where the application cannot edit them. Wire reconciliation to an automatic soft throttle with human-reviewed hard freeze, and run a game day that simulates a forged-job scenario end to end.

The longer-term work is architectural independence. Give signers their own policy and balance views. Segment vendor zones from the money zone with default-deny policy. Size online floats deliberately and keep the cold refill path slow and ceremonial. Build vendor contracts around disclosure speed and the ability to disable functionality fast.

A short checklist you can adapt:

Inventory every third-party tool and the privileges, credentials and network reach it holds.
Split duties so no identity can create, approve, change policy for and erase the record of a withdrawal.
Store policy limits and allowlists outside the application’s write path.
Make each signer validate requests against independent data before signing.
Cap hourly outflow per asset and cap new-destination transfers.
Reconcile per block, and authorize an automatic freeze.
Ship logs off-host to write-once storage.
Default-deny egress for appliances and wallet servers.
Rehearse containment and evidence preservation with outside responders.
Reassess caps and floats on a fixed schedule.

Frequently Asked Questions

What happened in the Bitget breach?

According to public reporting, attackers exploited zero-day vulnerabilities in third-party security products, gained privileged access, moved to the system that handles wallet withdrawals and drained about $387.5 million from hot and warm wallets across 11 blockchains around 24 and 25 September 2026. Bitget says private keys and cold wallets were not compromised. Details such as the vendor name and final loss accounting remain subject to Bitget’s formal investigation report.

Who was behind the Bitget breach?

Attribution is contested in the reporting I reviewed. Investigators cited IP behavior and on-chain wallet overlap with earlier incidents that point to North Korean groups. One outlet describes this as confirmed, while another calls it suspected and not officially confirmed. Until Bitget or a government agency publishes a formal finding, the safest reading is suspected attribution, supported by circumstantial indicators rather than a signed conclusion.

Were customer funds lost in the Bitget breach?

Reports say Bitget is covering the loss from its protection fund, cited at $465 million as of 25 September, with a stated plan to top it up to at least $300 million. Specific customer outcomes were not described in the sources I could access. Check Bitget’s official announcements for the current status, since fund levels and withdrawal restart schedules change as the incident develops.

Why are hot wallets the main target for exchange hacks?

Hot wallets hold online keys or signing access so withdrawals work instantly, which makes them reachable from the same networks attackers compromise. Cold storage is offline and needs a deliberate ceremony to sign. Attackers therefore aim at the software that feeds hot and warm wallets, such as job servers and admin consoles, because forging an instruction there can move funds without ever touching an offline key.

How can exchanges reduce third-party vendor risk?

Treat vendor products as untrusted. Inventory the credentials and network reach each holds, replace standing credentials with short-lived scoped ones, segment vendor hosts away from wallet systems, default-deny egress, and demand fast disclosure and patch commitments contractually. Keep independent telemetry that does not rely on the vendor’s own logs, and make sure you can disable a product quickly without taking the exchange offline.

Does MPC or an HSM prevent attacks like this?

Not by itself. MPC and hardware security modules protect the signing key from theft or single-machine compromise. They do not decide whether a request is legitimate. If an attacker controls the service that submits requests and the signers trust it, the signers will sign forged withdrawals. Pair key protection with independent policy enforcement, destination allowlists, velocity caps and per-signer verification of balances and rules.