A delisting threshold is a predefined condition that tells a platform when support for an asset must be paused or removed. It turns vague concern into an operational control by linking measurable changes such as reserve failure, de-pegging, or scam exposure to a formal decision.
Expanded Definition
A delisting threshold is the point at which a platform, exchange, or governance body stops supporting an asset because a predefined risk condition has been met. In practice, it converts subjective concern into an enforceable rule tied to measurable signals such as reserve shortfalls, repeated de-pegging, sanctions exposure, fraud indicators, or loss of operational transparency. The concept is common in finance and digital-asset governance, but definitions vary across vendors and venues because no single standard governs this yet. In NHI-adjacent discussions, the same pattern applies to unsupported tokens, service assets, and delegated credentials when their trust assumptions no longer hold.
This is not the same as a warning threshold. A warning threshold triggers review; a delisting threshold triggers an action that removes or suspends support. That distinction matters because governance teams need a clear decision boundary, not a loosely interpreted alert. For risk framing, the NIST Cybersecurity Framework 2.0 is useful for mapping such thresholds to risk response and governance outcomes. The most common misapplication is treating a delisting threshold as an informal guideline, which occurs when teams fail to tie the trigger to a documented control owner and an execution deadline.
Examples and Use Cases
Implementing a delisting threshold rigorously often introduces operational friction, requiring organisations to weigh fast containment against the cost of false positives and market disruption.
- An exchange delists a token after reserve evidence repeatedly fails to meet published coverage ratios, with the decision anchored to a written risk policy rather than ad hoc escalation.
- A platform pauses support for an asset after on-chain activity shows scam clustering or sanctioned-wallet linkage, using the threshold to separate investigation from enforcement.
- A governance team sets a delisting threshold for custodial assets whose attestations are not refreshed on schedule, drawing a hard line between stale assurance and acceptable risk.
- Security operations apply the same logic to non-human access when a service credential cannot be rotated or verified, a pattern discussed in the Ultimate Guide to NHIs.
- Policy owners reference NIST Cybersecurity Framework 2.0 to align the threshold with incident response, containment, and recovery workflows.
These examples show that the term is less about market preference and more about operational control. A threshold only works when the evidence source, the approver, and the downstream action are all defined in advance. In governance-heavy environments, vague language such as "review for possible delisting" is usually insufficient because it does not force a timely decision.
Why It Matters in NHI Security
Delisting thresholds matter in NHI security because unmanaged support decisions create hidden exposure: stale assets stay trusted, compromised credentials stay active, and teams keep integrating what should already have been removed from service. The same governance failure pattern appears in identity estates where 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage, according to the Ultimate Guide to NHIs. That statistic is especially relevant here because a delisting threshold is ultimately a containment mechanism. It defines when confidence is low enough that continued support becomes the riskier choice.
For NHI programs, the issue is not only technical compromise but also governance drift. If thresholds are unclear, teams delay action, exceptions multiply, and support decisions become political rather than risk-based. A well-governed threshold supports Zero Trust by forcing revalidation when trust assumptions fail, while also giving operators a defensible rule for offboarding or suspension. Organisational teams often recognise the need for a delisting threshold only after an asset has already been exploited or publicly exposed, at which point the threshold becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Defines governance patterns for lifecycle decisions on non-human assets and credentials. |
| NIST CSF 2.0 | GV.RM-01 | Risk management decisions must be governed by defined thresholds and response criteria. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires continuous re-evaluation when trust assumptions are no longer valid. |
Reassess support and access whenever evidence shows an asset no longer meets trust requirements.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
