10 Wallet Security Best Practices for Consumer and Retail Apps

Retail and consumer e-commerce now represents the largest application segment for mobile wallets, capturing 34.4% of the market.

Reddit is one of the strongest examples of what this can look like in practice. Since launching Collectible Avatars in 2022, Reddit onboarded more than 4.25 million users to web3 within six months, without leading with words like 'NFT,' 'crypto,' or 'web3.' By 2025, the program had minted more than 30 million avatars and generated over $18 million in sales.

That is the direction consumer apps are moving.

Wallets are becoming embedded directly into the product experience, from retail and loyalty to gaming, creator platforms, financial apps, and AI-driven workflows. The wallet becomes part of the application, not a separate destination users have to understand before they can participate.

But securely embedding wallets into applications, including retail and consumer apps, is a difficult problem to get right. 

For your users, security is typically assumed as a default. They don't think about key management or signing infrastructure. But they do think about their balance. And when that balance disappears, so is their trust.

In this article, we’ll look at where embedded wallet security can break down and outline 10 practices developers can put in place now to help protect user assets.

The problem: If not protected well, one compromised credential can put digital assets at risk

75% of adults worldwide have adopted some form of digital payment method, making digital wallets a prime attack vector. Many users incorrectly assume digital wallets are invulnerable, letting their guard down on phishing and app security.

In March 2022, Axie Infinity players logged in to find they could not withdraw their earnings. The hack was not discovered until six days after it occurred, when the project team was notified by a user who could not withdraw 5,000 ETH from the bridge. 

Attackers had already stolen approximately 173,600 ETH and 25.5 million USDC, roughly $624 million total. The Axie DAO had whitelisted Sky Mavis to sign transactions on its behalf months earlier. 

That arrangement ended in December 2021. The access was never revoked.

Attackers used a fake LinkedIn job listing to social engineer Sky Mavis employees and extract details about the network's security setup, then used that stale permission to obtain the final validator signature they needed.

The FBI later attributed the attack to North Korea's Lazarus Group.
‍

Consumer apps that embed wallets, whether for gaming rewards, loyalty payouts, or brand engagement, inherit this same class of risk. Wallet security is not only about where keys are stored. It is about who can authorize signatures, what those signatures can do, and how quickly access can be constrained when something changes.

The following 10 practices address those risks directly.

10 security practices for retail and consumer wallet apps 

The risks above all come back to the same core problem: signing authority is easy to misuse when it is not isolated, scoped, verified, and monitored. A wallet app cannot rely on the UI alone, a valid credential alone, or a trusted dependency alone.

Each signing request needs stronger boundaries around who can authorize it, what it is allowed to do, how long that permission lasts, and whether the action matches policy before a signature is produced.

These ten security practices help create those boundaries, reduce the blast radius of compromise, and protect against the threats described above and others like them.

1. Give every user a fully isolated wallet environment

When all user wallets share the same key management context, one compromised credential can reach every user. Isolation should be structural.

Turnkey provisions a fully isolated environment, called a sub-organization, for each user with its own wallets, credentials, and policies. Credentials in one sub-org cannot authorize actions in another, and a backend compromise does not give an attacker cross-user signing authority.

For consumer and retail apps, this matters at scale. One user wallet should never become the path to every wallet in the system.

2. Keep private keys out of your application stack

Storing private key material in a database field, environment variable, or encrypted file on the same server means those keys inherit every vulnerability in your infrastructure.

That was the core failure in the Ronin breach: keys on centralized servers, reachable once the perimeter was crossed.

Turnkey keeps private keys inside hardware-backed secure enclaves, Trusted Execution Environments with no persistent storage, no interactive access, and no external network connections. Signing happens inside the enclave. Only the resulting signature is returned.

Your application can request a signature. It should never hold the key that produces it.

Case study

Explore how Turnkey powers Moonshot's mobile trading app

Turnkey's self-custodial wallet infrastructure powers Moonshot's mobile crypto trading platform. 1.5M+ user wallets created with 99.99% uptime, integrated in 2 weeks.

Read the case study →

3. Use phishing-resistant authentication for signing authority

The authentication method that gates signing is one of the most important security surfaces in a consumer wallet product.

Lazarus Group breached Sky Mavis through social engineering before ever touching the validator keys. That is the point: attackers often compromise the people and workflows around signing before they compromise the cryptography itself.

Passkeys are bound to a specific device and origin. They cannot be replayed or approved remotely, which helps eliminate a major class of phishing and social engineering attacks.

Turnkey supports passkey-based authentication alongside email and social login, so users can onboard with familiar methods while signing authority stays tied to a stronger credential.

The user experience can stay simple. The signing path should stay protected.

4. Scope what your backend can authorize

A backend credential that can authorize any action on any user wallet is a single point of failure.

If that key is compromised, the attacker has the same reach as a full infrastructure breach.

Turnkey supports non-custodial, custodial, and hybrid custody configurations. In a non-custodial setup, only the user's own authenticator can authorize the enclave to sign. In a hybrid setup, policies define exactly what the backend can authorize, such as gas sponsorship or scheduled operations, versus what requires the user's own credential, such as asset transfers.

This gives teams control over the product experience without giving the backend unrestricted signing authority.

A backend API key should never have blanket authority over recipient, value, operation type, or every wallet in the system. It should only authorize the narrow set of actions the product actually needs.

5. Policy-gate every signing operation

Signing requests should be evaluated against explicit rules before a signature is produced.

The Ronin validators had no such effective gate. Once the attacker controlled enough signing authority, nothing stood between them and the funds.

Turnkey's policy engine is deny-by-default. If no policy explicitly allows an action, it is rejected. Policies can restrict signing by recipient address, contract address, function selector, chain ID, and transaction value. They run inside the enclave at the same trust boundary as the keys.

The question should not be, “Can this credential sign?”

The question should be, “Can this credential sign this specific action under this policy?”

Case study

See how Turnkey powers Droppp's digital collectibles marketplace

Turnkey's embedded, non-custodial wallet infrastructure powers Droppp's global digital collectibles marketplace. Moving from custodial to non-custodial wallets opened 4 new user markets and cut service fees substantially.

Read the case study →

6. Enforce time-bounded access and revoke it immediately when it ends

Stale credentials are one of the most preventable attack vectors in signing infrastructure. The Axie DAO validator permission sat active for three months after the arrangement that created it ended. That single oversight became the entry point for a $624 million theft.

Every credential, API key, session, and third-party permission in your signing infrastructure needs a defined expiration and a revocation process that runs automatically at offboarding. This applies equally to user sessions and backend service accounts. A session that authenticated days ago for a routine action should not still be valid for a high-value transfer.

Turnkey's deny-by-default policy model means access that was never explicitly granted cannot be exercised. API keys support configurable expiration windows, and sessions can be scoped to specific operations with re-authentication required for sensitive actions regardless of session state.

Let low-risk activity feel seamless. Force fresh authorization when funds, permissions, or key material are involved. When the workflow ends, the permission should end with it.

7. Gate key export behind policy

Key export is the highest-stakes operation in an embedded wallet.

It moves key material out of the controlled environment permanently, and application-layer permission checks can be bypassed.

Turnkey's export flow encrypts key material to the user's own target public key inside the enclave before it leaves. The resulting bundle is only decryptable by the intended recipient.

Require explicit user authentication before initiating any export, and consider requiring a time delay or secondary approval for high-risk contexts.

Export is not a normal transaction. Treat it as a privileged security event.

8. Separate read access from signing authority

A backend service that can both read user data and authorize signing is a single point of failure.

Splitting those two capabilities limits what an attacker can do with a compromised service account.

Turnkey's parent org structure has read-only access to sub-organizations. It can initiate authentication and recovery flows but cannot sign transactions or modify policies inside a user's sub-org.

Design your access model so a compromised backend can see records, but cannot move funds.

Case study

Discover how Turnkey powers EarnOS's onchain rewards platform

Turnkey's non-custodial wallet infrastructure powers EarnOS's consumer rewards platform at scale. 3M+ wallets created in less than 60 days and a 10x reduction in wallet infrastructure costs.

Read the case study →

9. Validate what the transaction actually does before signing it

A signature request can look legitimate at the credential level and still authorize something harmful. Blind signing, where a wallet approves a payload without inspecting its contents, is how users and systems alike get drained by malicious contract calls disguised as routine operations.

Policy enforcement only works if it evaluates the transaction, not just the request.

Turnkey's policy engine parses the transaction payload before signing occurs. For Ethereum transactions, it exposes the recipient address, value, chain ID, and, when a Smart Contract Interface has been uploaded, the function name and decoded contract arguments. Policies can restrict signing to specific recipients, function selectors, argument values, and value ceilings, all evaluated inside the enclave before a signature is produced.

A signing request that passes authentication and policy review but targets an unexpected contract or calls an unauthorized function should not produce a signature. Make that check explicit.

10. Log every signing request and act on the signals

The Ronin bridge was drained across two transactions over six days before anyone noticed.

An immutable log with defined alerting thresholds would have surfaced the anomaly far sooner.

Turnkey maintains a tamper-proof activity log for every operation. Each activity is recorded with its inputs, policy evaluation outcome, and result.

Unusual signing volume, off-hours authentication, export requests from new devices, and failed policy evaluations are all signals worth escalating before they become incidents.

Logging is not just for audit. It is part of the security system.

Turnkey: Building wallet security into the signing layer

Consumer apps that embed wallets inherit the risks of wallet infrastructure, even when users never see that infrastructure directly.

The right model keeps private keys out of the application stack, isolates each user environment, scopes backend authority, checks every signing request against policy, and records every action.

That is the foundation Turnkey gives developers: secure wallet infrastructure where keys are generated and used inside hardware-backed enclaves, signing is governed by policy, and access is isolated by design.

Consumer experiences can feel simple. The signing infrastructure behind them should be secure.

Get started with Turnkey today. 

‍