TL;DR: Crypto losses fell 57% to approximately $972 million in H1 2026, but the number of security incidents hit a record high as attackers shifted toward more frequent and varied exploitation, according to FYEO. The pattern shows Web3 risk is becoming more distributed and operationally broad, not less dangerous.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on FYEO's report: Crypto losses fell 57% to approximately $972 million in H1 2026 even as security incidents reached a record high, signalling a more distributed Web3 threat environment.
Why it matters: This matters because crypto and Web3 teams cannot treat lower aggregate losses as proof that risk is improving when attack frequency, attack diversity, and operational exposure are all rising.
By the numbers:
- Crypto losses fell 57% to approximately $972 million in H1 2026.
- The number of security incidents reached an all-time high in H1 2026.
Context
Web3 security is not defined only by the size of individual thefts. When aggregate losses fall while incident counts rise, the governance problem shifts from headline prevention to broad exposure management across code, infrastructure, users, and operational controls.
FYEO's data points to an environment where attackers are no longer relying mainly on a few large exploits. The practical issue for security teams is that a wider attack surface creates more chances for smaller failures to become repeatable loss events.
Key questions
Q: How should Web3 teams respond when incident frequency rises but losses fall?
A: They should not treat lower losses as proof that controls are working. Rising incident frequency usually means attackers are finding more entry points, even if each event is smaller. Teams need to prioritise surface reduction, faster detection, and stronger identity and key governance across the full stack, not just better smart contract review.
Q: Why do front-end and dependency weaknesses matter as much as smart contract bugs?
A: Because they often give attackers a path to the user, the wallet, or the project team before any contract logic is touched. That makes them governance issues, not just engineering issues. If the delivery chain is weak, a perfect contract can still be reached through a compromised interface or package.
Q: What are the first controls to prioritise in a Web3 security programme?
A: Start with the controls that reduce access abuse and repeatable compromise: MFA, least privilege for operational accounts, dependency review, and monitoring for unusual transaction behaviour. Those measures reduce the chance that a small compromise becomes a scalable loss event across multiple services or wallets.
Q: What is the difference between on-chain security and Web3 operational security?
A: On-chain security focuses on the contract and protocol logic itself. Web3 operational security covers the people, tools, dependencies, wallets, front ends, and access paths that attackers often exploit first. Teams need both, because a secure contract can still be undermined by a compromised operational environment.
Technical breakdown
Why incident frequency can rise while losses fall
A falling loss total does not mean the threat is easing. In distributed attack environments, adversaries may shift from a small number of high-value exploits to many lower-value intrusions that are harder to detect and interrupt. That changes the operating model for defence: success is no longer measured only by preventing a single major drain, but by reducing the number of exploitable opportunities across the environment. In Web3, those opportunities can sit in smart contracts, front ends, developer workflows, dependencies, or user-facing authentication paths. The important point is that frequency itself becomes a signal of control weakness, even when the average size of each event is smaller. Practical implication: track incident density alongside loss totals to avoid false reassurance from a lower headline number.
Practical implication: Measure attack frequency, not just total losses, when deciding whether Web3 controls are improving.
How front-end, dependency, and social engineering risk expands the attack surface
The article points beyond smart contract flaws to the operational stack around them. Front-end weaknesses can redirect legitimate user intent into malicious transactions, third-party dependencies can propagate compromise across multiple projects, and social engineering can expose accounts or keys without touching on-chain logic at all. This is why Web3 risk is increasingly a system problem rather than a contract-only problem. If teams only audit code deployed on-chain, they miss the paths attackers use to reach those contracts in the first place. The governance challenge is to treat build pipelines, web interfaces, developer access, and vendor dependencies as part of the same trust boundary. Practical implication: extend assurance beyond contract code to the full delivery and interaction chain. See the Web3 Developer Operational Security Guide.
Practical implication: Audit the full delivery chain, including front-end code, dependencies, and team access paths, not just smart contracts.
Why operational discipline now matters as much as code quality
The article's strongest signal is that attack variety is increasing. That means prevention depends on layered controls, including stronger authentication, tighter access management, monitoring for anomalous behaviour, and rehearsed incident response. In practice, the gap is often not technical awareness but operational consistency: the same environment that may have a solid audit process can still fail if teams keep keys on developer machines, trust third-party integrations too broadly, or lack rapid containment playbooks. Web3 security is therefore converging with identity governance, because many attacks are really about access paths to wallets, accounts, and operational tooling. Practical implication: align security operations, identity controls, and treasury governance under one threat model. See the Crypto Exchange Identity and Key Security Guide.
Practical implication: Bring identity controls, monitoring, and incident response into the same operating model as protocol security.
Threat narrative
Attacker objective: Attackers seek repeatable access to funds, accounts, or transaction flows rather than only one-off smart contract exploitation.
- Entry often begins through social engineering, dependency compromise, or front-end manipulation rather than a single smart contract flaw.
- Credential or key access then gives attackers the ability to authorise transactions, export data, or pivot into project infrastructure.
- Escalation occurs when that access is reused across wallets, services, or governance workflows, allowing repeated theft or manipulation.
- Impact is cumulative loss, user distrust, and a broader erosion of confidence in the Web3 ecosystem.
Breaches seen in the wild
- Lottie Player npm compromise 2024: A compromised developer npm token let attackers publish three Lottie Player versions that pushed a crypto wallet drainer to websites.
- Mailchimp breach 2022: Attackers socially engineered Mailchimp staff, used a support tool to export 102 customer lists and exposed customer API keys for phishing.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Web3 security is shifting from concentration risk to dispersion risk. The article shows that fewer catastrophic losses can coexist with more total incidents, which means the control problem is no longer only about stopping one major exploit. Teams need to understand the distribution of smaller failures across wallets, front ends, dependencies, and user workflows. Practitioner conclusion: security posture has to be judged by attack surface breadth, not just loss magnitude.
Front-end and dependency compromise are now first-class governance issues in crypto security. The article explicitly moves beyond smart contract flaws, and that matters because many Web3 failures begin before any on-chain action occurs. A malicious package, compromised UI, or manipulated user flow can be just as damaging as a contract bug. Practitioner conclusion: treat the delivery chain as part of the trusted security boundary.
Identity and key governance are the real pressure points behind many Web3 incidents. The need for MFA, strong access controls, and team security practices shows that many losses begin with compromised human or machine access rather than protocol failure alone. This is where Web3 security intersects with crypto exchange identity and key security and with broader NHI governance. Practitioner conclusion: manage wallets, signers, and operational accounts as privileged identities.
Proactive controls matter more when attackers diversify their methods. When incidents become more frequent and less uniform, reactive defence loses effectiveness because teams cannot rely on a single exploit pattern. That pushes monitoring, audits, and incident response from supporting functions to core governance controls. Practitioner conclusion: build a security programme that can absorb varied attack paths without waiting for the next headline exploit.
From our research library:
- Organisations that rely heavily on static credentials reported a 20-percentage-point increase in security incidents compared with those with low reliance, according to the 2026 Infrastructure Identity Survey.
- Read next: Cybersecurity Statistics Guide
What this signals
Web3 programmes now need a broader trust boundary than smart contract review alone. The practical lesson from the article is that incident reduction will come from shrinking the number of places where attackers can intercept users, code, or keys. That means front-end assurance, dependency control, and operational account governance need to be managed together rather than as separate workstreams.
Distributed attack patterns demand distributed governance. When losses are spread across more incidents, a single control domain cannot carry the whole defence strategy. Security teams should plan for identity, treasury, development, and monitoring teams to share one operating view of risk, because the attack path increasingly crosses all four.
For practitioners
- Expand assurance beyond smart contracts Review front-end code, integrations, and third-party dependencies as part of the same security boundary as on-chain logic.
- Harden key and wallet access paths Treat operational wallets, signers, and administrative accounts as privileged assets with MFA, least privilege, and rapid revocation procedures.
- Increase detection for low-and-slow abuse Instrument monitoring to spot repeated smaller anomalies, unusual transaction patterns, and suspicious dependency behaviour before they accumulate into larger loss.
- Rehearse incident response across the full stack Test containment steps for compromised keys, malicious packages, and phishing-driven account takeover, including who can freeze activity and how quickly.
Key takeaways
- The core risk is no longer just large-scale theft. It is the growing number of smaller Web3 incidents that collectively weaken the environment.
- FYEO's data shows that losses fell even as incident count reached a record high, which is a warning sign rather than a sign of recovery.
- Security teams need to widen the control scope beyond smart contracts to include front ends, dependencies, identities, and incident response.
Related NHI Mgmt Group resources: Web3 and Crypto Security Guide · Web3 Developer Operational Security Guide · Cybersecurity Statistics Guide · Crypto Exchange Identity and Key Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while CSA Cloud Controls Matrix and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Operational wallets, signers, and accounts behave like privileged identities in this crypto environment. |
| NHI-07 — Long-Lived Secrets | The article's focus on keys and account compromise maps directly to long-lived credential exposure. | |
| Recommendation — Reduce standing privilege for wallets and admin accounts, and revoke access paths that exceed task scope. Shorten secret lifetime for operational credentials and rotate anything that can be reused after exposure. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes access-driven compromise patterns that lead from initial entry to broader reuse. |
| Recommendation — Map crypto incident patterns to credential access and lateral movement to prioritise detection and containment. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article stresses access controls, MFA, and privileged account governance in cloud and platform operations. |
| Recommendation — Use IAM controls to enforce MFA, least privilege, and rapid revocation across operational accounts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article's access-control emphasis aligns with entitlement governance for accounts and tools. |
| Recommendation — Review entitlements for wallets, developers, and admin tooling against PR.AA-05 and remove excess access. | ||
Key terms
- Web3 Operational Security: Web3 operational security is the set of controls that protect the tools, people, dependencies, and access paths used to run blockchain-facing systems. It extends beyond smart contract code to the environments where keys, admin privileges, and transaction workflows can be compromised.
- Front-end Vulnerability: A front-end vulnerability is a weakness in the user-facing interface that can redirect, alter, or expose a legitimate interaction with a blockchain application. It matters because attackers can exploit the interface even when the underlying contract logic is sound.
- Supply Chain Attack: A supply chain attack is a breach that targets a trusted third party to reach its customers or partners. Attackers compromise software vendors, service providers, updates, dependencies, or managed access paths, then use that trust to spread malware, steal data, or gain persistent access across many environments.
- Operational Wallet: An operational wallet is a cryptocurrency wallet used to receive, move, or manage funds for an ongoing campaign or activity. In illicit finance investigations, it often sits between donation addresses and downstream services, making it a useful point for clustering, attribution, and tracing.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity controls to the wider security programmes their environments depend on.
Published by the NHIMG editorial team on October 27, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org