Zero Trust has become the latest buzzword in digital asset security—but many wallet providers are using the term loosely. Financial institutions, exchanges, and trading firms may believe they’re operating with Zero Trust principles, only to discover trust assumptions and leaps of faith exist in how their wallet infrastructure is actually designed.
In this article, we break down seven signs that your custody infrastructure might not live up to the Zero Trust label—and how to identify wallet solutions that actually align with your operational, compliance, and security requirements.
1. Your Keys Are Still Generated by the Vendor
Zero Trust assumes breach. That includes your vendors. If your wallet provider generates your private keys—and sends it to you over a secure transport channel—you’re not operating in a Zero Trust environment.
Key generation is a security-critical process. It requires true randomness, high entropy sources, and appropriate algorithms. Even if you're confident that key generation is secure, the vendor may still fall short in ensuring confidentiality or providing assurances that they haven't accessed or retained a copy of your key. Any Key Management System that requires one actor to transfer key material to another actor after generating it will fail to achieve Level I under the Cryptocurrency Security Standards (CCSS).
Explore how key generation is handled under a Zero Trust model in our guide to Zero Trust Security.
2. Your Policy Engine Lives in a Centralized Vendor Database
A true Zero Trust system doesn’t just protect access to keys—it also secures how those keys are used. If your policy logic is managed and/or hosted by the vendor, usually stored in a centralized SQL database, and enforced outside of your infrastructure, you’re outsourcing a mission-critical security function. You are making the vendor your de facto policy administrator and trusting them with that role.
This opens the door to multiple risks:
- Malicious or accidental changes to policy rules
- Downtime or outages affecting your policy enforcement point
- No assurance that the policy you want to invoke is indeed the correct one
Zero Trust requires that policy enforcement be handled so that you are not trusting your vendor and what they say a policy response is for a given action. Therefore, this should stay in your environment, not the vendor’s, and should not be under the jurisdiction of a single privileged actor. MPC without distributed authentication and authorization is no better than plain secret keys.
3. Your Vendor Can Censor or Delay Transactions
Even if you hold a key share in an MPC signing quorum, what happens if the vendor goes offline, delays a policy check, or their message queue gets blocked up? All of these things have happened and resulted in delayed transactions, incident reports, and very opaque post mortems.
If your vendor is involved in the transaction path, whether by having a key share or also the policy engine, then they have control—even if they technically can’t sign unilaterally. That means they can censor your transaction by not being online. Or worse, they just arbitrarily co-sign and do not invoke any kind of fiduciary responsibility to ensure they are signing a correct payload. That’s not Zero Trust. It’s also not fault tolerant. It’s a critical dependency with maximum trust required. Not to mention that vendor side issues will quickly see your service level agreements (SLAs) and resolution times reduced to empty promises on a bit of paper.
Enforcing policies and quorum locally ensures your institution stays in full control. You can manage your infrastructure as you need, and not worry about any other tenants being in there putting load on the system, or how well a vendor hosted environment is set up for operational resilience and enforcing Zero Trust security principles.
4. You Can’t Enforce Least Privilege at a Granular Level
Zero Trust also involves leveraging the principle of least privilege. That means users and services should have only the permissions required to perform their role—nothing more.
Many Wallets-as-a-Service (WaaS) and MPC wallet platforms offer basic user roles (e.g., admin, viewer, signer, with advanced roles often available only for a higher fee) but lack fine-grained control. If you can’t:
- Build your own custom permission sets for your business users
- Define role-based access across different resources (addresses, accounts, assets)
- Set transaction limits by geography, time, or type
…then your policy framework is too coarse to enforce Zero Trust principles effectively and limit lateral movement for an attacker inside a system. Also opening up the possibility that you don’t have strong identity boundaries which are continuously tested by the policy engine.
5. The Platform Isn’t Self-Hosted—Or Doesn’t Support It
If your wallet infrastructure is hosted entirely by the vendor, you’re trusting them to secure it. That includes cloud perimeter, OS patching, hardware integrity, insider access controls, and more. Which might be fine if you are a small or mid size organization looking for convenience as well as a set-it-and-forget-it approach.
However, if you are a financial institution or a regulated crypto entity then that’s not an option for you. Zero Trust means removing unnecessary trust assumptions—especially around infrastructure. With self-hosted deployment options, your team can:
- Deploy in your own cloud or data center
- Align wallet operations with your security posture
- Reduce attack surface and audit more easily
Not every institution will want to self-host, but without the option, you're constrained by someone else's risk model. A risk model that might be generally good as a common denominator, but will certainly not meet your enterprise risk framework and high cybersecurity posture. As a reminder, you cannot outsource or delegate your compliance obligations - you are still on the hook should the vendor fail to perform.
Read more on why SaaS wallet models fall short.
6. Your Logs, Backups, and System State Aren’t Fully Yours
Auditability is core to Zero Trust. Institutions should be able to:
- Independently audit the codebase
- Conduct their own “red teaming” exercise
- Access complete, immutable logs of every transaction and policy change
- Export or mirror logs into their own monitoring tools
- Test BCP exercises, full system recovery, and rehydration independently
This is just a subset of the items. If you need to file a regulatory incident report or test disaster recovery—can you do it without the vendor’s help? Also worth noting that in a live fire drill everyone is rushing for the exit, can your disaster recovery still perform as well under those chaotic conditions as it does in isolated tests?
On the product instrumentation side, it’s important to monitor product health and ensure the reliability of that data. While we're on the topic, consider whether transaction data can be exported from a SaaS wallet provider when you offboard—can it be retained for your records? Regulated firms often face multi-year recordkeeping requirements, so a “write once, read many” approach is essential. You don’t want to risk losing critical data simply because you migrated away from a vendor.
7. You Can’t Review or Extend the Platform
Transparency is a foundational Zero Trust principle. If you can’t review the software, validate its security practices, or contribute improvements, you’re operating in the dark. Asking for SOC2, ISO27001, and other audit reports is just a colour by numbers exercise. You need to independently verify the substance of the product.
With Cordial, customers can:
- Have source code read-only access
- Perform threat-led penetration testing
- Extend functionality through our open-source crosschain library
This reduces blind spots, accelerates support for new protocols, and gives customers more ownership over their infrastructure. You can treat Cordial as nothing more than a software supplier—there's no need for a deeper dependency. Even our pre-built components are optional; you're free to build and verify everything yourself. We’re also happy to share our Software Bill of Materials (SBOM) and any known CVEs related to the software supply chain. That’s what Zero Trust looks like in practice.
Zero Trust: More Than a Marketing Term
Don’t let marketing language lull you into a false sense of security. Real Zero Trust takes real architecture, real accountability, and real control.
Cordial Treasury was built from day one to reflect these principles. From distributed policy enforcement to self-hosted deployment and source-available code, Cordial gives institutions like Jump Trading and SwissBorg the autonomy they need to manage risk on their own terms.
Ready to find out if your wallet stack meets the Zero Trust bar? Contact us for a demo or free advisory call.
