Cryptographic Key and Wallet Management Under VARA

If you get key management right, VARA compliance becomes dramatically easier. If you get it wrong, nothing else matters - because you won’t have a licence.

I spent a week in early 2025 helping a Dubai-based custody provider rebuild their key management documentation for their VARA application. They’d been running secure operations for two years - hardware security modules, multi-signature schemes, air-gapped key ceremonies, the works. Operationally, they were excellent.

Their documentation, however, was a disaster. Key generation procedures lived in one engineer’s head. Rotation schedules were “when we feel like it.” Backup procedures existed as a Confluence page that hadn’t been updated since 2023. There was no documented destruction process at all.

VARA returned their application with 14 findings, every single one in the key management section. Not because their security was bad - it was actually quite good - but because they couldn’t prove it. This article is about making sure you can prove it.

Why Key Management Is the Heart of VARA Compliance

Traditional financial regulation doesn’t have anything like this section. In banking, your assets are entries in a database - protected by access controls, encryption at rest, and audit trails. In crypto, your assets are cryptographic keys. Lose the keys, lose the assets. Compromise the keys, compromise everything.

VARA gets this at a fundamental level, and it’s reflected in the depth of the requirements. The key management section of the Technology and Information Rulebook (including Schedule 1) is arguably the most detailed and prescriptive section of the entire document. It covers every stage of the cryptographic key lifecycle, and it leaves very little room for interpretation.

Let me walk through each stage.

Key Generation: Where Everything Starts

VARA requires that cryptographic keys be generated using approved algorithms and cryptographically secure random number generators. That sounds obvious, but “approved algorithms” means specific standards - not “whatever the developer picked.”

In practice, VARA expects:

• Industry-standard algorithms: ECDSA (secp256k1 for Bitcoin/Ethereum), EdDSA (Ed25519), RSA (2048-bit minimum for non-blockchain uses). Custom or proprietary algorithms are a red flag.
• Hardware-based entropy: Keys should be generated inside hardware security modules (HSMs) or secure enclaves, not in software running on general-purpose servers.
• Key ceremonies: For high-value keys (master keys, cold storage keys), VARA expects documented ceremonies with multiple witnesses, segregated roles, and tamper-evident procedures.
• Audit trails: Every key generation event should be logged: when, where, by whom, using what hardware, with what witnesses.

Key Storage: Where Most VASPs Fall Short

Key storage is where VARA gets very specific about the difference between acceptable and unacceptable approaches.

What VARA expects:

• Private keys must be stored in HSMs, secure enclaves, or equivalent tamper-resistant hardware - especially for hot wallet operations
• Cold storage keys should be in offline, physically secured environments with access controls
• No private keys in plaintext, anywhere, ever. Not in databases, not in config files, not in environment variables
• Encryption of key material at rest using a separate key encryption key (KEK) hierarchy
• Physical security controls for any location housing key material

What I’ve seen go wrong:

A worrying number of crypto companies still store key material in software-based solutions without adequate protection. “We encrypt the keys in our database” is not the same as HSM-grade storage. VARA knows the difference, and so will their auditors.

Cloud-based HSM services (AWS CloudHSM, Azure Dedicated HSM, Google Cloud HSM) are generally acceptable for hot wallet operations, provided you can demonstrate that the key material never leaves the HSM boundary and that your access controls meet VARA’s requirements. For cold storage, VARA typically expects on-premises or co-located HSMs with physical access controls.

Hot/Cold Wallet Segregation

VARA requires VASPs that hold client assets to maintain a clear separation between hot wallets (online, connected to the internet) and cold wallets (offline, air-gapped). This isn’t just a best practice suggestion - it’s a regulatory requirement with specific parameters.

The common question is: what percentage should be in hot vs. cold storage? VARA doesn’t prescribe a specific ratio, but industry best practice - and what VARA reviewers expect - is that hot wallets hold no more than 2-5% of total client assets. Some exchanges operate with even less.

You also need documented procedures for moving assets between hot and cold storage, including who authorises transfers, what approvals are needed, and how those transactions are monitored and reconciled.

Multi-Signature and Threshold Controls

VARA requires multi-signature (or equivalent multi-party computation) controls for high-value transactions. The specific requirements depend on your activity type and risk profile, but the general principles are:

• No single individual should be able to authorise a transaction above a defined threshold
• Multi-sig configurations must involve a minimum number of signers (typically 2-of-3 or 3-of-5)
• Signers must be drawn from different organisational roles (no two signers from the same team)
• The threshold triggering multi-sig must be documented and proportionate to your risk appetite
• All multi-sig events must be logged with full audit trails

MPC (multi-party computation) is increasingly accepted as an alternative to traditional multi-sig, particularly for operational efficiency. VARA doesn’t mandate one approach over the other, but whatever you choose, you need to document the security model and demonstrate that it provides equivalent protections against single-point-of-failure risks.

Rotation, Backup, Recovery, and Destruction

The lifecycle doesn’t end at generation and storage. VARA requires documented procedures for every subsequent stage:

Key Rotation

Keys must be rotated on a defined schedule, and immediately upon suspected compromise. VARA doesn’t mandate specific rotation periods, but expects you to justify your rotation policy based on risk. For hot wallet keys, quarterly rotation is common. For cold storage keys, annual rotation is typical unless triggered by an event. Every rotation needs to be documented: old key decommissioned, new key generated, all dependent systems updated.

Key Backup and Recovery

You need a backup strategy that can survive catastrophic failure - fire, flood, building collapse - without exposing key material. This typically means:

• Shamir’s Secret Sharing or similar threshold schemes for backup distribution
• Geographically distributed backup locations
• Tamper-evident storage for backup media
• Regular recovery testing (at least annually) to confirm backups are viable
• Documented procedures for who can initiate recovery and under what circumstances

The recovery testing is critical. I’ve seen companies discover during a real incident that their “backup” was corrupted, incomplete, or relied on a password that nobody current remembers. Test your recovery process. Then test it again. Then document the test.

Key Destruction

When keys are decommissioned, they need to be destroyed in a way that’s verifiable and irreversible. For HSM-stored keys, this means cryptographic erasure with audit log confirmation. For backup media, physical destruction with witnessed procedures. You need to demonstrate that once a key is destroyed, it can’t be recovered from any location - including backups. This is often the most overlooked part of the lifecycle, and VARA checks for it.

The Documentation VARA Actually Wants

Let me be direct: every requirement above needs to be documented, and the documentation needs to be current, detailed, and accessible for regulatory review. Here’s the minimum set of documents VARA expects:

Managing this documentation in scattered locations is a recipe for audit failure. Tools like Venvera let you centralise key management documentation alongside your broader VARA compliance tracking, cross-mapped to DESC and other frameworks. When VARA asks for your key rotation records during a review, you don’t want to be searching through Confluence pages and shared drives.

The Bottom Line

Cryptographic key and wallet management isn’t just another compliance checkbox. It’s the foundation your entire VASP is built on. VARA understands this, which is why the requirements are so specific and so thorough.

The companies that sail through this section aren’t necessarily the ones with the most expensive hardware. They’re the ones with the most rigorous documentation, the clearest procedures, and the most consistent execution. A well-documented key management programme using cloud HSMs will pass VARA review more easily than an undocumented programme using state-of-the-art hardware.

Document everything. Test your recovery. Rotate your keys. Destroy what you don’t need. And for the love of everything, don’t store private keys in plaintext.

Last updated: March 2026. Requirements based on VARA Technology and Information Rulebook, including Schedule 1. Always verify current requirements with VARA directly.