JP Aumossan, author of “Serious Cryptography,” once told Microsoft, “Key management is always the hardest part of any cryptographic architecture.” It’s rarely the math that fails, but the handling of the keys themselves.
In crypto key management, wallet infrastructure providers take multiple different approaches to wallet security: some rely on HSMs, others on multi-party computation (MPC), and others on trusted execution environments (TEEs). Some even combine these strategies.
This article highlights the unique challenges of key management in decentralized applications, and defines the main schemes used when building secure key management infrastructure.
It also details how Turnkey’s own approach to key management differs from competing models and what that means for developers looking to use a wallet provider for their own decentralized applications.
Why robust key management is critical for your business
Whether you're building a decentralized exchange, a crypto game, or an AI-driven trading app, your users expect their assets to be secure by default. Failing to deliver on that trust can lead to churn, reputational damage, and significant financial losses.
This reality is underscored by history. Mt. Gox, once the world’s leading Bitcoin exchange, suffered catastrophic breaches in 2011 and 2014 due to poorly managed private keys that they stored in plain text without adequate safeguards. Undetected for years, the breach became one of crypto’s most notorious security failures, not from flaws in blockchain technology, but from mismanaged keys.
In contrast to poor key management, secure applications build trust and foster loyalty from their customers. A 2024 survey of 5,000 European digital banking customers, for example, found that 75% of respondents prioritized transaction security over user experience, a signal that users are willing to trade convenience for confidence when their money is at stake.
The point is when it comes to securing assets, there is no “good enough.” Without verifiable protection at every step, you’re gambling with your users’ trust and your business’s future.
Choosing wallet infrastructure, then, that prioritizes security, minimizes risks, and provides transparent proof of protection is non-negotiable for ensuring business stability and retention of customers.
Not all wallet infrastructure is created equal and developers need to make sure they understand what’s beneath the hood before trusting their application to infra that sounds good enough but could have underlying vulnerabilities. The strongest systems are those that can prove their security model at every point rather than relying on promises alone.
Crypto key management – the basics
Wallets don’t actually hold crypto. They hold keys, specifically, the cryptographic credentials that prove ownership of assets on a blockchain.
They’re made up of an asymmetric keypair that includes a public and private key. A wallet’s public address is derived from the public key, visible onchain and used to receive funds. The private key is the secret half of the pair, the credential required to authorize transactions. Whoever controls the private key controls the assets.
This simple model creates a high-stakes security problem. Private keys must be protected at all costs. If they are lost, assets are gone forever. If they are exposed, attackers can move funds instantly, without recourse.
Every wallet infrastructure solution, from consumer apps to institutional custody, is ultimately judged by how well it generates, stores, and uses private keys without letting them leak into untrusted environments. That’s why the architecture behind key management matters as much as the cryptography itself.
How do wallet providers keep keys safe?
Several cryptographic schemes exist to keep keys safe, but the three dominant ones are Hardware Security Modules (HSMs), Multi-Party Computation (MPC), and Trusted Execution Environments (TEEs). Some providers rely on one alone while others combine them.
Understanding these technologies is critical to choosing the right infrastructure for your application.
Hardware Security Modules (HSMs) in key management
Hardware Security Modules are physical devices designed to safeguard cryptographic key material. They generate, store, and use private keys inside hardened hardware, protecting against tampering and unauthorized access.
HSMs are often paired with digital certificates, digital signatures, and public key infrastructure (PKI), which has made them the backbone of enterprise key management for decades.
- Strengths: Proven in traditional finance; strong tamper resistance
- Weaknesses: Expensive to deploy; limited flexibility; hard to scale in decentralized and cloud-based environments.
Multi-Party Computation (MPC) in key management
Multi-Party Computation takes a different approach. Instead of storing the full private key in one place, MPC splits it into shares. Each share is distributed across different devices or services, and only when there is enough of them to participate in a signing protocol can a transaction be signed. This threshold model removes the single point of failure that comes with storing keys in one location.
- Strengths: Reduces single points of failure; flexible recovery models; can improve resilience across distributed participants.
- Weaknesses: Complex to manage; introduces latency; share distribution and transport can create new risks; a lot of the MPC algorithms are new and haven’t been battle-tested.
Trusted Execution Environments (TEEs) in key management
Trusted Execution Environments are secure enclaves built into commodity hardware. They create isolated environments where sensitive operations – like key generation, storage, and signing – are sealed off from the host operating system. Policies can also be enforced directly in the enclave, ensuring that only approved transactions are signed.
- Strengths: Flexible and cloud-native; isolates keys from host systems; enables in-enclave policy enforcement; can be easily scaled within a cloud environment (unlike HSMs).
- Weaknesses: Fewer physical safeguards than HSMs; requires reproducibility and attestation to ensure trust
Why combining key management approaches is not necessarily better
Some providers attempt to stack approaches, pairing MPC with HSMs, or layering enclaves on top of traditional hardware. On paper, this looks like extra protection. In practice, it often introduces more moving parts, more orchestration layers, and more opportunities for misconfiguration.
Security doesn’t automatically improve just because multiple schemes are combined. Each layer adds operational complexity, latency, and potential new attack surfaces. When two or more systems must coordinate, developers also inherit the risks of integration points.
In key management, complexity is not always your friend. What matters is whether keys are generated, stored, and used in a way that never exposes them outside a protected boundary. That’s where Turnkey’s TEE approach stands apart, removing unnecessary layers and keeping the security model simple, verifiable, and strong.
Turnkey’s TEE approach to key management
With Turnkey, keys are created inside secure enclaves and encrypted using a root key that never leaves, ensuring raw private keys never exist outside that protected boundary. All signing, encryption, and policy enforcement also happen in-enclave.
Conditions like transaction limits, multisig approvals, or role-based restrictions are also baked directly into the trusted execution environment. Developers simply set the rules, and Turnkey enforces them in the enclave
This is important because when policy enforcement lives outside the enclave, it relies on middleware that is less secure and could potentially leave the rules themselves open to manipulation or compromise.
Turnkey’s all-in enclave model also sidesteps another common weakness with competing models that attempt to combine MPCwith TEEs. In MPC models, key shares never leave their MPC nodes but must still participate in a distributed protocol, creating coordination paths where trust and exposure can creep in.
With Turnkey, the unencrypted key never exists outside the enclave at all, eliminating the risks of transporting or reconstructing secrets across systems and drastically reducing potential points of compromise.
- No external HSM orchestration or scaling challenges.
- No policy implementation outside of the enclave or insecure handoffs.
No one, including Turnkey, ever has access to the raw private key. It is generated inside a secure enclave and encrypted with an internal key that never leaves that boundary. The encrypted key material is stored securely, but decryption and signing occur only within the enclave under enforced policies.
This design delivers a truly non-custodial model, where only the key owner retains control, combined with the hardened security of enclave-based infrastructure.
Verifiable Security Guarantees
But true security isn’t just about protection, it’s about proof. Turnkey’s enclaves stand apart because they offer verifiability through reproducible builds and remote attestation.
End-to-end reproducible builds (full-source bootstrap reproducibility) — Enclave binaries are built deterministically from the ground up, with every layer – from kernel to dependencies – rebuilt from source. This means deployed binaries can be matched back through the entire audited history of the code, preventing stealth changes, hidden dependencies, or malicious insertions anywhere in the build pipeline.
Remote attestation — Independent verifiers can confirm the enclave is running exactly the binary you expect, matching it to reviewed code. This gives developers assurance of integrity and users confidence that transactions are signed in a trusted environment.
With Turnkey’s key management approach, you get strong, simple security assumptions. Keys and policy enforcement never escape the enclave. Your code is proven and therefore able to be trusted.
All of this means safer wallets, faster time to market, and trust from users that isn’t just promised but provably delivered.
Turnkey: the future of web3 key management
The strongest applications in web3 will be the ones that earn and keep user trust, and that starts with how keys are secured.
Each model has its place: HSMs have proven themselves in traditional finance but are costly and rigid. MPC removes single points of failure but adds operational complexity and new risks. TEEs are flexible and cloud-native, but without reproducibility and attestation, their promises remain unverified.
Turnkey’s enclave-native architecture closes these gaps. Keys never leave the enclave. Signing and policies are enforced in the same isolated environment where keys live. Reproducible builds and remote attestation ensure both the code and the runtime can be trusted.
For developers, this balance means stronger guarantees with less complexity. For users, it means their assets are protected by design, not by chance. This is the future of key management in web3: security that isn’t just marketed, but provably delivered.
Related articles
.png)
.png)
