VARA's Rulebook 2.0 raised the bar. Since June 2025, ITSEC has assessed over a dozen VASP applications against the new requirements — and the same seven cybersecurity failures keep derailing them. This is not a regulatory summary. This is a field report from the firms that didn't make it, and what you need to do differently.
On 19 May 2025, VARA published Version 2.0 of all twelve activity-based Rulebooks. Compliance was mandatory by 19 June 2025. That was eight months ago. And yet, the majority of VASP applications ITSEC reviews today are still built against the original 2023 framework — missing requirements that VARA now treats as baseline.
This is not a regulatory summary. Every consultancy in Dubai can summarize the rulebooks. What follows is a field report from inside the process: the specific cybersecurity failures we see repeatedly in real applications, what VARA reviewers actually probe during assessments, and the patterns that separate applications that advance from those that stall indefinitely.
ITSEC has guided VASPs through VARA authorization since the framework launched in 2023. We have conducted gap analyses, built compliance programs, and supported firms through live regulatory reviews. The observations in this article come from that direct experience — not from reading the rulebooks, but from watching what happens when regulators test whether firms actually live by them.
Between August 2024 and August 2025, VARA issued enforcement notices against 36 firms. Penalties ranged from AED 50,000 to AED 600,000. The violations included unlicensed virtual asset activities, unauthorized marketing, AML control failures, governance deficiencies, and failure to disclose material information. These are not theoretical risks. They are active consequences.
The Rulebook 2.0 updates added over 350 pages of new and revised requirements across all twelve rulebooks. The changes are not cosmetic. They introduce unified definitions for client assets and qualified custodians, standardized collateral wallet arrangements, explicit requirements for integrating onchain and offchain behavioral monitoring into a single unified picture, new Asset-Referenced Virtual Asset issuance rules with AED 1.5 million minimum capital or two percent of reserves, expanded supervisory powers including immediate access to all premises and data and records, and mandatory Licensed Distributor involvement for Category 2 token issuances.
For cybersecurity specifically, the implications are significant. VARA now expects VASPs to demonstrate that their compliance monitoring integrates blockchain analytics with traditional off-chain surveillance into a single unified view. Static rule-based monitoring is explicitly insufficient. The expectation is dynamic, behavior-based detection that adapts to evolving risk patterns.
The firms that understood this early are now licensed. The firms still assembling templated compliance packages are wondering why their applications are not progressing.
This is the most common failure we see, and the most consequential. Nearly every applicant produces a risk assessment. Almost none of them produce one that actually drives security decisions.
Here is what we mean. A typical application includes a risk register that lists standard threats — ransomware, phishing, DDoS, insider threat — scored on a generic likelihood-impact matrix. The register exists in a compliance folder. It was produced by a consultant. It has never influenced an architecture decision, a budget allocation, or a staffing choice.
VARA reviewers identify these immediately. They do not ask whether you have a risk assessment. They ask what it changed. Specifically: which security investments were prioritized because of it? Which risks were accepted and by whom? When was it last updated and what triggered the update?
What ITSEC builds instead: risk assessments that directly map to the VASP's actual architecture, specific blockchain integrations, and operational model. If you operate a custodial exchange on Ethereum and Solana, your risk assessment must address MEV exploitation, validator centralization risk, smart contract reentrancy specific to your deployed contracts, and hot wallet exposure calibrated to your actual transaction volumes — not generic crypto threats copied from a template.
The assessment must quantify residual risk after controls are applied, using a consistent methodology with defined scales. And critically, it must connect to the security budget. If your risk assessment identifies private key theft as the highest risk but your largest security investment is email filtering, VARA will notice the inconsistency. We have seen this exact scenario derail an application.
Every custodial VASP applicant describes multi-signature wallets and HSM-based key generation in their application. Very few can demonstrate it under examination.
VARA does not simply read your key management documentation. They probe it. They may request a walkthrough of the key ceremony process. They will ask who holds signing authority, where signers are physically located, what happens if a signer becomes unavailable, and how backup key material is stored and tested.
The failures we see most often: HSMs that are specified in documentation but not yet procured or configured. Multi-signature schemes described as three-of-five but implemented as two-of-three with two keys held by the same individual. Backup seed phrases stored in a single location — sometimes literally in the CEO's desk drawer. Key recovery procedures that have never been tested. No documented key ceremony with witnesses.
What passes scrutiny: HSMs certified to FIPS 140-2 Level 3 with documented procurement and configuration records. Multi-signature schemes with signing authority genuinely distributed across multiple individuals in different physical locations — ITSEC recommends different cities or countries for high-value custody. Backup material encrypted with separate keys, stored in geographically separated bank-grade vault facilities, tested for recovery at least quarterly with documented results. A formal key ceremony record including date, participants, witness signatures, and a serial-number-level inventory of HSM devices used.
The difference between what applicants write and what they can demonstrate is where applications die. VARA is not interested in your intentions. They are interested in your evidence.
The Rulebook 2.0 updates make this explicit: VASPs must integrate onchain and offchain signals into a unified behavioral monitoring picture. This is not a suggestion. It is a requirement.
Most applicants deploy a blockchain analytics tool — Chainalysis, Elliptic, or equivalent — and a separate transaction monitoring system. The two operate independently. The blockchain tool flags high-risk wallet interactions. The transaction monitoring system flags velocity and structuring patterns. Nobody correlates them.
This is the gap VARA exploits in reviews. They ask: if a customer receives funds from a wallet two hops removed from a sanctioned address and simultaneously changes their withdrawal pattern to rapid small amounts below your reporting threshold, does your system detect that as a single correlated event? In most applicant environments, it does not. The blockchain tool sees the wallet risk. The transaction monitor sees the structuring. Neither system talks to the other, and no analyst sees both signals together.
What ITSEC implements: unified monitoring architectures where blockchain analytics data feeds directly into the transaction monitoring engine. Risk scores from on-chain analysis adjust the sensitivity of off-chain detection rules in real time. A customer whose funds trace to a mixing service automatically triggers heightened monitoring for subsequent transaction patterns — not through manual analyst intervention, but through automated correlation.
The specific typologies your system must detect at minimum: peeling chains where large deposits fragment into many small withdrawals to different addresses, cross-chain movement specifically designed to break tracing through bridges and atomic swaps, round-trip transactions where funds cycle through your platform with minimal actual trading activity, coordinated multi-account behavior where linked accounts operate in concert to obscure fund flows, and structuring patterns calibrated to your specific reporting thresholds — not generic thresholds from a vendor default configuration.
If your compliance team cannot explain how each of these typologies is detected in your specific system architecture, your application is vulnerable.
Every applicant submits an incident response plan. ITSEC has reviewed dozens of them. The majority share three characteristics: they were written by a compliance consultant, they contain generic procedures that could apply to any industry, and they have never been tested.
VARA does not ask whether you have a plan. They ask when you last tested it, who participated, what gaps were identified, and what was changed as a result. If the answer to any of these is silence, the application stalls.
The specific failures we encounter: incident response plans that reference VARA notification timeframes but do not define who within the organization is authorized to make that notification. Plans that describe containment procedures using phrases like "isolate affected systems" without specifying which systems, how isolation is achieved technically, or who has the authority to take production systems offline. Plans with no procedures for virtual-asset-specific incidents — wallet compromise, private key exposure, smart contract exploitation, oracle manipulation, or blockchain fork response.
What VARA expects to see: tested plans with documented exercise results. ITSEC recommends quarterly tabletop exercises and annual full simulation exercises. Each exercise must produce findings, and those findings must drive measurable improvements. The exercise record should show who participated — and critically, it should include senior management and board members, not just the technical team.
For virtual asset platforms specifically, your incident response must include pre-approved containment strategies for high-value scenarios. If your hot wallet is compromised at 3 AM on a Friday, the person who discovers it must know exactly what they are authorized to do without waiting for management approval. ITSEC develops scenario-specific playbooks that define exactly this: halt all withdrawals above a threshold automatically, isolate the hot wallet signing infrastructure, preserve volatile forensic evidence before any remediation, notify the CISO and incident commander within 15 minutes, and notify VARA within the prescribed timeframe with a preliminary assessment including scope, affected systems, estimated customer impact, and containment actions taken.
VASPs focus heavily on external threats — hackers, nation-state actors, ransomware gangs. This is appropriate but incomplete. Some of the most damaging security incidents in the crypto industry have involved insiders: employees with legitimate access who abused it for personal gain, or privileged administrators whose compromised credentials gave attackers unrestricted access.
VARA's Rulebook 2.0 explicitly requires Know Your Employee controls and conflicts of interest management. This is not just an HR function. It is a cybersecurity control.
The access control gaps we find most frequently: administrative accounts shared among multiple staff members, making attribution impossible. Service accounts with excessive privileges that nobody has reviewed since initial deployment. No privileged access management — administrators use persistent credentials rather than just-in-time provisioning. Access reviews that exist on paper but have never resulted in an access revocation. Developers with production database access that was granted for a one-time troubleshooting task six months ago and never removed.
What ITSEC implements: role-based access control with formally documented access matrices mapping every role to specific system permissions. Privileged access management through a PAM solution providing just-in-time provisioning — administrative access granted only for the duration of a specific task, automatically revoked afterward, with full session recording. Quarterly access reviews for privileged accounts and semi-annual reviews for standard access, with documented evidence that inappropriate access was identified and revoked. Separation of duties ensuring no single individual can both initiate and approve high-value transactions.
For wallet infrastructure specifically: dual authorization for any transaction above defined thresholds, with signing authority distributed across individuals who do not report to the same manager. If your CTO can unilaterally move customer assets, you have a gap that VARA will find.
This is the gap that surprises crypto-native organizations most. In the startup world, deploying code to production multiple times per day is normal. In regulated financial services, every production change must follow a documented process with segregation of duties between requestor, approver, and implementer.
VARA expects formal change management. Not agile sprints. Not continuous deployment pipelines without security gates. Formal, documented, auditable change management.
What ITSEC sees in applicant environments: no change management process at all — developers push directly to production. Change processes that exist on paper but are routinely bypassed for urgent fixes. No segregation between development, testing, and production environments. Smart contract deployments without independent security audit. No rollback procedures documented or tested.
What regulated operations require: every production change following a defined workflow — request with documented justification, risk assessment including security implications, testing in a non-production environment that mirrors production architecture, approval by a designated authority who is not the requestor or implementer, implementation during a defined change window with monitoring, documented rollback procedures tested before implementation begins, and post-implementation review confirming the change achieved its objective without unintended effects.
For smart contracts specifically: independent security audit by a qualified firm before any deployment. Formal verification where the contract's financial value justifies it. Staged deployment using proxy patterns or tiered rollout. Time-locked administrative functions with a minimum 48-hour timelock on critical contract modifications. Organizations that resist this discipline should reconsider whether regulated financial services is the right market for them. VARA is not going to adjust its expectations to accommodate your deployment preferences.
Modern VASPs integrate with blockchain analytics providers, KYC verification vendors, cloud infrastructure providers, price feed oracles, liquidity providers, and payment processors. Each integration extends the attack surface beyond the VASP's direct control.
VARA holds the licensee accountable for the security of all operations, regardless of who performs them. A breach at your cloud provider that exposes customer data is your breach. A failure in your KYC vendor's liveness detection that allows synthetic identity fraud is your failure.
The third-party risk gaps we find: no formal vendor due diligence conducted before integration. SOC 2 reports accepted at face value without reviewing scope or findings. No contractual right-to-audit provisions. No ongoing monitoring of vendor security posture. No contingency plans for vendor failure or compromise — if your blockchain analytics provider goes down, do you halt all transactions? Most applicants have not answered this question.
What ITSEC builds: tiered vendor risk assessment programs where assessment rigor is proportionate to the criticality and data sensitivity of each integration. Pre-engagement due diligence that goes beyond collecting certifications — reviewing the actual scope of SOC 2 assessments, evaluating whether ISO 27001 certificates cover the specific services consumed, and assessing incident response capabilities including breach notification commitments. Contracts with enforceable security obligations including right-to-audit clauses, defined breach notification timeframes, data handling requirements, and exit provisions that protect customer data during vendor transitions.
For the most critical integrations — custody, blockchain analytics, and cloud infrastructure — ITSEC recommends annual on-site or detailed remote assessments, not just questionnaire-based reviews. And contingency plans must be tested: if your primary blockchain analytics provider becomes unavailable, your operations must have a documented fallback that does not involve simply continuing to process transactions without screening.
After guiding multiple VASPs through VARA authorization since the framework launched, the pattern is clear. Successful applications share three characteristics that failing applications lack.
First, they start early. The firms that engage compliance and cybersecurity advisors six months before filing — not six weeks — have time to build genuine capabilities rather than paper compliance. VARA reviewers can tell the difference between an organization that has been operating its security program for months and one that assembled documentation the week before submission.
Second, they tell a consistent story. The risk assessment identifies the same priorities that the security architecture addresses, that the penetration testing scope covers, that the incident response plan exercises, and that the board reporting discusses. Inconsistency between these elements is the fastest way to lose regulatory confidence.
Third, they demonstrate evidence, not intention. Policies are signed and dated. Training records show completion rates. Access reviews show revocations. Penetration tests show remediation. Incident response exercises show findings and improvements. Every claim in the application is backed by documentary proof that the control exists, operates, and is maintained.
The firms that treat VARA compliance as a documentation exercise will produce an application that reads well and fails under examination. The firms that treat it as an operational discipline will build something that withstands scrutiny — because the scrutiny tests reality, not paperwork.
ITSEC has operated at the intersection of cybersecurity and UAE financial regulation since 2011 — years before virtual assets were regulated in this market. We were building compliance programs for DFSA, ADGM, and CBUAE-regulated institutions while the crypto industry was still figuring out what regulation meant.
When VARA launched in 2022, we brought that institutional-grade regulatory experience to virtual assets. We do not approach VARA compliance as crypto consultants learning regulation. We approach it as regulatory cybersecurity specialists who understand crypto. The difference is fundamental, and it shows in outcomes.
Our VARA advisory covers the complete lifecycle: initial gap analysis against the full Rulebook 2.0 requirements, risk assessment development that drives genuine security decisions, security architecture design aligned to your specific operational model and blockchain integrations, policy and governance framework development, penetration testing across all attack surfaces including smart contracts and API security, AML technology architecture including unified onchain-offchain monitoring, incident response plan development and tabletop exercise facilitation, and pre-audit simulation that replicates the regulatory review process.
If you are preparing a VARA application — or if your existing application has stalled — contact ITSEC. We will tell you exactly where you stand, what needs to change, and how long it will take. No templates. No generic advice. Specific, actionable guidance from the team that has been through the process more times than anyone else in this market.
Get a comprehensive security assessment from our expert team. Protecting businesses since 2011.