Crypto and Web3 companies get attacked differently than mainstream SaaS. A bug in a checkout flow costs a retailer some fraud losses and an afternoon of cleanup. A bug in a smart contract, a bridge, or a custody wallet can drain funds in minutes, publicly, with no chargeback and no way to claw the money back. That asymmetry is why penetration testing for this sector needs to look different from a standard web app assessment, and why generic testing is not enough.
Why the stakes are different
Traditional web applications fail gracefully most of the time. Crypto and Web3 systems often fail catastrophically. A handful of factors make the sector a distinct threat category:
- Irreversibility. On-chain transactions cannot be reversed. There is no fraud department to call, no bank to freeze the wire.
- Public attack surface. Smart contracts are often deployed with source code visible on-chain or verified on a block explorer. Attackers can read your logic before they ever touch your infrastructure.
- Composability risk. Web3 products integrate with wallets, oracles, bridges, and other protocols. A vulnerability in a dependency becomes your vulnerability.
- Regulatory pressure. Exchanges, custodians, and stablecoin issuers increasingly face compliance obligations that require demonstrable security testing, not just a checkbox audit.
- High-value targets. Treasury wallets, bridge contracts, and custody infrastructure hold liquid value that draws organized, well-funded attackers, not opportunistic scanners.
The result is a threat model where a single missed authorization check or an unvalidated signature can be the difference between a normal Tuesday and a headline. Testing needs to reflect that.
What we actually test
A crypto or Web3 engagement is rarely just a web app scan. Depending on what you have built, scope typically spans several layers:
- Web and API surfaces. The dashboard, admin panels, and REST or GraphQL APIs that front your platform, tested the same way we test any production web application, for injection, broken access control, and logic flaws.
- Wallet and key management flows. How keys are generated, stored, rotated, and authorized. This is where custody incidents actually happen, far more often than an exotic contract exploit.
- Smart contract and on-chain logic. Reentrancy, integer handling, access control on privileged functions, oracle manipulation, and upgrade mechanisms if the contract is proxy-based.
- Infrastructure and cloud. Node operators, RPC endpoints, hot wallets, and the cloud environment hosting your backend services, reviewed with the same cloud and network testing methodology we apply across every engagement.
- Bridge and cross-chain logic. If your product moves value across chains, that boundary gets dedicated attention. It is one of the most exploited attack surfaces in the sector.
All of it is human-led. Automated scanners catch a fraction of what matters in a codebase where a logic error, not a missing patch, is usually the root cause of a real incident. Our testing is led by Jacob Masse, a published security researcher with six CVEs to his name, including CVE-2024-45163, a CVSS 9.1 finding that functioned as a kill-switch against the Mirai botnet. That is the kind of adversarial thinking crypto infrastructure needs: someone who has found and weaponized real vulnerabilities, not just run a checklist.
For engagements that need deeper offensive depth, particularly contract-level exploitation or red-team style attack chains, we co-deliver with our offensive-security partner Lorikeet. You get one point of contact and one report, backed by two teams with complementary specializations.
How we scope it
Scoping starts with a conversation about what you have built and what is actually at risk. A DeFi protocol with a live treasury needs a different test plan than an NFT marketplace or a custodial exchange. We typically walk through:
- What is on-chain versus off-chain, and where the trust boundaries sit between them
- Whether contracts are audited already, and by whom, so we are not duplicating work
- What custody model you use, self-custody, multisig, or third-party custodian
- What compliance driver is behind the engagement, if any, since evidence requirements differ
- Timeline pressure, particularly around mainnet launches or major upgrades
From there we build a scope document that names exactly what gets tested, what does not, and what a pass or fail looks like for each component. No surprise line items, no vague "we'll look around" language.
One test, two purposes
A lot of crypto and Web3 companies are also working toward compliance certifications, either because a bank partner requires it, an institutional client demands it, or a regulator is asking questions. The same penetration test that finds real vulnerabilities also produces the documented evidence auditors expect for SOC 2 and PCI DSS engagements. Rather than running one test for security and a separate one for the auditor, you get a single engagement that satisfies both. If compliance is part of your roadmap, our broader security testing services are built around that dual purpose from the start, and it is worth reviewing our compliance advisory work if you are mapping out a certification timeline alongside the testing.
What you get at the end
Every engagement ends with a report written for two audiences: your engineers, who need reproducible steps and remediation guidance, and your leadership or auditors, who need a clear risk summary they can act on or hand to a partner. We do not pad reports with informational findings to look thorough. If something is not exploitable and not a real risk, we say so.
If your platform touches on-chain value, custody, or bridges, the cost of a missed vulnerability is not theoretical. Contact us to talk through your architecture and get a scoped proposal for a penetration test built for how crypto and Web3 systems actually get attacked.