Key Management for Wallets: TEE vs MPC vs Shamir vs HSM

Last updated: September 13, 2026.

Every key management solution answers the same question in a different way: when a transaction has to be signed, where does the private key come from, and who could have produced it without permission?

This post compares the architectures in production today — TEE / secure enclave, TEE plus secret sharing, Shamir secret sharing, MPC threshold signatures, device hardware enclaves, and HSM / cloud KMS — and names which vendors ship which. Every architectural claim below is taken from the vendor's own documentation. Where a vendor does not publish a fact, the cell is blank rather than guessed.

What is non-custodial key management?

Custody is not about where the wallet lives. The wallet lives onchain. Custody is about who can authorize a transaction.

• Custodial — your organization can sign on its own. You are the custodian. In most jurisdictions this is the configuration that attracts licensing obligations.
• Non-custodial (self-custodial) — only the end user can sign. The provider holds infrastructure, not authority.
• Hybrid — both parties must cooperate, or different operations require different parties.

Two details decide which bucket a product actually falls into, and both are routinely missed.

Recovery counts as signing authority. A recovery credential can usually sign transactions directly, and whoever controls recovery can add or remove signers on the wallet. A wallet with a user-held device key but a company-held recovery key is hybrid, not non-custodial. Crossmint states this plainly in its custody models documentation, and it applies to every vendor on this page.

Non-custodial is not a property of the cryptography. Shamir secret sharing, MPC and a secure enclave can each be deployed custodially or non-custodially. What makes a setup non-custodial is that the credential releasing the key material — a passkey, a password, an OAuth session, a device key — is held by the end user and not by the provider or by you. Turnkey makes this explicit: a wallet-as-a-service implementation is non-custodial only if each end user gets a separate sub-organization and key "accessible only by the end user's secret."

So when a vendor says "non-custodial," the follow-up question is: which credential releases the key, and who holds it?

Key management architecture comparison

This is the table to read if you read nothing else. One row per architecture, one column per property.

Three things fall out of that table that vendor marketing tends to blur.

1. "Sharded" and "MPC" are not the same claim. Shamir secret sharing splits a key and then puts it back together. MPC never puts it together. Both are described as "the key is never stored in complete form," which is true of SSS only at rest — not at signing time.
2. The enclave is a trust assumption, not a proof. A TEE is only as good as its attestation and the party that publishes it. Turnkey addresses this by publishing QuorumOS, the enclave operating system, as open source — though the signing applications running on top of it are not.
3. Latency is architectural. MPC needs a round trip per signature across the quorum. Cloud TEEs need a network round trip to the enclave. A device enclave key signs locally with none.

Audits and attestations are different columns

This matters enough to separate out, because it is the single most-conflated pair in the category.

• A SOC 2 Type II attestation audits a company's controls over a period — access management, change management, monitoring. It says nothing about whether the signing code is correct.
• An independent code audit audits the implementation: the secret sharing, the enclave application, the contracts. It is scoped to a component and dated.

A vendor can hold one and not the other. Read the scope line, not the logo.

Openfort does not hold SOC 2 Type II. If a certificate is a hard gate in your procurement process today, that is a real gap and worth knowing before you start an evaluation. What Openfort publishes is five audits that are both dated and scoped to a named component — including a September 2024 Cure53 review of the Shamir secret sharing implementation itself and an October 2025 Quantstamp review of key management. The full set is on the Openfort security page.

Dating matters more than the count. Privy is the only other vendor here that dates its audits; Turnkey names four firms without dates, and Fireblocks names NCC without dates. An undated audit tells you a review happened at some point, not whether it covered the code running today.

Openfort — Shamir secret sharing with an open-source signer

Openfort embedded wallets split the private key with Shamir secret sharing. The shares are persisted to Shield — Openfort's key-management service — and to the user's account. The key is reassembled client-side inside an isolated signing boundary; the output is a signature, never an exported private key.

The recovery share is what determines the security model, and Openfort ships three ways to encrypt it:

• Automatic recovery — the recovery share is encrypted with a combination of project entropy and Openfort entropy. Your backend mints a single-use encryption session at login. Lowest friction; requires one API route.
• Password recovery — the recovery share is encrypted with user-provided entropy. No backend required. The user enters the password once per new device.
• Passkey recovery — the recovery share is encrypted by a hardware-backed WebAuthn credential. Note that WebAuthn credentials are domain-bound, so a passkey created for one domain will not work on another.

Backend wallets use a different model: signing runs inside an isolated execution environment (TEE) with the private key stored encrypted and never exposed.

The part that is specific to Openfort: the signer is open source. OpenSigner is the key-management infrastructure itself, and you can run it on your own servers, keeping custody of the key shares and the authentication data inside your infrastructure. That is a different claim from publishing a cryptographic primitive — it is the whole signing service, not the library underneath it. Openfort as a company is not "open source"; the signer is.

Audited components, oldest to newest: CertiK (December 2023, smart contract wallet), Cure53 (September 2024, Shamir secret sharing), Omniscia (December 2024, smart contract wallet), Quantstamp (September 2025, 7702 contract delegator), Quantstamp (October 2025, key management).

Privy — 2-of-2 Shamir shares recombined inside a TEE

Privy runs sensitive wallet operations inside AWS Nitro Enclaves and splits private keys using Shamir's secret sharing into what its documentation calls a 2-of-2 share set:

• an enclave share, "secured directly by the trusted execution environment and encrypted with the TEE's cryptographic key"
• an auth share, "encrypted and stored by Privy," released only against valid authentication credentials

Both shares are required to produce a signature. Per Privy's docs, "only the TEE can decrypt the enclave share and combine it with the auth share to temporarily reconstitute the wallet and execute actions," and keys "only exist in complete form temporarily within the trusted execution environment during signing operations."

Privy publishes four dated code audits — Cure53 (February 2023), Zellic (June 2023), SwordBytes (December 2023) and Doyensec (February 2024) — alongside SOC 2 Type II (April 2026) and a HackerOne bug bounty. Its Shamir secret sharing library is published under Apache-2.0 with the Cure53 and Zellic reports linked — a cryptographic primitive, not the signer.

Privy's audit record is the closest comparable to Openfort's on this page, and worth being precise about: four audits to Openfort's five, with the most recent dated February 2024 against Openfort's October 2025. Privy also holds the SOC 2 Type II that Openfort does not.

Turnkey — encrypted keys, decrypted only inside an attested enclave

Turnkey does not split keys. It persists encrypted private key ciphertext in its primary and disaster-recovery databases, and that ciphertext "is only to be decrypted from within the bounds of a secure enclave running verified Turnkey applications."

The enclaves are AWS Nitro-based, running Turnkey's own enclave operating system, QuorumOS, with "no persistent storage, no interactive access, and no external networking." Key generation, signing and policy evaluation all happen inside. Turnkey's own analogy is a safety deposit box operator: it secures and facilitates access, but only the customer can unlock the box.

For the model to be non-custodial for your end users, Turnkey's docs are specific about what you have to build: a separate Turnkey sub-organization, user and private key per end user, "accessible only by the end user's secret (e.g., API key or Passkey credentials)." That is a design decision in your integration, not a default.

Turnkey's Trust Center documents SOC 2 Type II and GDPR compliance, and turnkey.com states it is "SOC 2 Type II audited" and names four audit firms — Distrust, Cure53, Trail of Bits and Zellic. No dates or component scopes are published for those reviews, so you cannot tell from the outside how recent any of them is or what it covered. QuorumOS is open source; the signing applications running on it are not.

Coinbase CDP — AWS Nitro Enclaves, two auth modes

Coinbase Developer Platform Server Wallets run key operations inside AWS Nitro Enclaves with "no persistent storage, no interactive access, and no external networking." Keys are encrypted and decrypted inside the enclave and "never leave the enclave in plaintext." Private key operations are documented as not externally accessible to CDP, AWS, or other infrastructure components.

Custody depends on which auth mode you pick:

• API key auth — your backend holds the credential. Developer-managed, and therefore custodial for those wallets.
• End-user auth — device-specific key material is generated and stored locally on the end user's device. Non-custodial.

Recovery for a lost developer credential is credential rotation: delete the old Wallet Secret and generate a new one in the CDP Portal.

MetaMask Embedded Wallets (formerly Web3Auth) — 2-of-3 Shamir

Web3Auth is now MetaMask Embedded Wallets. Its default architecture is Shamir's Secret Sharing at a 2-of-3 threshold, with three named shares:

• ShareA (device share) — stored locally on the user's device
• ShareB (network share) — encrypted with the user's encryption key and held on the storage layer
• ShareC (recovery share) — "generally not used during normal operation," available when the device is lost

Any two shares reconstruct the key via Lagrange interpolation. Users add devices by issuing further shares (ShareD and onward), which raises the total and the threshold together. ShareC can be derived from deterministic inputs such as security questions.

A separate MPC/TSS path exists via the MPC Core Kit SDK, which performs no key reconstruction, and is documented as enterprise-plan only. SSS is what ships on the Base, Growth and Scale plans.

Fireblocks — MPC-CMP, no key ever assembled

Fireblocks uses MPC-CMP threshold signatures. Key shares live across "multiple independent endpoints, e.g. cloud servers, on-premises hardware, or mobile devices," and per Fireblocks' own description, "the complete key is never assembled in one place, at any point in time." Signing requires a quorum of at least three endpoints, each independently validating the transaction, and the signature is produced by distributed computation.

Storage tiers map to where shares sit: hot shares in the cloud, warm and cold configurations keeping at least one share offline on an air-gapped device. Shares can be refreshed and rotated without changing the wallet's onchain address, which is why key rotation does not force a wallet migration.

Fireblocks publishes SOC 2 Type 2, ISO 27001, and C4 CCSS QSP Level 3, and states its cryptographic libraries are NCC-audited. It is built for institutional custody and treasury operations, not for per-user embedded wallets.

Crossmint — non-extractable device keys, permissions enforced onchain

Crossmint separates the wallet from the signer. The wallet is an ERC-4337 smart contract with ERC-7579 modules on EVM chains (PDAs on Solana, Soroban contracts on Stellar), so signer permissions are enforced and auditable onchain rather than in a vendor's backend.

The default signer is a P256 key generated inside the user's device secure element — iOS Secure Enclave, Android Keystore, or a browser credential store. The key is non-extractable: not by your application, not by Crossmint, not by the operating system. Signing happens on the device with no network round-trip.

Recovery is a separate onchain signer — email OTP, phone OTP, or an external wallet — enrolled in the wallet's signer set. Because the recovery signer can also sign transactions directly, the choice of recovery signer is what decides custody. Crossmint's own mapping: device signer plus email/phone OTP is non-custodial; device signer plus server signer is hybrid; server signer plus server signer is custodial.

For server-side and treasury wallets, Crossmint supports server key signers held in your own infrastructure, and Cloud KMS signers on AWS KMS, Azure Key Vault or GCP Cloud HSM, keeping keys non-extractable inside the HSM at up to 1,000 signing operations per second per key.

Magic — sharded keys recombined inside a TEE

Magic's TKMS (TEE Key Management System, successor to its earlier DKMS) splits keys into shards held across Magic and, optionally, the developer, "depending on the security requirements." Each shard is encrypted and secured in Trusted Execution Environments with AWS KMS. Per Magic's documentation, shards "are retrieved and securely recombined inside the TEE, never leaving hardware isolation," and "no single party — including Magic — holds a complete, usable key outside the enclave."

Which model do you actually need?

Match the architecture to the constraint that is actually binding on you.

"We need non-custodial key management without holding customer keys." Any of TEE, TEE-plus-sharing, SSS or device enclave works — what matters is that the credential releasing the key stays with the end user, and that your recovery signer does not quietly hand you signing authority back. Check the recovery path before you check the cryptography.

"We're building a payment API and need to sign server-side, unattended." A user-device signer cannot sign at 3am on a cron. You need a TEE-backed server wallet (Turnkey, Coinbase CDP, Openfort backend wallets) or a server key in your own infrastructure (Crossmint server signers). Scope it with a smart account so the server credential can only do payouts, not arbitrary transfers.

"Enterprise-grade, and no single party may move funds alone." That is a separation-of-duties requirement and it is an MPC or multi-signer answer. Fireblocks' MPC-CMP with a quorum of independent endpoints is the established shape. No amount of policy configuration inside a single-signer system substitutes for it.

"We need transparent key management our security team can verify." Verifiability comes in three grades, and they are not equivalent: an attestation you can check (TEE remote attestation), a dated code audit naming the component it covered, or source you can read and run. Openfort's OpenSigner is the third, with the Shamir implementation covered by Cure53 in September 2024. Turnkey's QuorumOS is the third for the enclave OS but not the signing applications. Privy's SSS library is the third for the primitive but not the signer.

"Global payouts, high throughput, low latency per signature." MPC costs a quorum round trip per signature and cloud TEEs cost a network round trip. Device enclave signing (Crossmint) and in-process server key signing have neither. Measure signatures per second against your actual payout batch size before optimizing anything else.

"Consumer app — users will lose their phones." Recovery is the product decision, not storage. Passkey recovery gives you biometrics and phishing resistance but binds credentials to one domain. Password recovery works everywhere and needs no backend, at the cost of a forgettable secret. Backend-issued encryption sessions (Openfort automatic recovery, Privy auth share, MetaMask ShareB) give the lowest friction and require a server route.

Detailed comparison

Blank cells mean the vendor does not publish the fact in its own documentation, or it could not be read there. They are not "no."

Questions to ask a key management vendor

1. Which credential releases the key material, and who holds it? This, not the cryptography, decides custody.
2. Who holds the recovery signer? If the answer is "you do," the wallet is hybrid regardless of what the signing path looks like.
3. Is the key ever assembled whole, and where? SSS assembles it; MPC does not. Both are described as "never stored in complete form."
4. Can I read or self-host the signer? Not the primitive library — the signing service.
5. Which components have been audited, by whom, and when? Ask for the scope line. "We're audited" without a component name is not an answer.
6. Is your SOC 2 covering controls or code? Controls. Always controls. It is not a substitute for a code audit and should never share a column with one.
7. What happens to the wallet address when keys rotate? MPC reshares and smart-contract wallets keep the address. Key-derived addresses do not.

Related comparisons

• Best Wallet-as-a-Service Providers in 2026 — the infrastructure pillar
• Best Embedded Wallets in 2026
• Best Agent Wallets for Developers
• Non-custodial wallet infrastructure: open beats closed
• Fireblocks vs Turnkey and Privy vs Turnkey
• TEE wallets explained
• Smart wallet security best practices

Read the Openfort security page for the full audit record with dates and scopes, or start building for free.