Best Key Management and MPC Providers

Every vendor in this category will tell you the private key is never assembled in one place, and most of them are telling the truth. It is also not the question that matters.

Two things actually determine your exposure. Where the key material physically lives, and what the policy engine does with a request that matches no rule.

So this compares six providers on those two answers, because they predict almost everything else, including whether you can keep signing on the day the vendor cannot.

A policy engine that allows anything it was not told to block is not a control. The default behaviour, not the rule list, is the security posture.

Key Takeaways

• Architecture matters more than feature lists in this category.
• Fireblocks MPC-CMP signs in one round, never assembling the key.
• Turnkey and Privy keep key material inside hardware enclaves.
• Safe puts the policy onchain rather than in a vendor.
• Deny by default is the only defensible policy posture.

The Two Questions That Decide This

Four architectures appear in this comparison, and they fail in different ways rather than in different degrees.

Threshold signing splits a key into shares that never come together, so an attacker needs several environments at once. A secure enclave keeps the whole key inside hardware the operator cannot read into, which is a different bet, placed on the chip vendor rather than on distribution.

Contract-based multisig moves the rule entirely onchain, where it is public and permanent. The underlying choice is the same one set out in our comparison of custodial vs non-custodial wallets, which is who can move funds without you.

What to note: ask what happens to an unmatched request, and ask it before asking about chains or throughput.

Best Key Management and MPC Providers

1. Fireblocks

Does the job: the most documented threshold signing implementation in production.

Fireblocks publishes more detail about its cryptography than anyone else here, and MPC-CMP is the reason the performance objection to threshold signing largely went away.

The platform supports:

• Shares distributed across cloud servers, on-premises hardware and mobile devices
• A signing quorum of at least three endpoints, with the complete key never assembled
• One signing round, against nine for the previous industry standard
• Cold configurations keeping at least one share offline in an air-gapped device
• Policy rules on source, destination, asset type and amount, signed by an admin quorum and enforced inside Intel SGX
• Per-endpoint policy validation before any share is contributed

Three caveats. The speed claims carry no published benchmark methodology, the page makes no SOC or ISO claim, and since acquiring TRES Finance in January 2026 Fireblocks also sells the accounting layer that reconciles what it signs.

Best for institutions that need the signing architecture itself to survive a security review.

2. Turnkey

Does the job: deny by default, enforced inside the enclave rather than in front of it.

Turnkey takes the enclave route instead of threshold signing, and the policy engine runs in the same protected environment as the key.

The platform supports:

• Keys held in hardware-backed secure enclaves, with only derived outputs leaving
• A policy engine inside the enclave checking every request, deny by default
• Quorum approval available for sensitive operations
• Import and export encrypted end-to-end to the enclave using HPKE
• Exports gated by policy rather than available on request
• Each key operation described as stamped and verifiable

Two things the documentation does not answer. It does not explain how trust is split between Turnkey and the customer when it says no single party can reach plaintext key material, and it names verifiability without describing the attestation process.

Best for teams that want programmatic signing with a policy posture they can defend in writing.

3. Privy

Does the job: the clearest published split of who can reassemble a key.

Privy combines both approaches, splitting the key in two and keeping the reassembly inside an enclave, which produces the most specific trust statement in this group.

The platform supports:

• Key generation, policy enforcement and signing inside hardened execution environments
• Each wallet key split by Shamir secret sharing into two encrypted shares
• One share sealed in the enclave and one held by the API on separate infrastructure, never stored together
• Reassembly only inside the enclave, in memory, for the duration of one approved action
• A stated position that Privy staff cannot reconstruct keys or bypass policy checks
• Compromise of one provider being insufficient to recover a key

The secure enclave page describes no key export route, which is the question to ask if you want an exit path. Our comparison of Privy vs Turnkey goes further on how the two policy engines behave in practice.

Best for product teams embedding wallets for end users without wanting custody of the keys.

4. Dfns

Does the job: lets you choose where the key material physically sits.

Dfns is the only entry offering the deployment choice as a product decision, which is the difference between a vendor dependency and a software one.

The platform supports:

• Managed, hybrid and fully on-premises deployment of the key management system
• A distributed network of MPC nodes, each in its own secure enclave holding one share
• A stated position that no single node holds the full key and the key is never reconstructed
• Policy evaluation before signing, covering role permissions, destination allow and deny lists and transfer limits
• Multi-level approvals, with transactions held in a pending state until met
• Real-time alerts and audit logs

The architecture page leaves the central question open, since it does not say whether Dfns alone can meet the signing threshold or whether customer-held shares are required in hybrid deployments. It also names no certifications or audits, and the stronger security language is marketing rather than evidence.

Best for regulated businesses that need key material inside their own perimeter.

5. BitGo

Does the job: the regulated custodian route, with classic multisig underneath.

BitGo answers a different question from the rest of this list, which is who is legally responsible for the assets rather than how the signature is produced.

The platform supports:

• A two-of-three multi-signature key architecture
• Geographically dispersed cold storage
• Multiple regulated trust companies operating worldwide
• A qualified custody product for institutions needing a custodian of record
• An architecture where no single person can withdraw unilaterally

The published material is notably thin on the specifics that matter. It does not say who holds each of the three keys, whether a client can sign without BitGo, which entities hold which licences, or confirm BitGo's own SOC reports as opposed to describing them as an industry norm.

Best for institutions whose requirement is a named custodian of record rather than a signing architecture.

6. Safe

Does the job: moves the rule onchain and hands key management back to you.

Safe is the structural outlier here, because it does not manage keys at all. It enforces a threshold in a smart contract, and whose keys those are remains your problem.

The platform supports:

• A smart contract account with its own address, holding funds and interacting with contracts
• A list of owners and a threshold of approvals required to execute
• Owners that can be externally owned accounts, other smart accounts or passkeys
• Owner and threshold changes through the Owner Manager, emitting onchain events
• Modules for alternative execution patterns such as allowance limits and recovery
• Guards running checks before and after execution

Two risks are specific to this model. Modules can bypass standard authorisation, and a faulty or malicious guard can block transactions or lock funds outright, so both are security-critical additions rather than features.

Best for teams that want the control rule to be public and permanent rather than contractual.

Compared

The last two columns are where the real differences sit, and three of the six do not answer them in public documentation. That is not necessarily a red flag, but it does mean those answers belong in a security questionnaire rather than in a comparison table.

What to note: a vendor that cannot state its unmatched-request behaviour in one sentence has not finished designing its policy engine.

How to Choose

1. Write down who must be unable to move funds

Name the parties, including the vendor and your own engineers. The architecture that satisfies that sentence is usually the only one that fits.

2. Ask for the unmatched-request behaviour in writing

Deny by default and allow by default produce identical demos and opposite incident reports. Get the answer in the security review, not the sales call.

3. Test the exit before you depend on it

Export, migration and recovery are the paths nobody rehearses. If export is policy-gated or undocumented, assume you cannot leave quickly and price that in.

4. Separate the signer from the auditor

Buying signing, custody and accounting from one vendor is convenient and removes the independence that made reconciliation meaningful. Our comparison of BitGo vs Fireblocks covers the custody side of that same trade-off.

5. Run one failure drill during the pilot

Revoke a signer, lose a device, reject a transaction at the policy layer. The recovery path, not the happy path, is what you are actually buying.

What to note: involve whoever signs off on security before shortlisting, because their questions are the real requirements.

How This List Was Built

Inclusion required three things, so that the comparison means something.

• Public technical documentation describing the key architecture, rather than a security marketing page
• A stated policy mechanism, meaning something that evaluates a request before a signature is produced
• Enough published detail to state clearly what the vendor does not disclose

Several providers in this category are not here, either because the architecture is not publicly documented or because the detail could not be verified at the time of writing. Operators who believe they meet the three criteria above are welcome to send documentation for consideration in the next update.

What to note: last reviewed against vendor documentation in October 2026, and claims in this category change with each release.

Risks and Limitations

• Performance and security claims are vendor statements and are not independently verified here.
• Three of the six do not state publicly whether the vendor alone can produce a signature.
• Enclave-based designs move trust to the hardware vendor, which is a different risk rather than a smaller one.
• Safe modules can bypass standard authorisation and a faulty guard can lock funds permanently.
• Custody platforms are acquiring accounting and reporting tools, which reduces the independence of reconciliation.

Conclusion

The best key management provider is the one whose answers to two questions match your risk register. Where the key material lives, and what happens to a request nobody wrote a rule for.

Fireblocks is the most documented threshold implementation, Turnkey states the strongest default posture, Privy publishes the clearest account of who can reassemble a key, Dfns is the choice when the key material must stay inside your perimeter, BitGo answers the qualified custodian requirement, and Safe is for teams who want the rule onchain and the keys in their own hands.

Two habits matter more than the choice. Get the unmatched-request behaviour in writing before the contract, and rehearse the exit while you still have leverage.

Read Next:

• Custodial vs Non-Custodial Wallets
• Crossmint vs Privy vs Turnkey
• BitGo vs Fireblocks

FAQs:

1. What is MPC in key management?

Multi-party computation splits a private key into shares held in separate environments, and produces a signature through a joint computation so the full key is never assembled. The practical benefit is that compromising one environment is not enough to move funds.

2. Is a secure enclave better than MPC?

Neither is strictly better, because they place trust differently. MPC distributes the risk across environments and operators, while an enclave concentrates it inside hardware the operator cannot read into, which means trusting the chip vendor and the attestation process instead.

3. Why does deny by default matter so much?

Because production traffic eventually contains a request nobody anticipated. A deny-by-default engine refuses it and raises an alert, while an allow-by-default engine signs it and tells you afterwards.

4. Can I keep signing if the vendor goes down?

It depends entirely on the architecture. Safe owners hold their own keys, Dfns offers on-premises deployment, and Turnkey gates export behind policy, so this belongs in the contract rather than in an assumption.

5. Does using MPC remove the need for a policy engine?

No, and conflating the two is a common mistake. Threshold signing decides how a signature is produced, while the policy engine decides whether it should be produced at all, and only the second one stops an authorised but wrong transaction.

Disclaimer:
This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, tax, or security advice; no material herein should be interpreted as a recommendation, endorsement, or solicitation, and readers should conduct their own independent research or consult a qualified professional. Key architectures, policy behaviour, certifications and deployment options are drawn from each vendor's own documentation at the time of writing, are not independently verified or security-audited here, and change frequently; confirm current architecture, certifications and contractual terms directly with each vendor, and with your own security and legal reviewers, before moving funds or key material.