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.
Why falling losses can still mean the attack surface is growing
Lower losses do not automatically mean the environment is safer. In Web3, incident frequency often tells you whether adversaries are finding more entry points, even when each event is contained faster or causes less direct value loss. That pattern usually points to better blast-radius limits, but also to a broader and more active exposure surface that still needs reduction.
The practical question is whether the team is shrinking the number of ways in, or merely getting better at limiting the damage after entry. If the latter is true, losses can fall while the underlying control gap remains and the next incident can still scale badly.
Teams should interpret repeated smaller incidents as a signal to revisit exposure, assumptions and control coverage across contracts, front ends, custody paths and developer workflows. A good framing is to treat frequency as a surface indicator and loss severity as a containment indicator, not as substitutes for one another.
What rising incident frequency usually says about controls
When incidents become more common, attackers are usually probing more seams, more dependencies or more operational paths than before. That can include exposed keys, front-end compromise, weak approval flows, third-party dependencies, unsafe deployment practices or poor identity hygiene around admin and automation paths. Stronger review of one layer, such as smart contracts alone, rarely closes all of those paths.
For Web3 teams, the important shift is from “How much did we lose?” to “How often are we being forced to respond, and where are the repeated entry points?” If the same class of event keeps recurring, the control problem is structural, not just tactical. That is why surface reduction matters alongside faster detection and response.
The NHIMG Web3 and Crypto Security Guide is useful here because it keeps the focus on key compromise, bridge abuse, front-end defence and incident response as a connected control set rather than isolated issues.
Incidents that get cheaper without getting rarer often indicate partial containment, not durable security improvement. The team may be recovering faster, but attackers are still able to test the perimeter, abuse trust assumptions or reuse the same access path in slightly different ways.
How to respond: reduce surface, improve detection, govern keys and identities
The right response is to tighten the full attack path, not just the most visible component. That means reducing externally reachable exposure, limiting privileged access, reviewing key and token lifecycle rules, and instrumenting detection so that misuse is visible before loss becomes material. In Web3 environments, identity and key governance matter because compromise often starts with a credential, token or signing path before it becomes a protocol-level event.
Teams should also separate remediation goals. Surface reduction lowers the number of chances an attacker gets. Detection shortens dwell time. Identity and key governance limits what a single compromise can authorize. If those three are not improving together, incident counts can remain high even while average loss declines.
The NHIMG Web3 Incident Response Playbook helps because it reflects the operational reality that Web3 incidents need clear triggers, roles, pauses, freezes and post-mortems, not ad hoc reaction after value has already moved.
The NHIMG Lottie Player npm compromise 2024 is a reminder that adjacent software supply-chain paths can become the entry point, so the response has to include developer access, publishing credentials and dependency trust, not only on-chain code review.
For a broader practitioner view, the NHIMG The State of NHI & AI Agent Breach Report 2026 shows why leaked API keys, stolen tokens and compromised service accounts are recurring breach mechanisms across modern stacks, which is directly relevant when Web3 teams are trying to decide where to harden first.
What good looks like when losses fall but incidents rise
Good practice is not to celebrate lower losses in isolation. A mature team should expect incident frequency to decline over time as exposure is reduced, while the median time to detect and contain also improves. If frequency stays high, the team should demand evidence that each event is materially different, not just numerically smaller.
What to measure: Track incident frequency by attack path, time to detection, time to containment, and the share of incidents linked to credentials, keys, front-end compromise, dependency abuse or privilege misuse. That gives a better view of whether the team is shrinking the real attack surface or simply absorbing more small events.
Decision rule: If losses are falling but recurring incidents point to the same access pattern, prioritise control redesign over isolated incident tuning. If the incidents are truly diverse, use the pattern to identify which part of the stack is easiest for attackers to re-enter and close that path first.
Practitioner takeaway: Falling loss figures are only reassuring when they are paired with fewer successful entry attempts, less repeatable exposure, and stronger control over the credentials and trust paths attackers keep reusing.
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, OWASP API Security Top 10 and MITRE ATT&CK define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Repeated Web3 incidents often start with exposed keys or tokens. |
| NHI-05 — Overprivileged NHI | Losses can fall while excessive signing or admin privilege still expands blast radius. | |
| NHI-07 — Long-Lived Secrets | Rising incident frequency can reflect stale credentials that attackers keep reusing. | |
| Recommendation — Scan for exposed secrets and remove them from code, logs, CI and public repos. Reduce NHI permissions to the minimum needed for each workflow and contract action. Rotate and shorten credential lifetimes so stale tokens cannot be reused indefinitely. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Web3 front ends and service APIs often fail through weak authentication or token abuse. |
| Recommendation — Harden authentication paths and require strong, verifiable session or token validation. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | The answer centers on stolen keys, tokens and other credential paths into Web3 systems. |
| Recommendation — Hunt for exposed credentials and treat them as active intrusion opportunities. | ||
Related resources from NHI Mgmt Group
- How should incident teams respond when a threat actor may be operating during a blackout or network disruption?
- How should compliance teams respond when a regulator ties MFA failures to incident reporting gaps and certification risk?
- How should compliance teams respond when a state-sponsored actor uses web3 infrastructure to bypass sanctions and move stolen assets?
- How should web3 teams combine audit, monitoring, and incident response to reduce attack exposure before deployment?