A one-time review checks whether the system was safe when it was assessed. Runtime monitoring checks whether the system is still safe after strategies, dependencies and permissions change. DeFi teams need both, but only runtime monitoring can track the moving attack surface that actually determines loss exposure.
Why the Difference Matters in DeFi Operations
A one-time security review is a snapshot. It can tell you whether contracts, integrations, permissions and assumptions looked acceptable at a point in time, but it cannot keep pace with protocol upgrades, liquidity changes, dependency shifts or governance actions that alter risk after launch. Runtime monitoring is the control that watches the system while it is live and continues to expose drift, abnormal behaviour and new attack paths.
That distinction matters because DeFi risk is not static. A protocol can be sound at audit time and still become unsafe if a new admin path appears, a dependency is upgraded, a price feed changes, or an external integration starts behaving differently. Runtime monitoring does not replace design review, but it is the only way to see whether the security assumptions that passed review are still true.
What a One-Time Review Actually Gives You
A one-time review is strongest before deployment or at a major change gate. It is useful for finding design flaws, logic errors, access-control mistakes, unsafe upgrade paths and obvious implementation weaknesses before real value is exposed. It also gives teams a basis for go-live decisions, remediation tracking and risk acceptance.
Its limitation is that it cannot observe the future. Once a protocol is deployed, the attack surface can expand through new pools, routes, bridges, privileged roles, oracle dependencies or third-party contracts. A review may remain valid as evidence of what was present then, but it does not prove that the current production state still matches the reviewed state.
What Runtime Monitoring Adds That Review Cannot
Runtime monitoring looks for changes and behaviour, not just code quality. It can surface unexpected privilege use, large parameter changes, failed invariants, unusual transaction patterns, dependency degradation and signs that an attacker is probing or abusing the protocol. For DeFi, this is especially important because value can move quickly and a small control failure can become a loss event within minutes.
Web3 and Crypto Security Guide is useful here because it frames DeFi defence around live compromise paths such as key compromise, bridge abuse and front-end defence, which are exactly the kinds of conditions that static review can miss once the system is active.
Monitoring is also where operational response becomes possible. If a review finds a risky upgrade model, the team can redesign it. If monitoring sees that an upgrade was executed, a role was expanded, or a dependency started failing in production, the team can act before the issue turns into exploitable exposure.
How to Use Both Without Confusing Their Roles
Use one-time review as the entry gate and runtime monitoring as the continuous control. Review answers whether the design should be trusted to launch or continue. Monitoring answers whether the live system still deserves that trust. Teams that rely on only one of the two usually fail in predictable ways: either they ship an unsafe design, or they keep assuming a previously safe design is still safe after the environment changes.
For DeFi, the most practical boundary is simple: review before you expose value, monitor after you expose value, and revisit the review whenever the protocol’s permissions, dependencies or economic paths materially change. That is the point at which the threat model itself has changed, not just the implementation details.
Risk and Threat Considerations
The main risk is treating a security review as if it were a standing assurance mechanism. In DeFi, permissions can expand, integrations can change and live market conditions can turn a previously acceptable design into a loss path. Attackers often wait for that drift, then target the new weak point rather than the original codebase.
Failure mechanism: The system changes after review, but the organisation continues to trust the old assessment instead of the current runtime state. That creates blind spots around privilege changes, oracle shifts, liquidity movement, dependency failures and attack sequencing that only live observation will reveal.
Impact: Losses can occur before the team notices the exposure, especially when the exploit path depends on fast-moving on-chain behaviour or a short-lived governance action. In practice, the absence of monitoring can turn a manageable defect into an unrecoverable incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | DeFi reviews and monitoring both hinge on whether access and privilege remain correct as state changes. |
| Recommendation — Verify that contract and admin paths enforce least-privilege authorization at every privileged action. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Runtime drift in DeFi often appears as unauthorized use of privileged functions or roles. |
| Recommendation — Audit privileged functions continuously and alert on unauthorized execution paths. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Runtime monitoring must detect abuse of legitimate credentials or keys after initial review. |
| Recommendation — Hunt for suspicious use of valid accounts or keys after deployment. | ||
| NIST CSF 2.0 | DE.CM-01 — Adverse event detection is performed | Runtime monitoring is the mechanism that detects changing conditions and hostile activity in production. |
| Recommendation — Deploy continuous monitoring to detect adverse events and risky state changes. | ||
Practitioner Guidance
What to verify: Treat the review as valid only for the state it actually covered. Verify that monitored signals include privilege changes, contract upgrades, oracle and dependency changes, and abnormal value movement, because those are the changes most likely to invalidate the original assessment.
Decision rule: If the protocol can change state, permissions or integrations after launch, do not rely on review alone for operational safety. Use runtime monitoring as the control that tells you when the reviewed assumptions are no longer true.
What good looks like: The team can show that every material change in live risk is either detected automatically or deliberately re-reviewed, and that alerts are tied to a response path rather than being treated as informational noise.
Practitioner takeaway: One-time review answers whether the system was acceptable then; runtime monitoring answers whether it is still acceptable now, which is the question that matters most once DeFi value is live.
Related resources from NHI Mgmt Group
- What is the difference between one-time GitHub access review and continuous access certification for code security?
- What is the difference between secure software development attestation and a one-time security review?
- What is the difference between continuous penetration testing and one-time security review for election technology?
- What is the difference between role-based access and API key governance for NHI security?