Cybersecurity Due Diligence for Crypto Projects: What Investors Should Check

Dmytro MatviivCEO HackenProof

12 Minutes ReadPublished: 15 Oct 2026

Cybersecurity Due Diligence for Crypto Projects: HackenProof banner with glass discs showing code, server, lock and search icons leading to a blockchain cube protected by a shield.

Security is the part of crypto due diligence most likely to decide whether an investment survives. Hacken's 2025 Yearly Security Report counted about $4 billion in Web3 losses in 2025, 40% more than in 2024. Most of that money wasn't lost to bad code. It was lost through compromised keys, signers, and infrastructure.

That changes what due diligence has to cover. An audit report is a good start, but it only describes the code that was reviewed, on the day it was reviewed. The project you fund or list will keep shipping code, rotating keys, and hiring people long after that.

This guide explains what cybersecurity due diligence means for crypto projects and walks through the seven areas to check before you invest, list a token, or integrate a protocol. It ends with a checklist you can use on your next deal.

What Is Cybersecurity Due Diligence in Crypto?

Cybersecurity due diligence in crypto is the process of checking a project's smart contracts, key management, infrastructure, and incident history before you invest in it, list its token, or integrate with it. The goal is to find out how the project could lose funds and whether it can prevent or survive that loss.

The idea comes from traditional M&A, where buyers review a company's IT security before a deal. Crypto raises the stakes in four ways:

Funds sit on-chain. A project's treasury and user deposits are often controlled directly by code and keys, not by a bank.
Transactions are irreversible. There are no chargebacks. Recovery depends on negotiation, freezes or luck.
The code is public. Attackers can study a protocol for months before they strike.
One key can be enough. If a single admin wallet controls upgrades or the treasury, stealing that key means stealing everything.

This is different from the AML and KYC checks that also get called "crypto due diligence." Those screen customers and transactions for financial crime. Security due diligence asks a different question: can this project keep its own funds and its users' funds safe?

The people who run it include crypto funds and angel investors, exchange listing teams, launchpads and incubators, and protocols vetting a partner, bridge or oracle before integrating.

Why Security Is the Deal-Breaker

Most crypto losses come from operational failures, not from flawed smart contract code. Hacken's breakdown of 2025 losses shows how lopsided the split is:

Attack type	Losses in 2025	Share of total
Access control exploits	$2.12B	53.0%
Phishing and social engineering	$952M	23.8%
Smart contract vulnerabilities	$512M	12.8%
Rug pulls	$317M	7.9%
Other	$100M	2.5%

Attack type

Losses in 2025

Share of total

Access control exploits

$2.12B

53.0%

Phishing and social engineering

$952M

23.8%

Smart contract vulnerabilities

$512M

12.8%

Rug pulls

$317M

7.9%

Other

$100M

2.5%

The pattern held in 2026. In Q2 2026, Hacken traced 88.3% of $763.9 million in losses to compromised keys, signers and infrastructure. Smart contract bugs appeared in 44 of the quarter's 67 incidents but caused only about 11% of the losses.

Two examples show both sides of the risk:

Bybit, February 2025: $1.465 billion. The largest theft on record came from an operational compromise of the signing process, not a contract bug. Hacken attributes it to North Korea's TraderTraitor group.
Balancer V2, November 2025: about $128 million. A rounding error in a battle-tested, heavily audited protocol was enough to drain pools across several chains.

For an investor, a loss like this rarely stays with the project. It shows up as a collapsed token price, a drained treasury, a delisting, or a legal dispute. That is why security deserves the same weight in due diligence as the team, the market, and the tokenomics.

Smart Contract Audits: What to Check

An audit is evidence that the code was reviewed, not proof that it's safe. Hacken's 2025 report notes that several of the year's largest DeFi exploits hit projects that had been through multiple audits, and newer protocols such as Bunni and Arcadia Finance were drained despite theirs. Your job is to judge how much an audit actually tells you.

Who audited the code, and how many times

Start with the auditor's track record. Look for published reports, a public portfolio, and a history of findings on protocols similar to the one you're reviewing. High-value protocols should have more than one independent review.

Also ask how the audit was run, because private, crowdsourced, and combined audits give different coverage. A hand-picked team goes deep on a fixed scope, while a crowdsourced review puts many more researchers on the same code.

How to read a smart contract audit report

Three details in the report matter more than the summary page:

Scope. Check which contracts were reviewed. Core logic, upgrade contracts, and token contracts should all be in scope. A narrow scope can make a clean report meaningless.
Commit hash. The report should name the exact version of the code it covers. Compare it with the code deployed on-chain. If they differ, the deployed code wasn't audited.
Date. Compare the audit date with the project's upgrade history. Any major upgrade after the audit needs its own review.

Findings and fix status

Every finding should have a status. "Resolved" means the team fixed it and the auditor verified the fix. "Acknowledged" means the team accepted the risk and left it in the code. Ask why for each acknowledged finding.

Open critical or high-severity findings are a stop sign until they're fixed and re-checked. It also helps to see which classes of smart contract vulnerabilities the auditors tested for, such as access control, oracle manipulation and arithmetic errors.

Red flags in an audit report

The auditor has no public track record or portfolio
Core contracts are listed as out of scope
No fix review was done after the findings
The audit predates the last major upgrade
The team will only share the report privately, or only a summary

If the project hasn't been audited at all, an independent smart contract audit should be a condition of your investment or listing.

Ongoing Security: Bug Bounty and Vulnerability Disclosure

An audit is a snapshot; a bug bounty keeps testing the code after every deploy. A project that runs one is paying independent researchers to find flaws before attackers do, which is the clearest sign it treats security as ongoing work.

The scale can be significant. In the first half of 2026, 217 security researchers tested 1inch Aqua through its bounty program, and 9 findings earned payouts. No internal team or single audit puts that many eyes on a codebase.

When you review a project's bug bounty program, check:

Whether it's active. A program announced at launch and quietly closed later doesn't count.
Scope. The deployed contracts, frontend and APIs should all be covered, not only a test deployment.
Critical reward size. Rewards should make sense next to the funds at risk. A $10,000 cap on a protocol holding $200 million won't attract serious researchers.
Payout history. Paid reports show the program works and the team fixes what's found.
Response times. Ask how long it takes to triage a report and ship a fix.

Even projects without a bounty should have a public disclosure channel, such as a vulnerability disclosure policy or a security.txt file. If a researcher has no safe way to report a bug, the next person who finds it may not report it at all.

Bug bounties also complement other testing rather than replacing it, because bug bounties and penetration tests catch different problems on different schedules.

Admin Keys, Upgradeability and Access Control

Whoever controls a project's admin keys controls its funds, so this is where the largest and least recoverable losses happen. Access control exploits made up 53% of 2025 losses in Hacken's data.

Start by mapping every privileged action in the protocol and who can trigger it:

Upgrading contracts or swapping the logic behind a proxy
Pausing the protocol or freezing user funds
Minting tokens or changing supply
Changing fees, collateral factors, oracles, or other parameters
Moving treasury funds

For each action, find out whether it sits behind a single wallet, a multisig, a timelock, or a governance vote. A single wallet controlling any of these is a serious red flag.

Multisig is necessary, not sufficient

A multisig spreads control across several signers, but it only helps if those signers are independent and well protected. Hacken's report warns that multisig fails when signers sign from everyday laptops or when a vendor's interface can change what is actually signed.

Recent incidents prove the point. In the UXLINK breach in 2025, compromised signers let attackers take over admin functions and mint trillions of tokens. In Q2 2026, a multisig takeover at Drift Protocol cost $285 million.

Check the threshold, how many signers are truly independent, whether they use hardware wallets, and whether signing happens on a dedicated device that isn't used for email, chat, or code.

Timelocks and ownership claims

A timelock delays upgrades and parameter changes, giving users and monitoring tools time to react. Ask how long the delay is and which actions it covers.

If the team says ownership has been renounced, verify it on-chain. Contracts sometimes keep a hidden admin role, an upgradeable proxy, or a privileged function that survives the renouncement.

Questions to ask the founders

Which actions can change user balances or move funds, and who can call them?
What is the multisig threshold, and who are the signers?
How are signing devices protected, and when were they last reviewed?
Which actions sit behind a timelock, and for how long?
What happens if one signer is compromised tomorrow?

The answers should match what you can verify on-chain. Strong teams treat key management as part of their wider smart contract security program, not as an afterthought.

Dependencies: Oracles, Bridges and Third-Party Protocols

A project is only as secure as the systems it relies on. Even well-audited code can be drained through a price feed, a bridge, or a forked library it doesn't control.

Ask the team for a full list of external dependencies:

Price oracles. Which feeds set collateral values and liquidations? A protocol that trusts a single, thinly traded pool can be manipulated, often with flash loan attacks that borrow the capital needed for a few seconds.
Bridges. Bridges hold large pools of locked assets and are frequent targets. In Q2 2026, a cross-chain bridge breach at KelpDAO cost $292 million.
Other protocols. Lending markets, DEXs, and yield sources the project deposits into or builds on.
Forked code and shared libraries. A bug in the original code or a shared math library carries over to every fork.
Custody and infrastructure providers. Wallet providers, RPC nodes, and signing services.

For each one, ask what happens to user funds if it fails, is paused, or is exploited. Look for circuit breakers, multiple price sources, and limits on how much value can flow through any single dependency.

Projects that run their own chain or bridge need deeper review than a smart contract audit alone, such as a Layer 1 protocol audit of the consensus and networking layers.

Infrastructure and Operational Security

This is the area most due diligence checklists skip, and it's where most of the money is lost. Hacken attributes $2.1 billion of 2025 losses to operational security failures, and notes that the attackers behind most access control breaches "don't hack smart contracts; they hack operational processes and weak endpoint security."

People are the main attack surface

North Korean groups, linked to about 52% of 2025 losses, rely almost entirely on social engineering. Hacken's report describes two playbooks every investor should know:

Fake job interviews. Developers get recruiter messages for well-paid roles, then are asked to run a "skills test" that installs wallet-draining malware.
Fake VC calls. Founders and executives are invited to video calls by people posing as venture capitalists. An "audio issue" prompts them to install a malicious fix. Hacken says this group alone took nearly $200 million in 2025.

The second playbook impersonates investors, so your own outreach is part of the threat model. Ask how the team verifies who they're talking to, and expect them to ask the same of you.

What to check

Device security. Are signing and admin tasks done on dedicated devices, separate from email, and chat?
Access management. Who has access to cloud accounts, CI/CD pipelines, domain registrars, and deployment keys? Is access reviewed when people leave?
Frontend and DNS. Is the website protected against DNS hijacking and malicious script injection, which can trick users into signing harmful transactions?
Wallet architecture. For exchanges and custodians, how much sits in hot wallets versus cold storage, and how are withdrawals approved?
Security training. Do staff know how to spot phishing, fake recruiters, and fake support calls?

Ask for the results of recent penetration tests of web, mobile, and API systems. Smart contract audits don't cover this layer, and attackers know it.

Incident History and Response Readiness

A past incident isn't automatically a red flag; how the team handled it tells you more than the incident itself. A project that disclosed quickly, published a clear post-mortem, and made users whole may be safer than one with a spotless but untested record.

Past incidents

Search for every exploit, outage, or security disclosure tied to the project and its contracts. For each one, find out:

How quickly the team disclosed it
Whether a detailed post-mortem was published
Whether users were reimbursed, and how
What changed afterwards: new audits, new controls, new people

Recovery is sometimes possible. After GMX V1 lost $42 million in July 2025, the team negotiated a bounty with the attacker and about 90% of the funds were returned. That outcome depended on fast, public engagement, which is a skill you want to see before an incident, not after.

Response readiness

Ask the team to walk you through what happens in the first hour of an exploit:

Is on-chain activity monitored in real time, with alerts?
Can the protocol be paused, and who can pause it?
Is there a written incident response plan, and has it been rehearsed?
Who is on call, and which security firms can they reach immediately?

Team reputation

Check the people as well as the code. Review the founders' previous projects, both their public history and their on-chain activity. Search their names alongside terms like "exploit", "rug pull," and "scam". Talk to people who have worked with them before. A team with a track record of abandoned projects or unexplained token sales deserves a closer look.

Token Contract and Tokenomics Red Flags

A token's contract can hide risks that the whitepaper never mentions. Rug pulls alone accounted for $317 million in 2025 losses, and many of them were visible in the code before they happened.

In the token contract

Start with the verified source code on a block explorer. If the contract source isn't published, stop there. Then look for:

Unrestricted minting. Can an owner or admin create new tokens at will?
Owner-controlled fees or blacklists. Can someone raise transfer fees to 100% or block specific wallets from selling?
Transfer restrictions. Hidden conditions that let users buy but not sell are a classic honeypot pattern.
Upgradeable token logic. If the token sits behind a proxy, every rule above can change after you invest.

In the distribution

How concentrated are holdings among the top wallets?
Are team and investor allocations locked and vested, and is that enforced on-chain?
Is liquidity locked, for how long, and who controls it?

In the tokenomics document

A credible tokenomics document should explain the token's utility, how demand is created, the full distribution and vesting schedule, how inflation is controlled, and which chains the token lives on. Vague answers on any of these are worth pressing on before you commit capital.

Cybersecurity Due Diligence Checklist

Use this checklist on any crypto project before you invest, list its token or integrate with it.

Area	What to request or verify	Red flag
Audits	Full audit reports from independent firms	No audit, or only a summary shared privately
Audits	Audit scope and commit hash vs deployed code	Core contracts out of scope, or deployed code differs
Audits	Status of every finding after the fix review	Open critical or high findings
Audits	Audit dates vs upgrade history	Major upgrade with no new audit
Bug bounty	Active program, scope, reward size, payout history	No program, or rewards far below funds at risk
Disclosure	Public disclosure policy or security.txt	No safe way to report a bug
Admin keys	Map of privileged functions and who can call them	A single wallet controls upgrades, minting or treasury
Admin keys	Multisig threshold, signer independence, signing devices	Signers share devices or sign from everyday laptops
Admin keys	Timelocks on upgrades and parameter changes	Instant upgrades with no delay
Dependencies	List of oracles, bridges and integrated protocols	Single-source price feed or unreviewed bridge
Infrastructure	Recent penetration test of web, mobile, and APIs	Never tested outside the smart contracts
Infrastructure	Access controls for cloud, CI/CD and domains	Shared accounts, no access reviews
Incidents	Past incidents, post-mortems, reimbursements	Hidden or unexplained past exploits
Response	Monitoring, pause mechanism, incident response plan	No plan, no one on call
Token contract	Verified source, mint and fee controls, transfer rules	Unrestricted minting or sell restrictions
Distribution	Holder concentration, vesting, liquidity locks	Unlocked team tokens or unlocked liquidity

Make Security a Condition of the Deal

Due diligence tells you where a project stands today; the terms of your deal decide where it goes next. Investors and listing teams have the most leverage before money moves, so that's the moment to set security expectations.

Budget for it. Ask founders to include audits, a bug bounty, and penetration testing in their capital deployment plan, with real numbers attached.
Require a live bounty before mainnet or listing. Make an active program with meaningful critical rewards a precondition, not a roadmap item.
Require re-audits after major upgrades. New code needs new review, especially upgrades to core contracts or the token.
Agree on key management standards. Set minimum multisig thresholds, timelocks, and signing-device rules.
Ask for incident reporting. Founders should tell you about security incidents within an agreed time, not after they reach the news.
Make introductions early. Connect portfolio companies with vetted security vendors before they need them in a hurry.

Regulators are moving the same way. Hacken's 2025 report finds that regimes such as MiCA in the EU and state licenses in the US increasingly treat security, custody, and independent assurance as licensing prerequisites. Projects that build this in early are easier to list, insure, and scale.

One practical option is to pair a primary audit with a crowdsourced review on top of a third-party audit, then keep researchers testing through a bounty after launch. Large exchanges take the same layered approach: OKX built its security framework with HackenProof to protect more than 50 million users.

Conclusion

Cybersecurity due diligence in crypto goes well beyond asking whether a project has been audited. The largest losses come from keys, signers, infrastructure and people, so a credible review checks all of them, along with the code.

The projects worth backing can show their audits, run a live bug bounty, protect their admin keys, and explain how they would respond to an exploit. Book a call with HackenProof to plan audits and a bug bounty program for your portfolio companies or listing candidates.

FAQ

What is cybersecurity due diligence?

Cybersecurity due diligence is the process of assessing an organization's security before a deal, such as an investment, acquisition, listing or partnership. In crypto, it covers smart contract audits, admin key management, infrastructure, third-party dependencies, incident history and token contract risks.

How is crypto security due diligence different from KYC/AML due diligence?

KYC and AML due diligence screens customers and transactions for financial crime, such as money laundering or sanctions exposure. Security due diligence checks whether a project can protect its own funds and its users' funds from hackers, insiders and operational failures. Most investors and exchanges need both.

Is a smart contract audit enough before investing?

No. An audit covers specific code at a specific point in time, and most crypto losses come from compromised keys, signers and infrastructure that audits don't review. In Q2 2026, Hacken traced 88.3% of losses to these operational failures. Look for audits, a live bug bounty and strong key management together.

How do you check whether a crypto project has been audited?

Ask for the full audit reports and confirm them on the auditor's own website or public portfolio. Then compare the commit hash in the report with the code deployed on-chain, and check that the audit is newer than the project's last major upgrade.

What are the biggest security red flags in a crypto project?

The biggest red flags are a single wallet controlling upgrades or funds, open critical audit findings, no bug bounty or disclosure channel, unverified contract source code, unlocked team tokens or liquidity, and past incidents the team won't explain.

How long does security due diligence take?

A first-pass review using a checklist can take a few days if the team shares documents promptly. A deeper review, including independent verification of contracts, keys and infrastructure, usually takes several weeks, depending on the project's size and complexity.