Turnkey’s approach to digital asset security: Secure, verifiable, reproducible
In crypto, digital assets live onchain, but security depends on more than the chain itself. It also depends on offchain infrastructure that dictates how signing authority is created, protected, and controlled.
Private keys authorize the transactions that move crypto assets from one wallet to another. They govern access and define who can act on behalf of these assets. That makes key management the foundation of any serious digital asset security model, whether the architecture uses cold storage, hardware wallets, custodians, HSMs, MPC, or enclave-based infrastructure.
Whatever key management solution you choose to use, each of these solutions still boils down to the same questions: who can use the key, and what are they allowed to sign? How are keys generated? Which policies are checked before a signature is produced?
Turnkey's answer to those questions rests on a single goal: security claims should be provable, not promised. Everything else in Turnkey's architecture follows from that goal, and it comes down to three key design choices:
- Security: private keys and every sensitive operation around them stay inside hardware-isolated enclaves
- Verifiability: anyone can prove what code processed a sensitive operation
- Reproducibility: critical infrastructure can be inspected, reproduced, and measured
This article walks through what Turnkey is trying to achieve and why each infrastructure choice follows from it.
Turnkey’s digital asset security priorities: What we're trying to achieve
The standard approach to private key management is secrecy and trust in whatever key management provider maintains the infrastructure.
Keys are generated and managed behind redundant layers of defense, and customers are asked to trust that the vendor's software and operators behave correctly. The proof, when it exists, comes from periodic audits and compliance reports.
Turnkey starts from the opposite assumption: everything is potentially compromised until proven secure. Servers can be breached, credentials can be stolen, insiders can go rogue, and infrastructure providers can make mistakes.
Designing for that assumption produces a specific set of priorities. The system should remain safe even if everything outside its most protected boundary fails. No single engineer should be able to access a key, alter critical software, or reconstruct a secret. And customers should be able to verify all of this themselves rather than take Turnkey's word for it.
Those goals are why Turnkey is built the way it is.
Attackers don't need to steal your keys
Many platforms that mention HSMs or enclaves use them as a dumb vault: a hardened box that stores keys and signs whatever it is asked to sign. A traditional server sits in front of the box, decides what should be signed, and forwards the request.
The problem is that the box has no context. It cannot tell a legitimate withdrawal from a malicious one, so an attacker does not need to break into the vault at all. Compromising the ordinary server in front of it is enough to drain wallets, because the vault will faithfully sign whatever that server sends.
This is the insight at the center of Turnkey's design. Attackers do not need to extract private keys to steal digital assets; compromising authentication, transaction data, or policy evaluation is enough. Once funds are gone, it no longer matters that the key stayed private.
So the trusted environment has to be smart enough to say yes or no with the full context of the request. Otherwise, security has simply shifted from the machine holding the key to the machine that talks to it, and attackers always go after the weakest link.
Security: Protect the whole signing path
This is why Turnkey runs the entire signing path, not just key storage, inside hardware-isolated secure enclaves, a type of Trusted Execution Environment. An enclave verifies the credential, such as a passkey, on every request and parses the unsigned transaction to understand what it actually does. Enclaves also evaluate policies and produce the signature.
Turnkey enclaves are deliberately constrained. They have no persistent storage, no interactive access, and no external networking; the only way in or out is a single narrow channel to the host machine. Encrypted key material can live outside the enclave, but it is only ever decrypted inside an authorized enclave running verified Turnkey software.
Raw private keys are not exposed to Turnkey's application servers, databases, or employees, or to customer application code, during normal operation.
So this is a truly non-custodial solution: your users keep control of their assets without Turnkey or anyone else ever holding usable key material.
Ebook
Discover how Turnkey secures keys inside hardware enclaves
Turnkey's TEEs Explained ebook breaks down how trusted execution environments secure wallet operations by isolating keys and code inside tamper-proof hardware. Learn how enclaves keep private keys unexposed even when everything around them is compromised.
Read the ebook →Policy checks before every signature
Because the enclave understands the request, it can enforce rules before signing rather than after the fact.
Turnkey's policy engine runs inside the enclave boundary and checks every request against the organization's policies: which users or machines can access a wallet, which activity types they can perform, which destination addresses and contracts are allowed, which transaction values are permitted, and whether multiple approvals are required.
This is the difference between authentication and authorization. Authentication answers "who is making this request?" Authorization answers "should this request be allowed?" Turnkey brings both inside the same protected boundary as the key itself.
Teams use scoped policies and sub-organizations to separate wallets and administrative authority.
No single person is a point of failure
The same paranoia applies to Turnkey's own people. Core secrets are split into encrypted shares held by separate individuals on secure hardware, and they can only be reconstructed inside an enclave. Deploying new enclave software requires approval from a quorum of operators.
The result is that no single Turnkey engineer can access an enclave, alter what runs inside it, or reconstruct a secret. Insider risk is addressed structurally rather than through trust in any individual.
Ebook
Learn how Turnkey's policy engine guards every transaction
Turnkey's Policy Engine ebook shows how to define and enforce policies that defend every signing request. See how granular controls over who can sign, what they can sign, and when keep digital transactions secure.
Read the ebook →Verifiability: Don't trust, verify
Hardware isolation answers where sensitive operations run. It does not answer what software is running there, and a secure box running the wrong code is not secure at all.
Turnkey divides its infrastructure into two spaces. The untrusted space covers everything assumed to be compromisable: edge infrastructure, databases, deployment tooling, and ordinary servers. The trusted space contains the critical software that creates keys, authorizes their use, and signs with them. The bet Turnkey makes is that this trusted space should be verifiable by anyone, not just by auditors.
Remote attestation
The building block for this is remote attestation. Turnkey's enclaves run on AWS Nitro Enclaves, which produce signed documents containing measurements of the software and configuration running inside. Anyone holding an attestation can compare those measurements against known, approved values and confirm that a specific machine is running specific software.
Turnkey uses QuorumOS, an open source operating system for secure enclave applications, to make those attestations meaningful. QuorumOS ties each attestation to the exact application running inside the enclave, and no secrets are provisioned into an enclave until its measurements check out. Unapproved software never gets near protected material.
Verifiable data
The data behind authorization decisions gets the same treatment. Organizations, users, wallets, policies, and credentials are cryptographically authenticated, so untrusted infrastructure cannot quietly modify records or feed the enclave stale state.
That matters because a rollback can be as dangerous as a direct compromise. An attacker who could present last month's configuration might re-enable a removed credential or restore a weaker policy. Turnkey's enclaves verify that the data they evaluate is both authentic and fresh before acting on it.
Proof for every operation
Turnkey Verified extends verification from the system level down to individual operations. Boot Proofs establish that a result came from a legitimate enclave running approved software, and App Proofs are signed claims about what that enclave actually did, such as deriving a wallet address or evaluating a policy.
A conventional audit log says an operation happened. A proof connects that operation to an attested machine running attested code. Security no longer depends on Turnkey saying the right code processed a request; that claim can be independently checked.
Ebook
Understand how Turnkey proves every operation is correct
Turnkey's Verifiability Explained ebook shows how verifiability gives confidence in every transaction. Learn how proving that critical operations execute exactly as intended reshapes trust in onchain systems.
Read the ebook →Reproducibility: From inspectable code to provable binaries
Attestation proves an enclave is running a specific binary. By itself, that still leaves a gap: how does anyone know what that binary does, or that it was honestly built from the source code they reviewed?
A repository can be public while the build pipeline that turns it into a binary is compromised. Closing that gap requires reproducible builds: builds that produce the same artifact, byte for byte, from the same source code and inputs, no matter who runs them or where.
Turnkey uses StageX, an open source, container-native Linux distribution, built from the ground up for reproducibility, for every secure build. With reproducible builds, anyone can compile Turnkey's published source code themselves, compare the result against the measurements an enclave reports, and confirm the two match.
That turns "this enclave runs this binary" into "this enclave runs this source code," which is a much stronger statement. The full chain works like this:
- Source code is reviewed and approved.
- A deterministic artifact is built from controlled inputs.
- A quorum of operators approves it for deployment.
- The running workload is attested in production.
- Anyone can rebuild the source independently and compare the measurements.
Open source provides the visibility, reproducible builds provide the link to production, and attestation provides the proof that the link holds. Each piece alone is incomplete but together they replace vendor promises with evidence.
Turnkey's aim is to push verifiability outward: first so customers can attest the stack themselves rather than relying on Turnkey's word, and over time so they can extend the policy engine with their own QuorumOS applications and bring in outside data.
Ebook
Explore how Turnkey makes its builds independently verifiable
Turnkey's End-to-End Reproducible Builds ebook shows how to make every software artifact independently rebuildable, inspectable, and verifiable. See how reproducibility closes the gap between source code and what actually runs in production.
Read the ebook →Built for builders, across chains
None of this matters if it cannot support real applications. Developers are creating wallets, parsing transactions, automating transfers, sponsoring gas, and coordinating signing across multiple blockchains, often at high throughput.
Turnkey's design choices carry through here too. Because the system operates on shared cryptographic primitives rather than chain-specific transaction formats, it supports signing across ecosystems without waiting on bespoke integrations.
And because transaction parsing happens inside the enclave, policies can reason about what a Bitcoin, Solana, or Ethereum transaction actually does rather than treating it as an opaque payload.
Signing that blindly accepts opaque payloads pushes security responsibility back into application code. Turnkey's goal is the opposite: handle the security-sensitive private key operations inside the verifiable boundary, and give developers multichain APIs and SDKs to build correctly on top.
Turnkey: Security you can check for yourself
Secure digital asset custody requires more than placing private keys in specialized hardware. The full system has to protect key generation, authentication, authorization, transaction interpretation, data integrity, software deployment, and signature production. A weakness at any point in that path puts assets at risk.
Turnkey's philosophy closes that path end to end. Sensitive operations run inside constrained, hardware-isolated enclaves with policy checks before every signature. Remote attestation, authenticated data, and operation-level proofs make the system's behavior verifiable from the outside. Open source code and reproducible builds connect what runs in production back to source anyone can read.
Most wallet infrastructure asks you to trust opaque systems backed by audits and compliance reports. Turnkey has those too: We're SOC 2 Type 2 compliant and audited throughout the year by independent firms. But audits and certifications are point-in-time snapshots of a system you still cannot see into.
Turnkey's bet is that the industry deserves more than a snapshot: infrastructure that can show you, continuously and cryptographically, why it should be trusted.
For our complete architecture, read the Turnkey Whitepaper.
And get started with Turnkey today.
Related articles
The developer tooling stack for building secure crypto wallets faster
Build secure digital asset products faster with Turnkey’s developer tooling for wallets and key management.
Turnkey’s 3 phases of secure software development
Explore Turnkey’s software development process. See how each stage turns source code into a cryptographically verifiable artifact that is built, approved, and attested.
