Recidivism is the repeated return of a previously banned or restricted actor under a new identity. In fraud and Trust & Safety programmes, it usually indicates that enforcement removed an account but not the underlying device, workflow, or operator infrastructure.
Expanded Definition
Recidivism describes a pattern where a blocked, suspended, or banned actor returns under a new identity and resumes the same harmful behaviour. In Trust & Safety, fraud prevention, and identity operations, the term is less about the new account itself and more about the persistence of the underlying operator, device, network, payment trail, or automation stack. That makes recidivism a behavioral and infrastructure problem, not just a moderation outcome.
Definitions vary across vendors and platforms, but the core security meaning is consistent: an enforcement action has failed to disrupt the actor’s ability to re-enter the system. NHI Management Group treats recidivism as a signal that identity controls, device intelligence, and abuse detection are not sufficiently linked across sessions or lifecycle events. The concept is adjacent to ban evasion, but recidivism is broader because it includes repeat re-entry after fraud, policy abuse, or account takeovers, not only direct violation of terms.
Authoritative governance language in the NIST Cybersecurity Framework 2.0 supports the operational idea that response actions must reduce recurrence, not merely stop a single incident. The most common misapplication is treating recidivism as a simple username reuse problem, which occurs when teams only compare account attributes and ignore device, payment, and behavioral continuity.
Examples and Use Cases
Implementing recidivism controls rigorously often introduces friction for legitimate users, requiring organisations to weigh stronger abuse disruption against false positives and user experience costs.
- A banned marketplace seller returns with a fresh email address, but the same browser fingerprint, payout destination, and shipping pattern reveal the same operator.
- A spam account is removed, then recreated through a new phone number and IP address, while shared automation scripts and timing patterns link the activity to the prior cluster.
- An account farming ring rotates identities after enforcement, yet reuse of device enrolment, cookie state, and recovery channels exposes a persistent infrastructure chain.
- A gaming platform detects repeated chargeback abuse where each new profile looks unique, but linked payment methods and behavioural similarity indicate the same fraud group.
- A OWASP Non-Human Identity Top 10 perspective becomes relevant when bots or scripts are the repeat offender, because the operator can recycle service accounts, API keys, or automation identities after each takedown.
Why It Matters for Security Teams
Recidivism matters because it measures whether enforcement has actually changed attacker cost, or only forced a re-registration event. If teams cannot connect identities across resets, they may overestimate the effectiveness of bans, suspensions, and account closures while the same actor continues to exploit the platform. That gap is especially important in identity-centric environments, where weak linkage between people, devices, sessions, and non-human identities allows persistent abuse to hide behind new credentials.
For security, fraud, and Trust & Safety teams, recidivism should influence control design, case management, and escalation paths. It often points to missing telemetry, weak graph linkage, incomplete device reputation, or insufficient step-up verification after high-risk actions. In agentic AI and NHI-heavy environments, the same issue appears when automated agents, service accounts, or API clients can be recreated faster than controls can attribute them. The NIST Cybersecurity Framework 2.0 is useful here because it frames response as a cycle of containment, recovery, and continuous improvement rather than one-time removal. Organisations typically encounter recidivism only after repeated bans fail to reduce abuse, at which point identity correlation 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 surface, NIST CSF 2.0, NIST SP 800-63 and NIST AI RMF set the technical controls, and EU AI Act define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RS.MA-1 | Response outcomes should be monitored to see whether incidents repeat after enforcement. |
| OWASP Non-Human Identity Top 10 | NHI-4 | NHI abuse often recurs through recycled service identities, tokens, or automation. |
| NIST SP 800-63 | IAL2 | Identity proofing strength affects how easily a blocked actor can re-enrol under a new identity. |
| NIST AI RMF | AI RMF governance helps manage repeat misuse when AI-assisted abuse can reappear quickly. | |
| EU AI Act | Where AI systems enable repeat abuse, the Act reinforces governance around risk and oversight. |
Bind enforcement to device and workload signals so non-human identities cannot be cheaply reissued.