TL;DR: Infrastructure and operational compromises, rather than smart contract bugs, accounted for 74% of stolen crypto value in H1 2026, according to FYEO's analysis of Blockaid reporting. That shift means protocol security now depends on signers, deployments, third-party dependencies, and monitoring, not audits alone.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on FYEO's report: Infrastructure and operational compromises now account for most web3 crypto losses, with signers, deployments, shared services, and dependency chains emerging as the main failure points.
Why it matters: This matters because web3 teams that only harden contracts can still lose assets through compromised operational controls, which is an access and governance problem as much as a code problem.
By the numbers:
- 74% of stolen crypto value in H1 2026 resulted from infrastructure and operational compromises, according to FYEO.
- The number of incidents recorded in H1 2026 was approximately 3.4 times the total for all of 2025, according to FYEO.
Context
Web3 security is not limited to smart contract code. The operating environment around a protocol, including key custody, deployment pipelines, third-party services, and monitoring, can be the real point of failure when attackers target how systems are run rather than how they are written.
That matters because many web3 programmes still treat audit results as a proxy for security maturity. In practice, an exposed signer or weak dependency control can override a clean contract review, and that is where identity, privilege, and operational governance become inseparable.
Key questions
Q: What breaks when a web3 protocol does not govern signer access properly?
A: The protocol can still be drained or altered even when the smart contract code is sound, because attackers abuse the signing path rather than the logic. Once a signer is compromised, they can authorise transfers, upgrades, or configuration changes that bypass code-level protections. The failure is governance of privileged approval authority, not just application security.
Q: Why do compromised signers create more risk than isolated contract bugs?
A: A contract bug usually affects a specific code path, but a compromised signer can authorise many actions across the protocol. That turns one identity failure into broad operational power. In practice, the attacker gains a legitimate approval channel, which is harder to distinguish from normal use and often more damaging than a single exploit path.
Q: How can security teams tell whether dependency risk is being managed well in web3?
A: Look for a complete inventory of external services, explicit trust boundaries, and monitoring for changes in those dependencies. If a team cannot say which bridge, oracle, node provider, or shared platform could affect asset movement or uptime, then dependency risk is not under governance. Good management is visible in ownership, review, and change tracking.
Q: Should web3 teams rely on audits or continuous monitoring first?
A: Audits remain important, but they only prove a point-in-time view. Continuous monitoring is necessary when signers, dependencies, and deployments keep changing after release. Teams should use audits to validate architecture and monitoring to catch drift, because the highest-risk failures in this article come from operational change rather than static code defects.
Technical breakdown
Why compromised signers become the highest-value control failure
A compromised signer is an attacker-controlled approval path. In web3 systems, private keys, multisig signers, and delegated signing workflows can authorise transfers, upgrades, and configuration changes without needing a contract bug. Once a signer is abused, the attacker does not need to break the smart contract itself. The control failure is usually weak key protection, poor segregation of duties, or fragile operational processes around approvals and recovery. For identity teams, the parallel is clear: the signer is a high-risk non-human identity, and its authority must be lifecycle-managed like any privileged account. See the Web3 and Crypto Security Guide.
Practical implication: Treat signing keys and multisig roles as privileged identities with strict issuance, rotation, and approval governance.
How third-party protocols and shared infrastructure expand blast radius
Web3 applications rarely operate in isolation. They depend on bridges, oracles, node providers, identity services, and cloud-hosted components, any of which can become a propagation path if compromised. This creates supply chain risk at the protocol layer, where a trusted integration can be more dangerous than a direct exploit. Shared infrastructure also concentrates risk because one provider failure can affect many protocols at once. The architectural issue is not just dependency count, but dependency trust: each external service becomes part of the security boundary whether the team models it or not.
Practical implication: Map every external dependency to its operational trust boundary and review which ones can affect transaction integrity or uptime.
Why continuous onchain monitoring matters more than point-in-time audits
Audits are a snapshot, not a control plane. They can validate code and deployment assumptions at a moment in time, but they do not keep pace with changing signers, new integrations, or exposure that appears after release. Continuous monitoring closes that gap by tracking asset discovery, dependency changes, and anomalous onchain behaviour as the environment evolves. In governance terms, the question shifts from 'was this audited?' to 'what changed since the audit?' That is the right model for dynamic ecosystems where risk can materialise through configuration drift and operational change rather than code defects.
Practical implication: Use continuous monitoring to detect new exposure, changed dependencies, and suspicious transaction patterns after deployment.
Threat narrative
Attacker objective: The attacker aims to move assets or control protocol actions by abusing trusted operational authority instead of exploiting contract logic.
- Entry occurs through compromised signer credentials, insecure development environments, or another operational weakness that gives attackers approval authority.
- Escalation follows when the attacker uses that signing access to authorise malicious transactions, upgrades, or configuration changes.
- Impact is theft or manipulation of crypto assets across protocols that trusted the compromised operational path.
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.
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 has crossed from code risk into identity and operations risk. The report's central finding is that the dominant failure mode is no longer a contract flaw but a control failure around who or what can sign, deploy, or modify protocol behaviour. That is an identity governance problem as much as a blockchain security problem, because the approval path itself has become the attack surface. Practitioners should treat operational authority as the primary security boundary.
Signer governance is the new privileged access problem in web3. A compromised signer behaves like a stolen admin credential with transaction-level impact, and multi-signature designs only help when role assignment, approval thresholds, and recovery paths are governed tightly. The security question is not simply whether keys exist, but whether signing authority is scoped, monitored, and revocable in time. Practitioners should model signer lifecycle controls as privileged access controls, not as wallet administration.
Third-party dependencies create a hidden trust chain that many teams still under-model. Bridges, oracles, node services, and shared infrastructure can all extend the blast radius beyond the code a team directly owns. That means security reviews need dependency inventory, trust boundary mapping, and incident assumptions for upstream compromise. Practitioners should assume the protocol inherits the weakest operational link in its ecosystem.
Continuous monitoring is now a governance requirement, not an optional detection layer. The report shows that exposure can emerge after deployment through changed signers, outdated components, or new integrations, so one-time audit confidence decays quickly. That creates what we would call post-audit exposure drift: the widening gap between a static assurance event and a live, changing operational reality. Practitioners should govern for drift, not just for release readiness.
What this signals
Web3 security programmes need a control model that treats signing authority as live privileged access. The operational lesson is that approval power can be more dangerous than the code it authorises, especially when keys are reused across environments or recovery paths are not rehearsed. Practitioners should govern signer issuance, rotation, and revocation with the same discipline they apply to privileged human access.
Post-deployment assurance is now the weak point in many protocols. A clean audit can be undone by a compromised dependency, an outdated deployment, or a changed approval path the next day. The programme response is to shift from release-centric security to change-centric security, where exposure drift is detected as part of day-to-day operations.
For practitioners
- Implement signer lifecycle governance Inventory every signing key, multisig role, and delegated approval path, then assign owners, review cadence, and revocation rules.
- Map protocol dependencies and trust boundaries Document every bridge, oracle, node provider, identity service, and shared component that can affect transaction integrity or availability.
- Replace audit-only assurance with continuous monitoring Track changes in exposure, signer behaviour, dependency drift, and anomalous onchain activity after deployment.
- Harden deployment and recovery controls Separate development, approval, and production permissions, and test recovery paths for compromised credentials and malicious upgrades.
Key takeaways
- Web3 loss events are increasingly driven by operational control failures rather than direct contract exploitation.
- Compromised signers, shared infrastructure, and vulnerable dependencies widen the blast radius beyond the code a team audits.
- Protocols need lifecycle governance and continuous monitoring because assurance decays quickly after deployment.
Related NHI Mgmt Group resources: Web3 and Crypto Security Guide · Smart Contract Security Guide · Risk-Based Vulnerability Management Guide · OWASP Top 10 A09 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 NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Signer compromise turns signing authority into overprivileged machine access. |
| NHI-09 — NHI Reuse | Shared signing paths and reused operational identities widen the blast radius across environments. | |
| Recommendation — Scope signer authority narrowly and remove any approval path that exceeds its intended transaction role. Eliminate reused signing paths across environments and assign distinct identities to critical operational roles. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The threat pattern centres on stolen approval authority and movement across trusted dependencies. |
| Recommendation — Map signer compromise and dependency abuse to credential access and lateral movement tactics in detection planning. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about weak control over who can approve protocol actions and infrastructure changes. |
| Recommendation — Review entitlements for signer roles and external dependencies under PR.AA-05. | ||
| CIS Controls v8 | CIS-5 — Account Management | Operational compromise is driven by weak lifecycle control over privileged approval accounts. |
| Recommendation — Apply account management controls to signing roles, recovery accounts, and delegated approvals. | ||
Key terms
- Signer: A signer is the identity or key used to authorise a blockchain transaction, upgrade, or configuration change. In operational terms, it functions like privileged approval authority. If a signer is compromised, the attacker can act through legitimate trust rather than breaking the code itself.
- Onchain Monitoring: Onchain monitoring is the continuous observation of blockchain activity, asset exposure, and dependency behaviour to detect risk as it changes. It is not a one-time audit. In practice, it helps teams spot anomalous transactions, new integrations, and drift in operational trust boundaries.
- Dependency Mapping: Dependency mapping is the process of identifying which systems, services, and workflows rely on a given identity or secret. It is critical for NHI rotation because teams need to know what will fail before they change credentials. Without it, security teams often delay remediation to avoid outages.
- Post-Audit Exposure Drift: Post-audit exposure drift is the gap that develops when a system changes after an audit and the assurance no longer reflects the live environment. It captures the reality that deployments, approvals, and dependencies evolve continuously. Security governance must therefore monitor change, not just certify snapshots.
Deepen your knowledge
The NHI Foundation Level course covers NHI governance, secrets management, and workload identity for practitioners who need to manage privileged access beyond human users. It is designed for security teams that must govern machine-level approval paths as part of a wider identity programme.
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