It's no secret that wallet infrastructure is the backbone of any successful crypto project, but it's often too costly and time-consuming to build in-house. As a result, demand for Wallet-as-a-Service (WaaS) providers has remained strong over the years, particularly among lean-strapped teams eager to bring their products to market quickly.
But while all WaaS providers offer essential infrastructure, choosing which one to partner with can be a complex process that directly impacts compliance, scalability, and (most importantly) security. While many embedded wallet and key management solutions appear similar on the surface, they often differ dramatically in how they handle security from both an infrastructure and development perspective.
In this guide, we'll share seven security questions every organization should ask when evaluating a WaaS provider. You'll learn what answers to listen for, potential red flags to be wary of, and how to ensure your WaaS provider meets your organization's security requirements.
1. What tools do you offer to limit damage if our frontend is compromised?
For the majority of web3 apps, the frontend is the first (and often only) point of interaction between users and your wallet infrastructure. If this layer is compromised through cross-site scripting (XSS) or supply chain attacks, a malicious party could gain the ability to initiate unauthorized transactions.
This question helps uncover whether the WaaS provider has a toolkit in place for your developers to contain the blast radius of a UI breach and reduce reliance on the frontend as a trusted actor. Look for features such as:
- Policy-based transaction gating: This feature enables developers to define specific rules for what types of transactions can be automatically approved and which need extra verification. For example, a user might be allowed to swap tokens freely but would need to re-authenticate before withdrawing funds to a new wallet address.
- Multi-device authentication: With this capability, sensitive transactions will require confirmation from a second, independent device before being executed.
- Separation between action and approval: Here, initiating a transaction (such as clicking a button in the app) doesn't automatically authorize it. Instead, the approval happens separately, often through a second device or user prompt, which helps prevent unauthorized or unintended actions.
While this question is meant to reveal how the WaaS provider can empower your developers, be wary of answers such as, "We rely on your frontend for security." This often indicates the provider offers no security toolkit to help your developers mitigate the impact of a compromised frontend.
2. How are signing keys isolated at the infrastructure level?
Signing keys are one of the most sensitive elements of wallet infrastructure. If they're mishandled, attackers could gain the ability to move funds, impersonate users, or disrupt critical operations. Proper isolation at the infrastructure level ensures these sensitive assets are protected from unauthorized access, accidental exposure, or compromise.
This question gets to the heart of how your WaaS provider approaches key custody and whether their systems can contain damage in the event of a breach. We recommend looking for providers who employ effective key management through the following measures:
- Secure storage: Keys should be isolated in environments with strong security controls that reduce the risk of unauthorized use or abstraction, such as Trusted Execution Environments (TEEs).
- Role-based access controls (RBAC): Only authorized systems or individuals should have scoped, auditable access to perform specific actions.
- Defense in depth: Secure architectures should be resilient to single points of failure, requiring multiple security controls to fail in order for a compromise to occur.
If the WaaS provider does not have strong answers to these bullets, it may be an indication that they don't have comprehensive protections for signing keys.
3. How do you verify that your infrastructure is running the intended code — and how can we trust it?
When it comes to backend infrastructure, most WaaS providers will assure you their systems are secure. But unless they can prove what code is running in which environment, you're being asked to take that on faith.
If an attacker tampers with the provider's server or inserts unauthorized code during an update, your entire wallet infrastructure may be executing malicious actions such as unauthorized transaction signing, fund transfers, or misuse of user permissions.
This question reveals whether the WaaS provider's backend infrastructure is secure — or if you're left trusting opaque operations. The safeguards you should be on the lookout for include:
- Source code attestation: Can the provider prove the deployed code matches the expected source?
- Runtime integrity checks: Is there validation that the code hasn't been altered post-deployment?
If the provider's answer stops at, "We follow cloud best practices," that's usually not enough. Runtime attestation and verifiable deployment are what separate surface-level security from provable integrity.
4. How do you treat third-party dependencies in your trust model?
Third-party dependencies can introduce vulnerabilities if not properly managed by your WaaS provider. Every additional service, SDK, or integration — whether for analytics, authentication, notifications, or storage — broadens the attack surface. If even one is compromised, attackers may be able to introduce harmful code into your platform's frontend.
With this question, you'll learn whether your provider treats third-party code and infrastructure as untrusted by default and architects systems accordingly. Look for signs that the provider:
- Employs first-party authentication enforcement: A reputable WaaS provider won't automatically approve requests just because they come from your frontend. Instead, they treat any action executed outside of TEEs as compromised by default.
- Implements guardrails around key access: Even if malicious code ends up in your platform, it shouldn't be able to access signing keys or trigger transactions. Look for providers that enforce strict controls at the key management layer to prevent this.
If your provider can't explain how their system defends against malicious dependencies, it's safe to assume they haven't designed for it and that your users are at risk if you decide to move forward.
5. How are you protecting against spoofing or Man-in-the-Middle (MITM) attacks?
Spoofing and MITM attacks can intercept or alter communications between users and backend systems. In spoofing attacks, malicious actors create fraudulent versions of legitimate apps or websites to trick users into signing harmful transactions. In MITM attacks, they intercept network traffic to steal credentials or alter requests in transit.
This question verifies whether your WaaS provider approaches authentication using secure, verifiable methods or if their systems are exposed to interception and credential misuse. A security-focused provider will offer:
- Client-side asymmetric cryptography: Your provider should use a public key for encryption and a private key for decryption (both managed directly by the end user's device) to ensure all transaction requests are secure.
- Stronger alternatives to transport-layer security: Bearer tokens, sessions, and standard web authentication are easily compromised.
If your provider mentions bearer tokens, sessions, or other outdated authentication methods, they're likely reliant on transport-layer security, which isn't adequate to ensure every transaction is secure. Verifiable, cryptographic authentication ensures that even if someone is watching or interfering with your traffic, they can't impersonate users or forge actions.
6. How can we verify that what's being signed matches the user's intended action?
Ensuring the smart contract being signed aligns with user intent is crucial to preventing unauthorized actions. Even if keys are properly secured, attackers can still manipulate transaction data (such as the payload or destination address) before it reaches the signer. As a result, your end user might be tricked into authorizing a malicious or obfuscated transaction.
This question reveals whether the WaaS provider offers the tools needed for your developers to define and implement granular rules for transaction approvals. Look for support for the following:
- Separation of actions: Your developers should be able to separate transaction construction, signing, and broadcasting into distinct steps handled by separate systems or layers.
- Policy-based signing validation: Your end users should only be allowed to sign transactions that conform to the predefined policies set by your development team.
If a provider doesn't mention support for policy enforcement at the signing layer, it's worth pressing them on how they can help your development team validate intent. Support for these protections reduces the risk of transaction spoofing and prevents attackers from slipping malicious payloads past unsuspecting users.
7. How does your system help teams maintain security as they scale?
As your organization grows, your security architecture needs to keep up. Processes that work for a single developer or a small team won't necessarily hold up once you have multiple business units, products, or networks in play.
This question uncovers whether your WaaS provider offers the tools to implement your own security workflows and scale them alongside your organization's growth. When searching for a provider that offers these tools, look for:
- Separation of responsibilities: Your provider's toolset should enable the isolation of responsibilities across teams and business units, eliminating the risk of security errors and duplicative work.
- Policy-based workflows: Look for providers that support granular policy-based workflows with fully configurable language that can be mapped to compliance processes as you grow.
- Multi-chain support: Support for multiple chains at the cryptographic level is crucial to ensure your team can add new ecosystems without compromising on controls or security.
We recommend seeking providers that approach this challenge by limiting their role to secure signing while giving your team the tools to control how transactions are built, approved, and broadcast. That level of flexibility makes it easier to support everything from consumer wallets to complex treasury systems without having to re-architect your security model as you scale.
Get security-first wallet infrastructure with Turnkey
Secure wallet infrastructure is much more than a nice-to-have; it’s critical for any organization operating in the crypto space. As your products, teams, and user base grow, secure wallet infrastructure ensures you’re well-equipped to handle expanding attack surfaces while positioning your organization for sustainable growth.
Turnkey was built to deliver this infrastructure on day one. Developed by the team behind Coinbase Custody — the world's largest crypto custodian with over $100 billion in assets secured — Turnkey delivers secure, enterprise-grade wallet infrastructure without forcing you to compromise on flexibility, speed, or innovation. Our infrastructure combines secure enclave-backed key management, provable system integrity, modular workflows, and a future-proof architecture designed to evolve with your needs.
If you're ready to build with the confidence that your security model can scale as fast as you do, Turnkey is ready to help.
Get started with Turnkey today.
Related articles
