Most organisations that run phishing simulations are testing the wrong thing. They measure whether an employee clicks a link in a fake invoice email, then report a click rate to the board and move on. For a crypto firm, that metric tells you almost nothing about the risk that matters: whether a treasury operator will approve a fraudulent multisig transaction, whether an engineer will install a backdoored update because it looked like it came from a hardware wallet vendor, or whether a finance lead will wire funds because a message appeared to come from the CEO. The Bybit breach is the clearest recent illustration of why this distinction matters: the attackers did not need to break cryptography, they needed to compromise one developer's machine through social engineering and exploit the gap between what a signer's screen displayed and what was actually being signed. A generic phishing test would never have surfaced that failure mode.
This guide sets out how to build a phishing simulation programme designed specifically for the operational realities of crypto and Web3 organisations: what scenarios to run, how to structure the programme, which metrics actually indicate behavioural change, how to handle repeat failures without becoming punitive, and how to select a platform capable of running crypto-native lures rather than generic corporate templates.
Why Generic Phishing Tests Fail Crypto Teams
Commercial phishing simulation platforms are built for the broadest possible market: fake password resets, fake HR announcements, fake shipping notifications, fake shared documents. These templates are useful for baseline awareness but they do not reflect the attack patterns that actually target crypto organisations. Attackers targeting Web3 firms have adapted their lures to the specific trust relationships and operational workflows unique to this industry, and a testing programme that ignores this adaptation will consistently understate real exposure.
Three structural differences separate crypto organisations from typical enterprises in ways that matter for simulation design.
Transaction authority is distributed and time-pressured
In most enterprises, a successful phish leads to credential theft or malware installation, both of which are recoverable if caught quickly. In a crypto organisation, a successful phish can lead directly to an irreversible on-chain transaction. Multisig co-signers, treasury operators and anyone with access to hot wallet infrastructure represent a category of high-value target that simply does not exist in the same form elsewhere, and they are frequently under time pressure to approve transactions quickly, which attackers exploit deliberately.
The attacker base includes state-sponsored actors
Nation-state groups, most notably North Korea's Lazarus Group, treat crypto firms as a primary funding target and have developed long-horizon social engineering techniques, including fake recruiter and venture capital outreach that can run for weeks before any technical payload is delivered. This is a materially different threat model from the opportunistic criminal phishing that generic platforms are built to simulate.
Hardware wallets create a false sense of immunity
Teams that have adopted hardware wallets and multisig often assume they have solved the phishing problem, since a stolen password alone cannot move funds. This assumption is dangerous. The Bybit incident demonstrated that attackers can manipulate what a signer sees and approves even when hardware wallets are used correctly, by compromising the software layer that constructs the transaction rather than the hardware itself. Simulation programmes need to test whether staff would catch this kind of discrepancy, not just whether they avoid entering a password on a fake login page.
The Bybit breach did not fail because the technology was weak. It failed because the human and process layer around a technically sound multisig setup gave way under a well-constructed social engineering attack. Simulation testing exists to find out whether that layer holds before an attacker finds out for you.
Crypto-Specific Phishing Scenarios: What to Test
A useful simulation programme runs a rotating library of scenarios that mirror real attacker techniques observed against crypto organisations. The following scenarios should form the core of that library.
Fake hardware wallet firmware update
An email impersonating Ledger, Trezor or a similar vendor, warning of a critical security vulnerability and urging an immediate firmware update via a link. This scenario tests whether staff verify vendor communications through official channels before acting, and it is one of the most effective real-world lures because it exploits the target's own security instincts against them: the message frames urgency as a safety measure.
Fake multisig co-signer approval request
A message, ideally delivered through the same collaboration tool the team actually uses, appearing to come from a fellow signer and requesting urgent approval of a pending transaction. This is the highest-value scenario for organisations running multisig or Safe-style contract wallets, and it directly mirrors the transaction-approval manipulation seen in the Bybit case. Track not just whether the target clicks anything, but whether they independently verify the transaction details through a separate channel before approving.
Fake exchange security alert demanding seed phrase verification
An urgent notification, styled to resemble a major exchange, claiming suspicious account activity and requesting the recipient "verify" their wallet by entering a seed phrase or private key on a lookalike page. This scenario tests the most basic and most catastrophic failure mode: any employee who would enter a seed phrase into a web form under any circumstance represents a critical training gap requiring immediate remediation.
Fake VC or recruiter outreach (the Lazarus technique)
A LinkedIn message or email from a fabricated venture capital associate or recruiter, offering a lucrative opportunity and eventually requesting the target run a "coding assessment" or install a "meeting application," a technique associated with North Korean state-sponsored campaigns and linked to breaches including the Ronin and Axie Infinity incidents. This scenario should be run against engineering and business development staff specifically, since they are the most common targets, and should test the multi-week patience of real campaigns rather than a single-touch email.
Fake Safe{Wallet} or Gnosis Safe UI notification
A spoofed notification, styled as coming from the Safe interface itself, alerting the user to a pending action or requiring re-authentication. Given how central Safe-style contract wallets have become to institutional crypto treasury operations, staff need to be conditioned to treat in-app notifications with the same scepticism as email, particularly following incidents where frontend compromise altered what was displayed to signers.
Internal impersonation for urgent transaction authorisation
A business email compromise variant in which an attacker impersonates the CFO or another executive, requesting an urgent, confidential transaction outside normal approval channels. This scenario tests whether financial controls hold up under authority pressure, independent of any wallet or blockchain-specific mechanics, and it remains one of the most common vectors for large fraudulent transfers across all industries.
Designing Your Phishing Simulation Programme
A one-off simulation exercise produces a snapshot, not a programme. Behavioural change requires a structured, ongoing cadence with clear governance.
Establish a baseline before changing anything
Run an initial round of simulations across all scenario categories without any preceding announcement or training, to establish an honest baseline click rate, credential submission rate and reporting rate. This baseline is the only fair comparison point for measuring future improvement, and skipping it makes it impossible to demonstrate programme value later.
Segment by role and transaction authority
Not every employee needs the same testing cadence or scenario mix. Segment the organisation into at minimum three tiers: general staff, staff with system or data access but no transaction authority, and staff with direct or delegated authority to move funds or approve on-chain transactions. The highest tier should receive the most frequent testing and the most sophisticated scenarios, reflecting the disproportionate impact of a failure in that group.
Set a realistic cadence
Monthly simulations across the organisation, with the highest-risk tier tested every two to three weeks, is a workable standard for most crypto firms. Testing too infrequently allows complacency to return between exercises; testing too frequently without varying scenarios trains staff to recognise the test rather than the underlying threat pattern.
Vary sophistication deliberately
Run a mix of obvious and highly sophisticated lures within each cycle. If every simulation is trivially detectable, the programme produces false confidence. If every simulation is maximally sophisticated, low performers become demoralised rather than educated. A blended difficulty curve, disclosed in aggregate but not in advance, gives the most honest signal.
Involve leadership as test subjects, not just sponsors
Executives and founders are frequently exempted from simulation programmes, often informally, which is precisely backwards given that they are disproportionately targeted by fake VC and business email compromise scenarios. Leadership participation, including public acknowledgement when a leader fails a test, is one of the strongest signals a programme can send about the seriousness of the effort.
Metrics Beyond Click Rates: Measuring Behavioural Change
Click rate is the easiest metric to capture and the least informative on its own. A comprehensive measurement framework should track several layers of behaviour.
Submission rate versus click rate
Separate the percentage of recipients who click a link from the percentage who go on to enter credentials, a seed phrase, or approve a fraudulent transaction. This distinction matters enormously in crypto contexts: clicking a link is a recoverable moment of curiosity, while submitting a seed phrase is an unrecoverable compromise. Programmes should track submission rate as the primary risk indicator and treat it as a near-zero tolerance metric regardless of the click rate trend.
Reporting rate
Track the percentage of recipients who report the simulated phish to security rather than simply ignoring or deleting it. A rising reporting rate is often a better leading indicator of programme maturity than a falling click rate, since it reflects active vigilance rather than passive avoidance, and it directly improves the organisation's ability to respond to real attacks quickly.
Time to report
Measure the median time between a simulated phish being sent and the first report received. In a real incident, this window determines how much damage containment is possible, so a shrinking time-to-report is a directly actionable operational metric, not just an awareness proxy.
Repeat-clicker concentration
Identify what proportion of total failures come from a small group of repeat offenders versus being broadly distributed. A programme where failures are concentrated in a handful of individuals has a different remediation path, targeted coaching, from one where failures are broad-based, which points to a systemic gap in the underlying security awareness training curriculum.
Scenario-specific performance
Break down performance by scenario type rather than reporting a single blended figure. An organisation might perform well against generic credential phishing but poorly against multisig approval scenarios, and that gap is invisible in an aggregate number but critical for prioritising remediation effort.
Remediation Workflows for High-Risk Clickers
How an organisation responds to a failed simulation matters as much as running the simulation itself. Punitive responses drive underreporting and resentment; the goal is behavioural correction within a psychologically safe framework, while still treating persistent failure in privileged roles as a genuine risk signal.
First failure: immediate, private micro-training
A single failure should trigger a short, targeted training module delivered privately, focused specifically on the scenario type that caught the individual out, delivered within hours rather than at the next scheduled training session. Immediacy matters for retention.
Second failure: one-to-one coaching
A repeat failure, particularly on a different scenario type, warrants a direct conversation with a manager or security team member to understand what led to the failure and address any underlying gaps, such as unclear escalation paths or excessive workload pressure that made the individual more susceptible.
Persistent failure in privileged roles: access review
For staff holding transaction authority, multisig signing rights, or administrative access to key infrastructure, persistent simulation failures should trigger a formal review of whether that access remains appropriate, independent of any disciplinary process. This is not a punishment; it is a risk management decision consistent with how the organisation would treat any other control failure, and it should be documented as part of the broader employee security vetting lifecycle rather than treated as a one-off event.
Positive reinforcement for reporting
Recognise and reward employees who correctly identify and report simulated phishing attempts, publicly where the individual is comfortable with that. Positive reinforcement for good behaviour is consistently more effective at shifting organisational culture than negative consequences for failure alone.
Platform Selection for Crypto Phishing Simulations
Most mainstream phishing simulation platforms were not designed with crypto-specific lures in mind, and firms need to evaluate vendors against a different set of criteria than a typical enterprise buyer would use.
Custom template support
The platform must allow fully custom email and landing page templates rather than restricting users to a fixed library, since none of the mainstream template libraries include hardware wallet, multisig, or exchange-alert scenarios out of the box. Confirm during evaluation that the platform can replicate the visual branding of the specific wallets, exchanges and internal tools your organisation actually uses.
Multi-channel delivery
Real crypto-targeted attacks increasingly arrive through Telegram, Discord, and LinkedIn rather than email alone. A platform limited to email simulation will miss an increasing share of the actual threat surface, so multi-channel capability, or a willingness to integrate with a custom-built delivery mechanism for these channels, should be a hard requirement.
Granular reporting and segmentation
The platform needs to support the role-based segmentation described earlier and produce the submission-rate, reporting-rate and time-to-report metrics discussed above, not just an aggregate click rate. If a platform cannot break results down by scenario type and employee tier, it will not support the measurement framework this programme depends on.
Integration with identity and HR systems
Automated enrolment based on role changes, new hires and access grants reduces administrative overhead and ensures no privileged employee falls outside the testing cycle. This is particularly important in fast-growing crypto organisations where headcount and access levels change quickly.
Integrating Simulation Into Your Security Awareness Programme
Phishing simulation should never operate as a standalone exercise disconnected from the rest of the organisation's security awareness programme. It works best as one instrument within a broader effort that also covers social engineering attacks more generally, operational security hygiene, and incident reporting culture.
Feed results into training curriculum design
Simulation data should directly shape what the awareness programme teaches next. If a large share of the organisation fails multisig approval scenarios, the next training cycle should focus heavily on transaction verification procedures rather than generic phishing awareness that the data shows is already well understood.
Align with onboarding
New hires, particularly those joining with transaction authority or privileged system access, should be enrolled in the simulation programme from their first week, not after an arbitrary probationary period. Early exposure normalises the testing programme as a standard part of the organisation's culture rather than an occasional audit.
Report programme metrics to the board
Simulation metrics belong in regular board or executive reporting alongside other security KPIs, framed in terms of risk reduction over time rather than as an isolated compliance exercise. This framing helps sustain budget and leadership attention for a programme that only demonstrates its value over a multi-year horizon.
Close the loop with incident response
Ensure the reporting mechanism used in simulations is identical to the one used for real suspected phishing, so that muscle memory built through simulation transfers directly to genuine incidents. A simulation programme that trains staff to use a different reporting channel than the real one undermines its own purpose.
Frequently Asked Questions
How often should a crypto firm run phishing simulations?
Monthly simulations are the practical minimum for crypto firms, given the pace at which attackers refresh lures. Treasury, engineering and executive assistant roles that can authorise transactions should be tested more frequently, often every two to three weeks, because the cost of a single successful compromise in these roles is disproportionately high.
What click rate should a mature crypto security programme target?
Mature programmes typically bring click rates below 5 percent within twelve months, with repeat-click rates near zero. The more meaningful target is credential or approval submission rate, which should approach zero regardless of click rate, since clicking a link is recoverable but submitting a seed phrase or authorising a transaction is not.
Should phishing simulations include fake multisig approval requests?
Yes. Any organisation using multisig wallets or Safe-style contract wallets should simulate fake co-signer requests, since this is one of the highest-value targets for attackers and one of the least tested scenarios in generic phishing platforms.
What happens to an employee who repeatedly fails phishing simulations?
Repeated failures should trigger escalating, non-punitive remediation: targeted coaching, role-specific scenario retesting, and for high-risk roles with transaction authority, a temporary review of access privileges. The objective is behavioural correction, not discipline, though persistent failure in a privileged role is itself a risk signal that needs a governance response.
Can off-the-shelf phishing simulation platforms handle crypto-specific scenarios?
Most mainstream platforms are built around generic corporate templates such as fake invoices or password resets and do not include hardware wallet, multisig or exchange-alert templates natively. Crypto firms generally need to build custom templates on top of a platform's scenario engine or work with a provider experienced in Web3-specific social engineering.